Как составить техническое задание на бизнес-услуги: структура, критерии приёмки и типичные ошибки

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

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

Подготовка: что определить до открытия редактора

Написание ТЗ начинается не с заголовка «1. Общие положения», а с ответов на три вопроса. Без них документ превратится в шаблон, который не решает вашу задачу.

• Какой бизнес-проблема решается? Не «нужен SMM», а «нужно снизить стоимость лида от 1500 до 1000 руб. за 3 месяца в сегменте В2В». Проблема задаёт вектор для всех решений исполнителя.
• Каковы измеримые критерии успеха (KPI/OKR)? Конкретные метрики, дедлайны и пороговые значения. «Увеличить трафик» — плохо. «Довести органический трафик до 10 000 уникальных посетителей в месяц к 30 ноября» — хорошо.
• Какая модель оплаты и ответственности? Фиксированная цена (Fixed Price) требует максимально детального ТЗ. Почасовая / Time & Materials допускает гибкость, но требует строгого регламента согласования изменений и отчёта по часам.

Если вы не можете сформулировать метрику успеха, вы не готовы к ТЗ. В этом случае первым этапом заказывают аудит или стратегическую сессию с доставляемым артефактом (отчёт, дорожная карта), который станет входом для основного ТЗ.

Обязательная структура ТЗ на услуги

Универсального ГОСТа на бизнес-услуги нет, но практика выработала набор разделов, без которых документ неработоспособен. Порядок может меняться, смысл — нет.

1. Предмет и цель работ

Кратко: что делается, зачем и какой артефакт передаётся в конце. Пример: «Разработка и внедрение системы мотивации отдела продаж (предмет) для снижения текучести кадров с 35% до 15% в год (цель). Результат — утверждённый Положение о мотивации (PDF) и проведённые обучающие встречи (артефакты)».

2. Входные данные и предоставляемые заказчиком ресурсы

Что исполнитель получает от вас до старта: доступы к аналитике, брендбук, контакты ЛПР (лиц, принимающих решения), тестовые среды, исторические данные, серверные мощности. Укажите сроки предоставления и последствия задержки (сдвиг дедлайнов, изменение стоимости).

3. Комплект поставки (Deliverables) — самый важный раздел

Перечислите все передаваемые артефакты с форматами, объёмами и языками. Не «отчёт по SEO», а «Технический аудит сайта (PDF, 15+ стр., RU/EN), Чек-лист ошибок (Google Sheets), План приоритетных задач (Notion/Jira)». Для консалтинга: «Презентация стратегии (PPTX, 30 слайдов), Финансовая модель (XLSX), Протокол согласования (PDF)».

4. Критерии приёмки и KPI (Acceptance Criteria)

Это контрактная база для подписания акта. Для каждого артефакта или этапа опишите, как именно вы проверите качество.

Тип услуги	Пример слабого критерия	Пример сильного критерия (SMART)
Разработка / IT	Сайт работает быстро	Google PageSpeed Insights ≥ 90 (mobile) на 3 ключевых страницах; TTFB < 200 мс на сервереステージнге
Маркетинг / Реклама	Хорошие объявления	CTR ≥ 2.5% в поиске Яндекса за 14 дней; CPA ≤ 800 руб.; модерация без отклонений
Дизайн / Брендинг	Красивый логотип	Векторные исходники (AI, SVG), гайдлайн (PDF), прохождение теста на уникальность (ТМ), утверждение арт-директором заказчика
Консалтинг / Аудит	Полезный отчёт	Отчёт содержит: текущее состояние (AS-IS), 3 варианта TO-BE с ROI-расчётом, план миграции на 6 мес., оценка рисков. Утверждается подписью CEO заказчика
Обучение / HR	Провести тренинг	Проведено 3 занятия по 4 часа; NPS участников ≥ 8/10; 90% сдали итоговый тест; материалы переданы в LMS

Правило: Если критерий нельзя проверить объективно за 15 минут без привлечения сторонних экспертов — он плохой. Переформулируйте или добавьте процедуру экспертизы в ТЗ.

