Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

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

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

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

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

Глава 6

Архетипы плохого менеджера

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

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

Если вам посчастливилось получить образование в области управления продуктом, то, как правило, полученные знания все равно достаточно тактильные: вы умеете писать спецификации (или пользовательские истории в Agile-проектах), планировать встречи с разработчиками и проводить контрольные собрания, собирать запросы бизнес-команды, проводить тестирования. Многие из этих этапов вытекают из работы продакт-менеджеров, которые работают в традиционной каскадной среде. Именно в такой среде училась и я.

В рамках каскадной

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

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

Если вы слушаете и разводите руками, говоря: «Так не должно быть!», я с вами соглашусь. С ростом популярности методологии Agile все больше и больше людей видят недостатки этой системы, которая может годами определять ценность этих требований.

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