Оптимальный размер команды: между магией чисел и законами психофизиологии

Эмпирика оптимальных размеров: в поисках золотого сечения

Доцент Школы инноватики и предпринимательства Титов Сергей не так давно провел систематический обзор девяти научных эмпирических работ, посвященных оптимальному размеру команды. Совокупная база исследований охватила данные более 4700 реальных команд, мнения свыше 20 экспертов и результаты двух компьютерных симуляций.

Научное обоснование: почему бы не … 13?

Снижение продуктивности команд может быть объяснено рядом научных представлений, во многом подтвержденных эмпирически. Так, теория процессных потерь Стейнера А. выделяет потери мотивации и координации [Steiner, 1972]. Потери мотивации проявляются в эффекте «социальной лени», когда средняя результативность участника команды снижается по мере увеличения её размеров. Потери координации возникают из-за экспоненциального роста коммуникаций между участниками. С увеличением размера команды резко возрастают усилия на согласование действий и сложность коммуникаций.

Психофизиологическая ограниченность эффективной когнитивной нагрузки подтверждается исследованиями Миллера Дж. А., часто обобщёнными под названием закона Миллера [Miller, 1956]. Данный закон гласит, что средний человек способен хорошо удерживать в краткосрочной памяти 7+/-2 «предмета» и, соответственно, может в своем сознании сохранять всю полноту образов ограниченного количества людей: от 5 до 9.

Ухудшение социальных отношений при росте размера команды согласуется также с концепцией потерь в отношениях (relational loss), предложенной Мюллер Дж. С. [Mueller, 2012]. Автор отмечает, что команды, работающие как сплочённый коллектив, после превышения определенного размера имеют тенденцию к распаду на две клики, что снижает уровень доверия и согласованности.

Эксперты Skelton & Pais [2019] выделили когнитивную нагрузку как особый тип деятельности внутри команд. Они указывают на психофизиологические ограничения человека, опираясь на исследования Данбара Р., согласно которым человек способен поддерживать доверительные отношения в среднем только с 5 другими людьми [Geraphy, 2022]. Превышение этого размера в коллективе ведёт к существенному снижению доверия и понимания, и, соответственно, повышению когнитивных усилий.

От науки к практике: архитектоника команды

Изученные теоретические изыскания неплохо согласуются с лучшими практиками управления командами и использования командно-ориентированного организационного дизайна. В компании Amazon команда размером в «две пиццы» (это примерно 6-10 человек) рассматривается как «кирпичик» организационной архитектуры. При этом размеры этого стандартизированного «кирпича» напрямую связаны с используемой технологической архитектурой, а именно с микросервисной архитектурой, которая позволяет разбивать работу на автономные функциональные блоки. Каждый такой блок по своему объему и сложности рассчитан на выполнение одной командой стандартного размера всех работ по продукту — от концепции до конечной реализации. Это обеспечивает полную сквозную ответственность команды за свой продукт. Команды стабильны по составу, монопроектны и сохраняются как постоянные единицы, переходящие от задачи к задаче.

Skelton & Pais [2019] в своей топологии команд предлагают архитектуру «команда первична» (team-first architecture). Её суть заключается в том, чтобы не формировать команды под проекты, а, наоборот, структурировать работу под стабильные команды фиксированного размера. Для реализации этого принципа непрофильную, вспомогательную деятельность выводят в отдельные сервисы и платформы. Системы мотивации, обучения и целеполагания фокусируются на кросс-функциональных продуктовых командах, а не на сотрудниках или отделах. Для координации в сложных проектах выстраивают специальные интерфейсы взаимодействия между командами. Именно команды, а не отдельные люди, должны быть ключевыми единицами в бизнес-процессах. Важным дополнением является упрощённая система метрик. Вместо множества показателей и системы «360 градусов» рекомендуют подход одной ключевой метрики, привязанной к продукту команды — подход «Полярная звезда».

Обобщая теорию и практику, Титов С. А. формулирует следующие рекомендации:

• стабилизация и стандартизация не только количества, но и состава участников команд;
• определение объемов и содержания деятельности под команды, а не назначение команд на определенную деятельность;
• использование технологий и архитектур, способствующих модуляции деятельности и разбиению ее на объемы, подходящие под фиксированные команды;
• сокращение когнитивной нагрузки участников команд путем сокращения и упрощение ее внешних коммуникаций;
• системы мотивации, ориентированные на командный, а не индивидуальный результат;
• постоянное обучение команд и расширение их профессионального арсенала, обеспечивающего кросс-функциональность и сквозную ответственность за продукт;
• упрощение системы показателей и метрик для команд.

Мнения экспертов: а как в реальной жизни?

За комментариями мы обратились к экспертам, имеющим большой опыт управления инновационными и предпринимательскими проектами.

Винокуров Игорь, к.э.н. («Таймлист», «МитЛаб Консалтинг»):

В своей практике я сталкивался со сложностями масштабирования команды неоднократно. И признаюсь, что это не очень приятная и часто не самая очевидная вещь. Например, на начальном этапе разработки нашей ИИ-системы «Таймлист», позволяющей расшифровывать и структурировать совещания, нас было около 7 человек. И это был идеал. Понимание — полное. Решение принимаются мгновенно. Высокая скорость разработки. Но продукт усложнялся, инвесторы хотели видеть «солидную» команду, объемы работ подталкивали к увеличению команды. Мы выросли до 15 человек и попытались продолжить работу все вместе. Но обнаружили, что задачи касаются разных людей по-разному. Есть вопрос больше клиентские, а есть — преимущественно технические. И вместо ожидаемого роста продуктивности мы столкнулись с ее заметным снижением. Затем, возникли две команды, но не кросс-функциональные, как говорится в статье, а скорее специализированные. Одна команда стала больше заниматься клиентами, продвижением, позиционированием продукта. А вторая — техническая, исполнительная команда стала заниматься развитием функциональности продукта. Обе команды были в пределах 7 человек. Управляемость была восстановлена. Мы вернулись к прежним уровням эффективности. Так что цифра 7 это не магия, это практически значимый ориентир. Команды у нас оказались не в полном смысле кросс-функциональные, но и не монофункциональные. Это больше похоже на специализацию в разрезе подсистем или бизнес-модели, что, видимо, определяется спецификой нашего продукта.

Ибрагимов Урал, к.с.н. (предприниматель с многолетним стажем, доцент Школы инноватики и предпринимательства НИУ ВШЭ):

Я хотел бы обратить внимание на динамический характер команды и поделиться мнением о формировании команд до масштабирования. При запуске новых бизнесов мы всегда начинали с двух людей, которых, как правило, дополняли адвайзером (консультантом) во избежание типичных стартовых ошибок. На этом этапе важно понимать, что размер команды меняется по мере развития продукта. До тех пор, пока не определена архитектура или хотя бы четкое видение проекта, нет смысла подключать операционных участников, даже если вы строите продукт на основе клиентской обратной связи. Команда должна расти только тогда, когда для этого появляются задачи. Следующих участников мы подбирали, разделяя их на два типа. Одни были нужны для формирования системы, другие — для обеспечения потоковых процессов. Чтобы избежать излишнего роста команды, часть функций отдавали на аутсорсинг. Для выбора ключевых направлений деятельности использовали фреймворк, суть которого — выбрать три главных вида активности из всего многообразия, возникающего по мере развития бизнеса. Ведь то, что было важно на старте, может потерять актуальность через полгода, и команда должна гибко меняться вместе с проектом. Также мы столкнулись с одной важной особенностью. При создании новых бизнесов простое функциональное разделение без выстраивания прозрачной системы контроля не работает. Без контроля выполняемых задач идея основателя так и не становится объединяющей силой. Как правильно отмечено в статье, вопрос показателей команды — крайне важен. Но он важен не только для чистого контроля, но и для транслирования идеи и миссии на уровень операционки.

Цатурян Максим (директор Стартап-студии КубГУ):

