Источник
Людей в команде стало больше в 2 раза...
Пост про сублинейное масштабирование команд и причины, почему рост headcount не равен росту результата.
Источник
Людей в команде стало больше в 2 раза...
Пост про сублинейное масштабирование команд и причины, почему рост headcount не равен росту результата.
Рубрика #Management
Удвоение команды почти никогда не дает удвоение результата. На масштабе начинают доминировать эффекты убывающей полезности, онбординга, коммуникационных издержек и последовательной части работы.
Почему масштабирование становится сублинейным
Убывающая предельная полезность
Каждый следующий инженер добавляет меньше чистого эффекта, чем предыдущий.
Первые люди закрывают критичные задачи и создают базовую траекторию продукта. По мере роста команды добавляются все более периферийные задачи, и вклад становится сублинейным.
Онбординг и групповая динамика
Расширение команды временно снижает throughput, даже если найм качественный.
Новым людям нужен контекст, а сильные инженеры переключаются на менторинг и синхронизацию. Команда может откатываться в стадию storming и терять часть прежней скорости.
Стоимость коммуникаций
Связи между людьми растут быстрее, чем численность.
Если каждый взаимодействует со всеми, число коммуникационных связей = n*(n-1)/2. При росте N координационные издержки растут квадратично и съедают часть эффекта от найма.
Ограничения параллелизации
Не все части работы можно распараллелить.
Планирование, архитектурные стыки, узкие места в коде и часть операционных ритуалов остаются последовательными. Это ограничение хорошо описывает закон Амдала.
Коммуникации растут по формуле n*(n-1)/2
Даже без учета качества коммуникации, только количество потенциальных связей растет быстрее, чем размер команды. Это напрямую влияет на синхронизацию, скорость решений и контекстные переключения.
Размер команды
4
Связей
6
Размер команды
6
Связей
15
Размер команды
8
Связей
28
Размер команды
10
Связей
45
Размер команды
12
Связей
66
Ограничение закона Амдала на простом примере
Если 30% работы неизбежно последовательны (планирование, архитектурные стыки, координация), то предельный выигрыш ограничен. Ниже пример теоретического ускорения при росте команды:
Инженеров
2
Теоретический speedup
~1.54x
Инженеров
4
Теоретический speedup
~2.11x
Инженеров
8
Теоретический speedup
~2.58x
Инженеров
16
Теоретический speedup
~2.91x
Вывод: даже при росте до 16 человек ускорение остается далеко от 16x. Поэтому оргдизайн и архитектура важнее «добавим людей и поедем быстрее».
Типичные антипаттерны
Считать, что удвоение headcount автоматически дает 2x value delivery.
Добавлять людей в уже перегруженный контекст без redesign ролей и интерфейсов команд.
Игнорировать стоимость коммуникаций и продолжать модель "все общаются со всеми" даже при росте команды.
Пытаться ускорить bottleneck-задачи количеством людей вместо устранения архитектурных узких мест.
Оценивать эффект найма только по количеству задач, не считая lead time и outcome-метрики.
Практические рекомендации
Перед наймом проверьте, какая часть работы реально параллелизуется, а какая останется последовательной.
Делите большую команду на автономные контуры с явными API взаимодействия и зонами ответственности.
Заранее планируйте онбординг как инвестицию: capacity на менторинг, документацию и shadowing.
Уменьшайте связность коммуникаций через архитектурные и процессные границы, а не через встречи "на всех".
Смотрите на системные метрики потока: lead time, WIP, предсказуемость релизов и долю rework.
Для реально сложных проблем собирайте сильное ядро (центр кристаллизации), а не просто наращивайте численность.
Ключевой вывод
Масштабирование команды работает только вместе с масштабированием системы: структуры взаимодействия, архитектурных границ, качества онбординга и управленческих ритуалов. Без этого добавление людей дает убывающую отдачу.
Источники и связанные главы
Внешние ссылки
- book_cube: «Людей в команде стало больше в 2 раза, а результаты в 2 раза не увеличились»
- Предельная полезность
- Стадии развития группы по Такмену
- Полный граф и формула связей
- Закон Амдала
- How Technical Problems Cause Organizational Friction
- Code of Leadership: выпуск про Team Topologies и автономные команды
Связанные главы