ТЗ для проекта: как описать большую задачу от брифа до приёмки

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

Что такое ТЗ для проекта и чем оно отличается от ТЗ на разовую работу

ТЗ для проекта — это документ, который описывает серию взаимосвязанных задач с общей целью, разбитых на этапы с промежуточными результатами. В отличие от разовой задачи (логотип за 5 000 ₽ или лендинг за 30 000 ₽), проект имеет три ключевых отличия:

• Длительность. Проект идёт недели или месяцы, а не дни. За это время требования могут меняться, команда — обновляться, а заказчик — забывать, о чём договаривались на старте.
• Много исполнителей. Дизайнер, разработчик, тестировщик, копирайтер — каждый работает со своей частью, но все должны двигаться к одной цели. Без общего ТЗ они делают разные проекты.
• Высокие риски. Ошибка в ТЗ на 5 000 ₽ стоит пару часов переделок. Ошибка в ТЗ на 500 000 ₽ стоит десятки тысяч и недели работы. Цена недопонимания растёт с масштабом.

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

Миф «один исполнитель закроет весь проект» разбивается о реальность: на больших задачах всегда нужна команда или субподрядчики. Даже если вы работаете с одним фрилансером, он привлекает помощников — и все они должны работать по одному ТЗ.

Структура проектного ТЗ

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

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

Цель проекта — это не «сделать портал», а «запустить внутренний портал для 500 сотрудников, который сократит время на согласование заявок с 3 дней до 2 часов». Бизнес-контекст объясняет, почему проект важен сейчас: рост компании, устаревшие процессы, новые требования регулятора.

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

Требования: функциональные и нефункциональные

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

• Функциональные требования — что система должна делать: «пользователь может создать заявку», «система отправляет уведомление руководителю», «администратор видит статистику по заявкам». Это возможности и сценарии использования.
• Нефункциональные требования — как система должна работать: «загружается за 3 секунды», «выдерживает 1000 одновременных пользователей», «соответствует GDPR», «работает на мобильных устройствах». Это качество, производительность, безопасность.

Для автоматизированных систем (корпоративные порталы, CRM, ERP) можно ориентироваться на структуру ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — это не обязательно, но даёт хорошую структуру для сложных проектов.

Объём и границы: что входит, а что вне проекта

В проекте раздел «что не входит» критически важен. Без него задача расползается: «а давайте ещё добавим мобильное приложение», «а можно интеграцию с нашей бухгалтерией?». Каждое «давайте ещё» — это новые сроки и бюджет.

Чётко пропишите границы: «входит: веб-версия портала, 5 типов заявок, интеграция с Active Directory; не входит: мобильное приложение, интеграция с 1С, обучение пользователей». Если заказчик захочет добавить что-то из «не входит» — это оформляется как изменение проекта с пересмотром сроков и бюджета.

Этапы и сроки: декомпозиция и дедлайны

Проект разбивается на этапы, каждый со своим результатом и сроком. Типичная структура для IT-проекта:

• Этап 1: Проектирование (2 недели) — прототипы, архитектура, детальное ТЗ.
• Этап 2: Дизайн (3 недели) — макеты всех экранов, UI-кит.
• Этап 3: Разработка (8 недель) — функционал по этапам (спринтам).
• Этап 4: Тестирование (2 недели) — исправление багов, нагрузочное тестирование.
• Этап 5: Запуск (1 неделя) — деплой, обучение, передача документации.

Каждый этап имеет свой дедлайн и критерии приёмки. Это позволяет поймать расхождения на ранней стадии (прототип не тот), а не в день финальной сдачи (портал не тот).

Критерии приёмки каждого этапа

У каждого этапа — свои критерии приёмки, а не только у финала. Пример для этапа «Проектирование»:

• Прототипы всех экранов согласованы заказчиком.
• Архитектура системы описана в документе и согласована с техлидом заказчика.
• Детальное ТЗ на разработку написано и подписано обеими сторонами.

Без промежуточных критериев вы принимаете «чёрный ящик» — исполнитель что-то делал два месяца, показал результат, и вы не знаете, правильно ли он понял задачу. С критериями вы проверяете каждый этап и корректируете курс до того, как сделано много не того.

