Почему продуктовое проектиро­вание лучше формального ТЗ

Перед началом разработки любого продукта обычно составляется ТЗ – документ, отвечающий на вопрос: «Как надо делать?». Составляли его и мы, пока не нашли другой подход. Теперь на старте мы проводим продуктовое проектирование. В итоге получаем документацию здорового человека, которую бизнесу проще понять, а времени на ее создание тратится в 3 раза меньше, чем на проработку ТЗ. 

Что такое ТЗ и почему его составляют

Техническое задание (ТЗ) – это документ или пакет документов, определяющих требования и порядок создания IT-продукта. Проще говоря, это задание исполнителю от заказчика, в котором прописано, какой результат хочет получить заказчик, и как исполнитель должен его достигать. 

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

Нельзя просто так взять и составить крутое ТЗ

У классического подхода к созданию ТЗ есть 4 основные проблемы:

1. Сложно оценить объём работ 
2. ТЗ пишется долго
3. Требования описываются очень детально для разработчиков, но от этого становятся нечитаемыми для бизнеса
4. ТЗ устаревает в процессе собственного составления

Теперь расшифруем.

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

Дальше просто факт: для крупного проекта с разработкой от 6-ти месяцев составление документации занимает 2-3 месяца без учета верхнеуровневого описания требований. Еще один факт: бизнес покупает у нас не ТЗ – он хочет работающий продукт. При этом процесс создания ТЗ оплачивается. Заказчик все это время в ожидании. То есть, он знает, что исполнители заняты делом, вникают, но результат «пощупать» пока нельзя. Находиться в таком подвешенном состоянии не нравится никому. 

Теперь о том, что внутри. Сила ТЗ в его детализации. Грубо говоря, по хорошему ТЗ команда без лишних вопросов может запилить работающий продукт. Но это фантазии. Во-первых, потому что нельзя идеально детализировать ТЗ. Во-вторых, потому что сильной команде разработки не нужно, чтобы за нее решали, как реализовать «вот эту вот фичу» – она сама придумает изящное решение. А раз так, то время (и деньги) на детальные описания тратится зря. 

Помните про 2-3 месяца создания документации? Так вот за этот срок она может стать дважды, а то и трижды неактуальной. Причин масса: вновь появившиеся требования бизнеса, выход новой версии языка программирования, обновление API для интеграций, новые тренды рынка. 

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

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

Как сохранить пользу ТЗ и избавиться от его несовершенств

1. Сделать оценку объема работ проще
2. Ускорить создание документации
3. Меньше деталей – больше бизнес-пользы
4. Меньше времени на описание – выше актуальность

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

• Зачем создается продукт и каких бизнесовых целей он должен достичь?
• Что эта за система и как она должна работать?
• Какую архитектуру и какие технологии мы будем использовать?
• Как пользователь будет взаимодействовать с системой?
• Сколько будет стоить и сколько будет длиться разработка системы?
• Что мы делаем в первую очередь, а что оставляем на пострелизное развитие?

Обычно мы на первых двух встречах понимаем, что заказчику нужно проектирование. Уже здесь можем рассказать об этом этапе, о вилке цен и сроках. 

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

Результат продуктового проектирования – минимальный набор артефактов: 

1. Определение целей и границ проекта — Импакт Маппинг
2. Проработка и описание системы и ее работы — Описание системы
3. Архитектура и технологии для разработки системы
4. Приоритезация задач и выделение первой версии системы
5. Роадмап проекта со сроками и стоимостью разработки. Их всегда фиксируем точно. Фичи на пострелизное развитие проекта добавляем в беклог и роадмап на развитие продукта.
6. Набор метрик для отслеживания результата.

Дальше о том, что внутри каждого из артефактов.

Определение целей и границ проекта

Начинаем с постановки цели и обсуждаем с заказчиком границы проекта. Прибегаем к Карте влияний. Про нее мы писали в отдельной статье.

Синхронизируем нашу команду с бизнесом. Создаем базу для дальнейшей разработки и принятия решений. Всего этого не сделать без грамотной постановки целей, и лучше всего ставить их по SMART-методике. 

Сбор требований и описание системы

Самый трудоемкий этап — 60–70% от всего объема работ.

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

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

Это работает. Для одного нашего клиента мы делали проектирование с описанием системы. Согласно фидбеку, время на онбординг в проект после этого стало составлять 2 недели вместо 2-х месяцев. Это не значит, что через две недели разработчик уже пилит фичи на 100% эффективности, но он может участвовать в обсуждениях по проекту и не теряться на них.

Архитектура и технологии

Когда у нас на 90% готово описание системы, мы формируем верхнеуровневую архитектуру и подбираем технологии, на которых будем создавать продукт.

Если у клиента есть своя техническая команда, то координируемся с ней. Смотрим на технологии, внутренние и внешние системы для интеграций, согласовываем технологии и подходы.

Основной критерий качества здесь — быстрый старт разработки, актуальные технологии, возможность масштабирования архитектуры и поддержка продукта без бубна и матов. Подробнее в процесс закладывания архитектуры мы погрузились в отдельной статье: разобрали 6 понятных принципов, которые помогут сориентироваться, даже если вы впервые сталкиваетесь с этой областью знаний. 

Приоритезация задач и выделение первой версии продукта

Ближе к концу проектирования продукта мы приоритезируем описанные фичи и выделяем первую версию продукта. Работаем вместе с заказчиком: предлагаем свое видение и принимаем критику.

Эффективный инструмент для визуализации пользовательских сценариев и приоритезации функциональности – User Story Mapping. Он помогает команде сосредоточиться на создании ценности для пользователя и бизнеса. Подробнее о применении этого метода читайте в другой нашей статье.

Оценка разработки и роадмап продукта

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

А что потом?

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

Продуктовое проектирование в нашей практике показало себя как довольно универсальный подход. Единственный, пожалуй, случай, когда оно не будет работать – тендерная разработка. Для таких проектов важно четкое соответствие положениям ГОСТа. 

Но не поймите неправильно – наш подход удовлетворяет требованиям ГОСТ 34 на разработку ТЗ, просто улучшает его и делает менее бюрократическим. То есть мы меняем форму и упрощаем восприятие, а не бездумно вырываем куски из привычной для многих документации. А еще сокращаем время на онбординг команды и быстрее стартуем все то, что идет после проектирования продукта. Получается win-win.