Самый дорогой документ в IT-проекте — тот, которого нет. Устное «сделайте личный кабинет как у них, только удобнее» превращается в три месяца споров: кто виноват, что «удобнее» означало другое, почему интеграция с 1С не входила в фикс, и почему на приёмке всплыла роль бухгалтера. Подрядчик закладывает риск в цену. Заказчик получает либо переплату, либо войну на актах.
Техническое задание нужно не бюрократии, а общей картине: что считается готовым, что сознательно не делается, кто даёт доступы, как проверяют результат. Без этого даже сильная команда угадывает. Слишком толстое ТЗ «на 80 страниц до запятой» тоже вредно, если продукт ещё не понят: вы фиксируете догадки и потом платите за каждое изменение.
Ниже — как составить рабочее ТЗ заказчику, аналитику, разработчику и компании, которая принимает работы от субподрядчиков. Формат: зачем документ, нужно ли «полное ГОСТ-ТЗ», как собрать состав, какие ошибки повторяются и когда лучше начать с короткого брифа.
Зачем ТЗ, если «команда и так профессионалы»
Профессионалы как раз требуют границ. ТЗ снижает стоимость уточнений, даёт основу сметы, фиксирует критерии приёмки и защищает обе стороны. Для заказчика это способ не забыть админку, роли и отчёты. Для разработчика — способ отказаться от бесконечных «мелочей» без пересмотра срока. Для другой компании на стороне клиента — способ контролировать субподрядчика по чек-листу, а не по настроению директора.
ТЗ также выявляет дыры до кода: нет владельца продукта, нет источника данных, нет тестового контура банка, юридический текст не готов. Это дешевле, чем простой спринта.
Рабочее определение: ТЗ описывает, кто что делает в системе, какие данные откуда берутся, что происходит при ошибке и как вы поймёте, что этап сдан. Не описывает цвет кнопок «на глаз», если нет брендбука — для этого макеты.
Нужно ли «полное ТЗ» до старта
Нужно достаточное ТЗ под выбранную модель контракта. Fixed price без границ — лотерея. Time & materials без бэклога — бездонный бюджет. Для пилота достаточно 5–15 страниц: цели, роли, сценарии must-have, интеграции, приёмка, исключения. Для регулируемой поставки — детальнее: форматы обмена, права, журналы, требования ИБ.
Если гипотеза ещё не проверена, не пишите энциклопедию. Сначала рамка MVP — зачем это делается, см. зачем нужен MVP — затем ТЗ на первую версию. Полный контур опишете после пилота, иначе документ устареет раньше, чем его согласуют юристы.
Иногда ТЗ пишет подрядчик по итогам discovery. Это нормально, если discovery оплачен и результат вам принадлежит. «Бесплатное ТЗ за КП» часто поверхностно: его цель — продать, а не закрыть риски.
Для внутренней разработки документ всё равно нужен: через полгода автор кода уйдёт, а «и так все помнят» окажется мифом. Для компании, которая заказывает продукт другой студии, ТЗ — единственный общий язык между закупкой, юристами и IT. Без него сравнение КП превращается в сравнение слоганов.
Как составить ТЗ: структура, с которой можно работать
Начните не с оглавления ГОСТ, а с одного абзаца цели: какую проблему закрываем и для кого. Затем роли (клиент, менеджер, админ — только те, что в v1). Затем сценарии: «Пользователь может…», «Система при этом…», «Если ошибка, то…». Сценарии важнее списка кнопок: кнопки выводятся из сценариев.
Блоки, без которых оценку считать рано
- Цель и границы v1 / v2. Что входит сейчас, что явно нет.
- Роли и права. Кто что видит, кто может удалять, кто видит чужие данные.
- Пользовательские сценарии. 5–15 штук с приоритетом must / should / later.
- Данные и сущности. Заявка, клиент, заказ, статус — поля хотя бы на уровне «обязательно / нет».
- Интеграции. Система, направление обмена, кто хозяин данных, есть ли тестовый контур.
- Интерфейсы. Референсы, брендбук или «системные компоненты». Макеты — приложением.
- Нефункциональное. Нагрузка «до N пользователей», браузеры, мобильные ОС, 152-ФЗ, бэкапы.
- Приёмка. Чек-лист сценариев, среда (staging), срок на замечания.
- Контент и доступы. Кто даёт тексты, ключи API, аккаунты сторов.
- Поддержка после релиза. Входит ли, на сколько, что считается дефектом гарантии.
Пишите простым языком. «Система осуществляет осуществление» никто не реализует однозначно. Лучше: «Менеджер меняет статус заявки на “в работе”. Клиент видит новый статус в кабинете в течение минуты».
Мини-пример сценария
- Контекст: клиент уже зарегистрирован, есть черновик заявки.
- Действие: нажимает «Отправить», подтверждает контакты.
- Результат: заявка в статусе «новая», менеджер получает уведомление, клиент видит номер.
- Ошибки: нет сети — показать повтор; пустой телефон — не отправлять, подсветить поле.
Такой абзац дороже десяти скриншотов без пояснений. Для сайта добавьте список посадочных и цели форм — это стык с разработкой сайтов и SEO. Для приложения — платформы и магазины, см. разработку приложений. Для учёта клиентов — сущности воронки, см. CRM и статью нужна ли CRM, если есть Excel.
С чего начать сегодня: выпишите 7 сценариев must-have и 7 пунктов «не делаем в v1». Это уже 40% ТЗ и основа разговора о сроке.
Ошибки в ТЗ, которые раздувают бюджет
«Как у конкурента» без разбора процесса. У конкурента другая логика скидок, другая 1С, другая служба доставки. Копирование экранов переносит чужие ошибки к вам.
Смешение целей: в одном документе и лендинг, и биллинг, и склад, и мобильное приложение для курьера. Разделите продукты или явно пометьте этапы. Иначе смета будет «средней по больнице» и никому не подойдёт.
Нет приоритетов. Всё «критично» означает, что ничего не критично — подрядчик угадает сам. Нет описания ошибок и пустых состояний: «что если каталог пуст», «что если платёж завис». Нет хозяина интеграций: «нужна 1С» без ФИО администратора и формата обмена.
Юридические дыры: кто владеет кодом, где репозиторий, что с персональными данными. Это не «мелочь в конце», это риск смены подрядчика. Про выбор исполнителя — чек-лист подрядчика, про срыв проекта со стороны заказчика — ошибки заказчика.
Чего не стоит делать
- Писать ТЗ только дизайнеру: логика данных пропадёт.
- Фиксировать стек без причины («только этот фреймворк»), если нет ограничений ИБ или команды сопровождения.
- Требовать «как в Excel, только в системе» без отказа от ручных исключений — исключения и есть главная сложность.
- Забывать админку и выгрузки: ими живут операции после релиза.
Когда подробное ТЗ не нужно
Не нужно на этапе «проверить интерес лендингом»: хватит структуры страницы, оффера и формы. Не нужно расписывать 200 экранов, если вы сознательно идёте в discovery: оплатите исследование и прототип, ТЗ родится из них.
Не нужно притворяться полнотой, когда заказчик не может ответить на базовые вопросы. Лучше честный бриф на 2 страницы, чем фиктивный ГОСТ, который все подписали и никто не читал.
Не нужно путать ТЗ с маркетинговым текстом. «Инновационная экосистема» нельзя принять по акту. Приёмка — сценарии и ограничения.
Не копируйте чужое ТЗ целиком. Отраслевой шаблон полезен как оглавление, вреден как слепок чужих ролей и статусов. Вычистите всё, чего нет в вашей операционке, иначе подрядчик реализует чужой процесс дороже вашего настоящего.
Следующий шаг
Соберите цель, роли, must-have сценарии, интеграции и критерии «готово». Отметьте неизвестные как риски, а не прячьте их. С этим документом можно запрашивать КП у нескольких команд и сравнивать состав работ, а не только сумму. Если продукт ещё гипотеза — сузьте ТЗ до пилота, полный контур подождёт фактов.
Помощь с рамкой первой версии — Grevin, grevin.info@mail.ru, +7 993 302-62-55.