Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта - читать онлайн книгу. Автор: Мелисса Перри cтр.№ 39

читать книги онлайн бесплатно
 
 

Онлайн книга - Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта | Автор книги - Мелисса Перри

Cтраница 39
читать онлайн книги бесплатно

Расстановка приоритетов

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

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

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

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

Команда Кристы обсудила «Стоимость задержки», связанной с разработкой функции стороннего видео в первой версии. Она решила так: раз эта функция не является критически важным компонентом для большого числа пользователей, а на ее разработку уйдет еще месяц, продукт не должен ее включать. Быстрая разработка стала идеальным вариантом, поскольку каждая неделя задержки означала, что курс не будет опубликован.

Возможно, вы думаете: «Но как мне рассчитать доход от каждого из моих продуктов?» Озлем Юче и Джошуа Дж. Арнольд – эксперты в области «Стоимости задержки», и они создали качественный способ ее оценки, как показано на схеме 19.1.


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

Схема 19.1. Качественная стоимость задержки. Джошуа Арнольд и Озлем Юче


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

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

«Стоимость задержки» может помочь положить конец спорам о том, что должно и не должно быть приоритетным. Если вы хотите узнать больше, посетите сайт Black Swan Farming и прочитайте о том, как использовать эту концепцию в вашей компании.

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

Реальное определение готовности

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

Мы заканчиваем разработку или итерации над функцией только тогда, когда она достигла своих целей. Часто команды выпускают первую версию функции, а затем переходят к следующей, не оценивая результаты для пользователей. Как однажды сказал Джефф Готелф, автор книги «Sense & Respond»: «Версия 2 – это самая большая ложь в разработке программного обеспечения». Такой менталитет всегда ведет к ловушке разработки.

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

Когда у вас есть критерии успеха, вы можете использовать их в Product Kata и повторить шаги, которые мы рассмотрели в этом разделе: задать направление с помощью критериев, понять, какие проблемы стоят на пути к достижению цели, и систематически решать их с помощью экспериментов.

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

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

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

Часть V
Организация, ориентированная на продукт
Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

Вернуться к просмотру книги Перейти к Оглавлению Перейти к Примечанию