Техническое задание на разработку ПО: как составить, что включить и почему без него теряют деньги
Техническое задание (ТЗ) на разработку ПО — это документ, который описывает, что именно должна делать система, как она должна работать и чего от неё ждут пользователи и бизнес. Без него разработка превращается в игру в телефон: вы думали одно, программисты сделали другое, деньги потрачены. По данным Standish Group, 52% IT-проектов выходят за рамки бюджета именно из-за размытых требований на старте.
Последнее обновление: апрель 2026
Что такое техническое задание и зачем оно нужно бизнесу
Техническое задание — это не документ для программистов. Это ваш договор с разработчиком о том, что именно войдёт в продукт, в какие сроки и за какие деньги. Директор торговой компании из Екатеринбурга заказал CRM без ТЗ: через 4 месяца получил систему, в которой нельзя выгружать отчёты в Excel. Разработчик сказал: «Вы не просили». Переделка обошлась ещё в 300 000 рублей.
Техническое задание решает три задачи:
- Фиксирует объём работ — нет ТЗ, нет чёткой цены и сроков
- Защищает бюджет — любое «а ещё добавьте» теперь платная доработка
- Служит приёмочным документом — есть ли соответствие тому, что заказывали
На devrum.ru мы не берём проект в работу без ТЗ или хотя бы его первой версии. Не потому что бюрократия, а потому что так проекты реально заканчиваются вовремя.
Чем грозит разработка без технического задания
Числа говорят лучше слов:
- +40% к бюджету в среднем получают проекты, начатые без формализованных требований (McKinsey, 2023)
- Срыв сроков в 2,5 раза — типичная история для «давайте начнём, разберёмся по ходу»
- 30% функций выбрасываются при финальной приёмке, если требования не были согласованы письменно
Конкретный пример: логистическая компания заказала систему отслеживания грузов. Устная договорённость была «чтобы диспетчер видел машины на карте». Разработчик сделал карту. Заказчик хотел ещё уведомления водителям, журнал инцидентов и интеграцию с 1С. Итог: 8 месяцев вместо 3, бюджет вырос с 600 000 до 1,4 млн рублей.
Что включает техническое задание на разработку: структура по ГОСТ
ГОСТ 34.602-89 и ГОСТ Р ИСО/МЭК 29148-2013 описывают стандартную структуру ТЗ. В коммерческой разработке её упрощают, но суть не меняется.
Общее описание системы и цели
Первый раздел отвечает на вопрос «зачем это всё». Не «хочу CRM», а «хочу сократить время обработки заявки с 24 часов до 2 часов, снизить потери клиентов на стадии первого контакта с 35% до 15%». Конкретные цифры здесь — основа для оценки успеха проекта после запуска.
Функциональные требования
Это список того, что система умеет делать. Каждая функция описывается через сценарий: кто делает действие, при каких условиях, что получает на выходе. Например: «Менеджер создаёт заявку, выбирает клиента из базы, система автоматически подставляет его контакты и историю покупок». Чем точнее описание, тем ниже риск недопонимания.
Нефункциональные требования и ограничения
Здесь прописывают: сколько пользователей одновременно, какая нагрузка, какое время отклика (не дольше 2 секунд), с какими браузерами/устройствами должно работать, какие данные нельзя хранить за рубежом (152-ФЗ). Эти требования влияют на архитектуру, а значит, на стоимость.
Интеграции с внешними системами
Список всех систем, с которыми должно работать ПО: 1С, Битрикс24, API банка, телефония, склад. Для каждой интеграции указывается направление данных и формат. Интеграции — самая трудоёмкая часть разработки, и именно они чаще всего «всплывают» как неожиданные расходы.
Сроки, этапы и критерии приёмки
Разработку разбивают на этапы: прототип, MVP, полный релиз. Для каждого этапа указывают дату и список функций, которые должны работать. Это критически важно: если нет критериев приёмки, «готово» означает разное для разработчика и заказчика.
Пример технического задания: фрагмент для CRM
Вот как выглядит рабочий фрагмент ТЗ на разработку CRM для торговой компании (реальный пример из нашей практики, данные обезличены):
Функция: создание карточки клиента
Пользователь: менеджер по продажам
Условие: пользователь авторизован, находится в разделе «Клиенты»
Действие: нажимает «Добавить клиента», заполняет поля (ИНН обязателен)
Результат: карточка создана, ИНН проверен через API ФНС (за 3 секунды), дублирование заблокировано
Исключение: если ИНН уже есть в базе — система показывает ссылку на существующую карточку
Этот фрагмент занял 10 минут на написание, но сэкономил 2 итерации исправлений, каждая из которых стоила бы 1-2 дня разработки и 15 000-25 000 рублей. Образец технического задания в таком формате можно запросить у нас перед началом проекта.
Как составить ТЗ самостоятельно: 5 шагов для директора
Вы не обязаны знать стандарты ГОСТ, чтобы написать хорошее ТЗ. Нужно ответить на правильные вопросы:
- Опишите проблему, не решение. «Менеджеры забывают перезвонить клиентам» — это проблема. «Сделайте напоминания» — это уже решение, которое может быть неоптимальным. Разработчик предложит лучшее решение, если понимает проблему.
- Перечислите всех пользователей системы. Кто заходит, что делает, чего не видит. Права доступа — это не мелочь, это архитектурное решение.
- Напишите список «это должно быть точно». 10-15 конкретных функций, без которых система бесполезна. Это ваш MVP.
- Назовите все системы, с которыми нужна интеграция. Даже если «это же просто выгрузка в Excel» — напишите явно.
- Зафиксируйте ограничения: бюджет, срок, платформа. «Хочу готово через 3 месяца и не больше 500 000 рублей» — это тоже требование, и оно меняет объём работ.
Если писать ТЗ некогда — это нормально. В devrum.ru мы проводим discovery-фазу разработки, на которой помогаем сформулировать требования за 3-5 рабочих дней. Стоимость discovery входит в бюджет проекта, если вы продолжаете с нами работу.
Техническое задание и договор: в чём разница
Договор регулирует юридические отношения: кто платит, когда, что происходит при нарушениях. ТЗ является приложением к договору и описывает техническую суть работы. Именно ТЗ становится основой для оценки — выполнил ли разработчик то, за что заплатили.
Принципиальная ошибка: подписать договор без ТЗ или с ТЗ в одно предложение («разработать CRM систему»). В случае спора суд будет оценивать именно ТЗ. «Разработать CRM систему» — это не требование, это намерение.
В нашей практике разработки корпоративного ПО ТЗ проходит согласование в 2-3 итерации. Это норма. Если исполнитель говорит «ТЗ не нужно, я всё понял» — это красный флаг.
Разработка технического задания: стоит ли платить за это отдельно
Зависит от масштаба проекта:
- Проекты до 300 000 рублей: ТЗ часто пишется совместно в процессе работы, его стоимость включена в разработку
- Проекты от 300 000 до 1 000 000 рублей: отдельная discovery-фаза на 3-5 дней, стоимость 30 000-80 000 рублей; эти деньги окупаются экономией на переделках
- Проекты свыше 1 000 000 рублей: полноценный аналитический этап на 2-4 недели с UML-диаграммами, прототипами, согласованием с заинтересованными сторонами
Правило простое: чем больше людей будет пользоваться системой и чем дольше она должна работать — тем важнее инвестиция в качественное ТЗ. Система на 50 пользователей на 5 лет работы требует другого уровня проработки, чем MVP для теста гипотезы за 4 недели.
Если вы думаете о разработке мобильного приложения для бизнеса или внедрении ERP, начните с фиксации требований. Это сэкономит от 30 до 50% бюджета на исправления.
Часто задаваемые вопросы о техническом задании
Сколько страниц должно быть в техническом задании?
Зависит от проекта. Простой корпоративный портал — 15-25 страниц. Система управления складом с интеграциями — 50-80 страниц. Ориентир: каждая функциональная область занимает 3-7 страниц описания. Слишком короткое ТЗ (2-3 страницы на сложный проект) — тревожный сигнал.
Кто должен писать техническое задание — заказчик или разработчик?
Хорошее ТЗ всегда пишется совместно. Заказчик знает бизнес-процессы и цели. Разработчик знает, как технически это реализовать. Бизнес-аналитик (или опытный разработчик) задаёт правильные вопросы и оформляет требования в документ. Если разработчик пишет ТЗ самостоятельно без погружения в ваши процессы — он описывает свои предположения, а не вашу реальность.
Можно ли обойтись без ТЗ при гибкой разработке (Agile)?
В Agile ТЗ заменяется backlog-ом пользовательских историй (user stories), но суть та же — требования должны быть зафиксированы до начала разработки каждого спринта. «Мы работаем по Agile» не означает «у нас нет требований». Это означает «требования уточняются итерационно, но каждая итерация — это чёткий список задач».
Что делать, если требования меняются в процессе разработки?
Это нормально и неизбежно. Процедура change request: изменение фиксируется письменно, оценивается стоимость и сроки, вносится в ТЗ как дополнение, затем уходит в разработку. Разработчик не должен принимать устные изменения без фиксации в документе. Хаотичные изменения без контроля — главная причина смерти IT-проектов.