Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом

Во многих компаниях до сих пор существует убеждение: чем подробнее техническое задание, тем успешнее будет проект. Поэтому перед стартом разработки команды месяцами пишут документы, пытаясь предусмотреть все сценарии и описать каждую кнопку.

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

Разберем реальный кейс, где попытка сделать «идеальное» техническое задание привела к увеличению сроков проекта почти в два раза.

Как выглядит классический подход к разработке

В одном из проектов стояла задача создать новый цифровой сервис для клиентов компании. Команда решила подойти к задаче максимально основательно.

Процесс выглядел примерно так:

1. Длительный этап системного анализа

2. Подробная проработка всех сценариев

3. Подготовка большого технического задания

4. Передача документа разработчикам

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

Сам проект изначально планировался на один год разработки. Но дальше произошло то, что происходит во многих подобных проектах. Разработка заняла не один год, а полтора. В итоге полный цикл проекта составил почти два года.

Почему длинное ТЗ не спасает проект

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

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

К моменту начала разработки часть требований уже устаревает.

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

В результате команда начинает разрабатывать не минимально полезное решение, а максимально полный продукт.

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

На практике многие вещи все равно уточняются уже во время разработки.

Где именно ломается процесс

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

Например, в ТЗ может появиться требование:

«Создать личный кабинет пользователя с возможностью регистрации, накопления баллов и электронным кошельком».

Но если посмотреть на ситуацию с точки зрения пользователя, вопрос может звучать иначе:

Что именно он хочет получить?

Пользователь хочет создать личный кабинет или он хочет получать кэшбек за покупки?
Он хочет управлять кошельком или просто видеть свой баланс?

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

Когда требования формулируются через потребности пользователя, часть задач просто исчезает.

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

Как мы сократили срок разработки с года до четырех месяцев

В проекте с мобильным приложением для доставки товаров команда изначально планировала разработку нового функционала примерно на двенадцать месяцев.

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

Мы начали задавать простой вопрос для каждой задачи:

Какую конкретную потребность пользователя она решает?

Часть задач оказалось связана с реальными сценариями использования продукта. Но значительная часть представляла собой дополнительные функции, которые могли быть полезны когда-нибудь, но не были необходимы для запуска.

После пересмотра требований бэклог сократился примерно в три раза.

Это позволило сократить срок разработки до четырех месяцев. Если посчитать экономику проекта, результат становится еще более наглядным.

Команда состояла из семи разработчиков. Средняя стоимость одного разработчика с учетом налогов и накладных расходов составляла около 300 тысяч рублей в месяц.

Если бы проект продолжался двенадцать месяцев, стоимость разработки составила бы примерно 25 миллионов рублей.

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

Экономия бюджета составила около 24 миллионов рублей.

При этом продукт начал приносить бизнесу ценность гораздо раньше.

Что помогает запускать разработку быстрее

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

Простой шаблон выглядит так:

Я как <тип пользователя> хочу <действие>, чтобы <получить результат>.

Например:

Я как покупатель интернет-магазина хочу получать кэшбек за покупки, чтобы экономить деньги.

Такая формулировка заставляет команду думать о потребности пользователя, а не о функциях системы.

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

Например:

Пользователь видит баланс кэшбека
Кэшбек начисляется после оплаты заказа
Баланс можно использовать для следующей покупки

Этого часто достаточно, чтобы начать разработку.

Детали можно уточнять уже в процессе работы.

Почему минимальные требования работают лучше

Когда команда использует пользовательские истории вместо большого ТЗ, процесс разработки становится более гибким.

1. Во-первых, сокращается время подготовки проекта. Вместо месяцев анализа команда может начать работу через несколько недель.

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

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

Итог

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

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

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

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

Если статья была полезной, подписывайтесь на мой Telegram-канал. Там я делюсь практическими кейсами, инструментами и подходами к разработке продуктов и использованию нейросетей в работе.

Если хотите закрыть пробелы системно, а не собирать знания по кускам — обратите внимание на курс «Системный аналитик. Управление командой». На курсе разбирают управление командой аналитиков, проектирование архитектуры систем и данных, безопасность, анализ кода и практики автоматизации и документирования, которые нужны для работы на уровне лида. Пройдите вступительный тест, чтобы узнать, подойдет ли вам программа курса.

Для знакомства с форматом обучения и экспертами приходите на бесплатный урок 23 марта в 20:00 — «Как системный аналитик может использовать ИИ в своей работе». Проверить формат