Перейти к содержимому
Dokli
Создать

Техническое задание

Техническое задание (ТЗ) или бриф — структурированный документ, описывающий что именно нужно сделать. Без ТЗ любой проект превращается в бесконечные правки и недопонимания. ТЗ обычно идёт приложением к договору подряда и делает работу измеримой: есть критерий «сделано» — есть основания для подписания акта и оплаты.

Когда нужен этот документ

Перед началом работ, особенно по договору подряда или сложного оказания услуг. ТЗ описывает что именно нужно сделать, в каком объёме, по каким критериям приёмки. Подписанное ТЗ становится приложением к договору и снижает количество споров.

Поддержка по странам

Статус определяется матрицей поддержки Growth V2 и обновляется по мере расширения.

  • РоссияRU
    Поддерживается
  • КазахстанKZ
    Поддерживается с предупреждениями
  • БеларусьBY
    Поддерживается с предупреждениями
  • УзбекистанUZ
    Ограниченный режим — типовые ситуации
  • УкраинаUA
    Ограниченный режим — типовые ситуации
По профессии

Вариант документа, адаптированный под особенности вашей деятельности

Кому подходит

  • Разработчики, дизайнеры — для измеримой передачи результата
  • Агентства и веб-студии — приложение к договору с заказчиком
  • Заказчики, которые хотят точно зафиксировать ожидания на старте

Когда документ не подходит

  • Для типовых разовых задач (одна правка, мелкая консультация) — достаточно описания в теле договора
  • Когда стороны намеренно работают в режиме T&M (time & materials) — там ТЗ заменяется бэклогом и спринтами
  • Для маркетинговой коммуникации (бриф) — это другой по жанру документ

Какие данные потребуются для сборки

Подставляются автоматически из профиля и карточки контрагента — где это возможно.

  • Цель проекта в одном предложении
  • Целевая аудитория и контекст использования
  • Функциональные требования — список
  • Нефункциональные требования (скорость, дизайн, совместимость)
  • Объём работ — количественные параметры (страниц, экранов, итераций)
  • Критерии приёмки — измеримые
  • Что НЕ входит в объём — отдельный список
  • Сроки и этапы
  • Что предоставляет заказчик (тексты, фото, доступы)

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

Зачем нужно ТЗ

ТЗ — это контракт внутри контракта. Оно отвечает на вопросы: что делаем, как измеряем результат, что не делаем. Фрилансер защищён от «давайте ещё одну правку», заказчик — от «ну вы же не говорили что нужно так».

Структура правильного ТЗ

Цель проекта (одно предложение), целевая аудитория, функциональные требования (что должно работать), нефункциональные (скорость, совместимость, дизайн-стиль), объём работ (количество страниц/экранов/разделов), критерии приёмки, что НЕ входит в проект, сроки и этапы.

Чем бриф отличается от ТЗ

Бриф — это вводный документ от заказчика на старте («хочу сайт для ресторана»). ТЗ — технический документ, подписанный обеими сторонами, с точными требованиями. Обычно: клиент даёт бриф → исполнитель превращает в ТЗ → обе стороны подписывают.

Что обязательно должно быть в документе

  • Заголовок и номер документа (приложение к договору)
  • Цель проекта — одно предложение
  • Описание целевой аудитории / контекста использования
  • Функциональные требования — списком
  • Нефункциональные требования (скорость, дизайн, совместимость)
  • Объём работ — количественные показатели
  • Что НЕ входит в проект — отдельным списком
  • Критерии приёмки — измеримые
  • Сроки и этапы
  • Материалы от заказчика — что и когда предоставляет

Правовая база

  • — Ст. 702 ГК РФ — ТЗ как часть договора подряда
  • — Ст. 708 ГК РФ — сроки выполнения
  • — Ст. 720 ГК РФ — приёмка в соответствии с ТЗ

Частые ошибки

  • Расплывчатые формулировки «красивый дизайн», «быстрый сайт»
  • Нет раздела «не входит» — все правки считаются внутри бюджета
  • Нет количественных критериев — сколько ревизий, страниц, часов
  • ТЗ не подписано — юридически это просто заметки
  • Меняют ТЗ без допсоглашения — потом невозможно доказать, что было изначально

Риски, которые Dokli помогает увидеть

Сигналы, которые система покажет до выпуска документа. Не заменяет юридическую экспертизу — это автоматическая диагностика по чек-листу.

  • Размытые формулировки («красивый», «быстрый», «современный») — субъективные споры по приёмке
  • Нет раздела «не входит» — все доработки воспринимаются как часть оплаченного объёма
  • Не указано количество ревизий — конфликт «ещё одна правка»
  • ТЗ не подписано или нет ссылки на него в договоре — юридически это просто заметки
  • Меняют ТЗ без допсоглашения — потом невозможно доказать, что было изначально

Что Dokli не гарантирует

  • Соответствие ТЗ требованиям конкретной отрасли (медицина, финансы) — нужна доменная экспертиза
  • Описание сложных технических архитектур — для этого нужны архитекторы / системные аналитики
  • Юридическая оценка передачи прав на использованные библиотеки и компоненты

Когда обязательно нужен юрист или ручной просмотр

  • ТЗ описывает создание ПО, передаваемого по open-source лицензии или с использованием third-party — нужна оценка лицензионной чистоты
  • Передача прав на товарный знак или брендинг — нужна регистрация в Роспатенте
  • ТЗ для государственного контракта или тендера — отдельная нормативная база

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

Можно ли менять ТЗ после подписания?▾

Только через дополнительное соглашение. В нём фиксируются: что именно меняется, как меняется стоимость, как сдвигаются сроки. Изменения «на словах» потом невозможно доказать.

Что делать если клиент присылает бриф в два предложения?▾

Ваша задача — превратить это в полноценное ТЗ. Сделайте черновик ТЗ на основе брифа + уточняющих вопросов и попросите клиента его проверить и подписать. Это стандартная практика и она входит в начальные этапы проекта.

Можно ли взять готовое ТЗ из интернета?▾

Скелет — можно, но адаптировать под конкретный проект обязательно. Обобщённое ТЗ ни от чего не защищает.

Кто составляет ТЗ — заказчик или исполнитель?▾

Обычно исполнитель (он знает технические детали), а заказчик вычитывает и подтверждает. Главное — оба подписались под финальной версией.

Сколько страниц должно быть в ТЗ?▾

Столько, сколько нужно. Для лендинга — 2-4 страницы. Для корпоративного сайта — 10-20. Для мобильного приложения — 30-50. Короче — лучше, но не за счёт потери точности.

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

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

Связанные статьи

Связанные инструменты

Бесплатные проверки, которые полезны до или после подготовки документа.

Главный следующий шаг

Сборка по сценарию с проверкой рисков. Без оплаты на старте.

Подготовить «техническое задание»
Проверить свой договор
Сценарии использования →Все документы →

Контент проверен редакцией Dokli · Обновлено: