Вдохновленные. Все, что нужно знать продакт-менеджеру | страница 21

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

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

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

Осмыслить и визуализировать это можно несколькими способами, но, по сути, все довольно просто. Главное — все в команде всегда должны работать параллельно, стараясь определить, какой продукт нужно создать; над этим в основном изо дня в день работают менеджер продукта и дизайнер, в то время как инженеры-программисты трудятся над реализацией замысла и созданием готового программного продукта.

^{>Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок}

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

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

Цель исследования — как можно быстрее отделить хорошие идеи от плохих и получить в результате проверенный бэклог продукта (журнал задач, которые необходимо выполнить команде). В частности, это означает, что мы получили ответы на четыре главных вопроса:

1. Будет ли пользователь это покупать (или использовать)?