Agile-менеджмент. Лидерство и управление командами

Это означает, что коммуникация человека является функцией личности и внешней среды. А если мы будем говорить о группе людей, имея при этом в виду, что численность команды будет в том числе и вопросом коммуникаций, то уравнение примет такой вид:

S =f’’({P},E).

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

Другими словами, S (численность команды) может принимать любые значения! Для лунной программы «Аполлон-11» оптимальная численность команды составляла три человека. В регби играют команды по пятнадцать человек. Очевидным образом, оптимальная численность зависит от проекта, людей и внешней среды. И тем не менее статистически оптимальная численность команд может составлять пять человек. Можно обозначить это в виде интервала от трех до семи. Ну или на языке разработчиков как «пять плюс-минус два». При этом оптимальная численность, к счастью, не дотягивает до восьми (рис. 13.3).

Так что мы из всего этого узнали?

Моя рекомендация – не навязывать одну конкретную численность команды в качестве предпочтительной; при этом неплохо заранее ввести несколько ограничений. Например, скажите своим сотрудникам, что не разрешается создавать команды, насчитывающие более двадцати человек, и одновременно посоветуйте им ограничиться численностью пять плюс-минус два человека на одну команду. Затем пусть самоорганизация сделает свое дело и люди сами определят (в реальной операционной среде), какая численность для них оптимальна. Они хотят вместо одной команды из семи человек создать две по три и четыре человека? Почему бы и нет? Они хотят объединиться в одну команду из пятнадцати человек? Прекрасно, пусть сами убедятся, будет ли это работать. Только предупредите, что им может понадобиться все переосмыслить, когда обстановка или набор людей в команде изменится. И последний совет: будьте готовы вмешаться, если они хотят организовать команду из восьми человек (плюс-минус ноль).

Функциональные и кросс-функциональные команды

Независимо от того, создается ли команда менеджером или путем самоорганизации, необходимо ответить на важный вопрос: «Каким именно образом люди должны быть собраны в команды?» Фактически здесь есть два варианта: объединять людей по функциональному признаку или по бизнесу.

Первый вариант предполагает, что вы собираете разработчиков вместе с разработчиками, тестировщиков вместе с тестировщиками, а проектных менеджеров вместе с другими проектными менеджерами. Такие группы называются функциональными подразделениями, а основная мотивация этого способа организации – эффективность и возможности взаимного обучения в рамках данной функции [Larman, Vodde 2009: 243]. Сотрудникам, ответственным за пользовательские истории, легче всего научиться профессии, когда они входят в состав отдела, который может так и называться: «Отдел пользовательских историй».

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

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

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

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