Зачем нужен и как может быть устроен полезный Product Vision
Заказчики и подрядчики разработки ИТ-продуктов в целом догадываются, либо знают и понимают, что для:
- планирования создания продукта,
- оценки его стоимости,
- качественного проектирования,
- разработки и приёмки,
нужен какой-то достаточно объёмный (?) реестр функций, требований, возможностей.
Такой реестр обычно оформляется в виде:
- технического задания разной степени формальности и качества и/или
- набора сценариев использования / интеграции и/или
- бэклога пользовательских историй.
Практика показывает, что если просто собрать, скомпилировать и формализовать все возможные идеи заказчика, его экспертов и экспертов подрядчика, то иногда можно получить достаточно строгий документ/реестр, который:
- имеет понятную структуру
- имеет чёткие и понятные формулировки
- возможно даже наглядно взаимоувязывает свойства продукта и интересы пользователей/клиентов/партнёров
- наглядно показывает устройство продукта и взаимосвязи его частей
- детально описывает его свойства в объёме, достаточном для проектирования/реализации.
Перечисленные выше качества безусловно ценны для технического проектирования, разработки и приёмки, т.е. предсказуемого (в смысле сроков, стоимости и возможностей) создания продукта, который соответствует задумке создателей.
Однако, если стремиться к детальности и полноте, то работа по созданию такого документа может затянуться на многие месяцы, поэтому в современной практике чтобы проделать даже эту работу, нужно получить финансирование.
Более того, если пытаться детально описать продукт и потом оценить сроки и стоимость его создания, то может выясниться, что оценки в разы и порядки превышают возможности заказчика, поэтому в работу может пойти одна вторая / одна десятая часть всех потенциальных возможностей и важно понимать, какая именно, а проработка остальных частей по всей видимости была напрасна и представляет собой потери, «муду» в терминах бережливого производства.
Более того, в современном конкурентном рынке часто оказывается, что детальные планы длительностью более полугода имеют достоверность, близкую к нулевой из-за постоянных непредсказуемых событий со стороны игроков рынка и изменений законодательства.
Поэтому на самом деле нет никакого смысла СРАЗУ делать детальное описание продукта, не выяснив его приоритеты и границы бюджетов и сроков на уровне «надо» / «есть».
Чтобы получить грубые, но критически полезные оценки сроков и бюджета и чтобы спонсор мог принять взвешенное решение о финансировании инициативы, полезно создать краткое её описание в формате концепции продукта (product vision).
Концепция продукта
Такая концепция должна обладать некоторыми свойствами, которых мы ожидаем и от подробного описания продукта, как минимум, концепция продукта тоже:
- имеет понятную структуру
- имеет чёткие и понятные формулировки
- наглядно взаимоувязывает свойства продукта и интересы пользователей
- (возможно) наглядно показывает устройство продукта и взаимосвязи его частей
Какие разделы стоит включать в концепцию:
- Контекст проекта — кто является его инициаторами, какими они обладают активами, какими мотивами и соображениями руководствуются при выдвижении инициативы о продукте
- Целевой рынок — на кого рассчитан продукт, на чьи потребности, какова оценка рынка
- Конкурентная среда — какими продуктами и решениями пользуются потенциальные клиенты сейчас, каковы их преимущества и особенности
- Цели продукта — каких целей, каких значений KPI хотят добиться его инициаторы на перспективе 1 год, 3 года, 10 лет.
- Формула продукта — каким образом продукт помогает клиентам, в решении каких проблем и реализации каких потребностей и возможностей
- Позиционирование продукта — описание его ниши на фоне конкурентов
- Карта экосистемы — место продукта в существующей или создаваемой среде из множества взаимоувязанных продуктов, описание его роли в ней
- Поставщики, партнёры — кто и как может участвовать в жизни продукта, какие к ним требования
- Концептуальная диаграмма устройства продукта и его окружения
- Ключевые свойства продукта — описание возможностей, которыми должен обладать продукт
- Роудмап — высокоуровневый план вывода на рынок отдельных возможностей продукта
- Ценовая политика — правила формирования цены для разных сегментов клиентов и вариантов продукта
- Экономическая модель — расчёт окупаемости продукта.
- Юридическая модель — организационная форма существования продукта, её варианты в разных географических юрисдикциях.
На практике такой документ, чтобы быть полезным, должен не превышать по объёму 10–20 страниц, а в идеале — 5-и.
Итак, структура концепции выглядит внушительно и основательно, не правда ли?
Однако если мы говорим о создании УСПЕШНЫХ продуктов для рынка, эти качества (что концепции, что детального описания проекта) критически недостаточны, т.к. наглядность и структурность описания проекта продукта никоим образом не гарантирует успешность ПРОДУКТА, и более того, не имеет прямой связи с ним.
Т.е. приведённая выше структура описывает воздушный замок, структурированный набор иллюзий, фантазий или, говоря более удобным для людей языком, гипотез.
Самая уязвимая часть такой структуры — экономическая модель. Предыдущие 20 лет очень часто бывало так, что модель нового продукта строилась на пожеланиях создателей, а не каких либо фактах и сдержанных прогнозах (например, если вчера продали на 3, а сегодня — на 4, то нет никаких гарантий и надежд, что завтра продадим на 10).
Это не значит, что концепцию не надо делать — надо, но надо и проверять её на жизнеспособность, организовывать серию экспериментов по проверке отдельных предположений, на которых она строится — прежде всего, о востребованности тех или иных возможностей, существовании и значимости тех или иных задач и проблем клиентов.
Подход к проверке этих гипотез предложен Стивом Бланком в его методике Customer Development, довольно уверенно принят рынком продуктовой разработки и кратко раскрывается в статьях: