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