Whale Rider 2012: об интеграции управленцев интернет-проектами и правильном общении с заказчиками

24 – 25 сентября в Москве, в конференц-центре «Инфопространство» проходит ежегодная профессиональная конференция по управлению интернет-проектами «Whale Rider 2012».

В этом году в качестве определяющей идеи конференции был предложен слоган «Все вместе!», провозглашающий интеграцию управленцев всех стадий жизненного цикла интернет-продукта. По замыслу организаторов, выступления докладчиков будут рассматривать все ступени жизненного цикла производства программного продукта, каждый «со своей колокольни», чтобы в результате стало понятно, что только объединившись и решив проблемы объединения, можно выпускать качественные продукты для своих пользователей, радуя их и получая в ответ положительный фидбэк.

Секцию анализа и проектирования открыл генеральный директор UsabilityLab Дмитрий Сатин докладом об управлении ошибками. «Как совершить все ошибки, и когда их можно еще исправить».

Ведущий российский юзабилити-специалист убежден в том, что ошибки неизбежны, более того, они нужны для того, чтобы понять, а туда ли движется все предприятие.

По словам Дмитрия, не бывает проектов без ошибок, так или иначе какое-то их количество так и так будет допущено, и с этим нужно смириться. Вместо того, чтобы бесполезно сетовать и бояться допустить эти самые ошибки, нужно научиться управлять временем возникновения ошибок в проекте, дабы они допускались только тогда, когда их еще можно исправить.

Что же является обычно источником ошибок? Как ни странно это так называемые «тараканы» в голове, которые есть у каждого из нас. Мало кто из руководителей, давая задание исполнителю задумывается об этом, а ведь восприятие у всех людей разное, и если исполнитель не озвучит свое видение поставленной проблемы, работодатель, ожидая выполнения ее в требуемом формате, зачастую бывает неприятно удивлен результатом.

Дмитрий призывает организовывать некие на первый взгляд несерьезные игры на начальной стадии проекта, позволяющие всем участникам процесса проговорить и обсудить свои задания, скорректировать их под цели и задачи проекта. Иногда подобное обсуждение страхует проект от весьма серьезных ошибок, которые, будучи незамеченными на ранних стадиях, становятся критичными на стадиях завершающих.

Секцию разработки открыл доклад ведущего веб-программиста отдела технологического развития компании «Заказные ИнформСистемы» Виталия Филлипова с провокационным названием «Мода на коробки и фреймворки в вебе – доколе?»

Виталий негодовал на менеджеров, которые для разработки не самых простых проектов выбирают коробочную CMS, платят за нее, отстегивают за хостинг ежемесячно миллионы, а потом, пока программисты пытаются совладать с ее недостатками, продолжают защищать свой выбор, говоря, что «инструмент-то отличный, его-то всего лишь надо немного подкрутить и допилить».

Докладчик признался, что испытывает стойкую неприязнь к любым CMS , потому что предполагается, что на этих движках можно сделать все. Но надо смотреть правде в глаза – такого инструмента не существует, когда бы можно было создавать сайты любого уровня сложности, не владея программированием и основами php.

По словам Виталия, все эти CMS общего назначения – ужасные монстры. Они сложные и неэффективные, с кривой архитектурой, оптимизированной «для всего» и в то же время ни для чего. В них куча ненужного функционала. А платить за это все приходится клиенту – деньгами продавцу коробки, деньгами хостеру, деньгами подрядчикам при доработках, репутацией в глазах своих клиентов. А все дело в том, что если инструмент универсален настолько, то он абсолютно невменяем. Это такой закон природы.

Когда реально применять CMS? Когда проект простой – она не нужна, ибо это все равно, что палить из пушки по воробьям, а если проект сложный, то возможностей CMS наверняка не хватит, а плохая архитектура усложнит их реализацию. Докладчик считает, что только средним проектам, которые не планируют никакого роста, можно использовать коробочные решения, а если проект собирается расти, то лучше сразу же писать движок под себя и все.

Больше всех от ругательного докладчика досталось Битриксу. Но и фреймворки ему тоже не угодили. И CMS и фреймворки Виталий обвинил в том, что они родились из одного желания – создать и продавать продукт, который вроде-бы-все-может-решить, а также в том, что и то и другое настолько вошло в моду, что люди почти не задумываются о куче проблем, которые они получают с выбором таких инструментов.

Далее в рамках секции выступил Анатолий Стояновский, директор отдела разработки программного обеспечения РИА Новости, с докладом «Управление разработкой портфеля проектов в гетерогенной корпоративной среде».

РИА Новости – это новостное агентство, и отдел разработки ПО по этой причине вынужден разрабатывать множество софта inhous. В команде несколько десятков программистов, которые работают на более 50 сайтов, и постоянно создают новые. Компания не софтверная и является сама себе заказчиком. Проекты в основном однотипные с инновационной составляющей, а также в компании всегда есть тенденция к авралам.

