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