ТЗ в Agile

Классическое техническое задание и Agile-разработка часто воспринимаются как несовместимые подходы. Первое фиксирует требования заранее, второе — предполагает их изменение в процессе. Но на практике они могут работать вместе.

В 2026 году всё больше команд используют гибридный подход: описывают общую концепцию и архитектуру в ТЗ, а детальные требования — в виде User Stories и acceptance criteria. В этой статье — как совместить ТЗ и Agile, какие инструменты использовать. Если нужна разработка ТЗ — поможем.

Конфликт ТЗ и Agile

На первый взгляд ТЗ и Agile противоречат друг другу.

Аспект	Классическое ТЗ	Agile
Требования	Фиксируются заранее	Меняются в процессе
Документация	Подробная, полная	Минимальная, по необходимости
Изменения	Через допсоглашение	Приветствуются
Планирование	Долгосрочное	Итеративное
Результат	По ТЗ	По ценности для бизнеса

Проблемы жёсткого ТЗ в Agile

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

Проблемы отсутствия ТЗ в Agile

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

Гибридный подход

Оптимальное решение — комбинация: ТЗ для концепции, Agile для реализации.

Что фиксируется в ТЗ

Цели проекта — зачем создаётся продукт;
Пользователи — кто будет использовать;
Архитектура — общая структура системы;
Интеграции — с чем связывать;
Ограничения — технические и бизнес-ограничения.

Что описывается в User Stories

Детальные требования — что именно должно работать;
Сценарии — как пользователь взаимодействует;
Критерии приёмки — когда задача считается выполненной.

💡 Важно

Такой подход даёт лучшее из двух миров: стабильную концепцию и гибкую реализацию. ТЗ задаёт рамки, User Stories позволяют маневрировать.

User Stories

User Story (пользовательская история) — это краткое описание требования с точки зрения пользователя.

Формат

Классический формат:

«Как [роль], я хочу [действие], чтобы [цель]».

Примеры

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

Правила

Независимость — истории не зависят друг от друга;
Переговорность — детали обсуждаются;
Ценность — каждая история даёт ценность;
Оцениваемость — можно оценить сложность;
Компактность — история помещается на стикер.

Acceptance Criteria

Acceptance Criteria (критерии приёмки) — условия, при которых User Story считается выполненной.

Формат

Формулируются как чек-лист. Пример для истории «добавить товар в корзину»:

Given — пользователь на странице товара;
When — он нажимает кнопку «В корзину»;
Then — товар добавляется в корзину, счётчик увеличивается, появляется уведомление.

Что должно быть

Измеримость — можно проверить;
Однозначность — нельзя понять по-разному;
Полнота — все сценарии учтены;
Независимость — не зависят от других историй.

Примеры

История	Критерий приёмки
Добавить товар в корзину	Товар появляется в корзине, счётчик увеличивается
Оформить заказ	Заказ создаётся, приходит подтверждение на email
Войти в личный кабинет	Пользователь входит, видит свои данные

Product Backlog

Product Backlog — это упорядоченный список всех требований к продукту, выраженных в User Stories.

Структура

Epics — крупные блоки функционала;
Features — функциональные возможности;
User Stories — конкретные требования;
Tasks — задачи для реализации.

Приоритизация

По ценности — что даёт бизнесу больше;
По рискам — что может сломаться;
По зависимостям — что нужно сделать первым;
По сложности — что легко реализовать.

Груминг

Регулярная встреча команды для:

Уточнения — детали историй;
Разбивки — крупные истории на мелкие;
Оценки — сложность реализации;
Переприоритизации — что-то становится важнее.

Epics и Features

Крупные требования разбиваются на Epics и Features.

Уровень	Описание	Пример
Epic	Крупный блок функционала	Управление заказами
Feature	Функциональная возможность	Оформление заказа
User Story	Конкретное требование	Добавить товар в корзину
Task	Задача реализации	Создать таблицу cart_items

Пример разбивки

Epic: Управление заказами;
Feature 1: Оформление заказа;
User Story 1.1: Добавить товар в корзину;
User Story 1.2: Указать адрес доставки;
User Story 1.3: Выбрать способ оплаты;
Feature 2: Отслеживание заказа;
User Story 2.1: Видеть статус заказа;
User Story 2.2: Получать уведомления о статусе.

Инструменты

