Как написать техническое задание (ТЗ): гайд для бизнеса и аналитиков

Что такое ТЗ и зачем оно нужно

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

1. Юридическая — основание для договора. Если результат не соответствует ТЗ — исполнитель переделывает за свой счёт
2. Проектная — источник истины для команды. Разработчики, дизайнеры, тестировщики сверяются с ТЗ
3. Коммуникационная — перевод с языка бизнеса («хочу сайт как у конкурента») на язык разработки («CMS WordPress, интеграция с 1С через REST API»)

Структура ТЗ: что должно быть в документе

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

• Полное наименование системы/продукта
• Заказчик и исполнитель
• Основание для разработки (договор №, решение руководства)
• Плановые сроки

2. Цели и назначение

Зачем создаётся система? Какую проблему решает?

Пример: «Создать интернет-магазин для автоматизации приёма заказов и снижения нагрузки на менеджеров с 50 звонков/день до 10».

3. Объём работ

Что входит, а что — явно не входит в проект.

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

Что система должна делать. Каждая функция описывается по схеме: актор → действие → результат.

Пример для интернет-магазина:

• FR-01: Пользователь может искать товары по названию и категории
• FR-02: Пользователь может добавлять товары в корзину и изменять количество
• FR-03: Пользователь может оформить заказ с доставкой (3 способа) и оплатой (2 способа)
• FR-04: Администратор может добавлять/редактировать/удалять товары
• FR-05: Администратор может просматривать отчёт по заказам за период

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

Качество системы.

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

С какими внешними системами общается новая система, по какому протоколу, в каком формате.

Пример:

• 1С:Предприятие — обмен заказами и остатками через REST API (JSON)
• Платёжный шлюз (Сбер) — приём платежей через API эквайринга
• CDEK (доставка) — расчёт стоимости и трекинг через API

7. Пользовательские сценарии (Use Cases)

Описание ключевых путей пользователя.

Пример: «Покупка товара»

1. Пользователь заходит на главную страницу
2. Вводит «дрель» в поиск
3. Выбирает товар из выдачи → карточка товара
4. Нажимает «В корзину» → товар в корзине
5. Нажимает «Оформить заказ» → форма: контакты, адрес, способ оплаты
6. Заполняет форму → нажимает «Оплатить»
7. Перенаправляется на страницу платёжного шлюза
8. После оплаты → страница «Заказ принят, номер 12345»
9. Получает email с подтверждением

8. Макеты и дизайн

Ссылки на Figma/Sketch + описание основных состояний:

• Нормальное состояние
• Пустое (первый запуск, нет данных)
• Ошибка (404, 500, ошибка валидации)
• Загрузка (спиннер, скелетон)
• Edge cases (очень длинный текст, 0 товаров в корзине)

9. Требования к администрированию

• Роли и права доступа (админ, менеджер, контент-менеджер)
• Как добавлять/удалять пользователей
• Резервное копирование (как часто, где хранить)
• Логирование (какие события, хранение логов 30 дней)

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

Как заказчик поймёт, что работа выполнена?

Пример:

• Пройдены все приёмочные тесты (список тестов — приложение к ТЗ)
• Проведено нагрузочное тестирование (500 одновременных пользователей, без ошибок)
• Проведено регрессионное тестирование перед сдачей
• Развёрнуто на production-сервере, настроен CI/CD
• Передана документация: инструкция администратора, инструкция пользователя

ГОСТ 34 vs Agile: как писать ТЗ под разные подходы

Waterfall / ГОСТ 34: ТЗ = контракт

ТЗ пишется до начала разработки. Фиксируется всё: функции, интерфейсы, интеграции. Изменения — через формальный запрос (Change Request).

Плюсы: предсказуемые бюджет и сроки. Минусы: если в процессе выяснится, что «хотели не то» — переделка стоит дорого.

Когда применять: госпроекты, стройка, fixed-price контракты.

Agile: ТЗ = бэклог + Definition of Ready

«ТЗ» — это не один документ, а:

• User Story Map — общая картина продукта
• Бэклог — приоритезированные user stories
• Definition of Ready — критерии готовности истории к взятию в спринт
• Прототипы (Figma) + Acceptance Criteria

Истории уточняются на grooming'ах перед спринтами. Это позволяет менять приоритеты.

Плюсы: гибкость. Минусы: невозможно зафиксировать бюджет на весь проект.

Когда применять: разработка ПО, стартапы, customer-facing продукты.

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

1. Смесь «что» и «как»

ТЗ должно описывать что должно быть сделано, а не как.

2. Отсутствие границ проекта

ТЗ без раздела «не входит» обречено на scope creep (расползание границ). Каждое новое пожелание: «мы же договаривались» со стороны заказчика, «этого не было в ТЗ» со стороны исполнителя.

3. Расплывчатые формулировки

4. ТЗ без критериев приёмки

Как заказчик поймёт, что работа сделана? «Посмотрю и скажу» — путь к бесконечным правкам.

5. Ошибка выжившего из прошлого проекта

Копирование ТЗ из похожего проекта без адаптации. Бизнес-процессы разные, интеграции разные, контекст разный.

Шаблон ТЗ (лёгкая версия для малого бизнеса)

Для проектов до 500 тыс. руб. достаточно такого чек-листа:

1. Цель проекта (1 абзац)
2. Функции (список: что делает система)
3. Роли пользователей (кто чем пользуется)
4. Интеграции (таблица: система, протокол, формат, контакты)
5. Макеты (ссылка на Figma или эскизы)
6. Что не входит (список)
7. Критерии приёмки (список)
8. Сроки и бюджет (этапы, даты, стоимость)

Связанные статьи: Архитектурные роли в ИТ: кто пишет ТЗ, Справочник аналитика: требования к ПО, Use Cases по Коберну, Scrum vs Kanban vs Waterfall, Как написать понятное руководство