ТЗ на разработку: структура, требования и чек‑лист для бизнеса

Если входные данные размыты, подрядчики оценивают разные проекты — отсюда разные сроки, бюджеты и «включено/не включено». Поэтому ТЗ нужно не «для галочки» и не «чтобы было как в бумагах», а чтобы управлять тремя вещами: объёмом работ (scope), качеством (критерии приёмки) и изменениями (change requests). Хорошее ТЗ позволяет сравнить КП, снизить риски по срокам и бюджету и заранее договориться, что будет считаться «сделано».

В ТЗ на разработку (сайт/сервис/мобильное приложение) минимум должны быть:

1. Цель проекта и критерии успеха (KPI/метрики).
2. Сценарии пользователей (use cases/user stories).
3. Scope: что делаем и что не делаем.
4. Функциональные требования по модулям.
5. Нефункциональные требования: скорость, безопасность, доступность, масштабирование.
6. Интеграции и данные: источники, API, форматы, права доступа.
7. UX/UI: прототипы/референсы, адаптивность, контент‑структура.
8. Приёмка и качество: acceptance criteria, Definition of Done (DoD), тестирование.
9. Релизы и поддержка: окружения, гарантия/сопровождение, SLA (если требуется).

Что считается ТЗ в 2026: ТЗ vs спецификация vs бэклог

Классическое ТЗ «ГОСТ‑стиля» уместно, когда:

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

Спецификация/PRD (product requirements document) уместна, когда:

• продукт развивается;
• важны метрики, гипотезы, варианты решений;
• требуется связать бизнес‑цели с функционалом.

Agile‑бэклог + прототипы + acceptance criteria уместна, когда:

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

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

Структура ТЗ: 12 обязательных разделов

Ниже — универсальная структура ТЗ. Для каждого раздела: что включить, пример формулировки, типичная ошибка.

1) Цели проекта и KPI/метрики успеха

Что включить:

• бизнес‑цель (зачем проект);
• ключевые метрики (конверсия, заявки, LTV, скорость обработки, NPS и т.п.);
• ожидаемые эффекты и приоритеты (must‑have / nice‑to‑have).

Пример:

«Цель: сократить время обработки заявки с 2 дней до 4 часов. Метрики: доля заявок, обработанных <4 часов, ≥ 70% через 2 месяца после запуска».

Ошибка: «Сделать современный сайт/приложение» без измеримого результата.

2) Контекст и ограничения (сроки, бюджетные рамки, регуляторика)

Что включить:

• дедлайны/вехи (релизы, маркетинговые окна);
• бюджетный коридор (если есть);
• ограничения: инфраструктура, политика ИБ, требования бренда, юридические нормы.

Пример:

«Релиз MVP не позднее 15 июня. Размещение — в облаке заказчика. Требования ИБ: доступ по VPN, секреты через vault».

Ошибка: не указать «жёсткие» ограничения и выяснить их после начала работ.

3) Целевая аудитория и сценарии (use cases / user stories)

Что включить:

• сегменты пользователей и роли;
• ключевые сценарии (что человек делает «от входа до результата»);
• боли/мотивы, ограничения, частота действий.

Пример:

«Роль: менеджер продаж. Сценарий: открыть карточку клиента → увидеть историю касаний → создать задачу → назначить звонок → зафиксировать результат».

Ошибка: описывать «экраны», не описывая, зачем они и какой путь пользователя.

4) Объём работ (scope) + что НЕ входит

Что включить:

• список модулей/страниц/функций;
• границы: что явно исключено;
• зависимости: что предоставит заказчик (контент, доступы, данные).

Пример:

«Входит: личный кабинет клиента, заявки, уведомления, интеграция с CRM. Не входит: разработка CRM, закупка лицензий, наполнение контентом > 50 страниц».

Ошибка: отсутствие списка «не входит» → конфликт на каждом изменении.

5) Функциональные требования (по модулям)

Что включить:

• требования по каждому модулю: действия, правила, состояния;
• бизнес‑логика: проверки, статусы, ограничения;
• роли и разрешения (кто что может).