5. Этапы, календарный план и контрольные точки (Milestones)

Разбейте работу на этапы с датами начала/окончания и привязкой к оплатам. Для каждого этапа укажите: какой артефакт сдаётся, кто подписывает акт, сколько дней на доработку замечаний (обычно 3–5 рабочих дней). Пример структуры этапа:

1. Этап 1: Исследование и АС-ИС. Дедлайн: 10 рабочих дней. Артефакт: Отчёт AS-IS. Приёмка: согласование ЛПР заказчика. Оплата: 30%.
2. Этап 2: Проектирование решения (TO-BE). Дедлайн: 15 рабочих дней после приёмки Этапа 1. Артефакт: Презентация + Финмодель. Приёмка: экспертная оценка + подпись CEO. Оплата: 40%.
3. Этап 3: Внедрение / Пилот. Дедлайн: 20 рабочих дней. Артефакт: Акт внедрения + Метрики пилота. Приёмка: достижение KPI пилота. Оплата: 30%.

6. Процедура изменений (Change Request)

Бизнес-услуги меняются в процессе. Зафиксируйте: как инициируется изменение (форма заявки), кто оценивает влияние на сроки/бюджет (обычно 2–3 дня), как утверждается доп. соглашение. Без этого любое «а давайте ещё вот это» съедает маржу исполнителя или бюджет заказчика неконтролируемо.

7. Интеллектуальная собственность и конфиденциальность

Кому принадлежат права на результаты (исключительное право заказчику — стандарт для B2B), как используются предварительные материалы (черновики, библиотеки исполнителя), режим НДА, сроки хранения данных после проекта. Укажите, передаются ли исходники (код, PSD, Figma, рабочие файлы модели) или только конечные форматы.

8. Отчётность и коммуникация

Регламент: еженедельные статусы (письменно/звонок), формат отчёта по времени (для T&M), доступ к трекеру задач (Jira, Trello, Asana), контакты эскалации при конфликтах.

Как описывать объём работ (Scope), чтобы не спорить потом

Самая частая причина споров — размытость границ. Используйте три техники:

• Список «Входит в объём» (In Scope). Детальный перечень работ. Для разработки — User Stories с Definition of Done. Для маркетинга — количество кампаний, групп объявлений, баннеров, правок. Для аудита — список проверяемых систем/процессов.
• Список «Не входит в объём» (Out of Scope). Явные исключения: «Настройка серверной инфраструктуры не входит», «Написание текстов для лендинга не входит», «Работа с юристами по согласованию договора не входит». Это спасает от scope creep (неконтролируемого расширения).
• Пределы ответственности исполнителя. Ограничьте гарантии: «Исполнитель не гарантирует рост продаж, гарантирует выполнение работ по методологии X и достижение промежуточных метрик Y». Укажите форс-мажоры и зависимость от третьих лиц (модерация площадок, действия конкурентов, задержки заказчика).

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

Процедура приёмки должна быть прописана в ТЗ или приложении к договору. Типичный алгоритм:

1. Исполнитель присылает артефакт + заявку на приёмку.
2. Заказчик имеет N дней (фиксировано в ТЗ) на проверку по чек-листу критериев.
3. Результат: Подписанный акт (работа принята) или Мотивированный отказ со списком несоответствий (ссылка на пункт ТЗ/Критерий). «Не нравится» — не аргумент.
4. Исполнитель устраняет замечания за M дней (фиксировано). Цикл повторяется.
5. Если заказчик молчит сверх срока — считается принято (deemed acceptance). Пропишите это явно.

Важно: Для сложных услуг (IT, консалтинг) введите промежуточные приёмки (Demo, Code Review, промежуточные отчёты). Принимать всё в конце — риск получить не то, что нужно, за полгода работы.

Типичные ошибки в ТЗ и как их избежать

