Как перестать писать огромные ТЗ и быстрее стартовать разработку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат ППИ – минимальный набор артефактов:

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

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

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

Синхронизируем нашу команду с бизнесом. Создаем базу для дальнейшей разработки и принятия решений.

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

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

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

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

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

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

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

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

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

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

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

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