Анатолий сообщил, что когда в компании есть небольшое количество проектов и внутренних заказчиков, то волей неволей все начинают понимать друг друга и говорить на одном языке. А когда количество заказчиков растет, то появляется такая вещь, как противоположные представления и оценки реалий IT-разработки. Для того, чтобы как-то управлять этим хаосом, нужно разделять понятия проекта и продукта. Многие путают эти два понятия.

Проект – это инструмент управления продуктами. Это по науке. А в привязке к практике это выглядит так: продукт постоянно куда-то развивается и движется, и вокруг этого создаются проекты, которые наслаиваются друг на друга и являются источником этого самого хаоса.

Производство новостей является процессом непрерывным. Новости это такой продукт, который постоянно требует создания каких-то проектов, – в этом и заключается отличие от работы в коммерческой студии, коммерческая студия от какого-то заказа может отказаться, а у разработчиков РИА Новости такой возможности нет, они должны обслуживать всех внутренних заказчиков.

Еще одна проблема – это плохо определимые цели конечных проектов. IT-часть сталкивается с какими-то косвенными целями, которые следуют из больших каких-то целей, им не известных. Нужно ставить отдельные цели для программистов, чтобы они не находились где-то в конце производственной цепочки, дабы не определять свою цель интуитивным образом, исходя из целей большого проекта.

Также не хочется под каждый проект выделять отдельную команду. Не нужно создавать конкуренцию проектов за ресурсы – а это большая проблема.

Совмещение проектных и процессных подходов, дублирование и изобретение велосипедов командами, фрагментация знаний и опыта разработчиков, черные ящики и сакрализация, – это все мешает общей эффективной работе.

По словам докладчика, помочь может введение должности корпоративного архитектора, который будет контролировать все горизонтальные направления развития. Также можно создать некоторые макрокоманды, которые могут быстро перехватить знамя и в случае того самого автобусного эффекта, могут быстро помочь и продолжить выпуск продукта. Группировка взаимозаменяемых разработчиков в кластерах – это хороший выход.

Анатолий считает, что для того, чтобы сохранить единый уровень качества разработки, минимизировать бюрократию, не допустить раздувания штата, уменьшить затраты на переключение программистов, исключить простои и сделать корреляцию проектов управляемой, нужна методология PMBOK, в которой описываются все процессы управления проектом, 42 процесса – от инициации до завершения.

Но разработчики предпочитают agile-методики. В принципе активности этих методик однозначно входят в процессы PMBOK. РИА Новости идут по пути сращивания этих двух методик. PMBOK – верхняя часть описания проектов, agile – для внутреннего использования программистами.

Продолжил работу секции разработки Павел Емельянов, архитектор в департаменте серверной виртуализации Parallels, с докладом «Легко ли продавать контейнеры на базаре?».

В своем докладе Павел рассказал о том, как Parallels внедряла технологию контейнерной виртуализации в ядро. О методах кнута, пряника и много чего другого в работе с Linux-сообществом.

Докладчик сообщил, что основной способ общения в сообществе – электронная почта. Этот способ очень удобен, т.к. позволяет охватить большое количество участников. Он компенсирует разницу во времени. Это удобно, не только потому, что разработчики, привносящие что-то в Linux, зачастую находятся на разных часовых поясах. Способ также дает возможность подумать и сформулировать свои мысли тем, кому сложно это делать в режиме реального времени в силу например не важного владения языком. Кроме того, этот способ дает возможность хранить архивы переписки и рассылок.

Но одно дело, когда люди обмениваются идеями через почту, а другое дело, когда они общаются лицом к лицу. Здесь очень помогают конференции, где происходит вербальный обмен идеями. Происходит развиртуализация тех, кто присылает свои письма и свой код. Это также дает возможность преодоления языкового барьера. Иногда бывает, что из-за плохого английского, некоторые фразы по почте могут быть восприняты другими разработчиками неправильно, а когда все участники при личной встрече узнают, этого человека, то они сразу же поймут, что этот было сделано или сказано не со зла.

Итогом внедрения этого способа стало то, что количество людей, которое в таком смысле срослось с комьюнити, выросло от 1 до 10 человек. Разработчиков Parallels приглашают на разные конференции, они на хорошем счету у монтейнеров. В целом – отлично!

Докладчик уверен, что эта модель в миниатюре представляет собой модель любого аутсорс-проекта. Это пример того, как можно все это заставить функционировать.

О всех превратностях и тонкостях открытия удаленного офиса разработки рассказал Артем Кудзев, заместитель директора R&D 2ГИС, представив доклад, основанный на опыте компании, у которой основной центр разработки находится в Новосибирске, есть центр разработки в Киеве и удаленные разработчики в Германии и еще нескольких городах России.

