Чем детальнее ТЗ, тем слабее разработчики — парадокс, который я вижу на проектах

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

Парадокс, с которого всё началось

Навела меня на эту мысль обычная вечерняя переписка с одним хорошим аналитиком. Разговорились про то, как устроена работа на разных проектах, и всплыла закономерность, которую я потом стал замечать почти везде.

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

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

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

Почему детальное ТЗ отбивает экспертизу

Разберём по пунктам, что именно происходит с командой, когда каждое решение уже принято за неё.

Нет пространства для R&D. Аналитики «заложили» решение целиком, разработчику остаётся воплотить его в коде. Меньше творчества — меньше поводов думать о новых технологиях, алгоритмах и паттернах. А мышца, которую не тренируешь, атрофируется.

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

Узкое горлышко аналитики. Разработка ждёт, пока аналитики закончат свою работу. Документ «подвис» или ушёл на переделку — команда простаивает. А когда дело наконец доходит до кода, поменять что-то фундаментально уже поздно: всё завязано на утверждённые требования, и любая правка тянет за собой пересогласование.

Плюсы детального ТЗ (они есть)

Было бы нечестно сказать, что подробное ТЗ — это зло. У него есть вполне реальные плюсы, за которые его и любят менеджеры и заказчики.

• Предсказуемость. Заказчик и менеджмент понимают сроки и объём работ. Для бизнеса это часто важнее, чем рост экспертизы команды, — и это нормально.
• Быстрый старт. Проще начать, меньше вопросов на входе. Разработчик открыл задачу — и сразу понятно, что делать, не нужно неделю выяснять контекст.
• Меньше рисков по бизнес-логике. Аналитики учитывают нюансы и сценарии, до которых разработчик просто не докопается. Помнишь мем про сломанный телефон? Заказчик представил одно, аналитик понял второе, разработчик сделал третье — и на выходе нечто формально близкое, но совсем не то. Детальное ТЗ этот разрыв сокращает.

А минусы — ровно то, с чего мы начали: рост разработчика упирается в потолок (кодер так кодером и останется), команда попадает в зависимость от аналитиков (одна их неточность тянется багом по всей цепочке) и теряет сильные решения, которые у людей были, да так и остались невостребованными. А невостребованность — короткая дорога к выгоранию.

Обратная сторона: общее ТЗ

Если качнуть маятник в другую сторону и оставить только общие требования, картина получается зеркальная.

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

Минусы: выше риск, что дело пойдёт не так по срокам, объёму и качеству. И — ключевое — такому подходу нужна сильная команда, которая умеет держать удар. Слабая без детальных требований просто застрянет в бесконечных уточнениях и утонет в «а как надо-то?».

Именно поэтому нет универсального ответа «детализируй / не детализируй». Всё зависит от переменных уравнения: какая компания, насколько она забюрократизирована, насколько сложен проект и кто у тебя в команде.

Как искать баланс

Универсальной формулы нет, и любой, кто её продаёт, немного лукавит. Но за годы работы с разными командами у меня сложился рабочий чек-лист. Он субъективен, переменные придётся подтачивать под себя — но как отправная точка вполне годится.

1. Разделяй зоны ответственности. Аналитики отвечают за бизнес-логику, пользовательские сценарии и требования. Ведущие разработчики — за архитектуру и выбор технологий. Не надо, чтобы аналитик проектировал классы, а архитектор пересказывал бизнес-процессы.

2. Делай совместные воркшопы. Подключай разработчиков на этапе обсуждения требований, а аналитиков — на ревью архитектурных концепций. Когда обе стороны варятся в общем контексте, общий уровень команды растёт сам собой.

3. Вкладывайся в мотивацию и культуру. Создавай условия, где разработчику интересно предлагать и обосновывать новые решения. Если за инициативу не бьют по рукам, инициативы становится больше — банально, но работает.

4. Ставь гибкие рамки. Детально расписывай только самые рисковые участки системы — там, где ошибка стоит дорого. Всё остальное отдавай команде на проработку. Пусть думают там, где могут думать без риска уронить прод.

Итог

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

Если у тебя команда сильных инженеров, а ты душишь их детальными требованиями — ты своими руками превращаешь их в кодеров и готовишь себе волну выгорания. Если команда слабая, а ТЗ общее — готовь запасной спринт, он тебе понадобится. Правда, как всегда, где-то посередине, и её координаты придётся искать под каждый проект заново.

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП