ТЗ для проекта: пример структуры, границ, этапов и приёмки

«Сделайте проект» — самая опасная формулировка в работе с исполнителями. Проект может длиться недели, включать несколько команд, зависимостей и согласований, а ТЗ при этом остаётся на одну страницу: «нужно внедрить, настроить, обучить». В итоге заказчик ожидает бизнес-результат, исполнитель сдаёт набор задач, а спор начинается на приёмке. Разбираем, как составить ТЗ для проекта, чтобы в документе были не только требования, но и границы, этапы, метрики, порядок изменений и критерии сдачи. В конце — готовый пример структуры проектного ТЗ.

Что такое ТЗ для проекта и когда оно спасает

ТЗ для проекта — это документ, который описывает не отдельную функцию или макет, а целый результат: что должно появиться, в какие сроки, какими силами, с какими ограничениями и по каким критериям будет принято. Оно связывает бизнес-цель, объём работ, команду, риски, бюджет и приёмку в одну управляемую конструкцию.

Проектное ТЗ спасает, когда задача сложнее одной услуги:

• Несколько этапов и подрядчиков. Например, аналитика, дизайн, разработка, миграция данных, обучение, поддержка. Без общего ТЗ каждый исполнитель тянет одеяло на свою часть.
• Есть жёсткие границы бюджета и сроков. Проектное ТЗ помогает отделить «входит в стоимость» от «дополнительная задача».
• Результат должен измеряться бизнес-эффектом. Не просто «сайт сделан», а «заявки обрабатываются в CRM, менеджеры видят историю, руководитель получает отчёт».
• Высокий риск изменения требований по ходу. В проектах заказчик часто уточняет желания после первых демо. ТЗ с порядком изменений защищает от бесконечного scope creep.
• Нужна защита от споров на приёмке. Если критерии готовности зафиксированы заранее, стороны обсуждают не «нравится / не нравится», а соответствие документу.

Хорошее ТЗ для проекта — это не список желаний, а базовая линия: от неё считают объём, сроки, стоимость, риски и приёмку.

Если задача локальная — например, нарисовать логотип или собрать один экран — достаточно частного ТЗ. Но если проект включает процесс, людей, интеграции, данные и срок, без проектного документа вы быстро получите ситуацию: «мы же не это имели в виду».

Специфика ниши проекта: 5 особенностей, которые влияют на ТЗ

Проект отличается от разовой услуги. В нём важны не только «что сделать», но и «в каком порядке, кем, с какими зависимостями и что делать при изменениях». Эти особенности нужно зашивать в ТЗ.

1. Проект имеет границы, а не только содержание

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

Например, для проекта автоматизации продаж в ТЗ можно написать: «интеграция с 1С не входит, предоставляется только обмен через CSV; обучение не более 5 пользователей; доработка mobile-версии сайта — отдельный этап».

2. Результат декомпозируется на этапы и артефакты

Проект нельзя принять «целиком» без промежуточных точек. Нужно разложить его на артефакты: бриф, схема процессов, прототип, ТЗ на разработку, тестовый контур, обученные пользователи, акт. Каждый артефакт имеет свой критерий готовности.

Если в ТЗ нет декомпозиции, исполнитель может долго «работать», а заказчик не видеть, за что платит. Этапы делают проект управляемым.

3. Зависимости и риски важнее идеального списка требований

В проекте почти всегда есть внешние зависимости: доступы, данные, согласования, инфраструктура, сторонние сервисы, юристы, безопасность. Если их не описать, срыв сроков станет «виной исполнителя», хотя причина была в отсутствии доступа к тестовой среде.

В ТЗ стоит выделить раздел с рисками: что может пойти не так, кто за это отвечает, как фиксируется перенос сроков. Это не пессимизм, а управление.

4. Управление изменениями — часть ТЗ, а не приложение к договору