Мое отношение к оптимальному размеру команды менялось во времени. Из опыта хочу сказать, что на этапе запуска инновационного проекта ключевую роль играет не количество людей, а закрытие критически важных функций. В моей картине мира стартовая команда должна состоять из людей, выполняющих следующие роли: лидер-инноватор, который отвечает за маркетинг, продажи, привлечение ресурсов и развитие продукта; технический лидер, который отвечает за техническую работу и создание продукта; и «качественный бюрократ», которые берет на себя поддерживающую рутину, такую как бухгалтерия, юридические вопросы, налоги и прочее. На начальном этапе роли могут пересекаться, но сам факт их наличия критически важен. Такое разделение продиктовано склонностями людей. Инноватору редко интересно «крутить гайки» или писать код. А техническому специалисту, как правило, чужды продажи. И обоим вместе глубоко неприятно погружаться в бюрократию. Попытка совместить это в одном-двух людях часто приводит к выгоранию или внутренним конфликтам. Оптимальный размер команды для старта — от 3 до 5 человек. Три — это базовый «скелет» из описанных ролей. Пять — если продукт технически сложный и требует пары узких специалистов вместо одного универсального техлида. Я не сторонник больших команд, особенно на раннем этапе. Рост численности ведет к размытой ответственности, бесконечным согласованиям, снижению скорости. Лучше начать с компактной группы, закрывающей все ключевые потребности, а по мере развития проекта аккуратно встраивать дополнительных специалистов в уже сложившуюся команду.

Использованная литература (для тех, кто хочет разобраться поглубже)

1. Окороков, А.В., & Вертакова, Ю.В. (2023). Оптимальный размер команды в коммерческих и некоммерческих организациях. Лидерство и Менеджмент, 10(4). 1281-1290. https://doi.org/10.18334/lim.10.4.119289
2. Семина, А.П. (2019). Команда как групповая форма организации труда.  Вестник Алтайской Академии Экономики и Права, 12(1), 128-133. https://doi.org/10.17513/vaael.858
3. Титов, С.А., & Титов, А.С. (2025). Идеальный размер команды проекта: утопия или реальность. Вестник проектного управления, 1(2), 61-70. https://doi.org/10.26425/3034-6916-2025-1-2-61-70
4. Bitzer, M., Bürger, O., Häckel, B., & Voit, C. (2020). Toward an economically optimal team design in IT-related innovation projects. International Journal of Innovation and Technology Management, 17(08), 2150001. https://doi.org/10.1142/s0219877021500012
5. Geraphy, T. (2022). Dunbar’s number, psychological safety and team size. Psych Safety. https://psychsafety.com/psychological-safety-82-dunbars-number-and-team-size/
6. Heričko, M., Živkovič, A., & Rozman, I. (2008). An approach to optimizing software development team size. Information Processing Letters, 108(3), 101–106. https://doi.org/10.1016/j.ipl.2008.04.014
7. Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., Tesoriero, R., Williams, L., & Zelkowitz, M. (2002). Empirical findings in agile methods. In Extreme Programming and Agile Methods — XP/Agile Universe 2002 (pp. 197–207). Springer Berlin Heidelberg.
8. Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological review, 63(2), 81.
9. Mueller, J. S. (2012). Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes, 117(1), 111-124.
10. Olivares, R., Noel, R., Guzmán, S. M., Miranda, D., & Munoz, R. (2024). Intelligent learning-based methods for determining the ideal team size in agile practices. Biomimetics (Basel, Switzerland), 9(5), 292. https://doi.org/10.3390/biomimetics9050292
11. Putnam, D. (2005). Team size can be the key to a successful project. Quantitative Software Management.
12. Rodríguez, D., Sicilia, M. A., García, E., & Harrison, R. (2012). Empirical findings on team size and productivity in software development. The Journal of Systems and Software, 85(3), 562–570. https://doi.org/10.1016/j.jss.2011.09.009
13. Skelton, M., & Pais, M. (2019). Team topologies: organizing business and technology teams for fast flow. It Revolution.
14. Steiner, I. D. (1972). Group process and productivity (Vol. 1). New York: Academic press.
15. Zia, A., Arshad, W., & Mahmood, W. (2018). Preference in using agile development with larger team size. International Journal of Advanced Computer Science and Applications, 9(7), 116–123.