Перед началом разработки любого продукта обычно составляется ТЗ – документ, отвечающий на вопрос: «Как надо делать?». Составляли его и мы, пока не нашли другой подход. Теперь на старте мы проводим продуктовое проектирование. В итоге получаем документацию здорового человека, которую бизнесу проще понять, а времени на ее создание тратится в 3 раза меньше, чем на проработку ТЗ.
Что такое ТЗ и почему его составляют
Техническое задание (ТЗ) – это документ или пакет документов, определяющих требования и порядок создания IT-продукта. Проще говоря, это задание исполнителю от заказчика, в котором прописано, какой результат хочет получить заказчик, и как исполнитель должен его достигать.
ТЗ обычно составляют в формате текста. Иногда к тексту прилагают прототипы будущего продукта. Готовый документ содержит информацию о сроках реализации проекта, ожиданиях, рисках, сценариях использования продукта и пользе, которую он должен принести бизнесу и пользователям. Звучит неплохо, но это пока дело не дошло до его создания.
Нельзя просто так взять и составить крутое ТЗ
У классического подхода к созданию ТЗ есть 4 основные проблемы:
- Сложно оценить объём работ
- ТЗ пишется долго
- Требования описываются очень детально для разработчиков, но от этого становятся нечитаемыми для бизнеса
- ТЗ устаревает в процессе собственного составления
Теперь расшифруем.
Полноценное ТЗ не пишется сразу после первой встречи с заказчиком. Сначала мы погружаемся в проект, обозначаем требования верхнеуровнево, согласуем. На это нужно время, и тем больше, чем сложнее проект.
Дальше просто факт: для крупного проекта с разработкой от 6-ти месяцев составление документации занимает 2-3 месяца без учета верхнеуровневого описания требований. Еще один факт: бизнес покупает у нас не ТЗ – он хочет работающий продукт. При этом процесс создания ТЗ оплачивается. Заказчик все это время в ожидании. То есть, он знает, что исполнители заняты делом, вникают, но результат «пощупать» пока нельзя. Находиться в таком подвешенном состоянии не нравится никому.
Теперь о том, что внутри. Сила ТЗ в его детализации. Грубо говоря, по хорошему ТЗ команда без лишних вопросов может запилить работающий продукт. Но это фантазии. Во-первых, потому что нельзя идеально детализировать ТЗ. Во-вторых, потому что сильной команде разработки не нужно, чтобы за нее решали, как реализовать «вот эту вот фичу» – она сама придумает изящное решение. А раз так, то время (и деньги) на детальные описания тратится зря.
Помните про 2-3 месяца создания документации? Так вот за этот срок она может стать дважды, а то и трижды неактуальной. Причин масса: вновь появившиеся требования бизнеса, выход новой версии языка программирования, обновление API для интеграций, новые тренды рынка.
Чтобы подстроиться под меняющийся мир, придется переписывать и передоговариваться. Так можно вообще никогда не дописать ТЗ. Поэтому приходится закрывать глаза на окружение, в котором продукт будет существовать. Так, на выходе получается компромисс из того, что хотел получить заказчик в самом начале и того, что будет работать сейчас.
Ну и откровение напоследок. Классические ТЗ пытаются быть хорошими и для бизнеса, и для разработчиков. Это снова фантазии. Невозможно создать техническую инструкцию с легко считываемыми бизнес-смыслами. Это как писать руководство по эксплуатации автомобиля, надеясь, что оно будет работать как презентация для привлечения новых инвесторов.
узнать больше о разработке цифровых продуктов fuse8 можно в нашем тг-канале
Как сохранить пользу ТЗ и избавиться от его несовершенств
- Сделать оценку объема работ проще
- Ускорить создание документации
- Меньше деталей – больше бизнес-пользы
- Меньше времени на описание – выше актуальность
Вместо длительного сбора требований мы стали проводить продуктовое проектирование. Оно занимает не более 5 недель. Сначала примерно договариваемся с заказчиком о занятости на каждую неделю, потом уточняем план. Отвечаем в ходе исследования на вопросы:
- Зачем создается продукт и каких бизнесовых целей он должен достичь?
- Что эта за система и как она должна работать?
- Какую архитектуру и какие технологии мы будем использовать?
- Как пользователь будет взаимодействовать с системой?
- Сколько будет стоить и сколько будет длиться разработка системы?
- Что мы делаем в первую очередь, а что оставляем на пострелизное развитие?
Обычно мы на первых двух встречах понимаем, что заказчику нужно проектирование. Уже здесь можем рассказать об этом этапе, о вилке цен и сроках.
Заказчик же на второй-третьей встрече понимает, нравится ли ему мы и наш подход, формирует ожидания по бюджету и срокам.
Результат продуктового проектирования – минимальный набор артефактов:
- Определение целей и границ проекта — Импакт Маппинг
- Проработка и описание системы и ее работы — Описание системы
- Архитектура и технологии для разработки системы
- Приоритезация задач и выделение первой версии системы
- Роадмап проекта со сроками и стоимостью разработки. Их всегда фиксируем точно. Фичи на пострелизное развитие проекта добавляем в беклог и роадмап на развитие продукта.
- Набор метрик для отслеживания результата.
Дальше о том, что внутри каждого из артефактов.
Определение целей и границ проекта
Начинаем с постановки цели и обсуждаем с заказчиком границы проекта. Прибегаем к Карте влияний. Про нее мы писали в отдельной статье.
Синхронизируем нашу команду с бизнесом. Создаем базу для дальнейшей разработки и принятия решений. Всего этого не сделать без грамотной постановки целей, и лучше всего ставить их по SMART-методике.
Сбор требований и описание системы
Самый трудоемкий этап — 60–70% от всего объема работ.
Мы собираем требования почти как при разработке ТЗ, но не углубляемся в детали реализации функциональности продукта, которую обсуждаем. Получается описание системы. Это документ, из которого бизнес понимает, какой продукт получится в итоге, а команда разработки может декомпозировать его по задачам, принять решения о реализации фич и стартовать разработку.
Описание системы написано не характерным для гостовских ТЗ неформальным языком. Это сознательный шаг — так мы упрощаем онбординг для новичков, которые будут входить в проект на следующих этапах.
Это работает. Для одного нашего клиента мы делали проектирование с описанием системы. Согласно фидбеку, время на онбординг в проект после этого стало составлять 2 недели вместо 2-х месяцев. Это не значит, что через две недели разработчик уже пилит фичи на 100% эффективности, но он может участвовать в обсуждениях по проекту и не теряться на них.
Архитектура и технологии
Когда у нас на 90% готово описание системы, мы формируем верхнеуровневую архитектуру и подбираем технологии, на которых будем создавать продукт.
Если у клиента есть своя техническая команда, то координируемся с ней. Смотрим на технологии, внутренние и внешние системы для интеграций, согласовываем технологии и подходы.
Основной критерий качества здесь — быстрый старт разработки, актуальные технологии, возможность масштабирования архитектуры и поддержка продукта без бубна и матов. Подробнее в процесс закладывания архитектуры мы погрузились в отдельной статье: разобрали 6 понятных принципов, которые помогут сориентироваться, даже если вы впервые сталкиваетесь с этой областью знаний.
Приоритезация задач и выделение первой версии продукта
Ближе к концу проектирования продукта мы приоритезируем описанные фичи и выделяем первую версию продукта. Работаем вместе с заказчиком: предлагаем свое видение и принимаем критику.
Эффективный инструмент для визуализации пользовательских сценариев и приоритезации функциональности – User Story Mapping. Он помогает команде сосредоточиться на создании ценности для пользователя и бизнеса. Подробнее о применении этого метода читайте в другой нашей статье.
Оценка разработки и роадмап продукта
Финальный этап: декомпозируем задачи, уточняем оценку на разработку первой версии и формируем подробный план работ с разбивкой по функциональности. Далее прикидываем роадмап развития продукта после запуска. В него идут те фичи, которые не попали в первую версию. Все это согласовываем с заказчиком, собираем обратную связь и вносим коррективы в план, если надо.
А что потом?
После продуктового проектирования идет стандартный процесс разработки продукта: прототипирование и дизайн, разработка, тестирование и запуск. И здесь, конечно, стоит подумать о составе команды, которая реализует все задуманное. О том, как подойти к укомплектованию команды, мы рассказали в статье про продуктовые роли.
Продуктовое проектирование в нашей практике показало себя как довольно универсальный подход. Единственный, пожалуй, случай, когда оно не будет работать – тендерная разработка. Для таких проектов важно четкое соответствие положениям ГОСТа.
Но не поймите неправильно – наш подход удовлетворяет требованиям ГОСТ 34 на разработку ТЗ, просто улучшает его и делает менее бюрократическим. То есть мы меняем форму и упрощаем восприятие, а не бездумно вырываем куски из привычной для многих документации. А еще сокращаем время на онбординг команды и быстрее стартуем все то, что идет после проектирования продукта. Получается win-win.
