Как написать техническое задание: пошаговое руководство с примерами

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

Зачем нужно техническое задание

Техническое задание решает три задачи одновременно:

Фиксирует scope. Без ТЗ граница проекта размыта — каждый участник видит свой объём работ.
Снижает риски. Разработка технического задания до начала кода обходится в 10–100 раз дешевле, чем исправление ошибок на этапе тестирования.
Создаёт контракт. ТЗ — юридическая основа для приёмки: сделано или не сделано проверяется по пунктам.

Проекты с формализованным ТЗ завершаются в срок в 2,5 раза чаще, чем проекты без документации требований (Standish Group, CHAOS Report).

В каких случаях ТЗ обязательно

Не каждый проект требует 50-страничного документа. Вот простая матрица:

Ситуация	ТЗ нужно?	Формат
Внутренняя доработка на 1–2 дня	Нет	Задача в Jira
Новый модуль в существующей системе	Да	Краткое ТЗ (5–10 стр.)
Новый продукт с нуля	Обязательно	Полное ТЗ (20–50 стр.)
Интеграция с внешней системой	Обязательно	ТЗ + API-контракт
Проект с внешним подрядчиком	Обязательно	ТЗ + SLA

Структура технического задания

1. Общие сведения

Раздел, который читают все — от директора до тестировщика.

Название проекта — однозначное, без аббревиатур
Цель проекта — какую бизнес-задачу решаем (не техническую)
Заказчик и исполнитель — ответственные лица с обеих сторон
Глоссарий — определение терминов, которые могут трактоваться двояко

Пример цели:

❌ «Разработать CRM-систему» — это не цель, это задача. ✅ «Сократить время обработки входящей заявки с 4 часов до 25 минут и обеспечить 100% фиксацию обращений» — это бизнес-цель.

2. Описание текущего состояния (as-is)

Без понимания текущего процесса невозможно спроектировать целевой. Раздел включает:

Описание бизнес-процессов — в формате BPMN или текстовом
Участники и роли — кто что делает сейчас
Системы и инструменты — что используется (Excel, 1С, бумага)
Проблемы и боли — конкретные точки, которые нужно устранить

3. Целевое состояние (to-be)

Здесь начинается собственно техническое задание на разработку:

Функциональные требования — что система должна делать
Нефункциональные требования — как система должна работать (скорость, нагрузка, доступность)
Бизнес-правила — логика принятия решений (если сумма > 100 000 ₽ → требуется согласование)
Роли и права доступа — кто что видит и может делать

4. Функциональные требования

Ядро технического задания. Оптимальный формат — User Stories с критериями приёмки:

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

Критерии приёмки:
- Система отображает список заявок за выбранный период
- Фильтрация по статусу, дате, менеджеру
- Время загрузки списка из 1000 записей — не более 2 секунд

Сколько user stories нужно? Зависит от проекта. Для типичного внедрения CRM — 40–80 user stories. Для мобильного приложения — 20–50. Для интеграции — 10–20.

5. Интеграции

Раздел, который чаще всего недооценивают.

Для каждой интеграции фиксируется:

Внешняя система и её версия
Протокол — REST API, SOAP, файловый обмен, очередь сообщений
Направление — кто инициатор, кто получатель
Формат данных — JSON, XML, CSV
Частота обмена — реалтайм, раз в час, раз в сутки
Обработка ошибок — что делать, если внешняя система недоступна

6. Требования к UX/UI

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

Wireframes ключевых экранов (Figma, даже бумажные скетчи)
Навигационная карта — какие экраны существуют и как связаны
Адаптивность — какие устройства поддерживаются
Доступность — нужны ли WCAG-требования

7. Нефункциональные требования

Параметр	Пример требования
Производительность	Время ответа API ≤ 500 мс при 100 RPS
Доступность	99,5% uptime (не более 44 часов простоя в год)
Масштабируемость	Поддержка до 10 000 активных пользователей
Безопасность	Шифрование данных в покое и в транзите, 2FA
Резервное копирование	RPO ≤ 1 час, RTO ≤ 4 часа

8. Ограничения и допущения

