Что такое Product Flow

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

Как в таком случае определиться с тем, какие “фичи” требуется заложить в Продукт в самом начале, а какие можно отложить на потом? Как не забыть все аспекты будущего продукта, который может разрабатываться месяцы, а то и годы? Как распределить задачи между разными разработчиками и отследить процесс их выполнения?

Тут и приходят на помощь такие инструменты как Техническое задание, Методологии разработки ПО и целые Фреймворки вроде Scrum, Kanban и проч. Если вы даже не слышали о таких терминах – не пугайтесь, рассмотрим всё на примерах.

Что такое ТЗ

Суть любого технического задания заключается в том, чтобы четко и детально описать все требования к разрабатываемому продукту или оказываемой услуге. Оно служит основой для понимания между заказчиком и исполнителем, обеспечивая ясность и минимизируя риски недопонимания, а также фиксирует приоритеты на протяжении всего срока проектирования и производства готового Продукта.

В простейшем виде Техническое задание представляет из себя текстовый документ в котором перечислены:

1. Цель проекта
2. Основные задачи
3. Технические требования
4. Сроки выполнения
5. Критерии приёмки
6. Ответственность сторон

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

ТЗ в таком случае оформляется как обычный текст с примечаниями и описывает в первую очередь параметры, важные для Заказчика и его будущих клиентов. На примере автомобиля это: Классификация автомобиля по его размерам и назначению Предполагаемый расход топлива и соответствие экологическим нормам Желательный уровень безопасности при прохождении краш тестов Предельная себестоимость базовой комплектации Соответствие определенной маркетинговой стратегии

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

Аналогично происходит работа с ТЗ и в других сферах бизнеса: разработке ПО, маркетинге, добыче полезных ископаемых и даже при строительстве космических аппаратов и больниц. Детали реализации ложатся на производителей Продукта, но важно вписаться в заложенные технические требования.

Что такое Методология и Фреймворк

Методология разработки продуктов – это система принципов и практик для управления процессом создания продукта. Она определяет общий подход к разработке, например линейный, итеративный или гибкий, и помогает управлять ресурсами, временем и рисками.

Говоря простым языком – Методология описывает рабочие регламенты: кто, с кем, каким образом и с какой частотой коммуницирует, как происходит постановка задач и приёмка результатов. Например существует большая разница в работе внутри группы 3-х друзей или мегакорпорации, состоящей из десятков тысяч сотрудников.

Фреймворк разработки продуктов – это набор конкретных инструментов и шаблонов для реализации методологии, например “Доска задач” или “Недельный спринт”. Он предоставляет готовую систему для достижения поставленных целей в рамках определённой методологии.

Фреймворк позволяет упростить процесс внедрения Методологии в рабочие процессы, снимая с руководителя необходимость самостоятельного выбора инструментов и написания документации, однако требует от сотрудников затрачивать рабочее время на обучение особенностям работы в рамках конкретного Фреймворка.

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

Выбор Методологии и фреймворка зависит от таких факторов как:

• Тип продукта: Инновационный или стабильный.
• Гибкость требований: Возможность изменений в процессе.
• Размер команды: Малые или крупные группы.
• Скорость выхода на рынок: Быстрый запуск или долгосрочная разработка.
• Культура компании: Самоорганизация и вовлеченность команды.

На что похож Product Flow

По своей сути Product Flow – это совокупность Документации, Технического задания, “Таск трекера” и правила работы с ними, позволяющие разрабатывать Продукты разной сложности, такие как ПО, Литературное произведение или даже Автомобиль. В широком смысле такой набор инструментов и принято называть Методологией, а Фреймворк зачастую – это один из вариантов реализации этой методологии.

В основе Product Flow находится Техническое задание (ТЗ) – это документ, подчиняющийся строгим правилам оформления и позволяющий однозначно определить весь необходимый функционал Продукта. Выглядеть ТЗ может по-разному: как xml или json файл, таблица в Excel или специализированный веб-сервис. Однако независимо от исполнения, всегда сохраняется иерархическая структура и взаимосвязь различных элементов ТЗ, таких как:

• Роль
• Функция
• История

В качестве Роли может выступать “Авторизованный пользователь социальной сети”, “Житель квартиры” или “Водитель”.

Функция задаёт некую “хотелку” Роли: “Посетить приватную группу”, “Включить лампочку” или “Запустить двигатель автомобиля”.

История описывает некоторые условия, в которых Функция происходит, например “Подписан на паблик”, “С помощью телефона”, “Включена передача”.

Таким образом, все 3 элемента ТЗ выстраиваются в предложение определённой структуры
<Роль> хочет <Функция> при условии / если <История>
Из приведённых примеров получим:

• Авторизованный пользователь социальной сети хочет Посетить приватную группу, если он Подписан на этот паблик
• Житель квартиры хочет Включить лампочку С помощью телефона
• Водитель хочет Запустить двигатель автомобиля при Включенной передаче

Такая структура ТЗ позволяет максимально подробно описать все возможные сценарии использования Продукта разными типами пользователей. При этом ТЗ подсвечивает сомнительные Истории – если формулировка не складывается в ранее описанную структуру, значит есть какие-то неточности или такая ситуация “высосана из пальца”. К тому же ранее описанные Истории помогают при “Мозговом штурме” давая порой неожиданные идеи для альтернативных вариантов применения.

Как понять ТЗ в Product Flow

Т.к. в Product Flow техническое задание имеет специальный иерархический формат, его чтение требует определённого навыка. Для начала необходимо определить Роль, для которой описана конкретная часть ТЗ, например “Читатель / Новичок”

Далее для этой Роли может быть описано несколько Функций, например “Читатель / Новичок хочет Познакомиться с понятием ТЗ

После чего можно перейти к последовательному изучению каждой вложенной Истории по отдельности:

• если “Не знает для чего нужно ТЗ”
• если “Не знает как может выглядеть ТЗ”

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

Что дальше

Туториал “Как читать ТЗ Product Flow”