🛠️ Мануал по Agile: как количество людей влияет на производительность

Многие слышали о методологии Agile и имеют общее представление о том, что это такое. Если открыть учебники или статьи на Хабре про Scrum, часто можно увидеть, что оптимальный размер команды составляет около 8 человек. Но что происходит, если команда начинает расти?

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

Когда я начинал, мне посчастливилось работать в небольшой команде из 3 DevOps-инженеров. У нас было много преимуществ: мы работали быстро, решения принимались мгновенно, и каждый знал, кто за что отвечает.
Единственный минус — не всегда хватало рабочей силы для выполнения всех задач.

📈 Со временем наша команда начала расширяться. Это был интересный период: новые люди принесли свежие идеи и экспертизу в тех области технологий, в которых другие члены команды были менее компетентны.
Производительность действительно возросла, но вместе с этим увеличилось и количество процессов, которые требовали внимания. Нам пришлось не только правильно разделять задачи, но и обеспечивать эффективное взаимодействие, чтобы никто не выпадал из общей картины происходящего.

⚠️ Однако, в какой-то момент мы решили еще больше расширить команду, чтобы охватить еще больший объем задач. И это стало нашей ошибкой. Мы столкнулись с неожиданными проблемами: количество встреч резко возросло, многие члены команды перестали понимать, кто чем занимается, и эффективность снизилась. Появилось множество ненужных встреч и синков. Время, затрачиваемое на обсуждения, увеличилось — на примере дейликов большее количество человек стало тратить больше времени на высказывания и обсуждения.

Возникло ощущение, что вместо ускорения процесса разработки мы, наоборот, начали замедляться.

🤔 Какие же выводы можно сделать из этой истории?

1. Коммуникационные барьеры. В малых командах информация передается быстрее, решения принимаются оперативно. С увеличением числа участников растет количество коммуникационных каналов, что замедляет процесс согласования.

2. Сложность координации. По мере роста команды увеличивается количество задач и зависимостей. В результате, больше времени уходит на планирование и управление ресурсами, что замедляет процесс разработки.

3. Личная ответственность. В чрезмерно больших командах ответственность за конкретные задачи может стать размытой. Это снижает личную вовлеченность каждого участника, что негативно сказывается на сроках выполнения задач. Это приводит не только к потере общего направления развития, но и к усилению выгорания отдельных людей.

4. Принцип Брукса. Фредерик Брукс писал в своей книге "Мифический человеко-месяц", что добавление новых сотрудников к запаздывающему проекту делает его еще более запаздывающим. Этот принцип актуален и сегодня, особенно в контексте чрезмерного расширения команды.

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

А что вы думаете на этот счет? Какие меры принимались у вас в командах для повышения производительности?