Инструмент	Для чего	Особенности
Jira	Управление бэклогом	Epics, Stories, Tasks, спринты
YouTrack	Управление задачами	Российский, гибкий
Confluence	Документация	Хранение ТЗ, спецификаций
Kaiten	Канбан и Scrum	Российский, удобный
Trello	Простой канбан	Для небольших команд
Miro	Схемы и карты	Для проектирования

Как связать с ТЗ

ТЗ в Confluence — общее описание проекта;
Epics в Jira — крупные блоки;
User Stories в Jira — детальные требования;
Acceptance Criteria — в описании Story;
Спринты — итерации разработки.

Пример

Разберём на примере интернет-магазина.

Что в ТЗ

Цель — создать интернет-магазин для продажи одежды;
Пользователи — покупатели, менеджеры, администраторы;
Архитектура — Laravel + Vue, PostgreSQL, Redis;
Интеграции — 1С, ЮKassa, СДЭК, Яндекс.Метрика;
Ограничения — бюджет, сроки, команда.

Что в User Stories

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

Что в Acceptance Criteria

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

Чек-лист

В ТЗ

Цели проекта
Пользователи
Архитектура
Интеграции
Ограничения

В User Stories

Формат «Как... хочу... чтобы...»
Независимость
Ценность
Оцениваемость
Компактность

В Acceptance Criteria

Измеримость
Однозначность
Полнота
Формат Given-When-Then
Проверяемость

Инструменты

Jira или YouTrack
Confluence для ТЗ
Miro для схем
Регулярный груминг
Спринты по 1-2 недели

Наши рекомендации

1. Разделите уровни

ТЗ для концепции, Stories для деталей. Разработка ТЗ.

2. Используйте Stories

Формат «Как... хочу... чтобы...». Структура.

3. Пишите критерии

Acceptance criteria для каждой Story. Консультация.

Что вы получаете, заказывая разработку ТЗ у нас

ТЗ для концепции — цели, архитектура, интеграции;
User Stories — детальные требования;
Acceptance Criteria — критерии приёмки;
Product Backlog — упорядоченный список;
Epics и Features — структура требований;
Инструменты — Jira, Confluence, Miro.

📌 Итоговый вывод

ТЗ в Agile в 2026 году — это не противоречие, а комбинация.

Что нужно знать:

Конфликт — ТЗ фиксирует требования, Agile предполагает изменения;
Гибридный подход — ТЗ для концепции, User Stories для деталей;
User Stories — формат «Как [роль], я хочу [действие], чтобы [цель]»;
Acceptance Criteria — условия, при которых Story выполнена;
Product Backlog — упорядоченный список требований;
Epics и Features — уровни декомпозиции требований;
Инструменты — Jira, YouTrack, Confluence, Kaiten, Miro;
Регулярный груминг — уточнение и оценка требований.

Нужно ТЗ для Agile-проекта?

Оставьте заявку — разработаем гибридное ТЗ: концепция и архитектура в документе, детальные требования в User Stories. Совместим ТЗ и Agile.

Имя *

Телефон *

Что интересует

Тип проекта *

Формат требований *

ТЗ + User Stories

Только User Stories

Только ТЗ

Не знаю

Комментарий

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

Почему заказывают разработку ТЗ у нас

8 причин доверить разработку ТЗ нашей команде

Чёткое ТЗ

Опишем функционал, архитектуру, интеграции, сроки и критерии приёмки. Документ, по которому можно работать с любым подрядчиком.

Анализ требований

Проводим интервью с заказчиком, изучаем бизнес-процессы, выявляем скрытые требования.

Проектирование архитектуры

Описываем структуру системы, модули, базы данных, API. Продумываем масштабируемость.

Интеграции

Описываем все внешние интеграции: 1С, CRM, платёжные системы, телефония, маркетплейсы.

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

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

Сроки и этапы

Разбиваем проект на этапы, оцениваем сроки, определяем приоритеты.

Оценка бюджета

На основе ТЗ можно точно рассчитать бюджет и сравнить предложения подрядчиков.

Гарантия результата

Официальный договор, передача документации, поддержка при вопросах.

Что мы разрабатываем

40+ направлений разработки ТЗ — от простых сайтов до комплексных систем

ТЗ на сайт

Техническое задание для разработки сайта.

Структура
Функционал
Дизайн

Подробнее →

ТЗ на интернет-магазин

ТЗ для e-commerce проекта.

Каталог
Корзина
Оплата

Подробнее →

ТЗ на веб-приложение

ТЗ для SaaS и веб-сервисов.

Модули
API
БД

Подробнее →

ТЗ на мобильное приложение

ТЗ для iOS и Android приложений.

Экраны
Функции
Публикация

Подробнее →

ТЗ на CRM

ТЗ для CRM-системы.

Модули
Интеграции
Роли

Подробнее →

ТЗ на интеграцию

ТЗ для интеграции систем.

API
Обмен данными
Синхронизация

Подробнее →

ТЗ на чат-бот

ТЗ для Telegram, VK, WhatsApp ботов.

Сценарии
Интеграции
База знаний

Подробнее →

ТЗ на AI-решение

ТЗ для AI и ML проектов.

Данные
Модели
API

Подробнее →

ТЗ на облачное решение

ТЗ для миграции в облако.

Архитектура
Миграция
Безопасность

Подробнее →

ТЗ на безопасность

ТЗ для системы безопасности.

Аудит
Защита
Мониторинг

Подробнее →

ТЗ по ГОСТ 34.602-2020

ТЗ по государственному стандарту.

Структура
Разделы
Оформление

Подробнее →

ТЗ в свободном формате

ТЗ без строгой структуры ГОСТ.

Гибкость
Agile
User Stories

Подробнее →

Интервью с заказчиком

Выявление требований через интервью.

Вопросы
Анализ
Документация

Подробнее →

Анализ бизнес-процессов

Изучение текущих процессов.

As-Is
To-Be
Оптимизация

Подробнее →

Проектирование архитектуры

Описание структуры системы.

Модули
Связи
Масштабируемость

Подробнее →

Описание интеграций

Все внешние связи системы.

API
Форматы
Синхронизация

Подробнее →

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

Измеримые условия приёмки.

Функциональные
Производительность
Безопасность

Подробнее →

Оценка сроков

Разбивка проекта на этапы.

Этапы
Вехи
Дедлайны

Подробнее →

Оценка бюджета

Расчёт стоимости по ТЗ.

Смета
Ресурсы
Резерв

Подробнее →

Согласование ТЗ

Правки и утверждение документа.

Правки
Версии
Утверждение

Подробнее →

Доработка существующего ТЗ

Обновление и актуализация ТЗ.

Анализ
Правки
Актуализация

Подробнее →

Миграция ТЗ

Перенос ТЗ в другой формат.

Word
PDF
Confluence

Подробнее →

Обучение по ТЗ

Обучение команды работе с ТЗ.

Вебинары
Документация
Практика

Подробнее →

Консультации по ТЗ

Ответы на вопросы по ТЗ.

Вопросы
Разъяснения
Рекомендации

Подробнее →

Управление требованиями

Ведение требований в трекере.

Backlog
User Stories
Acceptance Criteria

Подробнее →

ТЗ для медицины

ТЗ для медицинских систем.

МИС
Пациенты
152-ФЗ

Подробнее →

ТЗ для финансов

ТЗ для банков и страховых.

Транзакции
Безопасность
Аудит

Подробнее →

ТЗ для логистики

ТЗ для логистических систем.

Подробнее →

ТЗ для образования

ТЗ для LMS и образовательных платформ.

LMS
Курсы
Тесты

Подробнее →

ТЗ для производства

ТЗ для АСУ ТП и MES.

SCADA
Датчики
Оборудование

Подробнее →

ТЗ для ритейла

ТЗ для розничных сетей.

POS
Кассы
Лояльность

Подробнее →

ТЗ для медиа

ТЗ для стриминга и медиа.

Видео
CDN
Трафик

Подробнее →

Этапы разработки ТЗ

Прозрачный процесс от интервью до согласования

Интервью

Проводим встречи с заказчиком, выявляем требования, изучаем бизнес-процессы.

Анализ

Изучаем текущую систему, конкурентов, технические ограничения.

Проектирование

Разрабатываем архитектуру, структуру модулей, схему БД.

Описание функционала

Описываем, что система должна делать, какие функции включены.

Интеграции

Описываем внешние интеграции: 1С, CRM, платёжки, телефония.

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

Формулируем измеримые критерии для проверки результата.

Согласование

Обсуждаем ТЗ с заказчиком, вносим правки.

Передача

Передаём финальный документ в Word, PDF или Confluence.

Стоимость разработки ТЗ

Выберите подходящий вариант или закажите индивидуальное решение

Базовое ТЗ

от 15 000 ₽

Для небольших проектов

Анализ требований
Описание функционала
Критерии приёмки
Срок: 2-3 дня

Заказать

ХИТ

Стандартное ТЗ

от 40 000 ₽

Для средних проектов

Интервью с заказчиком
Архитектура системы
Интеграции
Критерии приёмки
Срок: 5-7 дней

