Почему ТЗ — это не формальность, а необходимость
Представьте, что вы заказываете строительство дома. Если просто сказать "Хочу двухэтажный дом с окнами", результат может сильно разочаровать. Будет ли там отопление? Сколько комнат? Какая планировка? Техническое задание в IT — это тот самый детальный проект дома, без которого нельзя начать строительство.
Реальные последствия плохого ТЗ:
- 60% доработок в проектах возникают из-за неполных требований
- Исправление ошибки на этапе внедрения в 100 раз дороже, чем на этапе проектирования
- 30% проектов терпят неудачу из-за разногласий в понимании требований
Что такое ТЗ на самом деле?
Техническое задание — это живой документ, который:
- Фиксирует что нужно сделать (цели, функционал)
- Определяет как это будет работать (архитектура, интерфейсы)
- Устанавливает критерии успеха (как поймём, что всё готово)
Чем не является ТЗ:
- Это не юридический документ (хотя может быть приложением к договору)
- Не догма — можно и нужно корректировать по мере развития проекта
- Не заменяет общение между командой и заказчиком
Когда можно обойтись без ТЗ?
3 случая, когда ТЗ не обязательно:
- Косметические изменения
Пример: Удаление неиспользуемой кнопки в интерфейсе. Достаточно задачи в трекере: "Убрать кнопку 'Поделиться' со страницы товара". - Исследовательские проекты
Пример: Анализ технологий для чат-бота. Вместо ТЗ — гипотезы и план исследования. - Гибкие методологии (Agile)
Пример: Разработка стартапа. Используем User Stories вместо ТЗ: "Как пользователь, я хочу регистрироваться через соцсети, чтобы экономить время".
Но даже в этих случаях минимальная документация снижает риски!
Кто и как создаёт ТЗ: процесс разработки
Участники процесса:
- Бизнес-аналитик — главный "повар" ТЗ:
Проводит интервью с заказчиком
Анализирует бизнес-процессы
Формулирует требования - Системный аналитик — добавляет технические детали:
Описывает архитектуру
Продумывает интеграции
Учитывает ограничения - Заказчик — ставит задачи и проверяет:
Соответствие бизнес-целям
Полноту требований
Приоритеты - Команда (разработчики, тестировщики, дизайнеры) — даёт обратную связь:
Оценивает сложность
Предлагает альтернативы
Выявляет противоречия
Этапы создания:
- Сбор требований (интервью, воркшопы, анализ конкурентов)
- Структурирование информации
- Согласование с заказчиком
- Детализация с техническими специалистами
- Утверждение финальной версии
Из чего состоит хорошее ТЗ: структура
- Введение
Цели и задачи проекта
Описание проблем, которые решает система
Глоссарий терминов - Общее описание
Целевая аудитория
Основные сценарии использования
Ограничения (технические, бюджетные, временные) - Функциональные требования
Подробное описание возможностей системы
Пользовательские сценарии
Бизнес-правила - Нефункциональные требования
Производительность (нагрузка, время отклика)
Безопасность (аутентификация, шифрование)
Масштабируемость
Юзабилити - Интерфейсы
API (форматы запросов/ответов)
Интеграции с другими системами
Пользовательские интерфейсы (основные экраны) - Критерии приемки
Чек-лист для тестирования
Метрики успеха - Дополнительно
Риски и пути их минимизации
Этапы разработки
Приложения (прототипы, диаграммы)
Пример требования:
"Система должна позволять пользователю сбрасывать пароль. При нажатии кнопки 'Забыли пароль?' система отправляет письмо со ссылкой для сброса на email, указанный при регистрации. Ссылка действительна 24 часа."
Стандарты: как не изобретать велосипед
1. Российские ГОСТы
- ГОСТ 34 — для автоматизированных систем
- ГОСТ 19 — для программного обеспечения
Когда использовать: При работе с госструктурами или когда требуется строгая регламентация.
2. Международные стандарты
- IEEE 830 — шаблон для спецификаций требований
- ISO/IEC/IEEE 29148 — современный стандарт по инженерии требований
Когда использовать: Для международных проектов или когда нужен гибкий подход.
3. Практические руководства
- BABOK — "библия" бизнес-анализа
- Книга Вигерса "Разработка требований к ПО"
Когда использовать: Для внутренних проектов, когда важна суть, а не форма.
5 советов по написанию идеального ТЗ
- Используйте простой язык
Избегайте двусмысленностей. Вместо "Система должна быстро работать" → "Время отклика при 1000 пользователей — не более 2 сек". - Добавляйте примеры
Для сложных сценариев приводите конкретные кейсы:
"Если пользователь трижды введёт неверный пароль, аккаунт блокируется на 1 час". - Приоритезируйте требования
Разделяйте на:
Must have (без этого система не работает)
Should have (важно, но можно без этого)
Nice to have (улучшения) - Визуализируйте
Добавляйте:
Блок-схемы процессов
Прототипы интерфейсов
Диаграммы состояний - Пишите для всех
ТЗ должны понимать:
Заказчик (что получит)
Разработчик (как сделать)
Тестировщик (как проверить)
Типичные ошибки и как их избежать
- "Мы и так всё понимаем"
Проблема: Пропуск этапа формализации требований.
Решение: Всегда фиксируйте договорённости письменно. - "Сделаем как у конкурентов"
Проблема: Копирование без анализа реальных потребностей.
Решение: Проводите глубинные интервью с пользователями. - "Технические детали не важны"
Проблема: Размытые нефункциональные требования.
Решение: Чётко указывайте параметры производительности, безопасности и т.д. - "Это же Agile, документы не нужны"
Проблема: Полный отказ от документации.
Решение: Используйте легковесные форматы (User Stories, критерии приемки). - "ТЗ — это навсегда"
Проблема: Нежелание вносить изменения.
Решение: Установите процесс управления изменениями (Change Request).
ТЗ — это инвестиция, а не затраты
Хорошее техническое задание экономит время и деньги:
- Снижает количество доработок на 40-60%
- Ускоряет разработку в 2-3 раза
- Уменьшает количество конфликтов с заказчиком
Как писать техническое задание: практическое руководство для аналитиков и разработчиков
1. Используйте структурированный шаблон
Хорошее ТЗ должно быть логичным и легко читаемым. Стандартная структура включает:
- Введение (цель проекта, терминология, контекст)
- Общее описание (пользователи, основные сценарии)
- Функциональные требования (что должна делать система)
- Нефункциональные требования (производительность, безопасность)
- Интерфейсы и интеграции (API, сторонние сервисы)
- Критерии приемки (как проверить результат)
Почему это важно?
Единая структура ускоряет согласование и делает документ удобным для всех участников.
2. Соблюдайте единый стиль оформления
Названия разделов должны быть однотипными:
- Либо существительные («Требования», «Архитектура»),
- Либо отглагольные формы («Формирование требований», «Проектирование архитектуры»).
Пример плохого стиля:
- Требования
- Описание интеграции
- Как тестировать
Пример хорошего стиля:
- Требования
- Интеграция
- Тестирование
3. Добавьте визуальные элементы
Текст воспринимается сложнее, чем схемы и таблицы. Используйте:
- Блок-схемы для описания процессов (например, регистрации пользователя).
- Таблицы для сравнения вариантов решений.
- Прототипы интерфейсов (можно сделать в Figma или даже схематично в Miro).
Важно:
Избегайте избыточного оформления — слишком много цветов и шрифтов усложняют чтение.
4. Создайте оглавление и глоссарий
Оглавление помогает быстро находить нужный раздел. Современные редакторы (Word, Confluence, Notion) умеют генерировать его автоматически.
Глоссарий объясняет сложные термины. Например:
API (Application Programming Interface) — интерфейс для обмена данными между системами.
Пример: интеграция с CRM через REST API.
Почему это важно?
Даже если термин кажется очевидным, его определение исключает разночтения.
5. Следуйте принципам SMART
Каждое требование должно быть:
- Конкретным (не «удобный интерфейс», а «кнопка „Сохранить“ в правом верхнем углу»).
- Измеримым (не «быстрая загрузка», а «время отклика ≤ 1 секунды»).
- Достижимым (учитывайте бюджет и технологии).
- Релевантным (соответствует бизнес-целям).
- Ограниченным по времени (если есть жесткие дедлайны).
Пример плохого требования:
«Система должна работать быстро».
Пример хорошего требования:
«При 1000 одновременных пользователей время отклика не превышает 2 секунд».
6. Проверьте ТЗ на противоречия
Частая ошибка — требования, которые конфликтуют друг с другом. Например:
- В одном разделе: «Пользователь может отменить заказ в течение 24 часов».
- В другом: «После оплаты заказ нельзя отменить».
Решение:
Проведите кросс-проверку всех разделов перед утверждением.
7. Добавьте критерии приемки
Это чек-лист, по которому заказчик и тестировщики проверят готовый продукт.
Пример:
✅ При нажатии кнопки «Оплатить» система перенаправляет на страницу платежного шлюза.
✅ После успешной оплаты пользователь получает email-уведомление.
Почему это важно?
Чем конкретнее критерии, тем проще избежать споров на этапе сдачи проекта.
8. Укажите сроки и этапы
Даже если проект Agile, в ТЗ стоит прописать:
- Основные вехи (например, MVP через 2 месяца).
- Время на тестирование и доработки.
Дополнительно:
Можно приложить диаграмму Ганта, если проект сложный и многоэтапный.
9. Введите процесс внесения изменений
ТЗ редко остается неизменным. Чтобы правки не создали хаос:
- Все изменения оформляются официальным запросом (например, через Jira или email).
- Оценивается их влияние на сроки и бюджет.
- После согласования — обновляется основная версия ТЗ.
Важно:
Храните историю изменений, чтобы при конфликтах можно было обратиться к предыдущим версиям.
10. Проведите «тест-драйв» ТЗ
Перед финальным согласованием дайте ТЗ разным людям:
- Разработчику — поймет ли он, что делать?
- Тестировщику — сможет ли составить тест-кейсы?
- Менеджеру — видит ли он сроки и приоритеты?
- Заказчику — соответствует ли документ его ожиданиям?
Если все ответили «да» — ТЗ готово к работе.
Чек-лист перед отправкой ТЗ
Перед утверждением проверьте:
- Все требования конкретны и измеримы.
- Нет противоречий между разделами.
- Критерии приемки покрывают ключевые функции.
- Глоссарий включает все специальные термины.
- Визуальные материалы подписаны и понятны.
- Указаны сроки и этапы.
- Есть процесс внесения изменений.
Финальный совет:
ТЗ — это не бюрократия, а инструмент, который экономит время и нервы. Как говорят опытные разработчики:
«Лучше потратить день на уточнение ТЗ, чем неделю на переделку кода».
А какие правила написания ТЗ используете вы? Делитесь в комментариях!