Формат передачи результатов и отчётности

В проекте результат передаётся не один раз, а по этапам. Пропишите для каждого этапа, что именно сдаётся: прототипы в Figma, код в Git-репозитории, документация в Confluence, отчёты о тестировании.

Добавьте требования к отчётности: еженедельные статусы, демо каждые две недели, отчёт о рисках. Это держит проект в поле зрения и не даёт ему уйти в «чёрную дыру», где исполнитель что-то делает, но никто не видит прогресса.

Порядок правок и изменений

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

• Запрос изменения — письменное описание, что нужно изменить и почему.
• Оценка влияния — исполнитель оценивает, как изменение влияет на сроки и бюджет.
• Согласование — заказчик принимает решение: делать изменение (с пересмотром сроков/бюджета) или отложить.
• Фиксация — изменение вносится в ТЗ как приложение, обе стороны подписывают.

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

Таблица: раздел проектного ТЗ, что написать и где ошибаются

Этапность как страховка

Этапность — это не бюрократия, а страховка для обеих сторон. Для заказчика — возможность поймать проблему рано, когда переделать дёшево. Для исполнителя — возможность получить оплату за сделанную работу, даже если проект остановится на середине.

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

Типичная ошибка — оплачивать весь проект сразу на старте. Если через два месяца выяснится, что исполнитель не справляется, вы потеряете и деньги, и время. Этапная оплата с промежуточной приёмкой снижает этот риск до минимума.

Мини-пример

Так выглядит фрагмент проектного ТЗ — раздел «Этап 2: Дизайн» для корпоративного портала:

Этап 2: Дизайн (3 недели, дедлайн — 15 апреля)

Результат этапа: макеты всех экранов портала в Figma, UI-кит с компонентами.

Критерии приёмки:
1. Макеты 15 экранов согласованы заказчиком (подпись в Figma).
2. UI-кит содержит все используемые компоненты: кнопки, формы, таблицы, модальные окна.
3. Дизайн соответствует брендбуку компании (цвета, шрифты, логотип).
4. Макеты адаптированы под desktop (1920px) и tablet (768px).
5. Проведено юзабилити-тестирование на 5 пользователях, отчёт приложен.

Формат передачи: ссылка на Figma-проект с правами на просмотр и комментирование, экспорт UI-кита в PDF.

Оплата: 25% от бюджета проекта после приёмки этапа.

Конкретные критерии, понятный результат, фиксированная оплата — и обе стороны знают, что происходит на этом этапе.

Что уточнит хороший исполнитель

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

• Кто со стороны заказчика принимает каждый этап? Если принимает комиссия из пяти человек, нужно понимать, кто имеет право подписи.
• Какие зависимости от других систем или команд? Если портал интегрируется с CRM, нужно понимать, кто со стороны заказчика отвечает за эту интеграцию.
• Есть ли существующая инфраструктура? Серверы, домены, SSL-сертификаты, лицензии на софт — что уже есть, что нужно купить.
• Какие риски вы видите со своей стороны? Заказчик может знать о подводных камнях, которые не очевидны из ТЗ.
• Как будем коммуницировать? Еженедельные созвоны, ежедневные статусы в чате, демо каждые две недели — формат и частота.
• Что происходит, если этап не принят? Сколько кругов правок входит в этап, что если нужны доработки сверх этого.
• Каков процесс пост-проектной поддержки? Баги после запуска, мелкие доработки, обучение пользователей — это отдельный договор или часть проекта.

Чек-лист проектного ТЗ перед публикацией

Прогоните документ по этому списку, прежде чем публиковать заказ:

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

Что дальше

Проектное ТЗ — это инвестиция в предсказуемость: час, потраченный на детальное описание, экономит недели переделок и споров. Готовый документ разместите на Workink — выберите категорию «Разработка и IT» или «Дизайн» и опубликуйте заказ с этапной оплатой через безопасную сделку. Исполнители увидят структурированный проект и откликнутся предметно, а не шаблонно.

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