Технологический стек — если есть ограничения (только Python, только облако)
Бюджет и сроки — рамки, в которых нужно уложиться
Зависимости — от других проектов, команд, подрядчиков
Допущения — что принимаем как данность (например, «данные из 1С корректны»)

9. План приёмки

Как заказчик будет проверять, что ТЗ выполнено:

Сценарии приёмочного тестирования — конкретные шаги
Критерии готовности — что значит «сделано»
Период опытной эксплуатации — сколько длится и что проверяется

Типичные ошибки при написании ТЗ

Ошибка 1: ТЗ описывает решение, а не проблему

❌ «Добавить кнопку "Экспорт в Excel" на экране заявок»

Это задача для разработчика, а не требование. Правильный подход:

✅ «Менеджер должен иметь возможность выгрузить список заявок за период для отчёта руководству. Формат: табличный, совместимый с MS Excel. Максимальный объём выгрузки — 10 000 строк.»

Ошибка 2: Неизмеримые требования

❌ «Система должна быть быстрой и удобной»

Быстрой — это сколько? Удобной — по каким критериям? Необходимо указывать конкретные метрики.

Ошибка 3: Пропуск негативных сценариев

В каждом ТЗ должны быть ответы на вопросы:

Что если пользователь введёт некорректные данные?
Что если внешний сервис не отвечает?
Что если два пользователя попытаются редактировать одно и то же?

Ошибка 4: ТЗ пишется один раз и навсегда

Техническое задание — живой документ. Версионируйте его, фиксируйте изменения, согласовывайте дополнения. Типичная ТЗ проходит 3–5 итераций до финальной версии.

Ошибка 5: ТЗ без участия будущих пользователей

Аналитик, который пишет ТЗ только с руководителем заказчика и не общается с рядовыми пользователями, рискует создать систему, которой никто не будет пользоваться.

Чеклист: проверьте ваше ТЗ

Перед отправкой ТЗ в работу убедитесь:

Шаблон структуры ТЗ

Используйте этот шаблон как отправную точку:

1. Общие сведения
   1.1. Название проекта
   1.2. Цель и задачи
   1.3. Заказчик и исполнитель
   1.4. Глоссарий
   1.5. Ссылки на связанные документы

2. Описание текущего состояния
   2.1. Бизнес-процессы (as-is)
   2.2. Участники и роли
   2.3. Системы и инструменты
   2.4. Проблемы и узкие места

3. Целевое состояние
   3.1. Бизнес-процессы (to-be)
   3.2. Функциональные требования (User Stories)
   3.3. Бизнес-правила
   3.4. Роли и права доступа

4. Интеграции
   4.1. Перечень внешних систем
   4.2. API-контракты
   4.3. Обработка ошибок

5. UX/UI
   5.1. Wireframes
   5.2. Навигационная карта
   5.3. Требования к адаптивности

6. Нефункциональные требования
   6.1. Производительность
   6.2. Безопасность
   6.3. Доступность и отказоустойчивость

7. Ограничения и допущения

8. План приёмки
   8.1. Сценарии приёмочного тестирования
   8.2. Критерии готовности
   8.3. Период опытной эксплуатации

Приложения

Сколько времени уходит на написание ТЗ

Ориентировочные сроки для бизнес-аналитика:

Масштаб проекта	Объём ТЗ	Срок подготовки
Малый (доработка)	5–10 стр.	3–5 дней
Средний (новый модуль)	15–30 стр.	2–3 недели
Крупный (новый продукт)	30–80 стр.	1–2 месяца
Интеграционный	10–20 стр. + API-контракт	1–2 недели

Эти сроки включают сбор требований, интервью, согласование и 2–3 итерации.

Итог

Техническое задание — не бюрократия, а инструмент управления рисками. Хорошее ТЗ экономит в 10 раз больше времени, чем тратится на его подготовку. Начинайте с бизнес-проблемы, а не с технического решения. Используйте User Stories с критериями приёмки. Не пропускайте негативные сценарии и интеграции.

Если вам нужна помощь с разработкой технического задания для вашего проекта — напишите мне. Работаю с проектами любого масштаба, от аудита требований до полного ТЗ под ключ.