разработка не следует строгой линейной схеме, но для того, чтобы понять роль PM, полезно сгруппировать действия команды поэтапно.
В реальной жизни эти этапы накладываются друг на друга, происходят не по порядку или повторяются снова и снова. У каждой компании своя версия порядка действий, но общая схема такова:[10]
PM часто работают сразу в двух направлениях: над исследованием одного продукта и над запуском другого[11]. За счет этого по завершении работы над текущим проектом инженеры могут сразу переходить к следующему, не дожидаясь, пока PM придумает, чем им заняться.
Обратите внимание: выявление ключевых предположений, создание и проверка гипотез происходят на всех этапах.
На ранней стадии главные гипотезы касаются задачи, потребностей клиентов и бизнеса, а также емкости рынка. Позже фокус смещается на решения, юзабилити (удобство использования), реализуемость и планы по запуску.
ИССЛЕДОВАНИЕ ПРОДУКТА
Представьте, что вице-президент (vice-president, VP) компании останавливает вас в коридоре и говорит, что в этом квартале в продукт необходимо добавить функцию экспорта в PDF. Идея простая, но с имеющейся кодовой базой на разработку уйдет несколько недель. Вы подключаете команду, запускаете продукт без багов, но никто этой функцией не пользуется. Получив результаты годового перформанс-ревью, вы обнаруживаете, что в провале обвиняют вас (а не VP, который на самом деле дал это поручение).
Что же пошло не так?
Вы пропустили этап исследования продукта (product discovery) и восприняли распоряжение вашего VP слишком буквально. Нужно было копнуть глубже и разобраться, какая проблема его заботила изначально.
Процесс выявления основной проблемы, которую нужно решить, называется исследованием продукта.
Любой продукт начинается с идеи. Это может быть проблема, которую вы заметили, запрос на добавление функции, неэффективный показатель, выход на новый рынок или любой другой источник вдохновения. На этапе исследования продукта вы берете первоначальную идею и расширяете свое понимание потребностей, проблем и целей клиента.
Вам нужно найти достаточно крупную проблему, чтобы ее стоило решать, и в то же время достаточно выполнимую, чтобы ваша команда добилась успеха.
Часто запуск терпит неудачу из-за того, что команда фокусируется не на тех проблемах. Неправильно поняты важные детали, на которые указал клиент, проблема воспринята недостаточно серьезно, чтобы преодолеть инертность, или же упущено видение общей картины и решение оказалось лишь частичным.
Отличным примером такого провала стала война форматов видеозаписи VHS и Betamax в 1970-х годах. Качество изображения у Betamax было явно лучше, но оказалось, что клиентов больше заботила доступность и возможность записать на носитель двухчасовой фильм. Время записи у кассет Betamax ограничивалось всего одним часом. Более тщательная проработка исследования
Более детальная разбивка на этапы соответствует модели Double Diamond («Двойной алмаз») Совета по дизайну Великобритании (UK Design Council): https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond.
Марти Каган (Marty Cagan) называет это «непрерывным исследованием и запуском» (Continuous Discovery and Delivery) или «параллельной гибкой разработкой» (Dual Track Agile): https://svpg.com/continuousdiscovery/.