Ошибка	Последствие	Как исправить
Описание процесса вместо результата («провести 10 встреч» вместо «согласовать требования со всеми стейкхолдерами»)	Исполнитель сдаёт активность, результат не достигнут	Формулируйте через Deliverables и Outcome. Процесс — в методологии, не в ТЗ
Отсутствие критериев приёмки для промежуточных этапов	Накопление ошибок, переработка в конце, споры при подписании финального акта	Внедрите гейты (Quality Gates) на каждом этапе с чек-листами
Неучтённое предоставление доступов/данных заказчиком	Простой команды, сдвиг дедлайнов, претензии к исполнителю	Раздел «Входные данные» с датами и штрафами/сдвигами за просрочку
Фиксированная цена при неясном объёме (R&D, сложный аудит)	Урезание качества исполнителем или бесконечные доп. соглашения	Выбирайте T&M с капом (лимитом бюджета) или пилотный этап с переоценкой
Игнорирование процедуры изменений	Неконтролируемый рост объёма, конфликты по оплате «мелочей»	Обязательный Change Request для любого отклонения от ТЗ
Передача прав только на «результат», без исходников и ноу-хау	Вендор-локин: нельзя сменить исполнителя, дорого дорабатывать	Требуйте передачу исключительных прав на все артефакты, включая исходный код, макеты, модели, доступы

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

Пройдитесь по пунктам. Если хотя бы один пункт «Нет» — доработайте документ.

• [ ] Чётко сформулирована бизнес-цель и метрика успеха проекта.
• [ ] Перечислены все артефакты поставки с форматами и параметрами.
• [ ] Для каждого артефакта/этапа написаны измеримые критерии приёмки.
• [ ] Есть календарный план с привязкой оплат к приёмкам (Milestones).
• [ ] Описаны входные данные заказчика с дедлайнами предоставления.
• [ ] Составлен список Out of Scope (что точно не входит).
• [ ] Зафиксирована процедура Change Request (кто, как, за сколько оценивает).
• [ ] Прописаны права интеллектуальной собственности и режим НДА.
• [ ] Определён регламент отчётности и коммуникации (в т.ч. доступ к трекеру).
• [ ] Прописаана процедура приёмки: сроки проверки, формат замечаний, deemed acceptance.
• [ ] ТЗ согласовано с юристами по соответствию договору (предмет, цена, сроки совпадают).

Сценарии: как адаптировать ТЗ под тип услуги

Маркетинг и реклама (Performance, SEO, SMM)

Фокус на KPI и доступе к аккаунтам. ТЗ должно содержать: целевые метрики (CPA, ROAS, CTR, позиции), ограничения бренда (Тон оф Войс, брендбук), доступы к рекламным кабинетам/Аналитике/CRM, процедуру согласования креативов (сколько правок входит), отчётность (дашборд в Data Studio / Power BI / Таблицах), условия остановки/масштабирования кампаний.

IT-разработка и внедрение ПО (CRM, ERP, кастомизация)

Фокус на функциональных требованиях и нефункциональных (производительность, безопасность). Используйте User Stories / Use Cases с Definition of Done. Обязательно: стек технологий, требования к коду (Code Style, CI/CD, тестовое покрытие %), среды (dev/stage/prod), миграция данных, интеграции (API, вебхуки), нагрузочное тестирование, документация для админов/пользователей, гарантийная поддержка (срок, SLA, стоимость).

Консалтинг, аудит, стратегия

Фокус на глубине проработки и методологии. ТЗ: методология работы (какие фреймворки используются), состав командной группы заказчика (кто даёт интервью, данные), перечень интервью/воркшопов, структура итогового отчёта, формат презентации для совета директоров, критерий качества — «пригодность для принятия решения инвестиционного комитета», передача рабочих файлов моделей (Excel, Miro, FigJam).

Дизайн, брендинг, UX/UI

Фокус на исходниках и этапах согласования. ТЗ: количество концепций, раундов правок (входит в цену), технические требования (цветовые профили, разрешения, адаптивность), дизайн-система / UI-kit (Figma, токены), передача прав на шрифты/фото/иллюстрации (лицензии), гайдлайн использования, анимации (Lottie/After Effects исходники).

Практический итог: с чего начать завтра утром

