Техническое задание на разработку: как составить ТЗ, по которому можно посчитать смету

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

Техническое задание на разработку — документ, о котором спорят больше, чем о любом другом в проекте. Одни заказчики приходят с ТЗ на двести страниц и удивляются, что смета всё равно получается вилкой. Другие приходят с одной фразой и удивляются, что их просят потратить две недели на аналитику. Обе ситуации нормальны, и обе решаются одинаково: нужно понимать, зачем ТЗ существует, кто его пишет и что в нём должно быть, чтобы по нему можно было посчитать деньги и сроки. Ниже — практическое руководство для компании, которая заказывает сайт, веб-сервис или мобильное приложение: чем бриф отличается от ТЗ, какие разделы обязательны, как формулировать требования так, чтобы их нельзя было понять двумя способами, и где проходит граница между «достаточно подробно» и «пишем документ ради документа». Зачем вообще нужно техническое задание ТЗ решает три задачи, и важно не путать их между собой. Договорённость об объёме. Документ фиксирует, что именно будет сделано. Без этого любой спор о приёмке превращается в спор о воспоминаниях: заказчик помнит, что просил, исполнитель помнит, что не обещал. Основа для оценки. Смету считают по списку работ, а список работ выводится из требований. Чем меньше неопределённости в требованиях, тем уже вилка цены и сроков. Инструкция для команды. Дизайнер, разработчик и тестировщик работают по одному описанию. Если описания нет, каждый достраивает недостающее по-своему, и расхождения всплывают на приёмке. Отсюда главный вывод: ТЗ ценно ровно настолько, насколько оно снимает неопределённость. Документ, который подробно описывает очевидное и молчит о спорном, бесполезен при любом объёме. Бриф, концепция, ТЗ: в чём разница Путаница в названиях — первая причина, по которой заказчик и подрядчик говорят о разном. Разложим документы по стадиям проекта. Бриф Бриф заполняет заказчик до начала работ. Это описание задачи на языке бизнеса: что за компания, какую проблему решаем, кто пользователи, какой результат считаем успехом, какие есть ограничения по срокам и бюджету, с какими системами продукт должен работать. Бриф занимает несколько страниц и не требует технических знаний. Его цель — дать подрядчику достаточно контекста, чтобы задать правильные вопросы и назвать порядок бюджета. Концепция или предпроектное исследование Промежуточная стадия, которую часто пропускают и потом жалеют. Здесь проверяются гипотезы: действительно ли пользователям нужно то, что заложено в бриф, какие сценарии главные, что можно отложить. Результат — карта пользовательских сценариев, прототипы ключевых экранов, список интеграций и первые архитектурные решения. На крупном проекте эта стадия занимает от двух до шести недель и почти всегда окупается: ошибка, найденная на прототипе, стоит часы, та же ошибка в готовом коде стоит недели. Техническое задание ТЗ пишется на основе брифа и концепции. Это уже описание продукта на языке, понятном команде разработки: функциональные требования, нефункциональные требования, интеграции, роли и права, критерии приёмки. По ТЗ считается детальная смета и строится план работ. Если у вас есть только бриф, это не проблема. В нашем материале о выборе подрядчика мы прямо пишем: для первого разговора описания задачи достаточно, а ТЗ, написанное без участия разработчика, обычно приходится переделывать. Причина не в квалификации заказчика, а в том, что часть требований невозможно сформулировать, не понимая, как они будут реализованы. Кто должен писать ТЗ На этот вопрос есть три распространённых ответа, и у каждого своя цена. Заказчик пишет сам Плюс — заказчик лучше всех знает свой бизнес. Минус — он не знает, какие решения дорогие, а какие дешёвые, и не видит технических последствий формулировок. Типичный результат: подробно описаны экраны, которые можно было взять из готового решения, и одной строкой упомянута «интеграция с 1С», которая на деле съедает треть бюджета. Такое ТЗ полезно как расширенный бриф, но смету по нему подрядчик всё равно будет уточнять. Пишет подрядчик в рамках отдельного этапа Самый надёжный вариант для проектов среднего и крупного размера. Аналитик подрядчика проводит интервью с сотрудниками заказчика, изучает текущие процессы и системы, собирает требования и оформляет их. Этап оплачивается отдельно, а его результат принадлежит заказчику. Это важно: с готовым ТЗ компания может запросить оценку у других команд и сравнить предложения по одному документу, а не по разным интерпретациям одной идеи. Пишет независимый аналитик или внутренний продакт Разумный компромисс, если в компании уже есть продуктовая функция. Риск — документ получится корректным с точки зрения бизнеса, но без учёта ограничений конкретного стека. Снимается ревью ТЗ со стороны будущей команды разработки до подписания договора. Во всех трёх случаях работает одно правило: ТЗ должно пройти через руки тех, кто будет его реализовывать, до того как по нему зафиксирована цена. Иначе фиксированная стоимость превращается в лотерею, где проигравший определяется на приёмке. Структура технического задания Жёсткого стандарта для коммерческой разработки нет. ГОСТ 34.602 существует и обязателен в ряде государственных закупок, но для продуктовой разработки его структура избыточна и плохо ложится на итеративную работу. Ниже — состав разделов, который закрывает всё необходимое для оценки и приёмки. 1. Цели и контекст Одна-две страницы: что за продукт, зачем он создаётся, какие бизнес-метрики должен сдвинуть. Раздел кажется формальным, но именно он позволяет команде принимать правильные решения там, где требования молчат. Если разработчик знает, что цель — сократить время обработки заявки, он не станет усложнять интерфейс ради второстепенной функции. 2. Пользователи и роли Кто работает с системой и что каждому разрешено. Не «пользователь и администратор», а конкретные роли: менеджер отдела продаж, руководитель отдела, бухгалтер, внешний партнёр. Для каждой роли — какие данные видит, что может менять, какие действия требуют подтверждения. Ролевая модель — одно из мест, где недоописанность дорого обходится: права доступа, добавленные после запуска, затрагивают почти все экраны. 3. Пользовательские сценарии Главная часть документа. Сценарий описывает, как конкретная роль достигает конкретной цели: «Менеджер получает новую заявку с сайта, проверяет контакт на дубли, назначает себя ответственным и назначает звонок». Хорошо описанный сценарий содержит: исходное состояние — что должно быть до начала; шаги — действия пользователя и реакция системы; альтернативные ветки — что происходит, если данных нет, если контакт уже существует, если у пользователя нет прав; результат — в каком состоянии система после завершения. Альтернативные ветки — то, что чаще всего забывают. Основной путь пишется за минуту, а обработка ошибок, пустых состояний и пограничных случаев составляет значительную часть реальной работы. 4. Функциональные требования Детализация сценариев до уровня конкретных функций: поля форм и правила их проверки, фильтры и сортировки, уведомления и их триггеры, отчёты и их содержимое. Удобный формат — таблица с номером требования, описанием, приоритетом и ссылкой на сценарий. Нумерация нужна не для красоты: на неё потом ссылаются в смете, в плане работ и в акте приёмки. 5. Нефункциональные требования Раздел, который определяет архитектуру и сильнее всего влияет на цену, но почему-то заполняется в последнюю очередь. Сюда входят: Нагрузка. Сколько пользователей одновременно, сколько записей в базе через год, какие пики. Система на сто пользователей и система на сто тысяч — разные проекты. Производительность. Допустимое время ответа ключевых операций. Формулировка «быстро» не годится; годится «список заявок открывается не дольше двух секунд при ста тысячах записей». Доступность. Сколько простоя допустимо. Разница между «можно остановить на ночь для обновления» и «работает круглосуточно без плановых окон» — это разница в инфраструктуре и процессах выкладки. Безопасность и данные. Хранятся ли персональные данные, где физически должны находиться серверы, какие требования 152-ФЗ применимы, нужна ли двухфакторная авторизация. Поддерживаемые платформы. Браузеры и их версии, минимальные версии iOS и Android, нужна ли работа без сети. Доступность для людей с ограничениями. Нужно ли соответствие WCAG и на каком уровне. 6. Интеграции Для каждой внешней системы — отдельный подраздел: какая система, какие данные и в каком направлении передаются, с какой частотой, есть ли у системы документированный API, кто со стороны заказчика даёт доступы и отвечает за её работу. Интеграции — главный источник срывов сроков. Причина почти никогда не в сложности кода: тестовый стенд не выдали, документация устарела, ответственный за систему в отпуске. Поэтому в ТЗ полезно прямо указывать, какие действия ожидаются от заказчика. 7. Данные и миграция Если продукт заменяет существующую систему, нужно описать, какие данные переносятся, в каком объёме и в каком они состоянии. Перенос «как есть» из системы, где десять лет вводили данные вручную, почти никогда не бывает простым: дубли, пустые обязательные поля, разные форматы телефонов и дат. Отдельно стоит решить, кто отвечает за очистку данных и что делать с записями, которые не проходят проверку. 8. Дизайн и контент Есть ли фирменный стиль и дизайн-система, кто готовит тексты и изображения, на каком этапе контент должен быть передан команде. Отсутствие контента к моменту вёрстки — классическая причина, по которой готовый продукт неделями не запускается. 9. Критерии приёмки Как именно стороны поймут, что требование выполнено. Для функциональных требований это обычно проверяемый сценарий, для нефункциональных — измеримый порог. Критерии приёмки превращают субъективное «мне не нравится» в объективное «не выполнено требование 4.12». 10. Что не входит в проект Раздел, который экономит больше всего нервов. Явный список того, что в текущий объём не включено: мобильная версия, английская локализация, перенос архивных данных старше трёх лет, интеграция со второй учётной системой. Если чего-то нет в этом списке и нет в требованиях, стороны будут по-разному помнить, обсуждалось ли это. Как формулировать требования Структура — половина дела. Вторая половина — формулировки. Одно и то же требование можно записать так, что по нему оценят работу в десять часов или в сто. Требование должно быть проверяемым Плохо: «Система должна быть удобной». Хорошо: «Новый сотрудник без обучения создаёт заявку за три минуты или быстрее; проверяется на пяти сотрудниках, не работавших с системой». Плохо: «Сайт должен быстро загружаться». Хорошо: «Главная страница на мобильном соединении 4G отображает основной контент не позднее чем через 2,5 секунды по метрике LCP». Требование должно быть однозначным Плохо: «Пользователь может выгрузить отчёт». Какой отчёт, в каком формате, за какой период, с какими полями, для каких ролей? Хорошо: «Руководитель отдела выгружает в XLSX список сделок за выбранный период с полями: дата, клиент, менеджер, сумма, этап; выгрузка до 50 000 строк выполняется не дольше минуты». Требование описывает что, а не как Плохо: «Использовать выпадающий список из 200 городов». Хорошо: «Пользователь выбирает город доставки из справочника; поиск по первым буквам». Первая формулировка навязывает интерфейсное решение, которое для двухсот вариантов неудобно. Вторая оставляет дизайнеру пространство найти лучшее. Исключение — когда «как» действительно важно для бизнеса: корпоративный стандарт требует определённой СУБД, серверы должны располагаться в России, продукт должен работать на уже купленной платформе. Такие ограничения записываются явно и отдельно, с объяснением причины. Слова, которые стоит вычеркнуть В ТЗ не место словам, которые каждый понимает по-своему: «удобный», «современный», «быстрый», «интуитивный», «при необходимости», «и т. д.», «и другие», «гибкий», «масштабируемый» без цифр. Каждое такое слово — место будущего спора. Если без него не обойтись, за ним должна следовать конкретика: «масштабируемый — выдерживает десятикратный рост числа пользователей добавлением серверов без переработки кода».