Проект живёт: меняются приоритеты, появляются новые инсайты, вскрываются данные. Хорошо, если ТЗ заранее говорит, как вносить изменения: заявка, оценка влияния на срок и стоимость, согласование, фиксация в чате или допсоглашении. Без этого любой «маленький запрос» разрушает план.

На Workink удобно, что договорённости в чате заказа имеют силу ТЗ: если вы согласовали изменение объёма перепиской, это уже рабочий след для обеих сторон.

5. Приёмка проекта — это не один акт, а система проверок

Проект принимается по нескольким контурам: функциональному, техническому, пользовательскому, документационному. Мало, что «кнопка работает». Нужно проверить роли, данные, интеграции, нагрузку, обучение, инструкции, резервные копии, порядок поддержки.

Для проектного ТЗ критерии приёмки должны быть измеримыми: не «система удобная», а «менеджер создаёт сделку за 4 поля, отчёт формируется не дольше 10 секунд, 5 пользователей прошли обучение и подписали акт».

Структура ТЗ для проекта

1. Цель проекта и бизнес-результат

Начните не с функций, а с того, какой бизнес-эффект должен появиться. Цель формулируется через изменение в работе компании: сократить время обработки заявок, повысить конверсию, убрать ручной учёт, обеспечить прозрачность для руководителя, запустить новое направление.

Плохо: «Внедрить CRM». Хорошо: «Перевести обработку входящих заявок из почты и мессенджеров в единую систему, чтобы менеджер видел историю клиента, а руководитель получал отчёт по конверсии и просрочкам».

Добавьте 2–4 метрики успеха: срок обработки заявки, процент потерянных лидов, время формирования отчёта, количество пользователей в системе, доля сделок с заполненными обязательными полями.

2. Границы проекта: что входит и что не входит

Это ключевой раздел проектного ТЗ. Опишите:

• какие процессы затрагивает проект;
• какие системы и пользователи включены;
• какие данные migрируются, а какие нет;
• какие интеграции обязательны, а какие отложены;
• что не входит: дизайн бренда, контент, юридическое согласование, поддержка стороннего ПО, обучение подрядчиков заказчика;
• кто из сторон отвечает за доступы, согласования, инфраструктуру.

Чем конкретнее исключения, тем меньшеlater споров. Фраза «всё необходимое для запуска» не является границей.

3. Требования к результату и процессу

В проектном ТЗ нужно разделить требования на два типа: к конечному продукту и к самому процессу работы.

К продукту: функциональность, роли, права, отчёты, интеграции, производительность, безопасность, совместимость, мобильная версия, аудит действий.

К процессу: еженедельные статусы, доступ к тестовой среде, порядок согласования макетов, хранение исходников, документирование изменений, участие представителей заказчика, сроки обратной связи.

Если не задать требования к процессу, проект может быть технически верным, но управляемо хаотичным: согласования затягиваются, статусы не приходят, решения принимаются не тем лицом.

4. Объём работ и декомпозиция

Разбейте проект на логические блоки. Не обязательно сразу до уровня задач, но достаточно, чтобы каждый блок имел результат:

• обследование и аналитика;
• проектирование процесса «как будет»;
• настройка или разработка;
• интеграции;
• миграция данных;
• тестирование;
• обучение;
• опытная эксплуатация;
• передача в поддержку.

Для каждого блока укажите вход, выход и ответственного. Например: вход аналитики — интервью и доступ к текущей системе; выход — схема процесса и перечень требований; ответственный — бизнес-аналитик исполнителя и владелец процесса со стороны заказчика.

Если проект IT-направленный, полезно свериться с примером ТЗ для ПО. Он показывает, как переводить бизнес-требования в функциональные и нефункциональные пункты.

5. Сроки, этапы и контрольные точки

Проектное ТЗ должно содержать не только дедлайн, но и контрольные точки. Каждая точка — это событие, по которому можно понять, идёт проект по плану или нет.

Пример контрольных точек:

