Что включает техническое задание?

Что включает техническое задание (ТЗ)

Техническое задание (ТЗ) — это основополагающий документ в управлении IT-проектами, который служит юридическим и техническим соглашением между заказчиком и исполнителем. Он детально описывает, что должно быть сделано, в какие сроки, с каким качеством и в рамках какого бюджета. В моей практике хорошо структурированное ТЗ — это 50% успеха проекта, так как оно минимизирует недопонимание, служит критерием приемки и основой для планирования.

Ключевые разделы технического задания

Полноценное ТЗ для IT-проекта (например, разработки веб-приложения) обычно включает следующие разделы:

1. Общие положения (Введение)

• Название проекта и его краткое описание.
• Цели и задачи проекта. Четкое формулирование бизнес-целей (например, "увеличить конверсию на сайте на 15%") и конкретных задач для их достижения.
• Глоссарий. Определение ключевых терминов и аббревиатур, используемых в документе.
• Нормативные ссылки. Стандарты, законодательные акты или другие документы, которым должен соответствовать продукт.

2. Описание предметной области и бизнес-требований

Здесь описывается контекст без привязки к технической реализации.

• Анализ целевой аудитории и пользователей.
• Бизнес-процессы, которые система должна автоматизировать или улучшить.
• Общее описание системы: ее роль в инфраструктуре заказчика, основные потоки данных.

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

Сердце ТЗ. Подробное описание того, что система должна делать. Часто структурируется по модулям или пользовательским ролям (например, Администратор, Пользователь, Менеджер).

### Пример функционального требования для модуля "Личный кабинет пользователя"
*   **FR-UC-01: Регистрация нового пользователя.**
    *   **Предусловие:** Пользователь не авторизован в системе.
    *   **Основной поток:**
        1.  Пользователь переходит на страницу регистрации.
        2.  Система отображает форму с полями: Email, Пароль, Подтверждение пароля.
        3.  Пользователь заполняет поля и нажимает "Зарегистрироваться".
        4.  Система проверяет уникальность email и совпадение паролей.
        5.  При успешной проверке система создает учетную запись, отправляет письмо для подтверждения email и авторизует пользователя.
    *   **Постусловие:** Создана новая неподтвержденная учетная запись. Пользователь авторизован и перенаправлен в личный кабинет.
    *   **Альтернативные потоки:**
        *   A1: Email уже существует -> Система показывает сообщение об ошибке.
        *   A2: Пароли не совпадают -> Система показывает сообщение об ошибке.

4. Нефункциональные требования (NFR)

Описывают качественные характеристики системы:

• Требования к производительности: время отклика системы (< 2 сек. для 95% запросов при нагрузке 1000 пользователей), пропускная способность.
• Требования к безопасности: аутентификация, авторизация, шифрование данных, соответствие GDPR/152-ФЗ.
• Требования к надежности и отказоустойчивости: uptime (99.9%), процедуры восстановления после сбоев.
• Требования к удобству использования (Usability): соответствие гайдлайнам (Material Design, Apple HIG), время обучения новому пользователю.
• Масштабируемость: возможность увеличения нагрузки в 2 раза без изменения архитектуры.

5. Требования к интерфейсам и интеграциям

• Описание внешних систем (платежные шлюзы, CRM, 1C), с которыми необходимо интегрироваться.
• Формат и протоколы обмена данными (REST API, SOAP, GraphQL, формат JSON/XML).
• Mock-up или прототипы ключевых экранов (часто выносятся в приложение).

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

• Технологический стек: разрешенные или запрещенные языки, фреймворки, СУБД (например, "Backend: Python/Django, Frontend: React 18+").
• Ограничения по срокам и бюджету.
• Допущения, принятые при составлении ТЗ (напр., "Предполагается, что API внешней службы доставки стабильно доступно").

7. Критерии приемки и условия сдачи-приемки работ

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

• Список критериев приемки (Acceptance Criteria) для каждого ключевого требования или пользовательского сценария.
• Процедура приемки: сроки, форматы отчетности (UAT-тестирование), состав приемочной комиссии.
• График поставки (если проект сдается по частям).

8. Приложения

• Диаграммы: Use Case, BPMN, ER-диаграммы базы данных.
• Прототипы интерфейсов (Figma, Axure ссылки).
• Пользовательские сценарии (User Stories) в формате "Как <роль>, я хочу <функция>, чтобы <ценность>".

Практические рекомендации по составлению ТЗ

• Используйте единый, структурированный шаблон для всех проектов в компании.
• Пишите требования в стиле SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
• Избегайте двусмысленностей. Вместо "система должна работать быстро" — "время загрузки главной страницы не должно превышать 2 секунд при ширине канала 10 Мбит/с".
• Вовлекайте в согласование ТЗ всех ключевых стейкхолдеров: заказчика, бизнес-аналитика, архитектора, ведущего разработчика, тестировщика.
• Рассматривайте ТЗ как "живой документ". Изменения неизбежны, но они должны управляться через формальный процесс управления изменениями (Change Request Process), с оценкой влияния на сроки и бюджет.

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