Как часто вы сталкиваетесь с большими командами? Я регулярно встречаю команды размером 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 разработчиков итд). Изменить такую структуру будет крайне сложно.
Какие из этих эффектов вы наблюдаете в своей работе? Пишите в комментариях.
Ну а пока, продолжение следует :) …