Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В этой статье я хочу поделится небольшим опытом касательно построения команд в ИТ-проектах. Поговорить я хочу о такой не всегда очевидной вещи как «Пирамида зрелости команды».
Этот индикатор не является строгим научным термином и не имеет точных формул расчета, но его принцип хорошо сформулирован в самом названии.
Типичная команда в средних и больших проектах состоит из различных участников: менеджер проекта, бизнес аналитики, разработчики, тестировщики и ops-инженеры. В каждом направлении обычно есть лиды — ведущие сотрудники по направлению, например ведущий инженер разработки, ведущий инженер-тестировщик и тд.
Если изобразить структуру такой команды в виде пирамиды с отображением опытности сотрудников и их влиянием на принятие решений, то мы получим вот такую пирамиду:
У нас получилась эдакая «пирамида Маслоу для команды». Но не стоит забывать, что на ИТ-проектах не бывает просто инженеров. Например разработчики могут делится на Junior/Middle/Senior и бог весть еще как в зависимости от опыта работы и знаний(или от фантазии работодателя).
Бывает, что человек имеет негромкий тайтл, но по опыту и знаниям этот человек способен выполнять роль Solution Architect(но в силу обстоятельств не выполняет эту роль). Очевидно, что такие люди оказывают влияние на принятие решений внутри команды, даже не занимая формальных должностей в рамках проекта. И таких людей нужно поднять на вторую ступеньку в нашей пирамиде. Важно, чтобы людей на втором уровне не было больше, чем на третьем.
Можно присвоить каждому члену команды определенное количество «манны» в зависимости от опыта и влияния на принятие решений. Например рядовые члены команды получат 1 pt, лиды и менеджеры 2 pts.
Представим что у нас команда из 15 человек, тогда типичная пирамида будет считаться как-то вот так:
И у нас получается вот такая пирамида:
Хорошо, скажете вы, у нас на проекте именно так или не совсем так и у нас все хорошо. А какой от этого практический результат?
Оценка команды с помощью такого метода позволяет понять две вещи: насколько управляема (устойчива) существующая команда и как не странно насколько всем комфортно работать в такой команде.
На самом деле важнее, что происходит когда пирамида зрелости команды становится перевернутой. Или когда становится плоской, параллелепипедом или чем-нибудь еще. И это очень плохой сценарий.
Правильная пирамида очень устойчива, а перевернутая — нет. Можно вспомнить коварный эксперимент с колонией «Белый лебедь» где сидели одни криминальные авторитеты и чем это для них закончилось.
А если не отклонятся от ИТ-сферы, то можно представить себе две реальные ситуации:
1) Эффективному менеджеру проекта предлагают сделать дешево и сердито — нанять 30 «индусов» и запилить проект за месяц вместо полугода;
2) Очень важный заказчик режет на собеседованиях всех инженеров кроме имеющих тайтлы Senior или Lead;
В первом случае мы получим «кирпич» вместо пирамиды и явно неуправляемый проект с печальным финалом.
Во-втором случае мы получим ту самую колонию «Белый Лебедь» на проекте. Это когда собираются в одной комнате уважаемые и опытные люди и за два часа не могут прийти к простому решению. Просто потому, что они все опытные и клевые, каждый из них хочет высказаться и считает, что его идея сама хорошая. Толку от таких разговоров обычно очень мало. Кроме того, непонятно кто должен «поднять мыло», ой, то есть, кто должен пилить эту фичу?
В моей карьере были проекты с таким набором людей в командах и я честно скажу, работать и в первом и во втором варианте очень не комфортно. Как менеджеру, так и рядовому сотруднику. Когда в команде слишком много умных людей, она глупеет. Пирамида становится неустойчивой и зачастую «падает» придавливая неосторожных.
На самом деле все просто, на ИТ-проекте должно быть достаточно инженеров которые делают работу, наносят пользу и не задают вопросов. Без достаточного количества таких людей у проекта просто не хватает «лошадиных сил» и он не выруливает в счастливое будущее.
Обратная ситуация- это когда у вас слишком много «лошадиных сил» и мало контроля, тогда ваш гоночный болид просто разобьется о первый забор.
Идеальное количество людей в ИТ-команде 5-15 человек. Товарищ Безос из Amazon сформировал это как принцип “Two Pizza team”. Дальнейший рост числа людей усложняет коммуникацию внутри команды и уже не имеет мультипликативного эффекта.
Идеальное распределение членов команды по зрелости — на одного лида от 2-х до 5-ти инженеров среднего уровня. Если мы говорим про Junior инженеров или про Василиев — то таковых не должно быть больше 1-2 на лида(или на человека, который за них отвечает). Просто потому что он физически не сможет уделять внимание большему количеству людей. Элементарное Code Review для 5 человек уже может занимать половину рабочего времени. Кроме того у лидов еще есть всякие митинги с другими командами и заказчиком, поэтому он не может выполнять работу 100% времени как обычный инженер.
Т.е. можно сказать, что внутри пирамиды зрелости команды, мы должны строить небольшие пирамиды из отдельных под-команд для дополнительной устойчивости.
Что касается верхнего уровня пирамиды — не так важно сколько у вас человек на самом верху, если у вас адекватные 2 нижних уровня — они вынесут весь проект. Пирамида в большинстве случаев будет не идеальной, но это не страшно. Главное иметь достаточное количество людей снизу.
Не стоит учитывать в пирамиде супервайзоров — т.е. людей которые ведут целое направление и просто контролируют процесс на нескольких проектах не вмешиваясь в управление.
Product Owner в соответствии с Agile является частью команды, но не должен вмешиваться в процесс управления. Если он начинает заниматься микро-менеджментом или у вас появляется сразу 5 Product Owners, то у вас большие проблемы. Но это уже вопросы грамотного управления проектами и отношений с заказчиком. Если вы попали в эту ловушку, то перевернутая пирамида — это уже самая маленькая ваша проблема.
Другой момент — это когда на проекте собирается слишком много желающих поруководить, и вы как единственный человек который работает, вспоминаете произведение Салтыкова-Щедрина «Как один мужик двух генералов прокормил». Или вот эту историю. Но такую ситуацию легко предсказать воспользовавшись «пирамидой зрелости команды» и не идти на такой проект.
В грамотной компании такие вещи, как состав команды, должны планироваться еще на этапе продажи проекта. Затем подбирают менеджера проекта, который сформирует костяк команды из лидов и с их помощью строит пирамиды, пилит проекты и захватывает галактики.
Этот индикатор не является строгим научным термином и не имеет точных формул расчета, но его принцип хорошо сформулирован в самом названии.
Типичная команда в средних и больших проектах состоит из различных участников: менеджер проекта, бизнес аналитики, разработчики, тестировщики и ops-инженеры. В каждом направлении обычно есть лиды — ведущие сотрудники по направлению, например ведущий инженер разработки, ведущий инженер-тестировщик и тд.
Если изобразить структуру такой команды в виде пирамиды с отображением опытности сотрудников и их влиянием на принятие решений, то мы получим вот такую пирамиду:
У нас получилась эдакая «пирамида Маслоу для команды». Но не стоит забывать, что на ИТ-проектах не бывает просто инженеров. Например разработчики могут делится на Junior/Middle/Senior и бог весть еще как в зависимости от опыта работы и знаний(или от фантазии работодателя).
Бывает, что человек имеет негромкий тайтл, но по опыту и знаниям этот человек способен выполнять роль Solution Architect(но в силу обстоятельств не выполняет эту роль). Очевидно, что такие люди оказывают влияние на принятие решений внутри команды, даже не занимая формальных должностей в рамках проекта. И таких людей нужно поднять на вторую ступеньку в нашей пирамиде. Важно, чтобы людей на втором уровне не было больше, чем на третьем.
Можно присвоить каждому члену команды определенное количество «манны» в зависимости от опыта и влияния на принятие решений. Например рядовые члены команды получат 1 pt, лиды и менеджеры 2 pts.
Представим что у нас команда из 15 человек, тогда типичная пирамида будет считаться как-то вот так:
1 уровень:
Project Manager + Technical Lead = 4 pts
2 уровень:
2x Stream Leads + 2x Senior Engineer = 8 pts
3 уровень:
9x Middle and Junuor Engineers = 9 ptsИ у нас получается вот такая пирамида:
Хорошо, скажете вы, у нас на проекте именно так или не совсем так и у нас все хорошо. А какой от этого практический результат?
Оценка команды с помощью такого метода позволяет понять две вещи: насколько управляема (устойчива) существующая команда и как не странно насколько всем комфортно работать в такой команде.
На самом деле важнее, что происходит когда пирамида зрелости команды становится перевернутой. Или когда становится плоской, параллелепипедом или чем-нибудь еще. И это очень плохой сценарий.
Правильная пирамида очень устойчива, а перевернутая — нет. Можно вспомнить коварный эксперимент с колонией «Белый лебедь» где сидели одни криминальные авторитеты и чем это для них закончилось.
А если не отклонятся от ИТ-сферы, то можно представить себе две реальные ситуации:
1) Эффективному менеджеру проекта предлагают сделать дешево и сердито — нанять 30 «индусов» и запилить проект за месяц вместо полугода;
2) Очень важный заказчик режет на собеседованиях всех инженеров кроме имеющих тайтлы Senior или Lead;
В первом случае мы получим «кирпич» вместо пирамиды и явно неуправляемый проект с печальным финалом.
Во-втором случае мы получим ту самую колонию «Белый Лебедь» на проекте. Это когда собираются в одной комнате уважаемые и опытные люди и за два часа не могут прийти к простому решению. Просто потому, что они все опытные и клевые, каждый из них хочет высказаться и считает, что его идея сама хорошая. Толку от таких разговоров обычно очень мало. Кроме того, непонятно кто должен «поднять мыло», ой, то есть, кто должен пилить эту фичу?
В моей карьере были проекты с таким набором людей в командах и я честно скажу, работать и в первом и во втором варианте очень не комфортно. Как менеджеру, так и рядовому сотруднику. Когда в команде слишком много умных людей, она глупеет. Пирамида становится неустойчивой и зачастую «падает» придавливая неосторожных.
На самом деле все просто, на ИТ-проекте должно быть достаточно инженеров которые делают работу, наносят пользу и не задают вопросов. Без достаточного количества таких людей у проекта просто не хватает «лошадиных сил» и он не выруливает в счастливое будущее.
Обратная ситуация- это когда у вас слишком много «лошадиных сил» и мало контроля, тогда ваш гоночный болид просто разобьется о первый забор.
Идеальное количество людей в ИТ-команде 5-15 человек. Товарищ Безос из Amazon сформировал это как принцип “Two Pizza team”. Дальнейший рост числа людей усложняет коммуникацию внутри команды и уже не имеет мультипликативного эффекта.
Идеальное распределение членов команды по зрелости — на одного лида от 2-х до 5-ти инженеров среднего уровня. Если мы говорим про Junior инженеров или про Василиев — то таковых не должно быть больше 1-2 на лида(или на человека, который за них отвечает). Просто потому что он физически не сможет уделять внимание большему количеству людей. Элементарное Code Review для 5 человек уже может занимать половину рабочего времени. Кроме того у лидов еще есть всякие митинги с другими командами и заказчиком, поэтому он не может выполнять работу 100% времени как обычный инженер.
Т.е. можно сказать, что внутри пирамиды зрелости команды, мы должны строить небольшие пирамиды из отдельных под-команд для дополнительной устойчивости.
Что касается верхнего уровня пирамиды — не так важно сколько у вас человек на самом верху, если у вас адекватные 2 нижних уровня — они вынесут весь проект. Пирамида в большинстве случаев будет не идеальной, но это не страшно. Главное иметь достаточное количество людей снизу.
Не стоит учитывать в пирамиде супервайзоров — т.е. людей которые ведут целое направление и просто контролируют процесс на нескольких проектах не вмешиваясь в управление.
Product Owner в соответствии с Agile является частью команды, но не должен вмешиваться в процесс управления. Если он начинает заниматься микро-менеджментом или у вас появляется сразу 5 Product Owners, то у вас большие проблемы. Но это уже вопросы грамотного управления проектами и отношений с заказчиком. Если вы попали в эту ловушку, то перевернутая пирамида — это уже самая маленькая ваша проблема.
Другой момент — это когда на проекте собирается слишком много желающих поруководить, и вы как единственный человек который работает, вспоминаете произведение Салтыкова-Щедрина «Как один мужик двух генералов прокормил». Или вот эту историю. Но такую ситуацию легко предсказать воспользовавшись «пирамидой зрелости команды» и не идти на такой проект.
В грамотной компании такие вещи, как состав команды, должны планироваться еще на этапе продажи проекта. Затем подбирают менеджера проекта, который сформирует костяк команды из лидов и с их помощью строит пирамиды, пилит проекты и захватывает галактики.