• согласована схема процесса «как будет» — 10 рабочий день;
• утверждён перечень интеграций и форматов данных — 15 рабочий день;
• готов тестовый контур с миграцией 100 записей — 30 рабочий день;
• проведено обучение 5 ключевых пользователей — 40 рабочий день;
• подписан акт опытной эксплуатации — 50 рабочий день.

Важно зафиксировать, что срок может сдвигаться, если заказчик не предоставил доступы, данные или согласование. Но сам факт задержки должен фиксироваться письменно, а не «на словах».

6. Критерии приёмки результата проекта

Критерии приёмки — это чек-лист, по которому проект считается завершённым. Они должны быть проверяемыми. Не «работа выполнена качественно», а «все пользовательские сценарии из приложения 2 проходят без критических дефектов».

Хорошая структура приёмки включает:

• функциональные сценарии;
• права доступа и роли;
• интеграции и обмен данными;
• производительность;
• безопасность и логирование;
• обучение и инструкции;
• передачу исходников и доступов;
• гарантийный период.

Отдельно пропишите, что считается критическим дефектом, что — несущественным, и в какие сроки исполнитель обязан устранить каждое.

7. Формат передачи и документация

Проект не заканчивается «работает». Нужно передать артефакты, без которых система станет чёрным ящиком:

• техническая документация;
• описание процессов;
• инструкции для пользователей и администратора;
• доступы и учётные записи;
• исходники или конфиги, если это предусмотрено;
• резервные копии или регламент восстановления;
• реестр интеграций и форматов;
• акты этапов и финальный акт.

Укажите формат: PDF, DOCX, wiki, репозиторий, личная папка, ссылка на базу знаний. Для проектов с несколькими подрядчиками единый формат передачи критичен.

8. Правки и управление изменениями

В проектном ТЗ нужен раздел «Порядок изменений». Он должен отвечать на вопросы:

• кто может инициировать изменение;
• в какой форме подаётся запрос;
• за какой срок исполнитель оценивает влияние на срок и бюджет;
• как согласовывается изменение;
• что считается правкой в рамках этапа, а что — новой задачей;
• как фиксируется перенос сроков из-за изменений.

Пример формулировки: «Правки в пределах согласованного этапа включены в стоимость. Изменение бизнес-процесса, добавление новой роли, интеграции или отчёта оценивается отдельно и оформляется письменно в чате заказа или дополнительным соглашением».

Для постановки таких правил удобно использовать план для ТЗ и вопросы для ТЗ. Они помогают не забыть про согласования, ответственность и точки контроля.

Готовый пример ТЗ

Ниже — сокращённый, но рабочий пример проектного ТЗ для внедрения CRM в отделе продаж. Его можно адаптировать под другой проект:替换 название, метрики, интеграции и этапы.

1. Паспорт проекта

Название: автоматизация обработки входящих заявок в отделе продаж.
Заказчик: компания услуг B2B, 12 менеджеров, 3 руководителя.
Исполнитель: интегратор CRM.
Срок: 8 недель с даты подписания ТЗ.
Бюджет: фиксированный в рамках этапов 1–5; изменения оцениваются отдельно.

2. Цель и бизнес-результат

Перевести приём заявок из почты, Telegram и телефонии в единую очередь CRM. Обеспечить назначение менеджера, контроль сроков ответа и отчётность по конверсии.

Метрики успеха:

• среднее время первого ответа — не более 15 минут в рабочее время;
• доля заявок без ответственного — 0%;
• время формирования отчёта по воронке — не более 1 минуты;
• не менее 10 менеджеров работают в системе после обучения.

3. Границы проекта

Входит:

• обследование текущего процесса;
• настройка CRM: лиды, сделки, задачи, роли, отчёты;
• интеграция с почдой и Telegram-ботом;
• загрузка исторических данных за 6 месяцев из Excel;
• обучение 12 пользователей и 3 руководителей;
• инструкции и тестовая эксплуатация 2 недели.

Не входит:

