Техническое задание на разработку: структура и чеклист ТЗ

Зачем нужно техническое задание на разработку

Техническое задание (ТЗ) фиксирует, что именно строит подрядчик и как вы проверите результат. Без него стороны по-разному понимают объём работ, и спор возникает в момент приёмки, когда исправлять дороже всего.

Цифры это подтверждают. В исследовании PMI Pulse of the Profession 47% неуспешных проектов не достигли целей из-за неточного управления требованиями. Инженеры NASA оценили, как растёт цена ошибки в требованиях: если исправление на этапе требований принять за 1 единицу, на этапе проектирования оно стоит 3–8 единиц, на интеграции и тестировании — 21–78, а в эксплуатации — от 29 до более чем 1 500 единиц.

Хорошее ТЗ решает три задачи:

• даёт основу для оценки — подрядчик считает сроки и бюджет по списку требований, а не по общему описанию идеи;
• задаёт правила приёмки — у каждой функции есть критерий, по которому видно, сделана она или нет;
• отделяет объём от «хотелок» — всё, что не вошло в ТЗ, обсуждается как отдельная доработка.

Бриф, ТЗ и договор: в чём разница

Бриф — это анкета для первой оценки, ТЗ — детальное описание системы, а договор — юридическая рамка, к которой ТЗ прикладывается как приложение. Путать их не стоит: бриф заполняет заказчик за вечер, ТЗ обычно готовят вместе с аналитиком подрядчика.

В Win to Win этот порядок отражён в шаблонах: бриф на разработку занимает 3 страницы и помогает быстро оценить проект, а техническое задание оформлено как Приложение №1 к договору. Если между ТЗ и договором есть противоречие, в шаблоне W2W применяются положения договора.

Структура ТЗ: 12 ключевых разделов

Минимальное рабочее ТЗ отвечает на вопросы «зачем», «для кого», «что именно», «с чем связано», «когда» и «как принимаем». Ниже — структура, на которой построен шаблон W2W (всего в нём 15 разделов, включая термины, исключения и подписи):

1. Общие сведения — название системы и цель в измеримом виде: не «ускорить работу», а «сократить обработку заявки с 2 часов до 15 минут».
2. Текущее состояние и проблемы — как процесс устроен сейчас, какие таблицы и программы используются, где теряется время.
3. Состав системы — модули: веб-кабинет, админ-панель, мобильное приложение, интеграции.
4. Роли и права доступа — кто что может делать и чего не может.
5. Функциональные требования — пронумерованный список (ФТ-1.1, ФТ-1.2…) с критерием приёмки у каждого пункта.
6. Нефункциональные требования — скорость, поддерживаемые браузеры и версии ОС, языки интерфейса, резервное копирование.
7. Безопасность и размещение — где стоит сервер, как выдаются доступы, ведётся ли журнал действий.
8. Интеграции — с какими системами обмен, какие данные, в каком направлении и кто даёт доступ.
9. Данные и материалы от заказчика — доступы, тексты, справочники, сроки и ответственные.
10. Этапы, сроки и результаты — что сдаётся после каждого этапа.
11. Порядок приёмки — где и на каких данных проверяется результат.
12. Работы вне ТЗ — что точно не входит в объём.

Для крупных государственных и корпоративных систем в странах СНГ часто опираются на межгосударственный ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы»: он вступил в силу 1 января 2022 года и заменил версию 1989 года. Для коммерческого веб-сервиса или мобильного приложения такой объём обычно избыточен — достаточно разделов выше.

Как писать требования, чтобы их можно было принять

Требование хорошее, если по нему можно однозначно сказать «сделано» или «не сделано». Для этого у каждого пункта должен быть критерий приёмки — конкретная проверка, а не оценка «удобно» или «быстро».

Международный стандарт требований ISO/IEC/IEEE 29148 перечисляет девять характеристик качественного требования: необходимое, уместное, однозначное, полное, единичное (одна функция в одном пункте), выполнимое, проверяемое, корректное и соответствующее принятому формату. На практике достаточно трёх проверок:

• одна функция — один пункт: «пользователь входит по логину и паролю и может восстановить пароль» — это уже две функции, их стоит разделить или принимать вместе осознанно;
• нет оценочных слов: вместо «быстрая загрузка» — «страница открывается не дольше 2 секунд при 100 одновременных пользователях»;
• есть критерий приёмки: «заблокированный пользователь не может войти» проверяется за минуту.

Сравните два варианта одного требования:

Нефункциональные требования: что чаще всего забывают

Нефункциональные требования описывают не что система делает, а как она работает: скорость, совместимость, надёжность и безопасность. Именно их чаще всего пропускают, а потом выясняется, что приложение не работает на старых телефонах или база не копируется.

Минимум, который стоит записать в ТЗ:

• производительность — время открытия страницы при заданном числе одновременных пользователей;
• совместимость — браузеры (например, актуальные Chrome, Safari, Edge и Firefox), минимальная ширина экрана для адаптивной вёрстки (в шаблоне W2W — от 360 px), минимальные версии iOS и Android;
• языки интерфейса — для Узбекистана это обычно русский, узбекский и английский; от этого зависят объём текстов и тестирования;
• дизайн — по чьему фирменному стилю и сколько итераций согласования макетов входит в цену;
• надёжность — частота резервного копирования (в шаблоне W2W — не реже раза в сутки) и срок хранения копий;
• безопасность — персональные учётные записи для доступа к серверу, журнал действий администраторов, HTTPS.

Если система обрабатывает персональные данные клиентов, требования к месту хранения данных стоит записать в ТЗ отдельно и сверить с действующим законодательством до начала разработки.

Частые ошибки в ТЗ

Большинство ошибок связаны не с технологиями, а с тем, что в документе чего-то не хватает. Проверьте свой текст по этому списку:

• нет измеримой цели — потом невозможно понять, достиг ли проект результата;
• не описаны роли — права доступа «всплывают» на тестировании и ломают логику;
• интеграции названы, но не расписаны — неизвестно, кто даёт доступы к внешней системе и какие данные идут в каждую сторону;
• не указаны обязательства заказчика — тексты, справочники и доступы приходят с опозданием, и сроки едут; в шаблоне W2W прямо записано, что задержка материалов соразмерно переносит сроки работ;
• нет раздела «что не входит» — наполнение контентом, фирменный стиль, лицензии и серверы считаются «само собой разумеющимися»;
• решение вместо задачи — заказчик описывает конкретную кнопку, а не проблему пользователя, и лишает команду возможности предложить вариант проще.

Чеклист ТЗ перед подписанием

Перед тем как утвердить ТЗ, пройдитесь по 10 вопросам. Если на какой-то нет ответа в документе — это зона риска.

1. Записана ли цель системы с цифрой?
2. Перечислены ли все модули и платформы?
3. Есть ли таблица ролей с правами и ограничениями?
4. У каждого функционального требования есть номер и критерий приёмки?
5. Указаны ли скорость, браузеры, версии iOS и Android, языки интерфейса?
6. Определено, где размещается система и как хранятся резервные копии?
7. Для каждой интеграции понятны данные, направление, способ и владелец доступа?
8. Есть ли список материалов от заказчика со сроками и ответственными?
9. Разбиты ли работы на этапы с понятным результатом каждого?
10. Есть ли раздел «работы, не входящие в ТЗ»?

ТЗ не обязано быть финальным до первой строки кода. При гибком подходе его уточняют на этапе аналитики и дизайна, а модель оплаты выбирают под степень определённости — подробнее в статье Fixed Price или Time & Materials.

С чего начать

Начните с брифа: опишите задачу, пользователей, обязательные к запуску функции и интеграции. Это займёт меньше часа и даст подрядчику достаточно данных для первой оценки.

Дальше порядок такой:

• скачайте бриф и шаблон ТЗ — те же формы, по которым W2W работает с клиентами (PDF для просмотра, DOCX для заполнения);
• запишитесь на 30-минутный созвон — разберём задачу, после чего W2W готовит коммерческое предложение за 2–3 дня;
• посмотрите, как устроен процесс работы: ТЗ и архитектура утверждаются на этапе проектирования, до начала разработки.