Артем рассказал, что нужно делать, когда стартап сталкивается с проблемой того, что требуются новые кадры, но рынок уже полностью профильтрован и все правильные люди уже работают в компании, перекупать – дорого, а аутсорсинг – ненадежно.

Решение заключается в том, чтобы открыть офис разработки там, где нужные люди есть.

Докладчик описал опыт организации удаленного офиса разработки в Киеве и дал множество дельных советов, при выборе региона:

-Изучить список учебных заведений в рассматриваемом регионе,

-Важный критерий – наличие профессиональных комьюнити, конференций и профильных тусовок,

-Есть ли в регионе кузницы кадров. Большие компании, которые обучают студентов и отпускают их дальше. Это большой плюс компаниям, которые берут оттуда людей, у которых уже есть какой-то бэкграунд за спиной.

Артем также обозначил, что можно отдавать такому офису в разработку:

-Можно отдать продукт целиком или проект целиком.

-Можно отдавать на разработку только некоторые фичи, некоторые части проектов, причем самодостаточные, чтобы общение с основным офисом сводилось к минимуму. Выяснилось, что они действительно смогли взять на себя весь продукт.

-Узкая специализация.

По словам Артема, для успешного функционирования удаленного офиса очень важна команда. Для того, чтобы команда работала, нужен главный человек, который донесет культуру компании в новую команду, он будет проводить финальные собеседования, арендовать офис и вообще всем заправлять.

После открытия офиса, первой задачей этого «отца» становится – найти «мать». Мать – это человек, который должен быть местным, и отвечать за хранение офисного очага.

Дальше нужны бойцы. Артем сказал, что они пробовали нанимать людей с опытом – но они обычно не приживались, т.к. их было тяжело изменять. Люди должны быть компанейскими, здесь даже не так важны технические скилы, лучше набирать джуниоров.

Управление в удаленном офисе может быть централизованным, децентрализованным и смешанным. В киевском офисе 2Гис децентрализованное управление, потому что у компании есть четкая задача – чтобы удаленный офис работал автономно.

Далее Артем рассказал о том, что нужно учитывать при открытии удаленного офиса, и без чего все труды могут пойти прахом – это и разница в менталитете, и разница во времени, обычаях, праздниках и т.д.

Когда удаленный офис создан, работает, налажены все проекты, можно все так и оставить. Можно сделать некое самостоятельное предприятие – нанять туда продакта, создать продакт-тим, и на базе Киева можно сделать не один продукт, а несколько. А если все плохо и не окупается, то можно все расформировать и начать где-нибудь в другом месте.

Секцию «Тестирование» открыла Ольга Павлова с докладом «Качество продукта через управление проектом: что конкретно делать менеджеру».

В начале своего выступления Ольга высказала спорную мысль о том, что если команда понимает что делать, то в общем-то руководитель ей и не нужен (зал стал возмущаться и не соглашаться).

Ольга продолжила обзором теорий управления, какие они бывают. По ее словам, теории сами по себе никогда не взлетают, можно их изменить, можно как-то на себя примерить, но больших результатов достигнуть не удастся.

Что же нужно внедрить менеджеру? Управление качеством, потому что количество случится и само по себе. В каждый конкретный момент времени о качестве никто не думает, потому что это такая вещь, которая видится всем где-то далеко-далеко. Вырасти изнутри оно не может, это надо двигать снаружи.

Для улучшения качества продукта, докладчица предложила три способа:

1 способ – послушать, что говорит начальство и сделать так, как оно говорит. Качество по отмашке сверху будет похоже на качество как у кого-то – у Эппл, у Вольво и т.д.

2 способ – положиться на коллег-профи. В любой компании есть лидеры по качеству, которые убьются, но свой кусок работы сделают хорошо. Чем это поможет менеджеру? Такой правильный профи сможет построить своих коллег. Если в команде такие люди есть, и даже если они неприятны, они могут сделать за менеджера то, чего не сможет сделать он сам.

3 способ – один на один. Тут есть два пути развития событий. Надо начинать с эволюционного пути – почитать немного теории, собрать понравившиеся тезисы, инвентаризовать то, что хотелось бы сделать, написать это на бумаге и потихоньку начать это внедрять. Ольга ратует за эволюционный путь развития, она уверяет, что никакой революции не случится, окружающих просто надо потихоньку задалбывать и все.

Здесь важно наличие веры в качество, в его важность. Пока менеджер не будет обращать внимание на какой-то предмет, он не станет предметом управления. На качество надо всегда обращать внимание, это должна быть практически религия качества. Управление – это фокус на определенных предметах.

