Большие команды. Почему это плохо?

Как часто вы сталкиваетесь с большими командами? Я регулярно встречаю команды размером 20-30 человек. И всегда говорю, что это не лучшая идея.

Scrum Guide дает следующую рекомендацию о численности: “Не более 10 человек в команде”. Развернутый ответ на вопрос “почему?” Скрам дает только в специализированных источниках (Scrum Patterns - Small teams).

В этой статье захотелось ответить более структурированно, плюс добавить своих наблюдений и опыта.

Описываемые ниже проблемы особенно ярко проявляют себя в продуктовых командах, так как такие команды работают в комплексном домене (Cynefin framework). Разработка продукта и любое функционирование в комплексном домене подразумевает:

Но эти выводы в некоторой мере подходят и для любых других команд и социальных групп.

Итак, приступим. Почему же?

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

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

Известный социальный эксперимент. Мужчина на улице притворялся, что ему плохо. Исследователи изучали в каком случае ему окажут помощь. Выяснилось, чем больше прохожих людей видят эту картину, тем меньше шансов на то, что ему окажут помощь. Соответственно, когда рядом находился 1 прохожий, к больному подходили практически всегда. Объяснялось такое поведение психологической установкой «ему кто-нибудь поможет».

Подобное можно наблюдать и в рабочей обстановке. При возникновении ситуаций, где нужно взять ответственность, появляется внутренний голос “кто-то этим займется”. Если в команде есть инициативные участники, этот вопрос решается быстро. Но и они когда-то устают. Поэтому рано или поздно руководителю приходится назначать конкретных исполнителей.

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

Когда в команде становится много участников, начинают возникать следующие вопросы:

Все это усложняется форматом онлайна. Если асинхронная коммуникация 1-1 особо не меняется (у нас есть личные чаты), то вот синхронная коммуникация (общие встречи) значительно усложняется. Независимо от количества человек 3 или 30 в каждый момент времени говорит только один. Это в свою очередь накладывает ограничения на количество обрабатываемой всей группой информации.

Команда, работающая над единым продуктом, должна принимать большинство решений совместно. Усложнение и замедление коммуникаций приводит к сложностям в принятии решений группой.

Отдельно стоит проговорить про решения методом Консенсуса. Косенсус - это решение на основе общего согласия без проведения голосования и при отсутствии существенных противоречий (когда мы просто поговорили, согласились на чем-то одном и все остались довольны).

Наиболее быстро и качественно принять решение консенсусом можно, когда в группе 4 человека. 6 человек в группе - это максимальное количество участников, в котором удастся good enough учесть интересы всех и не потратить на это много времени.

Чем дальше число участников от цифры 6 (7, 8, 9 итд), тем сильнее решение консенсусом страдает либо в качестве либо в количестве времени, необходимого на принятие решения.

В группе из 15 человек решение консенсусом принять практически невозможно. Оно все равно в итоге сводится к тому, что решение принимают 3-4 участника команды.

Это боль Скрам-мастеров и менеджеров, пытающихся построить гибкие кроссфункциональные команды.

При увеличении группы наиболее частые коммуникации возникают с 2-3 людьми. Зачастую это представители своей платформы/ компоненты. Таким образом формируются “неформальные команды” внутри.

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

Какие из этих эффектов вы наблюдаете в своей работе? Пишите в комментариях.

Ну а пока, продолжение следует :) …