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