Пример:

«Модуль „Заявки“: создание, редактирование, назначение ответственного, статусы (Новая/В работе/Закрыта), история изменений, фильтры по статусу и дате».

Ошибка: «Сделать заявки» без статусов, ролей, правил и исключений.

6) Нефункциональные требования (скорость, доступность, безопасность)

Что включить:

• производительность (время ответа, нагрузка);
• доступность (uptime), отказоустойчивость;
• безопасность (аутентификация, шифрование, хранение логов);
• требования к масштабированию.

Пример:

«95‑й перцентиль ответа API ≤ 500 мс при 200 RPS. Доступность сервиса ≥ 99,5% в месяц. Пароли/ключи — не хранить в репозитории».

Ошибка: игнорировать NFR и потом «догонять» производительность и ИБ дорого и долго.

7) Интеграции и данные (API, источники, форматы, доступы)

Что включить:

• список интеграций (CRM/ERP/1С, платежи, телефония, почта);
• источники данных и «истина» (system of record);
• форматы/протоколы (REST, webhooks), частота синхронизации;
• ответственность за доступы и тестовые данные.

Пример:

«Интеграция с CRM: передача лида (имя, телефон, источник) по REST API. Ошибки доставки — в очередь повторов, логирование обязательно».

Ошибка: «Интеграция с 1С» без описания данных, форматов и ответственности за доступы.

8) UX/UI требования (прототипы, дизайн‑система, адаптив, контент)

Что включить:

• прототипы (или требования к ним);
• адаптивность, доступность (если критично);
• контент‑структура: типы страниц, сущности, поля;
• референсы «как нравится» и «как не нравится».

Пример:

«Адаптив: desktop/tablet/mobile. Формы — с валидацией и понятными ошибками. Для карточки товара — обязательные поля: фото, цена, наличие».

Ошибка: ожидать «сами придумают UX» без прототипов/сценариев.

9) Роли, доступы и безопасность (RBAC, логи, секреты)

Что включить:

• роли пользователей и права (RBAC);
• требования к аудиту действий (логи, журналирование);
• политика доступа к окружениям, хранение секретов, NDA.

Пример:

«Роли: админ/менеджер/клиент. Все изменения статусов — в журнале: кто, когда, что поменял. Доступ к prod — только через approvals».

Ошибка: выдавать «всем всё» и потом исправлять безопасность в пожарном режиме.

10) Аналитика и события (что трекаем, какие отчёты)

Что включить:

• какие события и параметры фиксируем (event taxonomy);
• какие отчёты нужны бизнесу (воронка, конверсия, SLA обработки);
• требования к логированию ошибок.

Пример:

«События: registration_started/completed, form_submit_success, payment_success, lead_sent_to_crm. Отчёт: конверсия по источникам и этапам».

Ошибка: «поставим аналитику потом» → потом вы не знаете, что работает.

11) Приёмка и качество (acceptance criteria, DoD, тестирование)

Что включить:

• критерии приёмки по функциям (acceptance criteria);
• Definition of Done (код‑ревью, тесты, документация, демо);
• виды тестирования: smoke/regression, нагрузочное (если нужно).

Пример:

«Функция считается готовой, если: выполнены AC, пройдено code review, обновлена документация, пройдены тесты, показано на demo‑стенде».

Ошибка: «примем, когда понравится» → спор о качестве неизбежен.

12) Поддержка и развитие (гарантия, SLA, релизный процесс)

Что включить:

• гарантийный период и что в него входит;
• поддержка по SLA (приоритеты инцидентов, время реакции/решения);
• релизный процесс: окружения, окна релизов, откаты.

Пример:

«После запуска: гарантия 30 дней на дефекты. Поддержка: P1 реакция до 1 часа, P2 до 4 часов. Релизы — по согласованным окнам».

Ошибка: не определить, что происходит «после релиза», и получить простой без ответственных.

Кейс, как благодаря правильному ТЗ был разработан сайт для привлечения туристов на Урал

Минимальное ТЗ за 1 день

Если у вас «нет времени», сделайте минимум, который позволит начать Discovery и сравнить КП:

