Как составить ТЗ на разработку: структура, чек-лист и пример
Техническое задание — документ, по которому разработчик оценивает и делает работу, а заказчик принимает результат. Разбираем, из чего оно состоит, как его написать и как проверить, что оно годится.
Что такое ТЗ и чем оно отличается от брифа
Техническое задание — это формализованное описание того, что должна делать система и по каким признакам мы поймём, что она сделана. Бриф описывает пожелания и контекст: «хотим интернет-магазин, как у конкурентов, для молодой аудитории». ТЗ превращает это в проверяемые требования: какие страницы, какие роли, какие сценарии, что происходит при ошибке.
Главный критерий хорошего ТЗ — любой участник проекта понимает его одинаково, а любое требование можно проверить: выполнено или нет.
Структура ТЗ: из чего оно состоит
- Цели и контекстЗачем нужен продукт, какую проблему он решает, какие бизнес-метрики хотим улучшить. Без этого разработчик оптимизирует не то.
- Аудитория и ролиКто пользуется системой: клиент, менеджер, администратор. Для каждой роли — что можно и чего нельзя.
- Пользовательские сценарииПошаговые пути: от входа до результата. Отдельно — нетипичные случаи: ошибка оплаты, пустые данные, потеря связи.
- Функциональные требованияЧто система должна делать, разложено до отдельных функций. Каждое требование — одно действие и один проверяемый результат.
- Нефункциональные требованияСкорость, безопасность, доступность, поддерживаемые браузеры и устройства, объёмы данных и нагрузка.
- Интеграции и данныеС какими системами обменивается данными продукт, какие данные хранит и кто за них отвечает.
- Ограничения и допущенияБюджет, сроки, технологии, что сознательно не входит в объём. Всё, что мы приняли на веру.
- Критерии приёмкиПо каждому ключевому пункту — условия, при которых он считается выполненным. Они защищают обе стороны от споров на сдаче.
Чек-лист: годится ли ваше ТЗ
- У документа есть цель, и она измерима
- Описаны все роли и права каждой из них
- Для основных функций есть сценарии, а для нетипичных случаев — поведение системы
- Каждое требование можно проверить: выполнено или нет
- Нет слов «быстро», «удобно», «современно» без конкретных критериев
- Указаны интеграции, данные и ограничения
- Есть критерии приёмки и порядок передачи результата
- Открытые вопросы вынесены в отдельный список и имеют ответственных
Типичные ошибки при составлении ТЗ
Самая частая ошибка — размытые формулировки. «Сайт должен быть удобным» невозможно ни реализовать, ни проверить. Вместо этого пишут измеримое: «пользователь оформляет заказ не более чем за три шага, на мобильном экране нет горизонтальной прокрутки».
Вторая ошибка — смешивать «что» и «как». ТЗ описывает результат и поведение системы, а не выбор технологий, если только технология не является ограничением. Третья — забывать про нетипичные случаи: именно они приводят к багам и спорам после релиза.
Четвёртая — документ без владельца. Если никто не отвечает за обновление ТЗ, оно устаревает уже на второй неделе. Назначьте человека, который ведёт версии и фиксирует решения.
Пример: как переписать размытое требование
Было: «Нужна удобная форма заявки». Стало: «Форма содержит поля имя, телефон и комментарий. Телефон проверяется на формат. После отправки пользователь видит сообщение об успехе, а менеджер получает уведомление в течение минуты. При ошибке сети данные не теряются, пользователь может повторить отправку».
Во втором варианте у разработчика нет простора для догадок, а у тестировщика — готовый список проверок. Именно так превращаются пожелания в требования.
Когда стоит доверить ТЗ специалисту
Если проект небольшой, с ТЗ справится сам заказчик по этой инструкции. Если в проекте несколько ролей, интеграции, сложные процессы или высокая цена ошибки, лучше привлечь аналитика: он задаст вопросы, о которых вы не подумали, и сразу выстроит документ в понятную структуру.
Я составляю ТЗ на заказ: от 8 часов работы по ставке 680 ₽ в час. Предварительную смету можно собрать в калькуляторе, а подробнее об услуге — на странице «Составление ТЗ на заказ».
Частые вопросы
Сколько страниц должно быть в ТЗ?
Объём определяется задачей, а не количеством страниц. Для небольшой функции хватает нескольких страниц, для сложного продукта — десятков. Важнее, чтобы требования были проверяемыми и без воды.
Кто должен писать ТЗ: заказчик или исполнитель?
Лучше всего — совместно. Заказчик знает цели и контекст, аналитик умеет формализовать требования и задавать уточняющие вопросы. ТЗ, которое пишет только исполнитель, часто описывает то, что ему удобно сделать.
Можно ли работать без ТЗ?
Для очень маленьких задач — да. Для всего остального отсутствие ТЗ означает, что требования будут «додумываться» по ходу, а спорные места всплывут на сдаче, когда исправлять дороже.
Читайте также
Начнём с честного разговора о задаче.
30–60 минут, без презентаций и продаж. Разберём задачу, и я скажу прямо, нужен ли я вообще.