3. И наконец, главное — решить проблему, а не имплементировать новые функции.
Как мы уже говорили, традиционные дорожные карты продуктов нацелены прежде всего на процесс, но сильные команды знают, что их цель — не только и не столько внедрение того или иного решения. Они обязаны гарантировать, что оно позволит устранить фундаментальную проблему. Иными словами, они нацелены на реальныеКак вы скоро убедитесь, книга посвящена именно этим трем принципам.
Глава 8. Ключевые идеи
В этой книге я часто ссылаюсь на понятия, которые можно считать фундаментом современной работы над продуктом. И мне хотелось бы кратко объяснить их, прежде чем продолжать обсуждение.
Термин
Понятие продукта, безусловно, включает
Если вы разрабатываете сайты для e-commerce, то ваш продукт включает в себя опыт выполнения и возврата заказа. В общем продукт такой компании представляет собой все,
Суть в том, что определение
Я уже говорил, что большинство компаний по-прежнему используют по сути каскадный процесс и что в лучших современных командах вы ничего похожего не увидите.
Позже мы рассмотрим процесс разработки продукта подробнее, а сейчас я изложу вам общую концепцию.
Все продуктовые команды занимаются двумя основными видами деятельности:
Осмыслить и визуализировать это можно несколькими способами, но, по сути, все довольно просто. Главное — все в команде всегда должны работать параллельно, стараясь
Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок
Как вы скоро увидите, в реальности все немного сложнее. Например, технари тоже ежедневно помогают выяснять, над каким продуктом следует работать (и, надо признать, многие лучшие инновации рождаются благодаря их участию, так что недооценивать их вклад ни в коем случае не стоит), а менеджер продукта и дизайнер ежедневно помогают инженерам создавать фактический продукт (в основном уточняя необходимые характеристики и функции). Но в целом все сводится к этим двум видам деятельности.
Эта концепция связана с понятием тесного сотрудничества в управлении продуктом, проектирования пользовательского интерфейса и инженерной разработки. На этапе исследования мы сокращаем разные формы риска, прежде чем будет написана хоть одна строка кода.
Цель исследования — как можно быстрее отделить хорошие идеи от плохих и получить в результате
1. Будет ли пользователь это покупать (или использовать)?
2. Сможет ли он понять, как это использовать?
3. Смогут ли инженеры это построить?
4. Станут ли заинтересованные стороны это поддерживать?