Техническое задание на автоматизацию — это документ из девяти разделов, который отвечает на один вопрос: что будет считаться сделанным. Цели и измеримый эффект, границы работ, процесс «как есть» и «как будет», роли и права, интеграции, требования к данным и доступам, нефункциональные требования и критерии приёмки со сценариями. Ценность документа держится на двух разделах из девяти — границах и критериях приёмки; остальные семь только описывают задачу, а спорят всегда об этих двух.
От коммерческого предложения ТЗ отличается направлением взгляда. КП отвечает на вопрос «сколько это стоит у нас», ТЗ — «что именно вы получите и как это проверить». Поэтому нормальное ТЗ пригодно для торга: по нему считают несколько подрядчиков и получают сопоставимые цифры. Документ, по которому три исполнителя называют суммы, отличающиеся в четыре раза, задание описывает плохо, каким бы толстым он ни был.
Дальше — структура по разделам с колонкой «что бывает без него», разбор границ и критериев приёмки, пять формулировок, которые почти гарантированно приводят к спору, процедура сборки документа за восемь рабочих дней, расчёт стоимости ТЗ и чек-лист проверки готового документа из 20 пунктов. Речь о проектах на 300 000–5 000 000 ₽ в компаниях 20–300 человек: там, где ТЗ пишут для одного заказчика и одного подрядчика, а не для конкурсной процедуры по 44-ФЗ.
Чем ТЗ отличается от КП, карты процесса и договора
Документ, который фиксирует три вещи: что должно работать после проекта, что в работы не входит и как обе стороны проверят результат. Всё остальное — описание процессов, схемы интеграций, требования к данным — существует в нём ради этих трёх. ТЗ подписывается как приложение к договору с номером версии и датой; ссылка на «согласовано в переписке» юридической силы приложения не имеет.
В проекте автоматизации живут четыре документа, и их регулярно путают между собой. Коммерческое предложение продаёт; карта процесса описывает реальность; ТЗ описывает будущее и правила проверки; договор описывает отношения сторон. Подмена одного другим стоит денег: КП вместо ТЗ означает, что вы приняли на веру объём работ; карта процесса вместо ТЗ означает, что вам описали, как есть, но не написали, как будет.
- Коммерческое предложение. Отвечает на вопрос «сколько и за сколько». Составляется до обследования, поэтому цифра в нём — вилка с разбросом до двух раз. Проверять по нему результат нельзя: там нет ни одного числа, которое можно измерить после запуска.
- Карта процесса «как есть». Фиксирует, как работа идёт сегодня: шаги, исполнители, объёмы, время, исключения. Это вход для ТЗ, а не замена: карта отвечает на «что происходит», но не отвечает на «что мы построим».
- Техническое задание. Отвечает на «что будет сделано, что не будет и как это проверить». Единственный документ, из которого получаются приёмочные сценарии.
- Договор с приложениями. Отвечает на «кто кому что должен»: этапы, оплата, права на результат, ответственность, порядок изменений. Технических деталей в нём нет — они в ТЗ, которое приложено к нему как приложение с номером и датой.
Из этого следует практическая проверка, которая занимает неделю и стоит ноль. Готовое ТЗ отдают трём подрядчикам и просят оценку. Если суммы сопоставимы, документ описывает задачу. Если разлетаются в разы — исполнители додумывают разное, а значит, на приёмке додумывать будет тот, у кого сильнее переговорная позиция.
Две группы вертикальных столбцов на одной оси в рублях. Левая группа «ТЗ без границ и критериев»: 620 000, 1 400 000, 2 900 000 ₽, подпись «разброс 4,7 раза». Правая группа «ТЗ с границами и сценариями приёмки»: 1 100 000, 1 250 000, 1 390 000 ₽, подпись «разброс 26 %». Горизонтальная пунктирная линия на 1 200 000 ₽ с подписью «фактический бюджет проекта». Ось Y — рубли, подписи по-русски.
Цифры в этом примере модельные, но пропорция взята из живой практики пересчёта чужих ТЗ. Разброс до 30–40 % — норма: подрядчики по-разному оценивают риск и по-разному считают свои часы. Разброс в два раза и больше означает, что документ допускает как минимум два разных прочтения объёма работ, и до подписания это исправляется бесплатно.
Девять разделов: зачем каждый и что бывает без него
Ниже — структура, которую мы используем сами. Порядок не случаен: сначала фиксируется, ради чего всё делается, потом чего не делается, и только потом идёт содержание работ. Раздел, который в этой таблице выглядит скучнее всех, — «требования к данным и доступам» — на практике чаще всего и определяет, уложится проект в срок или нет.
| Раздел ТЗ | Зачем он нужен | Что бывает без него |
|---|---|---|
| 1. Цели и измеримый эффект | Привязывает работы к цифре, ради которой их затевали: сократить время обработки заявки с 40 до 8 минут, снять 60 % ручного ввода | Обсуждение уходит в функции. На приёмке нечем измерить успех, и разговор сводится к «нам это не нравится» |
| 2. Границы работ | Явно перечисляет, что НЕ входит в проект: системы, сценарии, роли, объёмы, сроки поддержки | Каждое «это же само собой» становится либо бесплатной работой подрядчика, либо конфликтом. Смета растёт на 20–40 % задним числом |
| 3. Процесс «как есть» | Фиксирует реальность с объёмами, временем и исключениями, а не регламент из папки | Система строится под порядок, которого никто не соблюдает; на пилоте выясняется, что половина случаев идёт мимо схемы |
| 4. Процесс «как будет» | Показывает, что изменится в работе людей: кто какой шаг делает после запуска и какой шаг исчезает | На запуске обнаруживается новый ручной шаг, на который не выделен человек. Экономия съедается новой рутиной |
| 5. Роли и права | Кто что видит, кто что может менять, кто утверждает исключения | Права раздаются по факту и обычно шире нужного: менеджер видит закупочные цены, стажёр правит справочник номенклатуры |
| 6. Интеграции и обмен | Перечень систем, направление обмена, состав полей, частота, поведение при недоступности стороны | Интеграция формально «есть», но при недоступности 1С заявки молча теряются, а повторная отправка создаёт дубли заказов |
| 7. Требования к данным и доступам | Что предоставляет заказчик, в каком виде и к какой дате: выгрузки, тестовый контур, ключи API, ответственный | Просрочка на стороне заказчика превращается в просрочку проекта. Срок едет на 1–3 недели, и виноватым выглядит подрядчик |
| 8. Нефункциональные требования | Время отклика, объёмы, доступность, журналирование, хранение и защита персональных данных по 152-ФЗ | Решение работает на десяти документах и ложится на двухстах. Записи разговоров хранятся неизвестно где и неизвестно сколько |
| 9. Критерии приёмки и сценарии | Описывает, как обе стороны проверят результат: перечень сценариев с числовыми порогами | Приёмка «по факту работы»: систему открыли, она открылась, акт подписан. Дефекты всплывают в эксплуатации и чинятся за ваш счёт |
Схема-конструкция из девяти пронумерованных блоков, соединённых сверху вниз в три яруса. Верхний ярус: «1. Цели и эффект» и «2. Границы работ». Средний: «3. Как есть», «4. Как будет», «5. Роли и права». Нижний: «6. Интеграции», «7. Данные и доступы», «8. Нефункциональные требования», «9. Критерии приёмки». Блоки 2 и 9 обведены жирной рамкой с подписью «здесь решается спор на сдаче». Сбоку вертикальная подпись «версия 1.0, дата, подписи сторон». Чертёжный стиль, подписи по-русски.
Отдельно про восьмой раздел, который в малых проектах пропускают чаще остальных. Нефункциональные требования — это не бюрократия, а ответ на вопрос «при каких условиях всё это перестанет работать». Достаточно четырёх строк: сколько документов в пиковый день, сколько одновременных пользователей, за какое время система обязана ответить и сколько хранятся журналы. Если в проекте есть записи разговоров, имена или телефоны, туда же добавляется строка про размещение данных на серверах в России — это базовое требование 152-ФЗ, а не пожелание службы безопасности.
Раздел границ: самый ценный лист в документе
Границы — единственный раздел, который пишется методом вычитания. Всё остальное описывает, что будет; этот перечисляет, чего не будет, хотя заказчик мог бы разумно этого ожидать. Именно поэтому его пропускают: список выглядит как перечень отказов. На практике он работает в обе стороны — заказчику показывает истинный объём покупки, подрядчику закрывает бесконечное «доделайте заодно».
Хороший раздел границ занимает половину страницы и содержит 8–12 пунктов. Формулировка простая: «в объём работ не входит …», без объяснений и извинений. Если по какому-то пункту стороны хотят договориться отдельно, туда же ставится цена: «перенос истории старше 24 месяцев — отдельная работа, оценка 60 000 ₽». Это лучше, чем молчание: заказчик видит, что вопрос не забыт, а отложен.
- Перенос данных за пределами согласованного среза: истории старше 24 месяцев, архивов закрытых сделок, вложений из старой почты.
- Доработка печатных форм и отчётов учётной системы, если они не названы поимённо. «Печатные формы 1С» без списка — это от двух до сорока форм.
- Мобильное приложение и мобильная вёрстка интерфейсов, если в ТЗ описан только рабочий стол.
- Интеграции со всем, что не перечислено в шестом разделе. В том числе с системами, которые появятся у заказчика во время проекта.
- Работа с государственными системами — Честный знак, ЕГАИС, ВетИС, ЭДО — если она не описана отдельным сценарием с полями и регламентом.
- Обучение сверх согласованного: две группы по два часа входят, отдельные занятия для каждой смены — нет.
- Круглосуточное дежурство и SLA выходного дня, если в договоре поддержки написан рабочий график.
- Чистка справочников и устранение дублей в исходных системах: это отдельный этап с отдельной приёмкой, а не побочный эффект интеграции.
- Покупка лицензий, оплата облачных сервисов, телефонии и токенов языковых моделей — расходы заказчика, если прямо не написано иное.
- Нагрузка сверх заявленной: если в ТЗ 50 одновременных пользователей, поведение при 300 не гарантируется и проверке не подлежит.
Сравнение в две колонки под общей рамкой «объём проекта, 1 200 000 ₽». Левая колонка «Входит»: приём заявок из почты и Авито, распознавание спецификаций, создание заказа в 1С:УТ, карточка в amoCRM, интерфейс исключений, обучение двух групп. Правая колонка «Не входит, оценивается отдельно»: перенос истории старше 24 месяцев — 60 000 ₽, печатные формы — по списку, мобильное приложение — нет, интеграция с Честным знаком — нет, дежурство 24/7 — нет. Между колонками вертикальная линия границы. Подписи по-русски.
Проверить свой раздел границ можно одним приёмом. Возьмите список пожеланий, которые звучали на переговорах устно, и найдите каждое либо в объёме работ, либо в границах. То, что не нашлось ни там ни там, — и есть будущий спор. Обычно таких пунктов от трёх до семи, и все они всплывают на приёмке, когда цена вопроса уже не ноль.
Критерии приёмки: как формулировать проверяемо
Критерий приёмки — это утверждение, которое можно проверить, не спрашивая мнения автора. Проверка одна: два человека, независимо прогнав сценарий, обязаны получить одинаковый ответ «да» или «нет». Если ответ зависит от того, кто смотрит, это не критерий, а пожелание. Разница между двумя формулировками в стоимости написания равна нулю, а в стоимости приёмки — неделям.
| Оценочная формулировка | Проверяемая замена | Чем меряется |
|---|---|---|
| Удобный интерфейс создания заказа | Менеджер создаёт заказ из письма не более чем за 90 секунд и не более чем в 3 перехода между экранами | Секундомер, выборка из 20 писем, двое сотрудников |
| Система корректно распознаёт спецификации | На 100 реальных письмах 6 полей извлечены верно не менее чем в 88 % случаев, ошибки в номенклатуре не более 2 % | Протокол прогона на 100 письмах с построчной сверкой |
| Быстрая работа при нагрузке | Время ответа интерфейса не более 3 секунд при 50 одновременных пользователях | Замер на тестовом контуре, журнал с временными метками |
| Надёжный обмен с 1С | При недоступности 1С заявка ставится в очередь и уходит после восстановления связи без дублей; проверено на 10 отключениях | Сценарий с принудительным отключением, сверка количества заказов |
| Отчёт по заявкам для руководителя | Отчёт за месяц строится не дольше 10 секунд и сходится с выгрузкой из 1С по количеству и сумме с расхождением не более 0,5 % | Сверка двух выгрузок за один и тот же период |
| Понятные сообщения об ошибках | В каждом из 12 сценариев ошибки пользователь видит текст с указанием, что сделать дальше; список текстов приложен к ТЗ | Прогон 12 сценариев, сравнение с приложением |
Две колонки по четыре парных строки. Левая «Оценочно» с пометкой «проверить нельзя»: «удобный интерфейс», «корректно распознаёт», «быстрая работа», «надёжный обмен». Правая «Проверяемо» с пометкой «проверить можно»: «не более 90 секунд и 3 переходов», «88 % на 100 письмах, ошибки номенклатуры до 2 %», «до 3 секунд при 50 пользователях», «10 отключений без дублей». Между колонками стрелки. Внизу подпись: «стоимость написания одинаковая, стоимость приёмки отличается в недели». Подписи по-русски.
Число сценариев зависит от объёма, но ориентир простой: на проект в 1–1,5 млн ₽ получается 20–40 сценариев. Меньше двадцати — значит, часть процесса описана словами и на приёмке будет обсуждаться устно. Больше сорока — обычно признак того, что в сценарии попали варианты, различающиеся одной кнопкой; их укрупняют. Сама процедура прогона, классификация замечаний и мотивированный отказ — тема отдельного разбора, здесь важно только то, что все эти сценарии рождаются в ТЗ, а не пишутся в день приёмки.
«88 % корректных распознаваний» звучит проверяемо, но проверяемым становится только вместе с тремя уточнениями: на какой выборке (100 реальных писем за последние 30 дней), кто её формирует (заказчик, до начала проверки) и что считается ошибкой (расхождение в любом из шести полей). Без этих уточнений на приёмке начнётся спор о выборке: подрядчик принесёт свои сто писем, и на них всё сойдётся. Правило простое — в каждом критерии есть число, выборка и определение ошибки.
Пять формулировок, после которых спорят гарантированно
Это не стилистические придирки. Каждая из пяти формулировок ниже создаёт зону, где две стороны честно понимают документ по-разному, и обнаруживается это на сдаче, когда одна из сторон уже потратила деньги, а другая — время.
- 1«Удобный и интуитивно понятный интерфейс». Слово «удобный» не имеет владельца: удобно кому и по сравнению с чем. Замена — числа и шаги: сколько кликов, сколько секунд, сколько полей заполняется автоматически. Если хочется зафиксировать именно ощущение, это делается иначе: макеты экранов прикладываются к ТЗ и подписываются вместе с ним.
- 2«В разумные сроки» и «оперативно». В договоре это превращается в ноль обязательств. Замена — рабочие дни и часы: «дефект блокирующего класса устраняется за 8 рабочих часов», «выгрузка предоставляется в течение 3 рабочих дней с даты запроса».
- 3«Стандартная интеграция с 1С». Стандартной интеграции не существует: у 1С:Бухгалтерии, 1С:УТ и 1С:УНФ разные объекты и разные обмены, а у вашей базы почти наверняка есть доработки. Замена — конфигурация с версией, перечень объектов обмена, состав полей, направление и частота, поведение при сбое.
- 4«При необходимости» и «по согласованию сторон». Конструкция, которая переносит решение в будущее, где у сторон уже разные интересы. Замена — либо пункт входит в объём и описан, либо вынесен в границы с отдельной оценкой. Третьего состояния у требования быть не должно.
- 5«И тому подобное», «и другие отчёты», «и прочие документы». Открытый список — это обязательство неизвестного размера. Подрядчик закладывает в цену запас, заказчик рассчитывает на всё сразу, и обе стороны ошибаются. Замена — закрытый перечень с количеством: «шесть печатных форм по списку в приложении 2».
Откройте готовое ТЗ и поиском найдите «и т. д.», «и др.», «и тому подобное», «при необходимости», «по возможности», «желательно». Каждое совпадение — это либо будущая бесплатная работа, либо будущий отказ. В документе на 20 страниц таких мест обычно от четырёх до десяти, и все они закрываются одним раундом правок до подписания.
Как собирается ТЗ: восемь рабочих дней по шагам
Модельный проект для всей статьи: оптовая компания, 70 человек. Заявки приходят на общую почту и в чаты Авито, менеджер вручную переносит позиции из спецификации в заказ 1С:УТ и заводит сделку в amoCRM. Задача — принимать заявку автоматически, извлекать позиции, создавать заказ и карточку, а спорные случаи отдавать человеку. Бюджет внедрения — 1 200 000 ₽, срок 12 недель. ТЗ на такой проект собирается за восемь рабочих дней.
- 1День 1. Цель, границы и владелец процесса
Двухчасовая сессия с владельцем процесса и руководителем. Формулируем цель в цифрах («время обработки заявки с 40 до 8 минут, ручной ввод позиций — минус 60 %»), сразу же составляем черновик границ и называем человека, который принимает спорные решения. Без назначенного владельца дальше идти бессмысленно: каждый второй вопрос требует решения на месте.
- 2День 1–2. Интервью и наблюдение на рабочих местах
Пять интервью по 40–60 минут с теми, кто делает работу руками, и три часа наблюдения: аналитик сидит рядом и смотрит, как менеджер разбирает почту. Наблюдение находит то, чего не находит опрос, — обходные пути, второй экран с таблицей, папку «разобрать потом».
- 3День 2–3. Выгрузки, объёмы, состояние данных
Шесть запросов к системам: сколько заявок в месяц за последние 6 месяцев, сколько позиций в среднем, сколько разных форматов спецификаций, сколько дублей в справочнике контрагентов, сколько заявок приходит вне рабочего времени, доля переделок. Это те числа, которые потом станут порогами в критериях приёмки.
- 4День 3–5. Процессы «как есть» и «как будет»
Рисуем два состояния: 22 шага текущего процесса и 14 шагов будущего. Отдельно собираем исключения с частотой: девять правил, из которых три срабатывают реже раза в месяц — их сознательно оставляем человеку. Каждое такое решение экономит несколько дней разработки и строку в смете.
- 5День 5–6. Интеграции, данные, доступы
Реестр из четырёх систем: почтовый ящик, Авито, 1С:УТ, amoCRM. По каждой — направление обмена, состав полей, частота, ответственный на стороне заказчика, срок предоставления доступа и поведение при недоступности. Здесь же появляется список того, что заказчик обязан дать и к какой дате.
- 6День 6–7. Сценарии приёмки
Из процесса «как будет» получаются 26 сценариев: путь заявки от письма до заказа, разбор нечитаемой спецификации, неизвестный контрагент, дубль заявки, недоступная 1С, права доступа, отчёт для руководителя. У каждого — числовой порог, выборка и определение ошибки.
- 7День 8. Согласование и версия 1.0
Двухчасовая сессия по документу целиком, правки, присвоение версии и даты, подписание как приложения к договору. Дальше любое изменение оформляется запросом с оценкой в часах и деньгах, а не правкой файла «мы там подправили пару строк».
Горизонтальная лента времени на 8 рабочих дней с семью перекрывающимися дорожками: цель и границы (день 1), интервью и наблюдение (дни 1–2), выгрузки и объёмы (дни 2–3), процессы «как есть» и «как будет» (дни 3–5), интеграции и доступы (дни 5–6), сценарии приёмки (дни 6–7), согласование (день 8). Под каждой дорожкой — результат: черновик границ, 5 интервью, 6 цифр, 22 и 14 шагов, реестр 4 систем, 26 сценариев, версия 1.0. Отдельной отметкой в начале: «без назначенного владельца процесса не начинать». Подписи по-русски.
Восемь дней — это календарь аналитика, а не заказчика. От заказчика за эти дни требуется около 9 часов суммарно: две сессии по два часа, пять интервью, полтора часа на чтение и правки. Это самые дешёвые часы всего проекта. Правка формулировки в ТЗ стоит ноль, та же правка на седьмой неделе разработки стоит недели работы и переписывания тестов.
Кто пишет ТЗ и сколько это стоит
Схем три, и у каждой своя цена и свой перекос. Заказчик, пишущий ТЗ сам, экономит деньги и почти гарантированно упускает технические разделы: интеграции, нефункциональные требования, поведение при сбоях. Подрядчик пишет качественно, но описывает то решение, которое умеет строить. Независимый аналитик даёт документ, пригодный для торга, и стоит дороже всех.
| Кто пишет | Ориентир цены | Что получается хорошо | Где перекос |
|---|---|---|---|
| Заказчик своими силами | 0 ₽ плюс 30–60 часов своего времени | Цели, процесс «как есть», исключения, реальные объёмы | Интеграции, нефункциональные требования, критерии приёмки. Обычно нет ни одного проверяемого числа |
| Подрядчик, который будет внедрять | От 0 до 8 % бюджета; часто зачитывается в стоимость проекта | Технические разделы, схема обмена, реалистичные сроки | Границы написаны в пользу автора, а решение описано под его стек. Для сравнения с другими исполнителями документ малопригоден |
| Независимый аналитик | 100 000–300 000 ₽, 8–15 рабочих дней | Документ, по которому считают трое и получают сопоставимые цифры | Дороже и дольше; аналитик не отвечает за реализуемость так, как отвечает будущий исполнитель |
| Смешанная схема: обследование у одного, реализация у другого | Обследование 8–15 % бюджета отдельным договором | Право остановиться после обследования, документ остаётся у заказчика | Требует прописать в договоре права на результат обследования, иначе документ формально не ваш |
Рыночный ориентир по состоянию на сентябрь 2026 года — 5–12 % бюджета проекта. Ниже 5 % документ обычно оказывается пересказом коммерческого предложения; выше 15 % имеет смысл только тогда, когда обследование заменяет собой пилот, то есть отвечает на вопрос о принципиальной реализуемости. Отдельная строка расходов, о которой забывают, — время собственных сотрудников: те самые 9 часов заказчика при ставке 1 500 ₽/час добавляют к смете ещё около 13 500 ₽.
Документ, написанный будущим исполнителем бесплатно, почти всегда описывает именно его решение: его платформу, его набор интеграций, его представление о границах. Это не злой умысел, а естественное следствие — человек описывает то, что умеет делать. Проверка одна и занимает неделю: отдайте документ двум другим подрядчикам и попросите оценку. Если они отвечают «непонятно, что тут делать» или называют суммы, отличающиеся в разы, вы получили не задание, а презентацию. И отдельно проверьте в договоре, кому принадлежит результат: право оставить документ у себя при отказе от продолжения работ нужно писать явно.
Горизонтальная столбчатая диаграмма по часам: цели и границы — 4 ч, интервью и наблюдение — 10 ч, выгрузки и объёмы — 6 ч, процессы «как есть» и «как будет» — 12 ч, интеграции и доступы — 8 ч, сценарии приёмки — 8 ч, согласование — 2 ч. Итоговая подпись справа: «50 часов × 2 800 ₽ = 140 000 ₽, 11,7 % от бюджета 1 200 000 ₽». Отдельная сноска: «на проекте 4 000 000 ₽ — 250 000–300 000 ₽, 6–8 %». Ось — часы, подписи по-русски.
Что в ТЗ, а что в договоре и приложениях
ТЗ не живёт в одиночку. Вокруг него собирается комплект из пяти документов, и путаница между ними — вторая по частоте причина споров после открытых границ. Правило разделения простое: договор описывает отношения и деньги, ТЗ описывает содержание и проверку, остальные приложения фиксируют то, что меняется чаще договора.
| Документ | Что в нём | Чего в нём быть не должно |
|---|---|---|
| Договор | Предмет, этапы, порядок сдачи-приёмки, оплата, права на результат, ответственность, порядок изменений | Состава полей обмена, названий кнопок, числовых порогов точности |
| Приложение 1. Техническое задание | Девять разделов: цели, границы, процессы, роли, интеграции, данные, нефункциональные требования, критерии приёмки | Стоимости этапов и графика платежей — иначе каждая правка требований задевает финансовые условия |
| Приложение 2. Смета и календарный план | Разбивка по этапам: работы, срок, стоимость, что принимается в конце | Технических требований — они уже в ТЗ; дублирование расходится при первой же правке |
| Приложение 3. Реестр доступов и данных | Что предоставляет заказчик, кто ответственный, к какой дате, в каком формате | Паролей и ключей в открытом виде: в реестре указывается способ передачи, а не значение |
| Протокол приёмки этапа | Перечень прогнанных сценариев с номерами из ТЗ, результат, замечания с классами, срок устранения | Формулировки «работы выполнены в полном объёме» без ссылок на сценарии |
| Запрос на изменение | Что меняется, зачем, что затрагивает, оценка в часах и деньгах, влияние на срок | Устных договорённостей: изменение, не оформленное документом, не существует ни для одной из сторон |
Карта связей. В центре крупный узел «ТЗ, версия 1.0, приложение 1». Вверх стрелка к узлу «Договор» с подписью «предмет и порядок приёмки». Вправо — «Смета и календарный план» с подписью «этапы и деньги». Влево — «Реестр доступов и данных» с подписью «что даёт заказчик и к какой дате». Вниз две стрелки: «Протоколы приёмки этапов» с подписью «сценарии с номерами из ТЗ» и «Запросы на изменение» с подписью «правки только через оценку в часах и рублях». Подписи по-русски, чертёжный стиль.
Разбор того, какие пункты договора реально защищают заказчика — про неустойку, права на код по статьям 1296 и 1297 ГК РФ и поэтапную оплату — мы вынесли в отдельный материал журнала. Здесь достаточно одного правила: ТЗ должно быть приложением с номером версии и датой, а в договоре должна стоять ссылка именно на эту версию. Документ без версии превращает любой спор в сравнение файлов из разных почтовых ящиков.
Чек-лист проверки готового ТЗ: 20 пунктов
Этот список проходится за час-полтора по готовому документу, до подписания. Каждый пункт формулируется как факт, который либо есть, либо нет: промежуточных состояний в чек-листе не предусмотрено. Норма — 18 пунктов из 20; провал по пунктам 2, 9, 12 и 17 считаем блокирующим независимо от общего счёта.
- 1У документа есть номер версии и дата, и в договоре стоит ссылка именно на эту версию.
- 2Цель сформулирована числом «было — станет», а не глаголом «улучшить» или «оптимизировать».
- 3Указан владелец процесса со стороны заказчика поимённо, с правом принимать спорные решения.
- 4Есть раздел границ, и в нём не меньше восьми пунктов «в объём работ не входит».
- 5Каждое устно обсуждавшееся пожелание нашлось либо в объёме, либо в границах.
- 6Процесс «как есть» описан с объёмами: сколько операций в месяц, сколько времени занимает шаг.
- 7Исключения перечислены с частотой, и отмечено, какие из них сознательно оставлены человеку.
- 8Процесс «как будет» показывает, какие шаги исчезают и какие новые шаги появляются у людей.
- 9Каждая интеграция описана четырьмя параметрами: система с версией, направление, состав полей, частота.
- 10Для каждой интеграции написано поведение при недоступности стороны и правило защиты от дублей.
- 11Есть таблица ролей и прав: кто что видит, кто что меняет, кто утверждает исключения.
- 12Нефункциональные требования содержат хотя бы четыре числа: объём, одновременные пользователи, время отклика, срок хранения журналов.
- 13Если в системе есть имена, телефоны или записи разговоров, указано размещение данных на серверах в России и срок хранения.
- 14Перечислено, что предоставляет заказчик, кто ответственный и к какой дате.
- 15Написано, что происходит со сроком проекта, если заказчик просрочил предоставление данных или доступов.
- 16Сценариев приёмки не меньше двадцати, и у каждого есть номер, по которому на него можно сослаться в протоколе.
- 17В каждом критерии приёмки есть число, выборка и определение того, что считается ошибкой.
- 18Ни одного «и тому подобное», «при необходимости», «по возможности», «желательно» — проверено поиском по документу.
- 19Названы конкретные конфигурации и версии систем, а не «учётная система» и «CRM».
- 20Описан порядок изменений: кто инициирует, кто оценивает, в каком документе фиксируется результат.
Формулировка «сроки этапа сдвигаются на количество рабочих дней просрочки предоставления доступов» выглядит как пункт в пользу подрядчика, и его часто вычёркивают. На практике он защищает обе стороны: без него любая задержка превращается в спор о том, кто виноват, а с ним появляется простой счётчик дней, по которому видно, чья это просрочка. По нашей практике на стороне заказчика набирается от 3 до 12 рабочих дней за проект — и это нормально, если посчитано, а не обнаружено на приёмке.
Когда ТЗ писать не надо
ТЗ — инструмент, а не ритуал, и в четырёх ситуациях он не нужен или вредит.
- Типовая настройка коробочного продукта до 150 000 ₽. Подключение телефонии к CRM, настройка воронки, шаблоны документов — здесь хватает короткого перечня работ и списка проверок на полстраницы. ТЗ за 100 000 ₽ на работу за 120 000 ₽ — очевидная нелепость.
- Состояние данных неизвестно. Если непонятно, есть ли вообще пригодные данные, сначала делается обследование или пилот с одним вопросом, и только потом ТЗ. Задание, написанное на предположениях о данных, переписывается целиком через месяц.
- Процесс перестраивается прямо сейчас. Компания меняет структуру, схему продаж или учётную систему — фиксировать в документе то, что изменится через два месяца, значит оплатить документ дважды.
- Документ пишется ради объёма. Восемьдесят страниц, из которых семьдесят — пересказ интерфейсов и общих слов, читать никто не будет, а спор всё равно решат две страницы про границы и приёмку. Полезное ТЗ на проект в 1–1,5 млн ₽ обычно занимает 15–25 страниц.
И последнее наблюдение, которое стоит всех предыдущих разделов. Плохое ТЗ почти никогда не является следствием плохого аналитика. Оно является следствием того, что на стороне заказчика не нашлось человека, который имеет право сказать «этого мы делать не будем». Границы, числовые пороги и закрытые списки — все они требуют решений, а не описаний. Там, где такой человек назначен и у него есть два часа в неделю, документ получается за восемь дней и работает три года. Там, где его нет, никакая методология не помогает: получается красивый текст, по которому невозможно принять работу.
Спор на приёмке всегда идёт не о том, что написано в ТЗ, а о том, что в нём не написано.
