“Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile”. Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.
Вообще, сам термин “техническое задание” для разработки в последнее время стал встречаться реже — и в обсуждениях и в профильных статьях. Чаще его заменяют словом “требования” (reqirements) или Product vision и это действительно ближе к истине — в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным — хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый “образ победы” — того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по-разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию — чтобы у всех было единое понимание того, что такое “Заказ”, из чего состоит “Заявка”, кто такой “Администратор” и т.п.
Помимо единого понимания будущего проекта для всех участников, в подробном описании требований есть и много другой пользы:
-
Разработка может быть разделена между несколькими отдельными командами, и важно чтобы все они руководствовались единым планом
-
При завершении разработки нужен документ, по которому продукт будут тестировать и сдавать заказчику
-
В случае юридических и финансовых споров будет полезен список того, что изначально планировалось разработать — даже если разработчик работает по принципу time&material и уж конечно, если он работает за фиксированную оплату
-
Нужна документация с описанием проекта для его дальнейшей поддержки и развития, особенно если это будет делать не тот, кто разрабатывал (да и новым участниками команды он явно не помешает). Бывает, ее пишут в конце проекта, с описанием того, что в итоге получилось. Но и в этом случае хорошо бы иметь перед глазами постановку задачи, которую изначально хотели
-
Архитектор проекта скажет большое спасибо, если для проектирования ему предоставят хотя бы примерное описание будущих фич и направлений развития. Иначе есть риск того, что итоговый набор сервисов не будет влезать в заложенную на старте архитектуру.
Что стоит включать в документ с описанием первичных требований — минимальный набор:
-
Постановка целей. Несмотря на кажущуюся простоту, это квинтессенция всей подготовительной работы проекта, в которой кратко описывается, что же собственно нужно сделать, для чего и в чьих интересах
-
Термины — объяснение основных понятий, которые используются в документе
-
Бизнес-требования — описание тех ценностей, которые бизнес ожидает от использования продукта. Без подробностей реализации в системе, просто сама потребность, что должно быть сделано. Например “Пользователь-подрядчик должен иметь возможность подать запрос на получение заказа в тендерном блоке, если его компания допущена к этому заказу”. Есть разные техники выяснения и описания БТ, не будем здесь подробно на этом останавливаться
-
Ролевая модель. Минимальный набор пользовательских ролей в продукте и отличия между ними
-
Структура — какие разделы предполагается разработать на первом этапе. Должен ли быть в проекте каталог, система заказов, калькуляторы, карты, чаты и т.п. Для верхнеуровневых требований перечня и краткого описания разделов структуры будет достаточно, для более глубокой проработки будет полезно составить список страниц для каждого из них, а также зафиксировать предварительную модель данных — схему необходимых связей между разделами
-
Функциональные требования — описание того, как должно быть реализовано то, что описано в бизнес-требованиях. Для кого-то это уже излишняя глубина, которая должна декомпозироваться и решаться уже в процессе разработки, но для основных сущностей ФТ лучше прописывать на старте — хотя бы для получения адекватной оценки реализации от разработчика
-
Пользовательские истории (user stories или job stories) — кусочки пользовательских сценариев, которые должны быть реализованы в проекте. Для них тоже существуют разные форматы, самый распространенный, по Вигерсу “Как <роль>, я хочу <действие>, чтобы <ценность>”. В гибкой разработки именно этот формат чаще всего используется вместо функциональных требований, а часто и вместо всех остальных перечисленных выше разделов
-
Критерии приемки — заранее заданные сценарии проверки, при выполнении которых проект будет считаться выполненным. Обычно следуют из пользовательских историй и служат основой для последующего создания тест-кейсов
-
Интеграции. Из каких систем проект должен брать данные и куда передавать — для начала будет достаточно хотя бы перечня этих систем и данных, чтобы представлять объем работ
-
Нефункциональные требования к системе — как минимум базовые рамки по производительности, безопасности, совместимости, требования к отображению продукта для различных устройств.
-
Референсы — примеры продуктов, которые заказчик считает удачными, аналогичными, красивыми и т.п.
Вот такой базовый набор у меня получается в качестве исходных требований для создания MVP. В зависимости от проекта сюда могут добавляться схемы наиболее важных бизнес-процессов, схемы клиентских путей, диаграммы интеграций, перечень пользовательских уведомлений и так далее. Само собой, это только начало — гибкая разработка на то и гибкая, что в процессе разработки и диалога с заказчиком будут добавляться новые требования (особенно после согласования прототипов), из них будут получаться новые фичи, а после проверки минимального продукта на живых пользователях этот процесс встанет на поток.
Поэтому ответ на исходный вопрос — да, для работы по аджайлу ТЗ нужно, хоть и в не вполне традиционном исполнении. Основной нюанс только в том, что каскадный метод это «сначала полностью опиши, потом строй», а гибкая технология — «опиши достаточно, чтобы начать, а потом уточняй по обратной связи». В итоге, если в первом случае работа аналитика почти целиком сосредоточена в начале проекта и в его завершении (помощь по тестированию), то во втором она полностью распределена на весь проект и требуется для каждой итерации. А как вы пишете требования, обсудим? Если нужно участие в их сборе и описании, буду рад помочь.
ссылка на оригинал статьи https://habr.com/ru/articles/1074232/