ТЗ и технический проект: что описывает каждый документ

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

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

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

Технический проект: решения

Технический проект отвечает на вопрос «как система будет устроена, чтобы выполнить требования». Его пишут архитектор и ведущие разработчики. В нём появляются конкретные решения:

• Архитектура: из каких компонентов состоит система и как они взаимодействуют
• Технологии: языки, фреймворки, СУБД, брокеры сообщений, и почему выбраны именно они
• Модель данных: таблицы или коллекции, связи, индексы, правила хранения истории
• Интеграции: протоколы, форматы, расписание обмена, обработка сбоев и повторов
• Инфраструктура: где и как развёрнута система, резервирование, мониторинг
• Безопасность: аутентификация, разграничение прав, шифрование, журналы действий
• Решения по производительности: кэширование, очереди, фоновые задачи

Пример на одном требовании

ТЗ: «Менеджер видит актуальные остатки товара при оформлении заказа».

Технический проект: остатки хранятся в учётной системе; сервис синхронизации забирает изменения по API раз в несколько минут и записывает в базу приложения; при оформлении заказа резерв создаётся в приложении и сразу передаётся в учёт; при недоступности учётной системы заказ сохраняется со статусом «ожидает подтверждения остатка», а менеджер видит предупреждение.

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

Зачем заказчику технический проект

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

Когда технический проект обязателен

• Система с несколькими интеграциями и обменом данными
• Высокие требования к надёжности: платежи, медицина, учёт денег
• Проект делают несколько команд или подрядчиков
• Система рассчитана на годы и будет передаваться на поддержку
• Требуется согласование со службой безопасности или IT-отделом заказчика

Для простого сайта или бота отдельный технический проект избыточен — достаточно короткого раздела «архитектура и технологии» в документации.

Как принимать технический проект

Попросите провести защиту: архитектор объясняет решения и отвечает на вопросы. Если в компании есть IT-специалист, пусть проверит выбор технологий и инфраструктуры. Задайте вопросы: что будет, если нагрузка вырастет в несколько раз; что будет при отказе каждой внешней системы; как восстановить данные после сбоя; можно ли сменить подрядчика без переписывания.

Частые ошибки

Смешивание документов: в ТЗ заранее зашивают технологии, которые выбрал заказчик по совету знакомых, и команда не может предложить лучшее решение. Обратная ошибка — технический проект пишут после разработки, «для галочки», описывая то, что получилось. И третья — проект не обновляют, когда решения меняются по ходу работ.

Итог

ТЗ задаёт рамки и критерии, технический проект — внутреннее устройство. Первый документ защищает интересы заказчика при приёмке, второй — при эксплуатации и развитии системы.