Если, конечно, одна из них не на 8 месяце.

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

Расчет количества связей

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

Участники команды разработки постоянно общаются между собой: обсуждают рабочие моменты, делятся предложениями, отчитываются о проделанной работе и т.д. Между ними возникают связи, число которых увеличивается с ростом людей в команде.

Для оценки количества связей используется формула: N*(N – 1) / 2, где N – это число людей в команде. Она позволяет определить количество взаимодействий между членами при их разном количестве. Например, команда из 3 человек имеет всего 3 связи, тогда как у команды из 7 человек уже 21 связь.

Зачем их считать? Каждый новый человек будет не только увеличивать продуктивность, но и добавлять значительное число связей. По наблюдениям, в командах из 3-4 человек на взаимоотношения с другими людьми тратится по 30 минут времени. В больших командах 7-8 человек на общение уходит около 90 минут.

При дальнейшем увеличении, например, в команде из 14 человек (91 связь) затраты на общения настолько значительны, что члены команды начнут отказываться от них. Это также плохо влияет на продуктивность и психологическое состояние.

Психолог и профессор менеджмента Дженнифер Мюллер предложила такой термин как «реляционная потеря». Это ощущение, что вы получаете меньшую поддержку по мере роста вашей команды. Из-за того, что в больших командах все не могут взаимодействовать со всеми: из-за больших затрат времени, велик шанс, что кого-то в команде обделят общением значительнее остальных. Получается: чем больше команда, тем меньше поддержки.

«Закон Амдала»

Изменение в продуктивности в команде происходит не только из за количества взаимоотношений, а также из‑за того, что не все работы можно вести параллельно.

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

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

Например, если мы возьмем процесс, который 1 человек выполнил бы за 7 дней (рисунок 2), то, увеличив команду до 3-х человек сможем выполнить его за 4 дня, так как распараллелить можно будет только 5 работ. Да, сокращение времени на выполнение работ происходит, но не так сильно, как хотелось бы.

У закона Амдала «страшная» формула. Однако если превратить ее в график, она становится вполне понятной.

Давайте представим, что 80% работ на проекте можно выполнить, работая параллельно. Точка отсчета — время выполнения работ 1 человеком. Тогда, чтобы сократить срок выполнения в 2 раза, нам понадобится 3 человека, в 3 раза — 6 человек, в 4 раза — 16 человек!

Смягчить закон Амдала можно несколькими способами:

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

• Использовать более эффективные методы в разработке, например те, которые позволяют выполнять разработку «микросервисами». В этом случае работать над проектом могут несколько независимых друг от друга команд.

• Уменьшить кросс‑командные зависимости для уменьшения «узких» мест разработки.

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

• Использовать более эффективные методы в разработке, например те, которые позволяют выполнять разработку «микросервисами». В этом случае работать над проектом могут несколько независимых друг от друга команд.

• Уменьшить кросс‑командные зависимости для уменьшения «узких» мест разработки.

Магическое число 7

Закономерность, обнаруженную учёным-психологом Джорджем Миллером, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов, также используют при составлении оптимального размера команд.

Джефф Сазерленд, один из изобретателей Scrum, написал: “Любая команда численностью более 7 человек должна быть разделена на несколько”.

Он наблюдал за командами в компании, разрабатывающей ПО для здравоохранения. Всего разработчиков было 500. 

После внедрения Scrum только несколько команд начали генерировать рабочий код в пять раз быстрее, чем в среднем по отрасли. Они вышли в режим высокой продуктивности благодаря тому, что всегда делились на подгруппы по 7 и менее человек. Несмотря на то, что в культуре компании размер команды закрепился на +/- 15 людях.

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

Его вывод также подтверждает исследованию компании Quantitative Software Management.

Они отобрали 491 проект, который был бы похож по сложности, количеству новых или измененных строках кода и завершен за последние 3 года. Их разделили по количеству людей в команде: 1-3; 3-5; 5-7; 9-11; 15-20.

Проанализировав производительность, затраты и время, потраченное на проект, они сделали вывод, что наиболее оптимальны команды из 3-5 и 5-7 человек. Команды из 9 и более человек оказались самыми «дорогими» и малоэффективными.

Эффект Рингельмана или социальной лени

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

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

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

Однако результат первого опыта подтвердился. У каждого из двух людей результат был 93% от индивидуальной эффективности, у трёх — 85%, а в группах из семи и более человек всего около — 42%.

Недавняя новость про разработчика, работающего на Google всего час в день за полный оклад только подтвердила эту теорию. Молодой человек просто создает иллюзию работы, а в компании‑гиганте про его «индивидуальный график», никто даже не подозревает.

Влияние этого эффекта также можно уменьшить:

1. Определите ясные роли и обязанности каждого участника группы. Чтобы каждый понимал, какую работу он выполняет и как это влияет на общую цель.

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

3. Обеспечьте эффективную коммуникацию и получение обратной связи. Чтобы можно было показывать свой вклад команде, а также знать, что их работа оценивается и ценится.

4. Декомпозируйте задачи и отслеживайте их выполнение. Чтобы любой участник мог видеть и показать свой личный вклад в проект.

Вместо итога

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

Оптимизируйте, разделяйте, увеличивайте и сокращайте. Желаю успехов в разработке!