Не пытайтесь написать идеальное ТЗ с нуля за час. Действуйте итеративно:

1. Соберите стейкхолдеров на 30-минутный колл: «Какую проблему решаем? Как измерим успех? Что получим на руках?». Зафиксируйте ответы.
2. Заполните шаблон чек-листа выше. Пробелы — это ваши задачи на прояснение до встречи с исполнителем.
3. Подготовьте «Входные данные» и «Out of Scope» — это самые недооценённые разделы, экономящие недели споров.
4. На первой встрече с потенциальным исполнителем обсудите не «сколько стоит», а «понятны ли критерии приёмки и риски». Компетентный подрядчик попросит уточнить ТЗ, некомпетентный — согласится на всё.
5. Включите ТЗ (или его приложение с КРИ) в договор как неотъемлемую часть. Договор без ТЗ — это договор на «оказание услуг», где суду будет нечего сравнивать с фактом исполнения.

Хорошее ТЗ — это не страховка от недобросовестного исполнителя, а инструмент для работы с хорошим. Оно переводит разговор из плоскости «ты не так сделал» в плоскость «здесь критерий не пройден, пункт 4.2, давайте исправим за 3 дня». Именно так выглядит взрослый B2B-менеджмент.

Материал носит информационный характер и не заменяет юридической экспертизы договора и технического задания. Условия передачи прав, ответственность сторон, форс-мажор и порядок расчётов зависят от законодательства (ГК РФ, 223-ФЗ/44-ФЗ при госзакупках), специфики отрасли и баланса интересов сторон. При крупных сделках или нестандартных условиях обязательно привлекайте корпоративного юриста для согласования текста ТЗ и договора до подписания.

FAQ: Частые вопросы при составлении ТЗ

Нужно ли подписывать ТЗ отдельно от договора?

ТЗ может быть приложением к договору (наиболее часто) или отдельным документом, на который ссылается договор. Юридическая сила одинакова, если в договоре есть фраза: «Стороны определяют предмет договора в соответствии с Техническим заданием № Х от ДД.ММ.ГГГГ, являющимся неотъемлемым приложением к настоящему Договору». Подписывать ТЗ отдельно удобно для версионирования: можно согласовать ТЗ v1.1 доп. соглашением, не переподписывая весь договор.

Что делать, если заказчик не может сформулировать чёткие KPI?

Разбейте проект на два этапа (или два договора). Этап 1 — «Исследование / Стратегия / Техническое проектирование» с фиксированной ценой и артефактом: «Утверждённое ТЗ / Дорожная карта / Смету на Этап 2». Этап 2 — исполнение по уже готовому, измеримому ТЗ. Это снижает риски для обеих сторон.

Как оформить правки по дизайну/текстам, чтобы не было бесконечных итераций?

В ТЗ пропишите: «В стоимость входит N раундов правок по каждому артефакту (например, 2 раунда правок макета главной страницы). Дополнительные раунды оплачиваются отдельно по ставке X руб./час или фиксированной сумме за раунд». Определите, что считается правкой (изменение текста — да, смена концепции — нет, это новый артефакт).

Можно ли использовать чужой шаблон ТЗ из интернета?

Можно как базу структуры (разделы 1–8 выше), но содержание (Scope, КРИ, входные данные, SLA) нужно писать под конкретный проект. Чужие КРИ («PageSpeed 90») могут быть нереалистичны для вашего легаси-стека, а чужие Out of Scope — не закрыть ваши риски. Шаблон — это чек-лист разделов, а не готовый текст.

Кто должен писать ТЗ: заказчик или исполнитель?

Ответственность за бизнес-цели и приёмку — у заказчика. Но в сложных проектах (IT, консалтинг) ТЗ пишут совместно: заказчик даёт «Что и Зачем» (Vision, Scope, KPI), исполнитель предлагает «Как» (Архитектура, Стек, Методология, план этапов) и пишет техническую часть. Итоговый документ согласовывают вместе. Если исполнитель пишет ТЗ в одиночку — требуйте раздел «Ограничения и допущения» и тщательно проверяйте КРИ.