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