• интеграция с 1С;
• разработка мобильного приложения;
• изменение телефонии оператора;
• написание маркетинговых текстов;
• поддержка сторонних плагинов после сдачи;
• доработка сайта заказчика.

4. Пользователи и роли

• менеджер: видит свои заявки, меняет стадию, ставит задачи, добавляет комментарии;
• руководитель отдела: видит всю воронку, распределяет заявки, получает отчёты;
• администратор: управляет пользователями, справочниками, правами;
• собственник/директор: read-only доступ к сводным отчётам.

5. Функциональные требования

• заявка из почты создаёт лид автоматически, с темой, отправителем, текстом и вложениями;
• сообщение из Telegram создаёт лид с указанием чата и текста;
• система назначает менеджера по правилу: округление по загрузке, затем по алфавиту;
• если заявка не взята в работу 15 минут, руководитель получает уведомление;
• обязательные поля для перевода в сделку: компания, контакт, потребность, источник;
• отчёт: количество заявок, конверсия по стадиям, среднее время ответа, просрочки.

6. Нефункциональные требования

• доступность в рабочее время — 99,5%;
• время открытия карточки заявки — не более 2 секунд;
• логирование изменений статуса и назначения менеджера;
• резервное копирование конфигурации — ежедневно;
• работа в Chrome, Edge, Safari последних двух версий.

7. Этапы и сроки

• Этап 1. Обследование и согласование схемы — 1 неделя;
• Этап 2. Настройка CRM и интеграций в тестовом контуре — 2 недели;
• Этап 3. Миграция исторических данных и тестирование — 1 неделя;
• Этап 4. Обучение и опытная эксплуатация — 3 недели;
• Этап 5. Приёмка и передача документации — 1 неделя.

8. Критерии приёмки

• 10 тестовых заявок из почты и Telegram созданы корректно;
• назначение менеджера работает по правилу;
• просрочка фиксируется и уведомляет руководителя;
• отчёт формируется за 1 минуту и совпадает с ручной выборкой;
• исторические данные загружены без потерь;
• пользователи обучены, инструкции переданы;
• критические дефекты отсутствуют.

9. Формат передачи

Исполнитель передаёт: доступы администратора, конфигурацию, инструкции в PDF, запись обучения, реестр интеграций, акт приёмки. Исходные Excel-файлы миграции остаются у заказчика.

10. Порядок изменений

Новые требования принимаются через чат заказа. Исполнитель в течение 2 рабочих дней оценивает влияние на срок и стоимость. Изменения, влияющие на бюджет более чем на 10%, оформляются дополнительно. Договорённости в чате имеют силу ТЗ.

Этот пример можно использовать как каркас. Если проект не IT, а, например, ремонт, маркетинговая кампания или запуск производства, логика остаётся той же: цель, границы, этапы, приёмка, изменения, передача. Для разных ниш меняются только артефакты и метрики.

Критерии приёмки результата проекта

Проект считается принятым, если выполнены все условия из ТЗ. Вот измеримый набор критериев, который подходит для большинства проектов:

• Бизнес-цель подтверждена метриками. Не «вроде стало удобнее», а конкретные показатели достигнуты или зафиксированы причины отклонения.
• Все этапы закрыты актами. Каждый артефакт принят: схема, настройка, миграция, обучение, документация.
• Пользовательские сценарии проходят тестирование. Проверены ключевые роли и типовые задачи, включая ошибки и граничные условия.
• Интеграции работают в штатном и аварийном режиме. Данные передаются, дубликаты обрабатываются, при недоступности внешней системы есть понятное поведение.
• Права доступа соответствуют матрице. Пользователь не видит лишнего, администратор может управлять доступами без участия исполнителя.
• Критические дефекты устранены. Список дефектов зафиксирован, критичные закрыты, некритичные согласованы к устранению в гарантийный период.
• Обучение проведено и задокументировано. Пользователи получили инструкции, запись или доступ к базе знаний; ключевые администраторы подтвердили готовность.
• Документация и доступы переданы. Заказчик может самостоятельно развивать или поддерживать результат без исполнителя.
• Гарантийные условия зафиксированы. Указаны срок гарантии, канал обращений, SLA на реакцию и устранение.
• Изменения оформлены письменно. Все отклонения от исходного ТЗ согласованы и отражены в чате, акте или допсоглашении.

