Документация здорового человека: как перестать писать огромные ТЗ и быстрее стартовать разработку

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

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

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

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

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

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

Дальше просто факт: для крупного проекта с разработкой от полугода составление документации занимает 2-3 месяца без учета верхнеуровневого описания требований.

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

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

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

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

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

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

Отвечаем в ходе ППА на вопросы:

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

Если задача – модернизировать бизнес-процессы, то добавляем в ППА этап изучения существующей системы и анализ путей ее улучшения.

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

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

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

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

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

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

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

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

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

При этом разработку первой версии стараемся уложить в 3–4 месяца для крупных проектов.

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

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

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

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

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