Заказать

ТЗ по ГОСТ

от 100 000 ₽

Для госсектора и крупных проектов

Полный анализ
Структура по ГОСТ 34.602-2020
Все обязательные разделы
Согласование
Срок: 3-4 недели

Заказать

* Цены ориентировочные. Точная стоимость — после обсуждения проекта.

Разработка ТЗ в цифрах

Ключевые показатели разработки ТЗ в 2026 году

от 15 000 ₽

стартовая цена

Базовое ТЗ для небольших проектов. Стандартное ТЗ — от 40 000 ₽. По ГОСТ — от 100 000 ₽.

2-3 дня

срок базового ТЗ

Стандартное ТЗ — 5-7 дней. Сложное ТЗ — 2-3 недели. ТЗ по ГОСТ — 3-4 недели.

12+

разделов в ТЗ

Цели, функционал, архитектура, интеграции, критерии приёмки, сроки и другие.

200+

разработанных ТЗ

Разрабатываем ТЗ для проектов из разных отраслей: e-commerce, SaaS, медицина, логистика.

Наши проекты

Примеры разработки ТЗ

ТЗ для интернет-магазина

Разработали ТЗ на интернет-магазин с интеграцией 1С, платёжными системами и маркетплейсами. 45 страниц, 12 интеграций.

E-commerce Интеграции

ТЗ для CRM-системы

ТЗ на кастомную CRM для логистической компании: 8 модулей, интеграция с 1С, GPS, банками. По ГОСТ 34.602-2020.

CRM ГОСТ

ТЗ для мобильного приложения

ТЗ на Flutter-приложение для доставки: личный кабинет, карта, оплата, push-уведомления. 30 страниц.

Мобильные Flutter

Смотреть все проекты

Часто задаваемые вопросы о разработке ТЗ

25+ ответов на популярные вопросы о технических заданиях

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

Без ТЗ проект превращается в бесконечные правки: заказчик ожидает одно, исполнитель делает другое. С ТЗ обе стороны понимают, что и в какие сроки будет сделано.

ТЗ решает несколько задач:

Фиксация требований — что именно нужно сделать;
Оценка бюджета — можно точно рассчитать стоимость;
Сравнение подрядчиков — все оценивают одно и то же;
Контроль результата — есть критерии приёмки;
Защита от споров — документ фиксирует договорённости.

Разработка ТЗ включает:

Интервью с заказчиком — выявление требований;
Анализ бизнес-процессов — как работает система сейчас;
Проектирование — архитектура, модули, БД;
Описание функционала — что система должна делать;
Описание интеграций — с чем связывать;
Критерии приёмки — как проверить результат;
Сроки и этапы — план работ.

Стоимость зависит от сложности проекта:

Простое ТЗ (лендинг, небольшая доработка) — от 15 000 ₽;
Среднее ТЗ (корпоративный сайт, веб-приложение) — от 40 000 ₽;
Сложное ТЗ (CRM, интеграции, мобильное приложение) — от 80 000 ₽;
ТЗ по ГОСТ 34.602-2020 — от 100 000 ₽.

Точная стоимость — после обсуждения проекта.

Сроки зависят от сложности:

Простое ТЗ — 2-3 дня;
Среднее ТЗ — 5-7 дней;
Сложное ТЗ — 2-3 недели;
ТЗ по ГОСТ — 3-4 недели.

ГОСТ 34.602-2020 — государственный стандарт, который определяет структуру и содержание технического задания на создание автоматизированных систем. Используется для проектов в госсекторе и крупных корпорациях.

Структура ТЗ по ГОСТ включает:

Общие сведения — наименование, заказчик, исполнитель;
Назначение и цели — зачем создаётся система;
Характеристика объекта — что автоматизируется;
Требования к системе — функционал, надёжность, безопасность;
Состав и содержание работ — этапы;
Порядок контроля и приёмки — критерии.

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

Свободный формат удобнее для Agile-проектов, где требования могут меняться в процессе. ГОСТ подходит для проектов с фиксированными требованиями и строгой отчётностью.

В разработке участвуют:

Заказчик — владелец продукта, который знает бизнес-требования;
Бизнес-аналитик — выявляет и формализует требования;
Технический архитектор — проектирует систему;
Разработчик — оценивает реализуемость;
Тестировщик — формулирует критерии приёмки.

Критерии приёмки — это измеримые условия, при выполнении которых результат считается принятым. Например:

