Перейти к содержимому

Разбираемся

Как зафиксировать ТЗ юридически — защита от бесплатных правок

Обновлено:

ТЗ написано в переписке, согласовано «на словах», в договоре — общая фраза «оказание услуг». Через 2 недели работы клиент говорит «а ещё нужно вот это, мы же договаривались» — и вы делаете бесплатно, потому что доказательств нет. Чтобы такого не было, ТЗ должно быть приложением к договору с подписями, а не сообщением в Telegram. [Создать ТЗ как приложение →]

Создать ТЗ как приложение к договоруУзнать как составить договор услуг
11 разделов·Что внутри страницы
  1. 01Почему ТЗ в переписке не защищает
  2. 02Как ТЗ становится юридически прочным
  3. 03Что должно быть в ТЗ
  4. 04Защита от scope creep
  5. 05Изменение требований по ходу работы
  6. 06Связанные документы
  7. 07Связанные сценарии
  8. 08Связанные проблемы
  9. 09Чек-лист: ТЗ готово к подписанию
  10. 10Что Dokli делает с ТЗ
  11. 11Частые вопросы

Почему ТЗ в переписке не защищает

Переписку можно «переинтерпретировать»: «я же имел в виду…»

Сообщения в Telegram / WhatsApp юридически — *только* доказательство при заверении нотариусом или скриншотами с метаданными. Это работа на 30+ тыс ₽.

Нет единой версии: 5 сообщений противоречивы, какая последняя?

Нет подписи клиента — он может сказать «это переписывал не я».

Суд (если дойдёт) переписку оценит, но взвесит ниже подписанного документа.

Как ТЗ становится юридически прочным

3 уровня прочности (от слабого к сильному):

  1. «Договор + общее описание работ внутри» — слабая защита. Описание = 1 предложение, спорные ситуации не разруливает.
  1. «Договор + ТЗ в приложении, подписанное обеими сторонами» — нормальная защита. ТЗ ссылается на договор, договор ссылается на ТЗ как «Приложение №1». Каждый лист подписан.
  1. «Договор + ТЗ + критерии приёмки (acceptance criteria)» — максимальная защита. К ТЗ добавлен список «работа считается принятой при выполнении следующих условий…». Споры закрываются проверкой по списку.

Что должно быть в ТЗ

  • Объём работ — конкретный список (не «сайт под ключ», а «дизайн 7 страниц + вёрстка 5 страниц»).
  • Что НЕ входит — отдельный список. Это спасает: «логотип не входит, нужен — отдельный заказ».
  • Сроки по этапам — не только финальная дата, но и промежуточные.
  • Критерии приёмки — что значит «готово».
  • Формат сдачи — какие файлы, в каком виде, с какими исходниками.
  • Количество правок — «3 раунда правок включены, 4-я и далее — по тарифу».
  • Что считается изменением требований — «добавление новой страницы / функции = изменение требований, оформляется доп. соглашением».

Защита от scope creep

Scope creep = «давай ещё чуть-чуть, это же мелочь». Не мелочь.

Стратегия защиты в три шага:

  1. В ТЗ заранее: пункт «изменение требований оформляется дополнительным соглашением (стоимость и срок пересчитываются)». Без этого — клиент будет пушить устно.
  1. При запросе изменения: ответ всегда в письме — «да, можем сделать, это изменение требований, новая стоимость + N дней. Подтвердите?». Не молчите и не делайте «по-быстрому» — это создаёт прецедент.
  1. Если клиент настаивает «без доп. соглашения»: вежливый отказ или фиксация *хотя бы* в имейле «согласовано бесплатное добавление X, без увеличения сроков; следующее изменение — по основной процедуре».

Изменение требований по ходу работы

Ссылка на старое ТЗ как «отменённое».

Что добавилось / убралось / изменилось — отдельный список.

Новая сумма (или подтверждение что цена не меняется).

Новые сроки.

Связанные документы

Техническое задание — основной шаблон.

Договор оказания услуг — куда ТЗ становится приложением.

Приложение к договору — формат оформления.

Дополнительное соглашение — для изменения ТЗ.

Хотите сразу к делу?

Dokli соберёт документ по этому сценарию с проверкой рисков перед выпуском.

Создать документ

Связанные сценарии

Работа по этапам — где детальное ТЗ обязательно.

Изменение условий договора — когда ТЗ нужно обновить.

Связанные проблемы

Чек-лист: ТЗ готово к подписанию

  • [ ] ТЗ оформлено отдельным документом (не сообщением в чате).
  • [ ] Озаглавлено «Приложение №1 к договору №X от DD.MM.YYYY».
  • [ ] Содержит список «что входит» и «что НЕ входит».
  • [ ] Указаны сроки по этапам, не только финальная дата.
  • [ ] Прописаны критерии приёмки.
  • [ ] Указан формат сдачи (файлы, исходники).
  • [ ] Указано количество правок.
  • [ ] Есть пункт «изменение требований = доп. соглашение».
  • [ ] Каждый лист содержит подписи обеих сторон.

Что Dokli делает с ТЗ

Создаёт ТЗ как приложение к договору с автоссылкой.

Использует данные договора (стороны, реквизиты, общая сумма) — реквизиты не дублируются вручную.

При экспорте PDF — ТЗ и договор идут одним документом или раздельно (на ваш выбор).

При создании дополнительного соглашения — старая и новая версия ТЗ показаны рядом.

Частые вопросы

Может ли ТЗ быть в Word без подписи?

Подпись — это не «электронная подпись», это и от руки на распечатке, и сканированная подпись на email-вложении. Минимум — обмен подписанными PDF. Просто Word без подписи = не приложение.

Если ТЗ переехало в Notion / Figma — это юридически работает?

Notion/Figma как ссылка в договоре работает только если в договоре прописано «зафиксированное на DD.MM.YYYY состояние документа по ссылке X». Иначе клиент может сказать «вы изменили ТЗ задним числом».

Что если ТЗ согласовано устно во время созвона?

Запись созвона + протокол = доказательство, но слабее подписи. Лучший паттерн: после созвона прислать «по итогам созвона договорились о следующем (список), подтвердите ответом ДА». Письменное подтверждение = договорённость.

Можно ли в ТЗ написать только «по согласованию с заказчиком»?

Технически можно, юридически = слабая позиция. Чем больше «по согласованию» — тем больше пустых мест для будущего спора. Лучше прописать заранее границы.

Готовы перейти к документу?

Dokli соберёт документ по вашему сценарию с вопросами по делу и проверкой рисков перед выпуском.