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

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

Зачем ТЗ заказчику, а не подрядчику

• Получить от разных исполнителей предложения, которые можно сравнить между собой.
• Зафиксировать объём работ до подписания договора, а не в процессе разработки.
• Отделить обязательные требования от желательных и управлять составом первой версии.
• Принять результат по заранее согласованным критериям.

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

Что должно быть в техническом задании

Состав зависит от проекта, но в ТЗ на цифровое решение обычно входят:

• Цели проекта и бизнес-задача — зачем всё это делается и как будет оцениваться результат.
• Пользователи и роли — кто будет работать с системой и с какими правами.
• Ключевые сценарии — что пользователь делает от начала до конца, включая исключения.
• Функциональные требования — что система должна уметь, сгруппированное по модулям или ролям.
• Нефункциональные требования — производительность, надёжность, безопасность, требования к инфраструктуре.
• Данные и интеграции — откуда берутся данные, с какими системами нужен обмен и в каком формате.
• Границы проекта — что входит в первую версию, а что сознательно отложено.
• Критерии и порядок приёмки — как будет проверяться, что требования выполнены.

Типичные ошибки

Требования без приоритета. Когда все пункты одинаково обязательны, подрядчик закладывает максимум, и бюджет вырастает. Разделите требования хотя бы на обязательные и желательные.

Описание интерфейса вместо задачи. «Кнопка выгрузки в правом верхнем углу» — это решение, которое ограничивает исполнителя. «Руководитель отдела раз в неделю получает отчёт о выполнении плана в формате Excel» — это требование, под которое можно предложить разные решения.

Забытые интеграции и данные. Обмен с учётной системой, перенос исторических данных, справочники — именно здесь чаще всего возникают незапланированные работы.

Отсутствие критериев приёмки. Без них приёмка превращается в переговоры, а результат зависит от того, кто настойчивее.

Как понять, что ТЗ готово

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

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