Людей в команде стало больше в 2 раза, а результаты в 2 раза не увеличились (Рубрика Management)

Вчера в офисе беседовал со своим коллегой на эту тему. Он раньше руководил несколькими командами, а теперь как staff engineer работает над вопросами архитектуры и проектирования. Коллега отметил насчет одной из команд, с которыми раньше он много взаимодействовал, что она значительно увеличилась, а результат увеличился не соразмерно. И дальше мы ушли в обсуждение причин такого эффекта, которые я объясняю следующими факторами

1. Убывающая предельная полезность - по мере добавления инженеров в команду их предельная полезность уменьшается. Суть в том, что добавление первого инженера позволяет начать развивать продукт, решая самые приоритетные задачи. Добавление второго инженера позволяет уделить время важным задачам, а добавление условно седьмого инженера позволяет заняться nice to have фичами. Примерно тоже самое наблюдается и в жизни, условно, когда вы страдаете от жажды в пустыне - первый стакан воды вам просто необходим и вы готовы за него заплатить много денег, второй полезен и вы все еще готовы платить, а условно десятый стакан для вас уже не несет пользы и платить за него вы не готовы:) 2. Групповая динамика отношений и онбординг новых людей - при добавлении новых людей в команду их требуется обучить и вписать в общую динамику группы (модель Такмана). На онбординге мы тратим время самих онбордящихся, а также сильных людей из команд. Кроме того, перформящая по Такману команда может проваливаться в стадию storming, где бурлят обсуждения и команда работает менее эффективно, чем до этого 3. Стоимость коммуникаций - даже если человек уже заонбордился, а динамика команды вернулась в норму, то у нас все равно остаются затраты на коммуникации. Если у нас в команде все общаются со всеми, то у нас получается полный граф, где количество связей равно n*(n-1)/2. Каждую связь требуется поддерживать, поэтому накладные расходы на коммуникации растут квадратично с ростом команды. Отсюда у нас получаются ограничения вида two-pizza team 4. Проблемы с параллелизацией работы - тут нам нужно вспомнить закон Амдала

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

А значит что парараллелизация работы внутри команды не позволяет линейно масштабироваться с увеличением количества человек, так как у нас есть часть работы, которую мы должны делать последовательно (планнинг, ретро, часть архитектурной работы, работа над местами с bottleneck в коде, про что рассказывалось в докладе "How Technical Problems Cause Organizational Friction", о котором я упоминал вчера). Кстати, именно поэтому все стремятся сделать автономные команды и топологию команд (можно почитать про team topologies или послушать первую серию подкаста Code of Leadership).

Если подводить итоги, то эти факторы приводят к тому, что масштабируя команды мы получаем сублинейное масштабирование эффекта. Причем если процессы на уровне компании выстроены совсем печально, то сублинейное время скорее похоже на ассимптотику log(N), где N - это количество людей🙂 В общем, в лоб решить задачу, закидав ее людьми не получится.

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

#Management #Leadership #Processes #Team #Software #SoftwareArchitecture