Холивар, который не заканчивается
Каждый раз, когда на проекте заходит речь о документации, делятся на два лагеря. Одни говорят: «ГОСТ 34 — это бюрократия советской эпохи». Другие: «Без ТЗ — ни шагу».
Я работал с обоими подходами. Вот что думаю.
Когда ГОСТ реально помогает
1. Государственные и окологосударственные заказчики.
Если ваш заказчик — бюджетная организация, приёмочная комиссия и договор с фиксированной суммой — без чёткого ТЗ вы просто не закроете проект. Всё, что не написано — не сделано.
2. Большие команды и длинный горизонт.
Когда над проектом работают 10+ человек больше года, документация — это не бюрократия, а система координат. Новый разработчик читает ТЗ, а не расспрашивает каждого коллегу.
3. Интеграции с внешними системами.
Если ваша система должна «разговаривать» с SAP, 1С или госреестром — форматы, протоколы и сценарии лучше зафиксировать письменно до начала разработки.
Когда agile работает лучше
- Стартап с быстро меняющимися требованиями
- Прототипирование — когда сам заказчик не знает, что хочет
- Небольшая команда, все в одном чате
- MVP за 1–2 месяца
Мой подход
Я пишу ТЗ в свободной форме, но со структурой ГОСТ: цели, границы системы, роли пользователей, функциональные требования, интеграции, ограничения.
Это даёт:
- юридическую защиту (есть что подписать)
- понимание у команды (есть что прочитать)
- гибкость (нет лишних разделов ради галочки)
Вывод
Вопрос не «ГОСТ или agile», а «что именно нужно зафиксировать на этом проекте». Документация — инструмент, а не цель.