Вопросы для уточнения до старта

Эти вопросы нужно задать до подписания ТЗ или первого этапа. Они помогают превратить расплывчатый проект в управляемый документ.

• Какой бизнес-результат ожидается и как он будет измеряться через 1, 3 и 6 месяцев?
• Кто является владельцем проекта со стороны заказчика и кто принимает решения?
• Какие пользователи, подразделения и процессы затронуты?
• Какие системы, данные и доступы уже есть, а какие нужно получить?
• Какие интеграции обязательны для запуска, а какие можно отложить?
• Какие требования к безопасности, хранению данных и резервному копированию?
• Есть ли жёсткий дедлайн и почему он важен: запуск, отчётность, сезон, инвесторы?
• Каков бюджет и допустим ли он как фиксированный, или нужна поэтапная оценка?
• Кто готовит контент, данные, тесты, согласования и обратную связь?
• Какой порядок приёмки: по этапам, по функциональным блокам или один финальный акт?
• Что считается критическим дефектом, а что — улучшением?
• Как вносятся изменения: через чат, допсоглашение, заявку в трекере?
• Какая поддержка нужна после сдачи: гарантия, сопровождение, развитие?
• Есть ли внешние зависимости: регуляторы, площадки, хостинг, операторы связи, юристы?
• Кто отвечает за обучение и как проверить, что пользователи готовы работать?

Если на часть вопросов нет ответа, это не всегда стоп-сигнал. Но тогда в ТЗ нужно зафиксировать этап обследования и условие: «детальные требования уточняются по итогам этапа 1, изменение объёма оформляется письменно».

Чек-лист готовности ТЗ

Перед тем как отдавать проект в работу, проверьте документ по короткому списку:

• Цель сформулирована через бизнес-результат и метрики, а не через название системы.
• Описаны границы: что входит, что не входит, кто отвечает за доступы и данные.
• Есть декомпозиция на этапы с артефактами и ответственными.
• Указаны сроки, контрольные точки и условия переноса при задержках заказчика.
• Прописаны функциональные и нефункциональные требования, роли и права.
• Есть критерии приёмки, классификация дефектов и порядок подписания актов.
• Определён порядок изменений и разграничены правка, доработка и новая задача.
• Указан формат передачи документации, доступов, исходников и инструкций.

Если хотя бы три пункта вызывают затруднение, проект лучше сначала обсудить с исполнителем или аналитиком. В проектной работе дешевле потратить неделю на уточнение ТЗ, чем месяц на переделку результата.

Как заказать проект на Workink

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

Платформа снижает типовые проектные риски:

• Безопасная сделка: деньги находятся в резерве до приёмки работы по согласованным критериям.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без дополнительного удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если результат не соответствует зафиксированным требованиям, исполнитель устраняет несоответствия.
• Договорённости в чате имеют силу ТЗ: уточнения по этапам, доступам, правкам и срокам сохраняются в переписке и могут служить подтверждением условий.

Перед публикацией заказа подготовьте проектное ТЗ по структуре из статьи: цель, границы, этапы, приёмка, изменения, передача. Это сэкономит время на согласованиях и защитит бюджет от разрастания объёма.

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

• Пример ТЗ для ПО — если проект связан с разработкой и нужно детализировать функциональные требования.
• План для ТЗ — как превратить проект в последовательность этапов и контрольных точек.
• Вопросы для ТЗ — список уточнений, который помогает закрыть слабые места проектного ТЗ.
• ТЗ для разработчика — взгляд исполнителя на проектные требования и декомпозицию.
• Шаблоны ТЗ — готовые каркасы документов, которые можно адаптировать под проект.