Техническое задание — это документ, который описывает, что именно должно заработать после проекта и по какому признаку стороны признают, что оно заработало. Не список пожеланий и не презентация подрядчика, а текст, на который можно сослаться в споре: вот здесь написано, что система делает, вот здесь — как это проверяется, вот здесь — чего в проекте нет вовсе.
Ближайшая офисная аналогия — заказ кейтеринга на конференцию. Заявка «привезите еды на 40 человек» и заявка «40 порций, из них 6 без мяса, доставка к 18:30, посуда и вывоз мусора ваши, разогрев наш» стоят одинаково по времени написания. Но по первой спорить придётся голосом, а по второй — читать строчку. Разница не в объёме, а в наличии проверяемых границ.
Дальше — восемь блоков документа, разбор двух главных из них и модельный расчёт по состоянию на сентябрь 2026 года. Пример: оптовая компания мебельной фурнитуры, 34 человека, 90 дилеров, проект «личный кабинет дилера плюс обмен с 1С:УНФ» на 640 000 ₽ и 9 недель. Ставка инженера — 3 000 ₽/час, полная стоимость часа рядового сотрудника — 700 ₽.
Восемь блоков, без которых документ не работает
Приложение к договору, которое описывает результат работ настолько подробно, чтобы по нему можно было проверить готовность без участия автора. Отличается от брифа и коммерческого предложения одним признаком: в ТЗ есть критерии приёмки и раздел о том, что в работы не входит. В смете — отдельная позиция предпроектного обследования на 15–50 часов. Проверочный вопрос подрядчику: по какому пункту вы будете доказывать, что этап сдан.
Структура по ГОСТу здесь мало помогает: она писалась для другого типа проектов и добавляет разделы, которые никто не читает. Практический минимум — восемь блоков. Проверять документ проще всего наоборот: не читать подряд, а искать каждый из восьми и смотреть, что произойдёт, если его нет.
| Блок | Что в нём | Что будет, если его нет |
|---|---|---|
| 1. Границы работ | Перечень того, что делаем: экраны, обмены, отчёты, роли | Каждая сторона держит в голове свой объём, разница вскрывается на приёмке |
| 2. Что не входит | Прямой список работ, которых в проекте нет | Заказчик считает пункт входящим, подрядчик — дополнительным; спор без победителя |
| 3. Критерии приёмки | Проверяемые условия готовности с числами и выборкой | Готовность обсуждается словами «работает» и «не работает» |
| 4. Данные и доступы заказчика | Что и в каком виде предоставляет компания, к какому сроку | Сдвиг сроков без виноватого: подрядчик ждал выгрузку, заказчик не знал, что должен |
| 5. Сроки и зависимости | Этапы и что блокирует каждый из них | Просрочка есть, а причина спорная |
| 6. Порядок изменений | Что считается изменением объёма и по какой ставке оно считается | Любая правка становится переговорами о доброй воле |
| 7. Эксплуатация | Кто администрирует систему, что входит в гарантию, что в поддержку | После акта система остаётся без хозяина |
| 8. Ответственность | Что делает каждая сторона при сбое, утечке, срыве срока | Разбирательство начинается с выяснения, кто вообще за это отвечал |
Полный разбор каждого раздела с чек-листом проверки мы вынесли в отдельный материал про техническое задание на автоматизацию — здесь важнее другое: из восьми блоков спор решают два, второй и третий. Остальные шесть описывают задачу, а эти два описывают границу.
«Что не входит» — раздел, который защищает обе стороны
Этот блок кажется недоверием к подрядчику, а на деле он в равной степени защищает подрядчика от бесконечного расширения задачи и заказчика от неприятного открытия на приёмке. Пишется он не абстрактно, а по конкретным пунктам, которые собеседник мог считать входящими.
- Перенос данных. «Перенос 3 200 карточек дилеров из старой базы в работы не входит; заказчик предоставляет файл выгрузки в формате, согласованном на этапе 1». Без этой строки перенос всплывает за неделю до запуска.
- Обучение сотрудников. «Входит одна сессия на 2 часа для 6 ключевых пользователей и запись экрана. Обучение остальных и повторные сессии — отдельно».
- Мобильная версия. «Кабинет работает в браузере мобильного телефона. Отдельное приложение для App Store и RuStore не разрабатывается».
- Доработки смежной системы. «Изменения в конфигурации 1С:УНФ ограничены расширением обмена. Правки печатных форм и учётной логики выполняет обслуживающая 1С организация заказчика».
- Историческая отчётность. «Отчёты строятся по данным, появившимся после запуска. Пересчёт архивных периодов не входит».
В нашем модельном проекте отсутствовала ровно первая строка. Заказчик считал, что 3 200 карточек дилеров с реквизитами и индивидуальными ценами перенесёт подрядчик, подрядчик считал, что файл придёт от заказчика. Разбор занял 22 часа инженера — 66 000 ₽ — и сдвинул запуск на две недели, потому что чистка и сопоставление полей встали в график задним числом. Одна строка в ТЗ стоила бы ноль.
Критерии приёмки: как отличить проверяемый от непроверяемого
Критерий приёмки — это условие, которое два человека проверят независимо друг от друга и получат одинаковый ответ. Тест простой: можно ли по формулировке сказать «да» или «нет», не спрашивая автора. Если нельзя — это не критерий, а настроение.
| Формулировка из проекта КП | Проверяемо | Как переписать |
|---|---|---|
| Личный кабинет работает корректно | Нет | Дилер повторяет прошлый заказ не более чем за 3 минуты, проверено на 20 заказах |
| Остатки актуальны | Нет | Остаток в кабинете отличается от 1С:УНФ не более чем на 15 минут, проверено на 3 срезах в течение дня |
| Прайс выгружается полностью | Нет | Из 2 800 позиций прайса в кабинет попадают все 2 800, расхождение по номенклатуре — ноль строк |
| Система удобна для дилеров | Нет | 6 из 8 дилеров пилотной группы оформляют заказ без обращения к менеджеру, замер за 10 рабочих дней |
| Обмен стабилен | Нет | За 10 рабочих дней наблюдения не более 2 сбоев обмена, каждый восстанавливается повтором без ручного ввода |
Обратите внимание, что переписанные формулировки не требуют технических знаний — только числа и выборку. Их может написать сам заказчик, и это лучший способ проверить, что подрядчик понял задачу так же. Как договариваться о таких числах до старта работ, разобрано отдельно в материале как договориться о метриках до старта.
Кто платит за ТЗ и во что обходятся 18 часов обследования
Нормальная рыночная практика — оплачиваемое предпроектное обследование отдельной строкой, до договора на разработку. Логика простая: чтобы написать проверяемое ТЗ, нужно разобрать процесс, а разбор процесса — это работа, а не пресейл. Подрядчик, который делает её бесплатно, закладывает её в цену проекта либо не делает вовсе.
Восемь процентов — это внутри рыночной вилки: ТЗ обычно стоит 5–15 % бюджета проекта, и доля падает с ростом проекта. Отдельный разбор способов оплаты документа и условия о правах на него — в статье про цену ТЗ на автоматизацию; там же про то, почему бесплатный документ иногда оказывается привязкой к исполнителю.
Второй эффект обследования виден только при сравнении предложений. По внятному ТЗ три подрядчика дают сопоставимые сметы, по невнятному — разлетаются в разы, и сравнивать становится нечего. Механику этого разброса мы разбирали на примере одной задачи и пяти смет.
Четыре вопроса подрядчику до подписания
- 1Как оформляется изменение объёма работ? Правильный ответ — процедура и цифра: столько-то экранов и обменов входит, каждое дополнительное считается по такой-то ставке и оформляется допсоглашением с новой версией ТЗ. Ответ «решим по-человечески» означает, что решать будут в момент, когда вы уже зависимы.
- 2Кто со стороны подрядчика и заказчика подписывает приёмку этапа? Должны быть названы должности и порядок: кто проверяет, за сколько дней, что происходит при мотивированном отказе. Как это выглядит на практике, разобрано в материале про приёмку работ по автоматизации.
- 3Что происходит с ТЗ, если при разработке выяснится, что вводные были неверны? Нормальный ответ: работы приостанавливаются, разница оценивается в часах и рублях, вы принимаете решение до продолжения. Ненормальный: «доделаем как получится, потом обсудим».
- 4Кому принадлежит документ и можно ли передать его другому исполнителю? Если права не оговорены, ТЗ формально остаётся у автора, и уйти с ним к другому подрядчику нельзя. Одна фраза о переходе исключительного права в договоре снимает вопрос; порядок фиксации версий разобран в статье про ТЗ как приложение к договору.
В коммерческих предложениях часто стоит строка «настройка под ваши процессы» без единого числа. Она означает ровно то, что процессы ещё не разобраны и объём работ неизвестен ни одной из сторон. До подписания её нужно раскрыть в перечень: сколько маршрутов, сколько ролей, сколько исключений входит в цену. Что такое сам процесс и как его описать на одну страницу — в материале про бизнес-процесс и BPM.
Когда без ТЗ можно обойтись
Документ нужен не всегда, и требовать его ради солидности — способ потратить 54 000 ₽ на описание работы, которая стоит 80 000 ₽. Есть три случая, когда начинать без ТЗ нормально.
- 1Типовая настройка коробочного продукта. Воронка в CRM, права доступа, шаблоны писем — здесь функциональность задана вендором, а не подрядчиком. Хватает перечня настроек на страницу и списка полей.
- 2Короткий пилот со сроком до двух недель и фиксированной ценой. Проверяется одна гипотеза, критерий выхода помещается в три строки, а расходы ограничены суммой пилота. Как ставится критерий выхода — в статье про пилот и MVP.
- 3Одна задача без интеграций. Отчёт, форма, бот с четырьмя ответами — работа на 10–20 часов, где описание займёт столько же, сколько исполнение.
Во всех остальных случаях — а это любой проект с обменом между системами, с переносом данных или дороже примерно 300 000 ₽ — отсутствие ТЗ означает, что спор о готовности будет решаться голосом. Обычно побеждает тот, у кого больше времени и меньше зависимости от результата, и это редко заказчик.
Хорошее техническое задание отличается от красивого коммерческого предложения одним: по нему можно проверить готовность, не спрашивая того, кто его написал.
