Рабочее техническое задание на автоматизацию состоит из одиннадцати разделов: цели и показатели, границы, процессы «как есть» и «как будет», роли, функциональные требования, интеграции, данные и миграция, нефункциональные требования, безопасность и персональные данные, обучение и документация, порядок приёмки. Порядок именно такой: сначала фиксируется, ради чего всё затевалось, потом — чего в проекте не будет, и только затем описывается содержание работ.
Дальше — не рассуждение о пользе документа, а сам скелет. По каждому разделу: что в него пишут одной строкой, что происходит в проекте, когда его пропускают, и как раздел выглядит заполненным. Заполняем всё на одной понятной задаче — приём и распределение заявок в сервисно-монтажной компании на 40 человек. Числа в примере сквозные: они не меняются от раздела к разделу, и в конце по ним же считается, сколько времени заказчика съедает документ.
Зачем ТЗ вообще нужно, чем оно отличается от коммерческого предложения и как по нему сходятся оценки разных подрядчиков — мы разбирали в отдельном материале журнала. Здесь предполагается, что писать документ вы уже решили, и нужен каркас, который можно взять и заполнить.
Одиннадцать разделов и цена каждого пропуска
Третья колонка в таблице ниже — не список рисков, а счёт. Все суммы взяты из одного модельного проекта на 780 000 ₽, который описан в следующем разделе, и в конце статьи собраны в общий итог. Смысл колонки простой: раздел, который выглядит формальностью при написании, имеет вполне конкретную цену при отсутствии.
| № | Раздел | Что в нём пишется | Что бывает, если пропустить |
|---|---|---|---|
| 1 | Цели и показатели | Ради какой цифры проект: с какого значения на какое двигаем два-три показателя | На приёмке нечего измерить, разговор сводится к «нам это не нравится». В модели — один внеплановый раунд правок, 2 недели и 60 000 ₽ |
| 2 | Границы работ | Перечень того, что в проект не входит, с отдельной оценкой по каждому отложенному пункту | +190 000 ₽ и 3 недели: мобильное приложение для бригад, которое заказчик считал частью поставки |
| 3 | Процессы «как есть» и «как будет» | Реальный маршрут заявки с объёмами по каналам, временем шагов и долей исключений | Система строится под 78 % случаев, оставшиеся 22 % возвращаются в ручной режим, и экономия падает вдвое |
| 4 | Роли и права | Кто что видит, кто меняет, кто утверждает исключения | Права раздаются по факту и шире нужного: бригада видит закупочные цены. Переделка матрицы прав после запуска — 25 000 ₽ |
| 5 | Функциональные требования | Что система делает по шагам сценария, с полями и правилами | Оценка превращается в диапазон: по одному и тому же описанию подрядчики называют 380 000, 760 000 и 1 400 000 ₽ |
| 6 | Интеграции и обмен | Системы, направление обмена, состав полей, частота, поведение при недоступности стороны | При недоступности 1С:УНФ заявки теряются молча. Разбор одного такого дня — 8 часов диспетчера и заказы, о которых никто не вспомнил |
| 7 | Данные и миграция | Что переносим, за какой период, кто чистит справочники и к какой дате | +115 000 ₽ и 2 недели на чистку 1 400 дублей в справочнике из 6 200 контрагентов, обнаруженных на четвёртой неделе |
| 8 | Нефункциональные требования | Объёмы, время отклика, доступность, журналы, сроки хранения | Решение проверено на 30 заявках в день и встаёт в понедельник, когда приходит 70 |
| 9 | Безопасность и персональные данные | Где лежат данные, кто обрабатывает, что записано в поручении подрядчику, сроки хранения | Телефоны клиентов и записи разговоров оказываются в сервисе без договора. Приведение в порядок задним числом — от 30 000 ₽ и смена всех ключей доступа |
| 10 | Обучение и документация | Кого учим, сколько групп, что остаётся в компании после ухода подрядчика | Через месяц половина диспетчеров работает по-старому. Повторное обучение — 40 000 ₽, и это ещё дешёвый исход |
| 11 | Порядок приёмки | Сценарии проверки с числовыми порогами, классы замечаний, сроки устранения | +85 000 ₽ и 3 недели: спор о том, что считать готовым, и два внеплановых раунда правок |
Схема из одиннадцати пронумерованных блоков в три яруса. Верхний ярус: «1. Цели и показатели», «2. Границы работ». Средний: «3. Процессы как есть и как будет», «4. Роли и права», «5. Функциональные требования», «6. Интеграции», «7. Данные и миграция». Нижний: «8. Нефункциональные требования», «9. Безопасность и персональные данные», «10. Обучение и документация», «11. Порядок приёмки». У каждого блока в углу подпись, кто заполняет: директор, руководитель сервиса, старший диспетчер, системный администратор, бухгалтер. Блоки 2 и 11 обведены жирной рамкой с подписью «здесь решается спор». Внизу подпись: «30 часов, пять человек, две недели». Чертёжный стиль, подписи по-русски.
Обратите внимание на разделы 3 и 5: они выглядят как один и тот же текст, и их часто склеивают. Разница принципиальная. Третий описывает, что происходит в компании сейчас и как будет происходить после запуска, — это язык людей и шагов. Пятый описывает, что делает система, — это язык полей, правил и экранов. Склеенные вместе, они дают документ, в котором невозможно понять, где кончается обязанность сотрудника и начинается обязанность программы, а именно на этой границе и живут все спорные случаи.
Задача, на которой мы заполним всю структуру
Компания обслуживает и монтирует климатическое и вентиляционное оборудование в коммерческих зданиях. 40 человек: 6 диспетчеров, 22 монтажника в 11 бригадах, остальные — снабжение, бухгалтерия, руководство. Заявки приходят из пяти каналов, диспетчер заводит их в Битрикс24 руками, назначает бригаду по памяти и повторно вбивает те же данные в 1С:УНФ, чтобы получился заказ-наряд.
- 900 заявок в месяц: телефон — 380, почта — 240, форма на сайте — 150, MAX — 90, Авито — 40.
- Среднее время оформления одной заявки диспетчером — 11 минут, из них около 4 минут уходит на повторный ввод в 1С:УНФ.
- Доля обращений, потерянных или просроченных по сроку реакции, — 6 %.
- Неравномерность: в среднем 41 заявка в рабочий день, в понедельник утром доходит до 70.
- Справочник контрагентов в 1С:УНФ — 6 200 карточек, из них около 1 400 дублей разного написания.
- Бюджет проекта — 780 000 ₽, срок — 8 недель, цель по срокам жёсткая: до начала отопительного сезона.
Цель проекта формулируется двумя числами: время оформления заявки с 11 до 3 минут и доля потерянных обращений с 6 % до 1 %. Первое число даёт 120 часов диспетчерской работы в месяц, второе — примерно 45 заявок, которые сейчас просто исчезают. Механику самого решения — приём обращений из разных каналов, классификацию и назначение исполнителя — мы разбираем на страницах решений по распределению заявок и по классификации обращений; здесь она нужна только как предмет описания.
Схема процесса слева направо. Слева пять входов с числами: телефон — 380, почта — 240, форма на сайте — 150, MAX — 90, Авито — 40, общая подпись «900 заявок в месяц». Все входы сходятся в один блок «Диспетчер, 11 минут на заявку» с пометкой «6 человек». Дальше две стрелки: «Битрикс24 — карточка заявки» и «1С:УНФ — заказ-наряд, повторный ввод 4 минуты». Справа блок «Бригада, 11 бригад». Внизу отдельной серой полосой: «6 % обращений теряется или просрочено по сроку реакции». В правом верхнем углу пометка «пик понедельника — 70 заявок в день при среднем 41». Чертёжный стиль, подписи по-русски.
Разделы 1–3: цель, границы, процессы
Ниже — как эти разделы выглядят заполненными. Формулировки можно брать целиком и подставлять свои значения: важна не литературная форма, а наличие числа, даты и фамилии в каждом утверждении.
- 1Раздел 1. Цели и показатели
«Цель проекта — сократить среднее время оформления заявки диспетчером с 11 до 3 минут и снизить долю обращений, потерянных или просроченных по сроку реакции, с 6 % до 1 %. Базовые значения зафиксированы по выгрузке из Битрикс24 за период с 1 июня по 31 августа 2026 года, объём выборки — 2 730 заявок. Контрольный замер проводится через 30 календарных дней после запуска на выборке того же объёма. Владелец процесса со стороны заказчика — руководитель сервисной службы». Три обязательных элемента: от какого значения, к какому, и на чём меряем.
- 2Раздел 2. Границы работ
«В объём работ не входит и оценивается отдельно: …» — далее закрытый список из 8–12 пунктов, каждый с ценой или пометкой «в этом проекте не рассматривается». Никаких объяснений и извинений: перечень отказов читается неприятно ровно один раз, а спасает от разговора, который стоит недель. Как этот список собирается за час — в следующем разделе.
- 3Раздел 3. Процессы «как есть» и «как будет»
Два маршрута заявки по шагам, с временем каждого шага и с долей случаев. «Как есть»: 14 шагов от поступления обращения до закрытия заказ-наряда, из них 6 ручных. «Как будет»: 9 шагов, из них 2 ручных. Отдельным подразделом — исключения: заявка без адреса объекта (примерно 7 %), повторное обращение по незакрытой заявке (11 %), заявка на оборудование, которого нет в карточке объекта (4 %). Правило простое: если исключение занимает больше 3 % потока, оно описывается сценарием, а не фразой «обрабатывается диспетчером вручную».
Регламент описывает, как должно быть; система, построенная по регламенту, встречается с реальностью на пилоте. Проверка занимает полдня: сядьте рядом с диспетчером и промерьте секундомером десять заявок подряд. В нашем модельном проекте именно так выяснилось, что 4 минуты из 11 уходят на повторный ввод в 1С:УНФ, — в регламенте этого шага не было вообще, потому что формально данные «переносятся автоматически».
Раздел границ: как собрать список за час
Границы — единственный раздел, который пишется вычитанием, и единственный, который заказчику писать неприятно. Поэтому его обычно и пропускают: список выглядит как перечень отказов, а на старте проекта хочется говорить о возможностях. При этом он же — самый дешёвый в написании и самый дорогой в отсутствии. Собирается по трём источникам, каждый даёт три-четыре пункта.
- 1Устные пожелания с переговоров. Выпишите всё, что звучало голосом на встречах и созвонах, включая брошенное вскользь «и чтобы мастера сразу в телефоне видели». Каждый пункт обязан оказаться либо в объёме работ, либо в границах. То, что не нашлось ни там ни там, и есть будущий спор: обычно таких пунктов от трёх до семи.
- 2Соседние системы. Пройдите по списку всего, что стоит в компании, — учётная система, телефония, склад, ЭДО, сайт, кассы, — и по каждой ответьте одним словом: трогаем или не трогаем. Система, о которой не сказано ничего, по умолчанию считается заказчиком включённой, а подрядчиком — исключённой. Ровно в этом месте расходятся представления о цене.
- 3Вопрос «а что потом». Спросите себя, чего вы захотите на второй месяц после запуска. Мобильное приложение, вторая площадка, отчёты для собственника, подключение ещё одного канала. Всё названное уходит в границы с оценкой — не потому, что вы от этого отказываетесь, а потому, что вы это увидите в смете второго этапа, а не в счёте за первый.
| Не входит в проект | Почему вынесено | Оценка отдельной работой |
|---|---|---|
| Мобильное приложение для выездных бригад | Бригады получают уведомления в мессенджер, отдельного приложения в этом проекте нет | 190 000 ₽, 4 недели |
| Чистка справочника контрагентов от дублей | 1 400 дублей из 6 200 карточек — отдельный этап со своей приёмкой, а не побочный эффект интеграции | 115 000 ₽, 2 недели |
| Перенос истории заявок старше 24 месяцев | Переносится срез за 24 месяца, остальное остаётся доступным в Битрикс24 | 45 000 ₽ |
| Интеграция со складом запчастей в 1С:УНФ | В первом этапе заказ-наряд создаётся без резервирования запчастей | 120 000 ₽, 3 недели |
| Голосовой робот на первичном приёме звонка | Звонки в этом проекте по-прежнему принимает диспетчер | 210 000 ₽ |
| Печатные формы сверх трёх названных в приложении | «Печатные формы 1С» без поимённого списка — это от двух до сорока форм | 12 000 ₽ за форму |
| Обучение третьей и последующих групп | В объём входят две группы по два часа | 15 000 ₽ за группу |
| Дежурство в выходные и по ночам | Поддержка работает по графику 9:00–18:00 в рабочие дни | Обсуждается в договоре поддержки |
Нарисованный абстрактный лист документа с шапкой «Раздел 2. Границы работ. ТЗ, версия 1.0 от 03.09.2026». Под шапкой заголовок «В объём работ не входит и оценивается отдельно» и восемь строк таблицы в три колонки: наименование, причина, оценка. Видимые суммы: 190 000 ₽, 115 000 ₽, 45 000 ₽, 120 000 ₽, 210 000 ₽, 12 000 ₽ за форму, 15 000 ₽ за группу, «по договору поддержки». Внизу листа сноска: «Пункт, которого нет ни в объёме, ни здесь, — будущий спор». Справа на полях рукописная пометка «собрано за 55 минут». Не скриншот реального продукта, а чертёж. Подписи по-русски.
Обратите внимание на третью колонку. Молчание по отложенному пункту хуже отказа: заказчик додумывает, что это войдёт «как-нибудь потом бесплатно», подрядчик додумывает, что этого не будет никогда. Цена рядом с пунктом переводит разговор из области ожиданий в область решений: заказчик видит, что вопрос не забыт, а отложен, и может в любой момент купить его отдельно.
Разделы 4–7: роли, функции, интеграции, данные
Это середина документа и его основной объём — примерно две трети страниц. Здесь же чаще всего появляется вода: длинные описания того, как «система обеспечивает эффективное взаимодействие». Проверка каждого абзаца одна: можно ли по нему написать сценарий проверки. Если нельзя — абзац не дописан.
- 1Раздел 4. Роли и права
Таблица «роль — что видит — что меняет — что утверждает». В нашем примере пять ролей: диспетчер, старший диспетчер, бригадир, снабженец, руководитель сервиса. Строка, которую забывают чаще всего, — «что видит бригадир»: если не написать явно, он увидит карточку заявки целиком вместе с закупочной ценой и маржой. Отдельной строкой — кто утверждает исключения: перенос срока, отказ от заявки, назначение бригады вне правил.
- 2Раздел 5. Функциональные требования
Нумерованные требования вида «Ф-14. При поступлении обращения система определяет объект по адресу или номеру телефона и подставляет установленное оборудование из карточки объекта. Если объект не определён, заявка помечается признаком „новый объект“ и уходит в очередь старшего диспетчера». Нумерация обязательна: на приёмке спорят не о разделах, а о конкретных пунктах, и мотивированный отказ ссылается на номер. В нашем модельном ТЗ таких пунктов 47.
- 3Раздел 6. Интеграции и обмен
По каждой паре систем — пять строк: направление, состав полей, частота или событие, поведение при недоступности, кто владеет ключом доступа. «Битрикс24 → 1С:УНФ: заказ-наряд создаётся по событию „заявка назначена“, передаются 11 полей по списку в приложении 3, при недоступности 1С:УНФ заявка ставится в очередь и повторяется каждые 5 минут в течение 6 часов, дубли исключаются по идентификатору заявки». Пункт про недоступность — не перестраховка: 1С:УНФ перезагружают при обновлении конфигурации, и это происходит в рабочее время.
- 4Раздел 7. Данные и миграция
Что переносим, за какой период, в каком виде, кто отвечает за чистку и к какой дате. «Переносятся: карточки объектов — все 1 840, контрагенты — после чистки дублей, заявки — за 24 месяца. Чистка справочника контрагентов выполняется заказчиком до 20 сентября 2026 года; при срыве этой даты срок проекта сдвигается на равное количество рабочих дней». Последняя фраза кажется недружелюбной ровно до момента, когда справочник не готов, а виноватым выглядит подрядчик. Как устроен сам перенос, с тремя прогонами и контрольными суммами, мы разбирали отдельно.
Карта связей систем. Слева узлы каналов: телефон, почта, форма на сайте, MAX, Авито. В центре узел «Битрикс24 — карточка заявки». Стрелка вправо к узлу «1С:УНФ — заказ-наряд» с подписью «11 полей, по событию „заявка назначена“». Под стрелкой пунктирный блок «Если 1С:УНФ недоступна: очередь, повтор каждые 5 минут в течение 6 часов, дубли исключаются по идентификатору заявки». Отдельная стрелка вниз к узлу «Уведомление бригаде: мессенджер, при недоставке SMS через 3 минуты». У каждого узла подпись, кто владеет доступом. Чертёжный стиль, подписи по-русски.
Разделы 8–11: нагрузка, безопасность, обучение, приёмка
Четыре последних раздела занимают три-четыре страницы и пропускаются чаще всех остальных вместе взятых. Каждый из них отвечает на вопрос, который до запуска кажется теоретическим, а после запуска становится единственным важным.
- 1Раздел 8. Нефункциональные требования
Четыре строки закрывают 90 % случаев: пиковый объём, время отклика, доступность, журналы. «Система принимает до 90 заявок в рабочий день при 8 одновременно работающих пользователях; интерфейс отвечает не дольше 2 секунд; плановые работы — только вне графика 9:00–18:00; журнал изменений заявки хранится 24 месяца и доступен старшему диспетчеру». Числа берутся из процесса «как есть» с запасом: 70 заявок в пик превращаются в 90 в требовании.
- 2Раздел 9. Безопасность и персональные данные
Здесь фиксируется, что в системе есть имена, телефоны и адреса клиентов, а значит применяется 152-ФЗ: где физически лежат данные, кто к ним имеет доступ со стороны подрядчика, сколько хранятся, что происходит с доступами после окончания работ. Отдельным пунктом — поручение обработки персональных данных подрядчику и запрет на выгрузку боевой базы на личные устройства. Если в проекте появляются облачные сервисы обработки текста или речи, сюда же уходит строка о том, какие данные туда отправляются и на основании чего.
- 3Раздел 10. Обучение и документация
«Две группы по два часа: диспетчеры и бригадиры. Записи занятий передаются заказчику. Инструкция диспетчера — до 8 страниц с экранами, инструкция администратора — порядок заведения пользователя, выдачи прав, перезапуска обмена. Документация передаётся до подписания акта по этапу». Проверка раздела простая: сможет ли компания завести нового сотрудника через год без звонка подрядчику. Если нет — раздел не написан.
- 4Раздел 11. Порядок приёмки
Перечень сценариев проверки с номерами, порогами и выборками, срок на проверку, классы замечаний и срок устранения по каждому классу. В нашем проекте 22 сценария на 5 рабочих дней проверки. Сценарии не пишутся в день приёмки — они рождаются здесь, вместе с требованиями, и каждый ссылается на номер требования из раздела 5. Сама процедура приёмки, классификация замечаний и мотивированный отказ — тема отдельного разбора.
Поручение обработки персональных данных и перечень доступов подрядчика — это не бумага для галочки, а описание того, кто и на каком основании держит в руках вашу клиентскую базу. Оформляется до начала работ, потому что доступы выдаются в первую неделю. Разбор задним числом означает, что несколько недель боевая база была у людей, чьи обязательства нигде не зафиксированы, и восстановить положение можно только сменой всех ключей — от 30 000 ₽ и полдня простоя обмена.
Пять требований, которые невозможно проверить
Требование существует, если два человека, независимо прогнав проверку, получают одинаковый ответ «да» или «нет». Если ответ зависит от того, кто смотрит, это пожелание. Разница в стоимости написания — ноль, разница в стоимости приёмки — недели. Ниже пять формулировок из реального ТЗ на нашу задачу и то, чем они были заменены.
| Как обычно пишут | Как написать, чтобы проверялось | Кто и на чём проверяет |
|---|---|---|
| Система справедливо распределяет заявки между бригадами | Заявка назначается по трём правилам: район, допуск к типу оборудования, свободное окно в ближайшие 4 часа. При конфликте правил заявка уходит в очередь диспетчера | Старший диспетчер, 50 заявок за прошлую неделю: назначение совпадает с его решением не менее чем в 45 случаях |
| Уведомления бригадам приходят вовремя | Уведомление уходит не позднее 60 секунд после назначения; при недоставке в мессенджер через 3 минуты отправляется SMS | Диспетчер, 20 назначений, из них 5 с отключённым интернетом на телефоне бригадира |
| Дубли заявок исключены | Два обращения с одного номера в течение 30 минут склеиваются в одну заявку с сохранением обоих источников | Диспетчер, 15 пар обращений, специально отправленных из разных каналов |
| Диспетчер видит всю информацию по клиенту | В карточке заявки шесть полей: адрес объекта, установленное оборудование с датами монтажа, три последние заявки, задолженность из 1С:УНФ на текущую дату, контактное лицо, срок реакции по договору | Диспетчер, 10 карточек: каждое из шести полей сверяется с 1С:УНФ |
| Система должна быть отказоустойчивой | При недоступности 1С:УНФ до 6 часов заявка принимается и ставится в очередь; после восстановления заказ-наряд создаётся без дублей | Системный администратор, 10 принудительных отключений длительностью до 30 минут, сверка количества заказ-нарядов |
Две колонки по пять парных строк со стрелками между ними. Левая колонка «Пожелание, проверить нельзя»: «справедливо распределяет», «уведомления вовремя», «дубли исключены», «видит всю информацию», «отказоустойчивая». Правая колонка «Требование, проверить можно»: «45 совпадений из 50», «60 секунд, SMS через 3 минуты», «15 пар обращений за 30 минут», «6 полей на 10 карточках», «10 отключений до 30 минут без дублей». Внизу общая подпись: «Стоимость написания одинаковая. Стоимость приёмки отличается на недели». Чертёжный стиль, подписи по-русски.
Откройте готовый документ и найдите поиском «и т. д.», «и др.», «при необходимости», «по возможности», «желательно», «и другие отчёты». Каждое совпадение — обязательство неизвестного размера: подрядчик закладывает в цену запас, заказчик рассчитывает на всё сразу, и обе стороны ошибаются. В документе на 20 страниц таких мест обычно от четырёх до десяти, и все они закрываются одним раундом правок до подписания.
Кто заполняет какой раздел и сколько это стоит
Главная причина, по которой ТЗ пишется месяцами, — попытка поручить его одному человеку. Одиннадцать разделов требуют пяти разных голов: директор знает цель и границы, руководитель сервиса — процесс, старший диспетчер — функции и сценарии проверки, системный администратор — интеграции и данные, бухгалтер с кадровиком — персональные данные. Ниже — сколько времени это заняло в модельном проекте. Ставки — полная стоимость часа с налогами и накладными: директор 2 600 ₽, руководитель сервиса 1 800 ₽, системный администратор 1 500 ₽, бухгалтер 1 400 ₽, старший диспетчер 1 200 ₽.
Горизонтальная столбчатая диаграмма по часам с группировкой по ролям. Директор — 4 ч (цели и границы), руководитель сервиса — 8 ч (процессы, роли, обучение), старший диспетчер — 9 ч (функциональные требования, порядок приёмки), системный администратор — 7 ч (интеграции, данные, нефункциональные требования), бухгалтер и кадровик — 2 ч (персональные данные). Справа итоговая подпись: «30 часов, 48 900 ₽, 6,3 % бюджета 780 000 ₽». Внизу сноска: «по календарю — две недели, три часа в неделю на человека». Ось — часы, подписи по-русски.
К этим 30 часам добавляется работа аналитика со стороны исполнителя: интервью, наблюдение на рабочих местах, сборка и две итерации правок. Рыночный ориентир по состоянию на сентябрь 2026 года — 5–12 % бюджета проекта на подготовку задания, и наш модельный проект укладывается в нижнюю половину вилки, потому что процесс один и систем всего две. На проекте с четырьмя учётными контурами и обменом с государственными системами доля уходит к верхней границе.
Счёт за пропущенные разделы
Теперь соберём третью колонку первой таблицы в один счёт. Это тот же проект, в котором на старте решили не тратить время на три раздела, показавшихся формальностью: границы, данные и миграцию, порядок приёмки. Остальные восемь были написаны.
Ни одна из трёх сумм не появилась из-за плохой работы подрядчика. Мобильное приложение действительно стоит 190 000 ₽ и действительно не входило в объём — просто никто не написал этого до подписания. Дубли действительно надо чистить, и делать это должен был заказчик. Спор о готовности возник потому, что готовность нигде не была описана числом. Все три суммы — это цена неназванного, и она платится один раз в конце вместо девяти часов в начале.
Диаграмма из двух вертикальных столбцов на одной оси в рублях. Левый столбец «Заполнение всех одиннадцати разделов — 48 900 ₽, 30 часов, две недели» разбит на пять сегментов по ролям. Правый столбец «Три пропущенных раздела — 390 000 ₽, 8 недель» разбит на три сегмента с подписями: границы 190 000 ₽, данные и миграция 115 000 ₽, порядок приёмки 85 000 ₽. Между столбцами подпись «в 8 раз». Пунктирная горизонтальная линия через оба столбца с подписью «бюджет проекта 780 000 ₽» и пометкой, что правый столбец — половина бюджета. Подписи по-русски.
Что в ТЗ, а что в договоре: правило приоритета
ТЗ не живёт в одиночку: рядом договор, смета с календарным планом, реестр доступов и протоколы приёмки. Правило разделения простое — договор описывает отношения и деньги, ТЗ описывает содержание и проверку. Числовые пороги в договоре не место: каждая правка требования будет задевать финансовые условия. Стоимость этапов в ТЗ не место по той же причине с обратным знаком.
Гораздо важнее пункт, которого нет почти нигде, — приоритет документов при противоречии. Документы пишут разные люди в разное время, противоречия неизбежны, и без правила приоритета спор превращается в сравнение файлов из разных почтовых ящиков.
«При противоречии между документами применяется следующий приоритет: договор — в части порядка выполнения работ, сдачи-приёмки и оплаты; техническое задание, версия 1.0 от 03.09.2026, — в части содержания работ, требований и критериев приёмки; приложение „Смета и календарный план“ — в части сроков и стоимости этапов. Коммерческое предложение частью договора не является». Две строки, которые снимают половину будущих разговоров о том, кто что имел в виду.
- У документа есть версия и дата, а в договоре стоит ссылка именно на эту версию. ТЗ без номера версии невозможно защитить: у сторон окажутся разные файлы с одинаковым названием.
- Обещание из коммерческого предложения, которого нет в ТЗ, не существует. Если продавец что-то обещал голосом или в презентации — перенесите фразу в раздел 5 или в границы, пока это ничего не стоит.
- Реестр доступов — отдельное приложение, и в нём указывается способ передачи ключа, а не сам ключ. Пароли в приложении к договору живут вечно и попадают в почтовую переписку.
- Любое изменение требований оформляется запросом на изменение с оценкой в часах и деньгах и порождает новую версию ТЗ. Устная договорённость не существует ни для одной из сторон, включая ту, которая её предложила.
- Что именно должно быть в самом договоре — предмет, этапы, права на результат, ответственность, порядок изменений — мы разбирали в отдельном материале журнала.
Когда одиннадцати разделов слишком много
Полная структура рассчитана на проект, где есть интеграция, миграция данных и несколько ролей пользователей. Ниже определённого размера она превращается в бюрократию, которая стоит дороже самой работы. Есть три случая, где мы сами советуем сокращённую форму.
- Доработка до 150 000 ₽ и до трёх недель внутри существующей системы: новое поле, отчёт, правило автоматического назначения. Хватает трёх разделов на полторы страницы: что должно происходить (сценарий по шагам), чего не трогаем, как проверим (2–3 сценария с числами).
- Готовый сервис по подписке без доработок. ТЗ заменяется списком из 8–10 сценариев, которые вы прогоняете на пилоте, и перечнем данных, которые в сервис уйдут. Описывать функции чужого продукта бессмысленно: вы на них не влияете.
- Разведочный пилот, цель которого — понять принципиальную реализуемость на ваших данных. Здесь вместо требований пишется гипотеза и порог: на какой выборке, какой результат считается успехом, и что происходит с обеими сторонами, если порог не взят.
Есть и обратный случай, о котором стоит сказать честно: одиннадцати разделов иногда мало. Если проект касается государственных систем — маркировки в Честном знаке, ветеринарных документов, обмена с медицинскими реестрами, — добавляется отдельный раздел о соответствии требованиям этих систем со ссылками на действующие форматы обмена. Их версии меняются, и раздел живёт своей жизнью с собственной датой актуальности.
И последнее. Сокращённая форма — это осознанное решение, а не «ТЗ на коленке». Разница в том, что в сокращённой форме три раздела написаны полностью и проверяемо, а в «ТЗ на коленке» одиннадцать разделов написаны наполовину. Первое даёт предсказуемый результат на маленьком проекте. Второе даёт счёт на 390 000 ₽ через восемь недель.
Документ пишется не для того, чтобы подрядчик знал, что делать. Он пишется для того, чтобы обе стороны одинаково понимали, когда всё закончилось.