Что надо делать? Надо стать пользователем своей системы, надо стать пользователем системы конкурентов, надо стать за плечом реального пользователя и смотреть на то, что он делает с вашим продуктом или с его аналогами, поработать пару дней в саппорте, почитать на блогах и форумах про свой продукт. – Это неплохо промывает мозг, и делать это нужно постоянно. Если этого не делать, то критерии качества размываются и о нем уже не может идти и речи.

Далее Ольга перечислила, какие неприятности встречаются в процессе управления проектами и как с ними справляться:

1. Главный враг – маркетинговое мышление, которое делает так, что пользователи начинают восприниматься как стадо баранов. Как от этого абстрагироваться? Вам самим приятно, когда к вам самим применяют маркетинговое мышление? Не делайте людям то, что вам самим неприятно.

2. Всегда существует торговля за время, всегда кажется что нельзя успеть за какое-то время что-то сделать хорошо. Мы не знаем качество продукта, который только-только появился, но хотим знать, когда же и чем это все закончится. Очень важно, чтобы продукт сформировался, а потом уже его отпускать в мир.

3. Важно всегда держать у себя в голове пункты сдачи-приемки. Всегда организовывать этот процесс, это очень важно для качества.

4. Контроль – это работа. Очень важно организовать проверку результатов. Контроль, напоминание, уточнение – это конкретная работа менеджеров. И она очень нужна.

5. Много – не значит хорошо. Много букв в ТЗ – это хороший способ запутать всех и запутаться самому.

6. Авральнй метод. Возвращаясь к своему жизненному опыту, мы еще раз отмечаем, что лучшие результаты бывают тогда, когда работа идет равномерно, а не в авральном режиме. Поэтому лучше всего организовывать какие-то постоянные сверки, общие собрания по проекту, это практика, которая часто спасает.

7. Нужно поощрять содержательные инициативы. Это довольно трудно, потому что чаще всего это формулируется как «эти идиоты все сделали неправильно». Но иногда можно таких людей присоединить к инициативной группе и посмотреть что будет.

8. Плохую работу не принимать ни под каким видом. Не спускаем троечникам, потому что это очень плохо действует на отличников.

9. Еще одна проблема выглядит так- если у менеджера вдруг появилась срочная задача для исполнителя, его просят сделать это срочно, он это делает, а все это откладывается в долгий ящик и не реализуется. Это безответственно поставленная задача. И в следующий раз такой исполнитель ничего делать не захочет. Поэтому просим делать только то, за что несем ответственность…

Разговор об эксплуатации и тестировании продолжила Евгения Фирсова, руководитель отдела веб-интерфейсов Яндекс.Деньги, представив доклад «Демонстрируем результаты заказчику: how to и how to not. Быть можно дельным человеком и думать о красе ногтей».

В начале своего выступления Евгения предложила слушателям вспомнить фильм «Самая обаятельная и привлекательная» и сказала, что как бы мы не пытались убедить себя в том, что наш продукт обаятельны й и привлекательный, таковым он станет только после того, как придет заказчик и скажет, что да, нам все нравится, продукт отличный.

Любому продукту, по словам докладчицы, не помешает легкий макияж, и к его презентации нужно готовиться.

Готовиться, выбирая нужный момент. Первая версия перед передачей в тестирование должна преподнести заказчику то, что он хотел увидеть, надо сделать ее так, чтобы живой вариант не разочаровал его. А разработчик должен сверить свое общее понимание с заказчиком.

Когда проект достиг промежуточной стадии, заказчик хочет видеть и чувствовать прогресс, а разработчик – получить конкретный фидбэк на уровне «здесь хорошо, здесь плохо – а здесь поправьте вот так».

Финальная версия перед релизом: заказчик хочет убедиться в готовности к публичному анонсу, а разработчики хотят получить формальную отмашку на запуск.

Евгения уверена, что заказчику нужно показывать только то, что заказывалось, и ничего больше. Очень важно заказчиков не обманывать и не показывать им то, чего не было. Лучше прятать поддерживающие процессы, эмулировать неработающие или недоступные компоненты, подменить динамику статикой.

Нужно учитывать контекст и понимать, что люди, которые приходят на отсмотр, это как всегда какая-то группа людей, каждый из которых сосредотачивается на своем:

Дизайнер смотрит на пикселы и отбивки,

Копирайтер читает тексты,

Технический специалист оценит скорость загрузки,

Менеджер проверит сценарии…

все надо предвидеть и знать, что каждому из них показать или сказать.

Перед началом демонстрации нужно пользователям сразу же рассказать на что именно надо смотреть, перечислить все известные проблемы/ограничения, и уточнить, кто именно будет рулить процессом.

После демонстрации и фиксации замечаний, нужно проверить, достигнуты ли цели отсмотра, отделить негатив в адрес продукта от недовольства командой, и запланировать следующую итерацию…

Источник: www.searchengines.ru