Главная / Блог / Как составить техническое задание на разработку

Процесс разработки

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

Большинство проблем в разработке — срыв сроков, перерасход бюджета, «получилось не то» — начинаются не в коде, а на этапе постановки задачи. Техническое задание (ТЗ) — это документ, который переводит бизнес-идею на язык, понятный и заказчику, и команде. Разбираем, зачем оно нужно и что в нём должно быть.

Зачем нужно ТЗ

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

Что включить в техническое задание

• Цель и контекст. Какую бизнес-задачу решает продукт, кто им пользуется и зачем. Это важнее списка кнопок — именно цель помогает принимать решения по спорным местам.
• Роли и сценарии. Какие типы пользователей есть (клиент, менеджер, администратор) и что каждый из них делает в системе.
• Функциональные требования. Перечень функций и экранов с описанием поведения — что происходит при каждом действии.
• Интеграции. С какими системами нужно связать продукт: 1С, CRM, платёжные сервисы, телефония, госсистемы. Интеграции часто недооценивают по сложности (когда нужны интеграции).
• Нефункциональные требования. Нагрузка, скорость, безопасность, требования к данным (например, 152-ФЗ), поддерживаемые устройства и браузеры.
• Границы проекта. Что в задачу НЕ входит — это не менее важно, чем то, что входит.

Кто составляет ТЗ

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

Частые ошибки

• Слишком общо: «сделайте удобный личный кабинет» — без описания функций и ролей.
• Слишком жёстко и рано: детальное ТЗ на 100 страниц до проверки гипотезы. Для нового продукта разумнее начать с MVP (MVP за 6–8 недель) и уточнять требования по ходу.
• Нет приоритетов: когда «всё важно», невозможно разумно резать объём при ограниченном бюджете.
• Забыты интеграции и нефункциональные требования — потом они оказываются самой трудоёмкой частью.

Хорошая новость

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

Частые вопросы