Техзадание становится частью договора только тогда, когда у него есть номер приложения, версия, дата и подписи обеих сторон. Документ в облаке с общим доступом, файл в переписке и презентация из чата этим требованиям не отвечают: в споре ни одна сторона не сможет доказать, каким был текст на дату подписания договора, потому что текст с тех пор менялся и продолжает меняться.
Это не формальность ради формальности. Приложение с ТЗ — единственное место, где написано, что именно делается, и именно на него ссылается предмет договора. Если приложения нет или оно не зафиксировано, вся конструкция договора повисает: предмет описывает жанр работы, критерии приёмки взять неоткуда, а изменение объёма невозможно отличить от исполнения обязательства. Как это устроено на уровне всего документа, разобрано в опорном материале о существенных условиях.
Ниже — процедура: семь реквизитов приложения, три способа зафиксировать версию, конструкция для документов, которые не помещаются в одно приложение, и порядок изменения ТЗ после подписания с расчётом стоимости.
Семь реквизитов приложения
Реквизиты нужны для одного: чтобы через полгода человек, не участвовавший в переговорах, установил по титульному листу, к какому договору документ относится, какая это редакция и кто её принял.
- 1Номер приложения и ссылка на договор. «Приложение № 1 к договору № 17/26 от 14.04.2026». Без ссылки документ не привязан ни к чему: с одним подрядчиком за год подписывают несколько договоров.
- 2Название и версия. «Техническое задание, версия 1.3». Версия — не украшение: она единственная позволяет отличить редакцию, которую подписали, от той, которую обсуждали.
- 3Дата версии. Дата именно этой редакции, а не дата договора. Они совпадают редко: ТЗ обычно дорабатывается после того, как договор ушёл на согласование.
- 4Оговорка о неотъемлемой части. Одна строка в договоре: приложение является его неотъемлемой частью. Без неё документ формально остаётся рабочим материалом.
- 5Правило приоритета. Что главнее при расхождении текстов — договор или приложение. Обычно договор, но это решение надо принять письменно, иначе спор о противоречии превращается в отдельный спор.
- 6Подписи обеих сторон на самом приложении, а не только на договоре. Подписант — директор по уставу или сотрудник по доверенности с указанием её реквизитов.
- 7Количество листов и сквозная нумерация. «На 18 листах», прошивка или подпись на каждом листе — защита от подмены листа в середине, самого дешёвого способа изменить документ задним числом.
«Требования к результату работ определены в Техническом задании (Приложение № 1 к настоящему Договору, версия 1.3 от 14.04.2026, на 18 листах), являющемся неотъемлемой частью Договора. При расхождении между текстом Договора и Приложения применяются положения Договора. Изменение Технического задания оформляется новой версией Приложения либо дополнительным соглашением.» Точную редакцию даст юрист — здесь важен состав, а не стиль.
Три способа зафиксировать версию
Реквизиты решают вопрос идентификации, но не неизменности: файл после подписания можно открыть и поправить. Ниже три способа зафиксировать содержание — они работают не вместо друг друга, а вместе.
| Способ | Что доказывает | Чего не доказывает | Цена и срок |
|---|---|---|---|
| Подписанный PDF на бумаге: прошит, подписи на титуле, нумерация листов | Состав документа и волеизъявление сторон на дату подписания | Что это последняя версия, если параллельно шли правки в других файлах | 0 ₽ плюс 1–3 дня на встречу или курьера |
| Обмен через ЭДО: Контур.Диадок, Saby ЭДО, 1С-ЭДО с квалифицированной подписью | Подписанта, точное время подписания и неизменность файла после отправки | Что содержание документа согласовано по существу, а не подписано не глядя | В пределах пакетного тарифа оператора, минуты |
| Коммит в репозитории с тегом версии плюс хеш файла, вписанный в подписанный документ | Неизменность содержания и всю последовательность редакций | Волеизъявление сторон, если хеш не попал ни в один подписанный документ | 0 ₽, минуты, но требует дисциплины обеих сторон |
Рабочая комбинация выглядит так: файл фиксируется хешем, хеш и количество листов вписываются в текст приложения, приложение подписывается и уходит через ЭДО. Каждый элемент закрывает то, чего не закрывают остальные, а суммарные затраты — полчаса работы. Если ЭДО у компании ещё нет, к нему в любом случае придётся прийти по другим причинам; порядок подключения мы разбирали в материале об устройстве ЭДО, а выбор оператора — в сравнении операторов.
Общий документ в облаке удобен при обсуждении и непригоден как приложение: содержание меняется без следов для второй стороны, история правок принадлежит владельцу файла, доступ отзывается одним кликом. Сценарий будничный — через четыре месяца заказчик открывает ссылку и видит текст, которого не помнит. Спор здесь уже не о требованиях, а о том, чей файл настоящий.
Сравнение в четыре колонки: «Подписанный PDF», «ЭДО», «Коммит с хешем», «Редактируемая ссылка». Три строки: что доказывает, чего не доказывает, цена. У первых трёх колонок в строке цены стоит «0 ₽ / пакетный тариф / 0 ₽», у четвёртой во всех трёх строках прочерк и подпись «не доказывает ничего». Под тремя первыми колонками общая скоба с надписью «работают вместе: хеш в тексте, подпись, отправка через ЭДО». Чертёжный стиль, подписи по-русски.
Если ТЗ не помещается в одно приложение
На проектах от 1 500 000 ₽ техзадание разрастается до 80–150 страниц, и подписывать его целиком в первую неделю плохо по двум причинам: о системе в этот момент известно меньше, чем когда-либо позже, а любая правка в деталях пятого этапа требует переподписания всего документа.
Решение — двухуровневая конструкция. Наверху приложение № 1 на 12–20 страниц: цель, границы работ, роли, перечень функциональных блоков, интеграции списком, требования к данным и порядок приёмки по этапам. Оно подписывается вместе с договором и меняется редко. Ниже — рабочие спецификации приложений 1.1, 1.2 и далее по числу этапов: каждая подписывается перед стартом своего этапа и уточняет верхний уровень, не расширяя границы.
Правило приоритета задаётся один раз на весь проект: договор главнее верхнеуровневого ТЗ, а оно — спецификации этапа. Если спецификация выходит за границы верхнего уровня, это уже не уточнение, а изменение объёма. Что попадает в верхний уровень, а что в спецификацию, разобрано в материале о структуре ТЗ по разделам.
Схема из двух ярусов. Верхний ярус — один широкий блок «Приложение № 1: верхнеуровневое ТЗ, 12–20 страниц, версия 1.3» с перечислением внутри: цель, границы, роли, функциональные блоки, интеграции, данные, приёмка по этапам. От него вниз пять стрелок к блокам «Приложение 1.1 … 1.5: спецификация этапа», у каждого подпись «подписывается перед стартом этапа». Сбоку вертикальная стрелка приоритета с подписями сверху вниз: «Договор → Приложение № 1 → Спецификация этапа». Чертёжный стиль, подписи по-русски.
Каждое требование обязано порождать сценарий
Приложение с ТЗ и раздел о приёмке — это один механизм, а не два соседних документа. Требование, из которого невозможно вывести проверку, до акта не доходит: на сдаче его нечем закрыть, и стороны спорят о том, считать его выполненным или нет. Поэтому в приложение имеет смысл сразу вносить третью колонку — сценарий, которым требование проверяется.
| Требование в ТЗ | Сценарий приёмки | Что фиксируется в протоколе |
|---|---|---|
| Система разбирает спецификации из входящих писем | Прогон на 40 письмах прошлого месяца: не менее 34 разобраны без правок, остальные уходят в ручную очередь, потерь нет | Номер сценария, дата прогона, файл с 40 исходными письмами |
| Данные передаются в 1С:УТ | Заказ появляется в 1С:УТ не позже чем через 5 минут после письма; при недоступности базы заявка встаёт в очередь и уходит после восстановления | Отметки времени по 10 заказам и один тест с отключённой базой |
| Ответственный получает уведомление | Сообщение приходит в течение 1 минуты; если ответа нет 30 минут, уведомление уходит руководителю | Журнал уведомлений за тестовые сутки |
| Разграничение прав по филиалам | Менеджер не видит заказы чужого филиала: проверено под тремя учётными записями | Выгрузка журнала доступа и перечень проверенных ролей |
Если сценарий для требования не придумывается, требование сформулировано как пожелание. Такие пункты либо переписываются в измеримые, либо переносятся в раздел границ. Кто прогоняет сценарии на самой приёмке и как классифицируются замечания — в материале о приёмке работ.
Порядок изменения: кто подписывает и за чей счёт
Требования меняются на любом проекте, и это нормально. Ненормально, когда изменение оформляется сообщением в чате: через месяц ни одна сторона не помнит, было это согласовано или только обсуждалось. Процедура из пяти шагов закрывает вопрос и занимает 2–3 рабочих дня.
- 1Письменная формулировка изменения
Инициатор — любая из сторон — описывает новое требование так же, как оно было бы написано в ТЗ: что должно происходить и как это проверить. Устная просьба «сделайте ещё вот так» шагом процедуры не является.
- 2Оценка подрядчиком за свой счёт
Подрядчик в течение 2–3 рабочих дней возвращает трудоёмкость в часах, влияние на срок этапа и на смежные требования. Сама оценка не оплачивается — это часть работы по договору; оплачивается только реализация.
- 3Решение заказчика
Три варианта: включить в текущий этап, отложить в следующий, отказаться. Отложенные полезно вести общим списком — к концу проекта из них набирается вторая очередь.
- 4Выбор формы оформления
Если границы, цена и срок не меняются — достаточно новой версии приложения: 1.3 становится 1.4 с новой датой и подписями. Если меняется цена или срок этапа — нужно допсоглашение к договору, потому что меняются условия самого договора, а не только требования.
- 5Подписание теми же лицами
Новую версию приложения и допсоглашение подписывают те же лица, что и договор, либо сотрудники по доверенности. Согласование руководителем проекта в переписке процедуру не заменяет.
«За чей счёт» решается по источнику изменения. Оценка — за счёт подрядчика. Новое требование заказчика — за счёт заказчика. Переделка того, что сделано не так, как записано в подписанной версии ТЗ, — за счёт подрядчика по гарантии. Спорной остаётся четвёртая ситуация: требование в ТЗ было, но сформулировано двусмысленно. Здесь помогает правило, которое стоит записать в договор: двусмысленность толкуется в пользу стороны, которая не составляла текст.
Столбчатая диаграмма из трёх столбцов на общей шкале в рублях с подписями стадий по горизонтали: «Стадия ТЗ — 7 500 ₽ (3 ч)», «Разработка — 55 000 ₽ (22 ч)», «После запуска — 115 000 ₽ (46 ч)». Над третьим столбцом выноска «в 15 раз дороже», внизу подпись «8 изменений за проект: разница 860 000 ₽». Чертёжный стиль, подписи по-русски.
Когда столько формальностей не нужно
Процедура выше рассчитана на проект от нескольких сотен тысяч рублей и от месяца работ. На меньших объёмах она обходится дороже риска, который снимает, и вместо защиты даёт усталость от согласований — после которой заказчик отказывается уже не от процедуры, а от проекта.
- Работа до 150 000 ₽ и до трёх недель. Достаточно одной подписанной страницы с описанием результата и двух-трёх проверок. Версионировать нечего: документ не успевает измениться.
- Разовая настройка внутри существующей системы, где нет нового кода: перенастройка воронки, печатная форма, подключение готового модуля. Приёмка занимает час, спорить не о чем.
- Работа внутренней команды без договора подряда. Там ТЗ живёт в трекере задач, версия — это номер задачи и история изменений в системе, а приложение к договору отсутствует за отсутствием договора.
- Договор поддержки по SLA. Приложением к нему выступает не техзадание, а перечень услуг, времена реакции и классы инцидентов — это другой документ с другой логикой изменения.
- Пилот на неизвестном объёме: обследование, разбор чужой самописной системы. Фиксировать нужно не требования, которых ещё нет, а потолок бюджета и право остановить работы — формулировка предмета для этого случая разобрана в отдельном материале.
Во всех остальных случаях правило одно и стоит полчаса работы: у приложения есть номер, версия, дата, подписи и количество листов, а любое изменение оставляет след. Проверить проект можно за минуту: откройте документ, по которому подрядчик сейчас работает, и найдите на титульном листе дату и две подписи. Если их нет, у вас не техзадание, а черновик, с которым согласны не все.