Функциональные — «пользователь может оформить заказ за 3 шага»;
Производительность — «страница загружается за 2 секунды»;
Безопасность — «данные передаются по HTTPS»;
Совместимость — «работает в Chrome, Firefox, Safari».

Без критериев приёмки невозможно объективно проверить результат.

Да. ТЗ — основа для тендера. Все подрядчики оценивают один и тот же объём работ, что позволяет сравнить предложения объективно.

Для тендера ТЗ должно быть:

Полным — все требования описаны;
Однозначным — нет двусмысленных формулировок;
Измеримым — критерии приёмки проверяемы.

Требования могут меняться. Варианты:

Дополнительное соглашение — изменения фиксируются отдельно;
Гибкое ТЗ — для Agile-проектов требования описаны в виде User Stories;
Резерв — в ТЗ закладывается запас на изменения.

Чек-лист проверки ТЗ:

Полнота — все требования описаны;
Однозначность — нет двусмысленных формулировок;
Реализуемость — технически возможно;
Измеримость — критерии приёмки проверяемы;
Согласованность — нет противоречий между разделами.

Да, даже для небольшого проекта ТЗ полезно. Оно может быть кратким (2-3 страницы), но должно включать:

Цель — зачем делается проект;
Функционал — что должно быть;
Критерии приёмки — как проверить результат.

Это защитит от недопонимания и споров.

ТЗ оформляется в виде документа:

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

Формат — Word, PDF или Confluence. Важно, чтобы документ был версионирован.

User Story — это описание требования с точки зрения пользователя. Формат: «Как [роль], я хочу [действие], чтобы [цель]».

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

User Stories используются в Agile-проектах вместо традиционного ТЗ.

Acceptance criteria (критерии приёмки) — условия, при которых User Story считается выполненной. Формулируются как чек-лист.

Пример для «добавить товар в корзину»:

Кнопка «В корзину» есть на странице товара;
При нажатии товар добавляется в корзину;
Счётчик корзины увеличивается;
Появляется уведомление об успехе.

Прототип и ТЗ дополняют друг друга:

Прототип — визуальное представление, как будет выглядеть;
ТЗ — описание, как будет работать.

Оптимально: сначала прототип для согласования UX, потом ТЗ для описания функционала.

ТЗ — это документ, на который можно ссылаться:

Напомнить о договоре — ТЗ часть договора;
Зафиксировать отклонения — что не соответствует;
Потребовать исправлений — в рамках ТЗ;
Обратиться в суд — если подрядчик отказывается.

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

Это одно из главных преимуществ ТЗ: вы не привязаны к одному исполнителю.

Стоимость оценивается по:

Объёму работ — сколько модулей, страниц, интеграций;
Сложности — какие технологии, есть ли нестандартные задачи;
Срокам — срочность влияет на цену;
Рискам — закладывается резерв.

В разработку ТЗ входит:

Интервью — 2-3 встречи с заказчиком;
Анализ — изучение бизнес-процессов;
Проектирование — архитектура, модули;
Документ — ТЗ в согласованном формате;
Согласование — правки до утверждения;
Передача — документ в Word, PDF.

Да, бизнес-аналитик — ключевой участник. Он:

Выявляет требования — задаёт правильные вопросы;
Формализует — превращает «хотелки» в требования;
Документирует — пишет ТЗ;
Согласовывает — работает с заказчиком и командой.

Чек-лист полноты ТЗ:

Цели — зачем создаётся продукт;
Пользователи — кто будет использовать;
Функционал — что система должна делать;
Интерфейсы — как выглядит;
Интеграции — с чем связывать;
Данные — что хранить;
Безопасность — требования к защите;
Производительность — нагрузка, скорость;
Критерии приёмки — как проверять.

Scope creep — расширение объёма работ без соответствующего увеличения бюджета и сроков. ТЗ помогает избежать:

Фиксирует объём — что входит, что нет;
Процедура изменений — как добавлять новые требования;
Критерии приёмки — что считается выполненным.

Да, ТЗ — основа для оценки. По нему можно:

Рассчитать бюджет — сколько будет стоить;
Оценить сроки — сколько времени займёт;
Сравнить подрядчиков — все оценивают одно и то же.

Процесс:

Оставьте заявку на бесплатную консультацию;
Обсудим проект, задачи, цели;
Предложим формат ТЗ и сроки;
Подпишем договор и начнём работу.

Разрабатываем ТЗ для проектов из разных отраслей: e-commerce, SaaS, медицина, финансы, логистика, образование, производство. Адаптируем подход под специфику вашего бизнеса.