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

И наконец, важной темой будет жизненный цикл команд. Исследования показывают, что команды более эффективны, когда они достаточно долговечны. И не только при разработке ПО [Larman, Vodde 2009: 149/153], но и в других видах бизнеса, например в авиакомпаниях [Hackman 2002]. Так что лучше, чтобы команда существовала настолько долго, насколько это возможно, потому что для возникновения устойчивых правил и каналов связи требуется время. Оно также необходимо, чтобы люди как команда научились отличать, какая информация для них важна, а какая – нет. И еще подумайте вот о чем: какая поп-группа была самой знаменитой за всю историю? И как долго они были вместе? Больше, чем несколько лет? Я так и думал. Если ваши проекты по своей природе краткосрочны, постарайтесь сделать так, чтобы жизненные циклы команд были длиннее, чем жизненные циклы проектов. Так вы дадите одной и той же команде возможность выполнять несколько проектов один за другим.

Каков оптимальный размер команды? Это один из самых интересных вопросов, который обсуждается с того самого момента, когда люди впервые объединились и убили мамонта.

Однажды я участвовал в конференции, где одну из сессий проводил Джозеф Пелрайн, эксперт в области сложных социальных систем. Он сообщил нам, что в качестве оптимальной численности социальных групп в исследованиях упоминаются (или это так или иначе следует из содержания соответствующего исследования) группы, состоящие из 5, 15 и 150 человек.

В Agile-методологиях, ведущей из которых на момент написания этой книги стал Scrum, в качестве предпочтительной численности команд часто указывается «семь человек плюс-минус два» (разработчики предпочитают именно так обозначать диапазон от пяти до девяти человек).

Исследования оптимальной численности групп для принятия решений позволяют сделать вывод, что эффективными будут группы, насчитывающие менее двадцати человек [Buchanan 2009: 38–39]. Группы от двадцати человек и более вряд ли можно называть командами . Если численность превышает двадцать, такое сообщество людей следует называть просто группой. (Я пишу этот текст тайком во время Скандинавской конференции разработчиков ПО, в которой участвует 600 человек. Это группа, а не команда.)

В статье этого автора отдельно упоминаются восемь человек в качестве примера неудачной численности команды, поскольку в этом случае мнения часто разделяются поровну. В ней даже утверждается, что Карл I, единственный британский монарх, работавший с тайным советом, состоящим из восьми членов, принимал настолько плохие решения, что в конечном счете это стоило ему головы [Buchanan 2009: 39].

С учетом всех этих данных мы приходим к выводу, что есть только одна конфигурация, которая удовлетворяет всем условиям: в составе команды должно быть пятьчеловек.

Пять человек – один из трех вариантов оптимальной численности, упомянутых Джозефом Пелрайном. Эта численность также находится в диапазоне, рекомендуемом для Scrum-команд. Пять меньше двадцати и не равно восьми. Это число также приблизительно равно среднему значению 4,6, которое было определено как оптимальная численность команд в исследовании, проведенном профессором Ричардом Хэкменом [Hackman 2002: 116–122]. Но лучше всего, что это мое любимое число. Так что все правильно.

Пять – это ответ, который я даю по умолчанию, когда могу ответить на вопрос, не имея доступа к дополнительной информации. Видите ли, на самом деле я не могу сказать вам, какова оптимальная численность команды. Поэтому предлагаю вернуться к уравнению Курта Левина (мы обсуждали его в главе 10 «Искусство создавать правила»). Сейчас вы поймете почему.

B = f (P,E).

Как мы говорили ранее, это уравнение означает, что поведение человека является функцией личности и внешней среды . Поскольку коммуникация – это часть поведения, то уравнение можно переписать в следующем виде:

C = f’ (P,E).

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

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

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

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

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

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

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

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