1. Описание бизнеса и задачи в 5–10 предложениях.
2. Цель проекта + 2–3 метрики успеха.
3. Роли пользователей (3–6 ролей).
4. 5–8 ключевых сценариев «от входа до результата».
5. Список must‑have функций (10–25 пунктов).
6. Список «не входит» (минимум 5 пунктов).
7. Интеграции: список систем + что передаём (данные).
8. Нефункциональные требования: скорость/безопасность/доступность (хотя бы ориентиры).
9. Прототипы или референсы (2–5 примеров).
10. Критерии приёмки для 3–5 ключевых функций.
11. Окружения/инфраструктура: где будет жить продукт.
12. Контакты ответственных и сроки согласований.

Типовые ошибки в ТЗ

Про цели

1. Нет измеримых метрик успеха.

2. Смешали цели бизнеса и список «хотелок» без приоритетов.

Про требования

3. Требования описаны «на уровне экрана», но без сценариев и правил.

4. Нет списка «не входит» — scope расползается.

5. Не описаны роли и права — потом ломается безопасность и логика.

Про приёмку

6. Нет acceptance criteria и Definition of Done.

7. Приёмка «по ощущениям», без тестового контура.

Про интеграции и данные

8. Интеграции указаны одним словом (“интеграция с CRM/1С“), без данных, форматов и доступа.

9. Не определён источник истины для данных и правила синхронизации.

Про поддержку и релизы

10. «После релиза разберёмся» — нет гарантий/поддержки/SLA.

11. Нет требований к окружениям, релизам, откатам.

Вопросы, которые подрядчик должен задать

1. Какая бизнес‑цель проекта и как измеряем успех?
2. Кто пользователи и какие у них ключевые сценарии?
3. Что обязательно входит в MVP, а что можно отложить?
4. Что точно не входит в проект?
5. Какие интеграции и какие данные в них участвуют? Кто даёт доступы?
6. Какие нефункциональные требования важнее всего (скорость/безопасность/доступность)?
7. Какие роли и права доступа нужны в системе?
8. Где будет инфраструктура и кто отвечает за окружения?
9. Как будет устроена приёмка: критерии, демо, тестирование?
10. Как управляем изменениями требований (CR) и кто согласует?
11. Что будет после релиза: гарантия, поддержка, SLA?
12. Какие риски подрядчик видит заранее и как предлагает их снять?
13. Как будет выглядеть отчётность и частота коммуникации?
14. Кто со стороны заказчика PO/PM и как быстро он может принимать решения?

Готовые формулировки (копипаст) для ТЗ/договора

1) Scope и “не входит”

«В состав работ входит: … (перечень модулей). Не входит: … (перечень исключений). Всё, что не перечислено в разделе “Входит”, считается изменением и оформляется Change Request.»

2) Acceptance criteria (критерии приёмки)

«Функциональность считается принятой, если выполнены критерии: (а) …; (б) …; (в) …; результат продемонстрирован на согласованном окружении.»

3) Definition of Done (DoD)

«Задача считается выполненной при соблюдении DoD: code review, прохождение тестов/чек‑листа, отсутствие критических дефектов, обновление документации, демонстрация результата.»

4) Нефункциональные требования (производительность/доступность)

«Целевые показатели: 95‑й перцентиль ответа API ≤ X мс, доступность сервиса ≥ Y% в месяц, обязательное логирование ошибок и мониторинг ключевых метрик.»

5) Change Request

«Изменения требований оформляются Change Request с оценкой влияния на сроки/стоимость и планом внедрения. Работы выполняются после письменного согласования Заказчиком.»

6) Права на код и доступы

«Репозиторий размещается в аккаунте Заказчика либо Заказчику предоставляется полный административный доступ. Права на результаты работ переходят к Заказчику с момента оплаты соответствующего этапа/периода.»

Итог

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

Если вы планируете разработку сайта/сервиса/приложения, логично начать с брифа и короткого Discovery: так оценка сроков и бюджета будет не “на глаз”, а опирающейся на требования, сценарии и риски.

FAQ