Техническое задание: структура, требования и критерии приёмки
Без ТЗ проект быстро превращается в игру «Угадайка». Исполнитель додумывает, заказчик надеется, сроки растут, а в финале выясняется, что все «вспоминали договоренности иначе».
Нормальное ТЗ — это не 40 страниц текста. Это документ, который фиксирует: границы работ, сценарии, требования и критерии «готово». Мы уже провели декомпозицию задач и постановку целей, теперь пришло время зафиксировать это на бумаге перед тем, как отдавать задачу в дизайн и код.
Главное правило: ТЗ начинается с границ
Напишите две строки, и вы спасете 50% бюджета и нервов:
- Входит в задачу (Scope): Четкий список фич и страниц.
- НЕ входит в задачу (Out of scope): То, что мы сознательно откладываем или не делаем.
Авторское примечание: Пока эти границы не зафиксированы, фраза «А еще надо бы добавить...» будет преследовать вас до самого релиза.
Структура ТЗ: Скелет проекта
| Блок | Зачем это нужно? |
|---|---|
| Цель и метрики | Чтобы понимать, зачем мы вообще тратим деньги (например, +10% к конверсии). |
| User Stories | 2–6 ключевых сценариев. Как именно пользователь решит свою задачу. |
| Функционал | Что система должна уметь (кнопки, поля, логика). |
| Нефункционал | Скорость загрузки, безопасность, SEO, адаптивность. |
| Интеграции | Куда улетают данные (CRM, почта, аналитика) и что делать, если API «лежит». |
| Критерии приёмки | Список чек-боксов, после которых работа считается выполненной. |
Как писать требования, чтобы их поняли
Главный враг ТЗ — прилагательные «удобно», «красиво», «быстро». Разработчик не может запрограммировать «красоту».
Сравним подходы:
| Плохо (непроверяемо) | Хорошо (ТЗ здорового человека) |
| Сделать удобную форму | Поля валидируются в реальном времени; обязательные поля подсвечены красным при ошибке. |
| Сайт должен быстро грузиться | Скорость загрузки страницы по Google PageSpeed — не менее 90 баллов для Desktop. |
| Интегрировать с CRM | При сабмите формы данные передаются в метод POST /leads в формате JSON. |
Критерии приёмки: где заканчиваются споры
Критерии приёмки — это список “готово/не готово”, который закрывает вкусовщину.
Пример для формы сбора данных:
- обязательные поля валидируются, ошибки понятные;
- успех/ошибка отображаются корректно;
- заявка создаётся в CRM и содержит нужные поля;
- события аналитики фиксируются;
- на мобильном экране форма не ломает верстку;
- обработаны крайние случаи: нет сети, таймаут, дубль заявки.
Частая ошибка
Частая ошибка — написать ТЗ, отправить и считать, что “всё решено”. На практике документ начинает работать только после короткого цикла согласования. Лучший формат такой: сначала выравниваете понимание по scope/out of scope и сценариям (это 15–30 минут), затем уточняете требования и крайние случаи (ошибки, отсутствие сети, дубли, ограничения тарифов/ролей), и только потом фиксируете критерии приёмки. В конце обязательно назначается “владелец ТЗ” — человек, который собирает правки и ведёт версионность. Иначе документ превращается в чат с комментариями, где никто не знает, какая версия актуальная.
ТЗ — это не бюрократия, а страховка от “угадайки”. Один раз фиксируете границы, сценарии и критерии — и дальше работа идёт по рельсам. Важный нюанс: ТЗ не должно быть “идеальным”. Оно должно быть достаточным, чтобы команда одинаково понимала задачу и могла ответить на вопрос “готово или нет” без философии и вкусовщины. Если в процессе всплывают уточнения — это нормально. Ненормально, когда уточнения появляются в момент приёмки и превращаются в “мы думали, что вы сами догадаетесь”.
