Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты… кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.

Другой вопрос, что, как показывает практика, внутренним проектам зачастую не хватает таких сроков. То, что я наблюдал — отстутствие сроков и контроля за ними, требований запустить описанный объем функционала с необходимым уровнем качества в заданную дату… приводит к расхолаживанию команды.

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

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

Я не говорю о том, что и здесь надо биться за запуск в срок любой ценой: если функционал откровенно сырой или ненужный, в чем смысл его запускать?! Но цель и срок должны быть, должны быть всегда, даже если позабыть про внешние факторы в духе уже назначенной даты старта проплаченной рекламной компании, прописанных в законодательстве сроков сдачи отчетности и т.д. и т.п. Да, я против навязанных сроков, но объем надо оценить, поставить дату и держаться за неё, держаться максимально точно. Это нужно всем. Да, и вам тоже.

Происходит достаточно забавный процесс: есть множество сервисов, для которых мобильная версия и/или мобильное приложение сейчас гораздо важнее “полноценного” сайта. Как-то все прошедшие годы обычно было наоборот: делался сайт, потом в качестве дополнения, чтобы еще малость поднять посещаемость и увеличить лояльность, делалась мобильная версия. Теперь возникает впечатление, что всё перевернулось с ног на голову.

Тенденция достаточно любопытная и всё более усиливающаяся: на днях ReadItLater, известный, прежде всего, за счет своих приложений для iPhone & Android, выкатил и онлайн-просмотр заметок для больших экранов. И я вполне осознанно говорю “больших экранов”, а не, скажем, ” браузеров настольных операционных систем”: дело в том, что создается отчетливое ощущение, что сделана эта версия для планшетов. Не для ноутбуков и, тем более, не для десктопов, а именно для планшетов — посмотрите на общий внешний вид, обратите внимание на элементы управления, ведь всё же рассчитано на тач-интерфейс.

Есть один простой, но почему-то не так часто используемый в наших палестинах способ совершенствования качества сервиса. Он настолько банален, что и говорить как-то неудобно: Eating your own dog food, т.е. по простому — использование собственных сервисов сотрудниками компании. Чаще всего эта политика используется в софтверных или технологических компаниях, что и понятно. Если вы видите сервис, в котором есть огромное количество мелочей, которые облегчают жизнь и появляются ровно в тот момент, когда они нужны… что ж, команда любит свой сервис, а кто-то уже достаточно эволюционировал, чтобы думать не только на уровне кода, но и интерфейса. Правда, будем честны, есть и другая крайность: типично “программерский дизайн” — это как раз, если этот шаг сделан не был, и весь интерфейс представляет собой бешенную мешанину контролов, художественно разбросанную по экрану. Впрочем, не об этом сейчас речь.

читать далее »

Наверняка все, кто интересовался менеджментом, хоть раз видели модель Такмана – forming-storming-performing. Проблема в том, что начинается после performing. А за границей performing есть только один вариант: evolving, вопрос в том, когда он начнется и как именно будет выглядеть.

Компания растет, люди растут, вопрос, кто быстрее. Варианта, по большому счету, 3.

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

Вариант второй, который встречается гораздо чаще – компания растет быстрее, чем (некоторые) её сотрудники. Тогда либо от сотрудников избавляются, либо они мертвым грузом повисают на компании, тормозя её. Здесь есть тяжелый момент: эти «гири» в компании давно, к ним все привыкли, и удалять их… во многом разрушать компанию, либо лишать её сотрудников ощущения стабильности и предсказуемости.

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

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

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

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