Техническое задание на разработку: бриф для подрядчика без лишних переплат и переделок

Компания отдаёт подрядчику страницу текста, получает смету «с запасом», а потом бесконечные доработки и споры о том, что входило в работу. Исправляет это редко документ на сорок страниц. Хватает короткого текста, и техническое задание на разработку в виде брифа на две-три страницы доступно человеку без технического образования. Ниже структура такого документа, готовая к заполнению.

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

Агентства умеют кивать. Без письменного брифа каждая сторона представляет свой продукт, а разницу потом оплачивает заказчик в виде дополнительных счетов. Бриф на разработку делает предложения сравнимыми: когда три студии отвечают на одни вопросы, видна реальная разница в цене и подходе, а не три разных догадки. Это не договор, но основа для него. Составляйте документ до запроса сметы. Подрядчик быстрее оценит задание, если бриф написан простым языком. От обычного шаблона брифа он отличается тем, что описывает результат бизнеса, а не только пожелания к дизайну.

Цель и метрики успеха: какой бизнес-результат вам нужен

Начинайте с результата, а не со списка функций. Так проще понять, как составить бриф для проекта, которого ещё нет, и затем согласовать смету по техническому заданию на разработку. Напишите, что должно измениться для бизнеса: больше онлайн-заказов, меньше обращений в поддержку, быстрее расчёт стоимости, а готовый бриф поможет выбрать компанию по разработке по списку вопросов. Добавьте одну-две цифры, которые докажут успех, и дату проверки. «Лучший сайт» ничего подрядчику не даёт, а «сократить выставление коммерческого предложения с двух дней до двух часов» позволяет команде подобрать нужные инструменты.

Что входит в техническое задание на разработку и что явно не входит

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

Структура на две страницы, которую можно скопировать

Раздел	Что написать	Пример
Цель	Результат и цифра	КП за два часа вместо двух дней
Пользователи	Кто и что делает	Менеджер создаёт КП
Входит	Основные части простыми словами	Форма, PDF, связь с CRM
Не входит	Что исключаем	Перенос данных, мобильное приложение
Интеграции	Системы и данные	CRM, платёжный сервис
Приёмка	Как проверим	Десять сценариев проходят
Люди	Кто решает и как быстро	Один владелец, ответ за два дня

Пользователи, сценарии и интеграции с вашими системами

Опишите два-три реальных сценария: кто что делает, в каком порядке и что должна делать система на каждом шаге. Назовите все системы, которых коснётся проект, например CRM, учёт или платёжный сервис, и укажите, кто отвечает за доступ, это особенно важно для кабинета клиентов, ведь разработка личного кабинета почти всегда держится на таких связях. Скрытые интеграции частая причина того, что смета растёт после согласования, поэтому занесите их в бриф сразу и приложите снимки текущего процесса. Список интеграций в техническом задании на разработку подрядчик видит одним из первых. Когда вы ещё выбираете между вебом и приложением, сначала прочитайте что строить первым.

Требования к данным, безопасности и GDPR, а также к доступности

Напишите, с какими данными работает продукт и где их нужно хранить. Работа с техническим заданием на разработку без этой строки превращается в догадки. Если затрагиваются персональные данные жителей ЕС, подрядчику, который их обрабатывает для вас, нужен письменный договор, как требует статья 28 GDPR. По безопасности назовите базу вместо «должно быть безопасно», например OWASP Application Security Verification Standard. По доступности попросите соответствие WCAG 2.2 названного уровня. Эти строки почти ничего не стоят в брифе. Добавленные поздно, они очень дорого обходятся.

Сроки, этапы приёмки и кто принимает решения

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

1. Запишите, что покажут на каждом этапе.
2. Определите проверку: сценарии, устройства, данные.
3. Договоритесь, кто подписывает и за сколько дней.
4. Решите, как оцениваются и согласуются изменения.

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

Какие вопросы задаёт хороший подрядчик и что значит, если он молчит

Хорошая команда задаёт вопросы до сметы. Ждите таких:

• Какой бизнес-результат нужен и как вы его измерите?
• Кто пользователи и кто принимает решения на вашей стороне?
• К каким системам нужно подключиться и кто владеет доступом?
• Какой диапазон бюджета и жёсткий срок, если он есть?
• Что нельзя менять, а что может подождать до второй версии?

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