+7 (495) 240-82-92
+7 (495) 240-82-92 Позвоните мне
Главная Блог ТЗ на разработку: структура, требования и чек-лист для бизнеса

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

Менеджмент
2 марта 2026
7 мин чтения

Что должно быть в ТЗ на сайт/сервис/приложение: 12 разделов, чек-лист «минимум за 1 день», типовые ошибки, вопросы подрядчику и шаблон формулировок.

Содержание

Если входные данные размыты, подрядчики оценивают разные проекты — отсюда разные сроки, бюджеты и «включено/не включено». Поэтому ТЗ нужно не «для галочки» и не «чтобы было как в бумагах», а чтобы управлять тремя вещами: объёмом работ (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 часов. Релизы — по согласованным окнам».

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

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

Если у вас «нет времени», сделайте минимум, который позволит начать 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. Контакты ответственных и сроки согласований.

Что приложить к ТЗ (таблица артефактов)

Артефакт Зачем нужен Кто обычно делает Без чего нельзя
Прототипы (wireframes) ускоряют согласование UX и scope заказчик/подрядчик без них сложнее оценка и выше риск переделок
User stories / use cases привязывают функции к реальным сценариям PM/аналитик нужны для корректной приёмки
Список интеграций + данные снижает риск “всплывших” работ заказчик + аналитик критично для CRM/ERP/legacy
Контент-структура (типы страниц/сущностей) помогает в CMS/порталах маркетинг/контент важно для сайтов и порталов
BPMN/схемы процессов (если есть) фиксирует бизнес-логику бизнес-аналитик полезно для внутренних систем
Требования ИБ / политики доступа предотвращает риски и задержки ИБ/IT заказчика нужно, если строгая безопасность
Пример отчётов/дашбордов формирует аналитику и данные бизнес важно, если цель — управлять метриками
Брендбук/дизайн-система снижает время на дизайн маркетинг полезно, если много интерфейсов
Референсы “нравится/не нравится” синхронизирует ожидания заказчик быстро устраняет разночтения

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

Про цели

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

1. Можно ли начать разработку без ТЗ?

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

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

Не важно. Важно, чтобы были: цели, scope, сценарии, интеграции, NFR и приёмка. Иногда это 8 страниц, иногда 40 — зависит от сложности.

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

Часто эффективнее совместно: заказчик даёт цели, контекст, данные и ограничения; подрядчик оформляет требования, прототипы, AC/DoD и риски.

4. Что важнее: прототипы или текст?

Для интерфейсных продуктов прототипы резко снижают риск недопонимания, а текст фиксирует правила и исключения. Лучше связка: прототип + сценарий + AC.

5. Как учесть интеграции в ТЗ?

Опишите список систем, данные, формат обмена, частоту, ответственность за доступы и “истину” данных. Без этого оценка почти всегда будет ошибочной.

6. Как прописать приёмку, чтобы не спорить?

Через acceptance criteria и DoD: что должно работать, на каком окружении, какие тесты пройдены, какие дефекты допустимы/недопустимы.

7. Как обновлять ТЗ в процессе разработки?

Через change requests и бэклог: фиксируйте изменения, пересчитывайте влияние на сроки/стоимость, храните актуальную версию требований в одном месте.

Содержание

Другие статьи

Разработка
24 апреля 2026
2 мин чтения
Какую CRM систему выбрать для бизнеса: пошаговый гид без ошибок
CRM выбирают часто «на эмоциях»: увидели рекламу, услышали от знакомых, взяли «как у конкурента». А потом — саботаж менеджеров, дубли контактов, разваленная воронка и ощущение, что «CRM не работает». На деле не работает подход к выбору и внедрению.
Менеджмент
29 марта 2026
15 мин чтения
Fixed Price vs Time & Materials: что выгоднее для разработки
Сравнение Fixed Price и T&M: таблица различий, дерево выбора, чек-листы контроля, как сравнить КП и какие формулировки закрепить в договоре.
Разработка
10 марта 2026
13 мин чтения
Как выбрать IT-подрядчика на разработку: чек-лист для бизнеса
Практичный чек-лист выбора подрядчика на разработку: критерии, red flags, вопросы на встрече, сравнение Fixed и T&M и чек-лист старта проекта.