Я провёл серию симуляций и хочу поделиться гипотезой, которую можно проверить на реальных данных.

В системе с зависимыми событиями, подверженными флуктуациям, задержки накапливаются, а ускорения - нет. Это подтвержденный факт, можно вбить в поисковик и углубиться. Флуктуация - случайное отклонение физической величины от её среднего значения. Что это для нас значит в мире IT - если аналитик задержал задачу, вся команда ждёт. Если аналитик сделал задачу быстрее, команда не может начать ей быстрее заниматься, если у неё в работе еще предыдущие задачи. Аналогично на этапах разработки и тестирования.

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

Попытки построить сбалансированную команду, где ресурсы аналитики, разработки и тестирования примерно равномощны, обречены на провал и ведут к срыву предсказуемости. Менеджеры начинают закладывать на все оценки "менеджерский коэффициент" (дерьмо случается), создавая себе буфер для сглаживания на каждом этапе. Где-то он используется, где-то нет, в итоге все разбалансируется и начинается хаос, требующий постоянного оперативного разруливания ситуации.

Теория ограничений говорит - найди узкое место, максимизируй его использование, подчини ему всё и затем расширь. И тогда узкое место переместится и мы вернемся на первый шаг. Поэтому в ИТ самый частый интуитивный паттерн "разработка не успеват - нужно нанять еще разработчика!" зачастую не приносит значимого результата. Куча разгребается, а затем средняя скорость команды может измениться весьма незначительно, потому что начнет не успевать аналитика или тестирование.

За свои 11.5 лет в ИТ, почти половина из которых в управлении, я ни разу не видел осознанного использованиях этих фактов при формировании ИТ-команд.

Теперь гипотеза: осознанное проектирование узкого места на этапе тестирования позволяет повысить стабильность и предсказуемость поставки. Допущение - в вашем процессе после тестирования нет каких-либо еще этапов, ограничивающих пропускную способность. Симуляции с помощью ИИ показывают - команды, в которых мощность аналитики, разработки и тестирования расположена по убывающей, выдают в среднем на 10% меньшую скорость, но на 20-40% большую предсказуемость. В таких командах избыточная мощность аналитики и разработки позволяет создавать буфер перед тестированием, защищающий общий процесс от флуктуаций, в т.ч. вызванных блокировками и влётами срочных задач.

Если гипотеза верна, то в командах с наиболее стабильным Throughput больше всего задач скапливается в буфере "Ожидание тестирование", с наименее - в ожидании аналитики.

Насчет простаивающих аналитиков и разработчиков - у нас нет цели на 100% утилизровать всю команду. Наша цель - выводить в пром функционал. Также (и это ВАЖНО) избыточная мощность разработки может пойти на рефакторинг, на который всегда не хватает времени, а в случае с аналитикой - на более качественную проработку требований и ответы на вопросы, неизбежно возникающие на этапах разработки и тестирования. Но за этим нужно следить, чтобы не получить счастливых лентяев =)

Выстроить "идеально несбалансированный баланс" вряд ли получится, но к нему, кажется стоит стремиться. Проверьте на своих данных. Если гипотеза подтвердится — напишите мне. Если нет — тем более напишите. Будем разбираться вместе.