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

Но… при этом необходимо учитывать пять важных факторов:

• Во-первых, когда какая-то работа (например, проектный менеджмент, создание архитектуры или дизайн графических пользовательских интерфейсов) передается отдельным функциональным командам, должен быть создан механизм коммуникации между кросс-функциональными командами и данной функциональной командой [Leffingwell 2007: 108]. В качестве такого механизма можно предложить регулярное участие представителя функциональной команды в стендапах проектной команды и/или назначение представителя от кросс-функциональной команды, который будет отвечать за коммуникацию с командой специалистов. Есть много вариантов обеспечить беспроблемную коммуникацию между кросс-функциональными командами и командами-специалистами.

• Во-вторых, люди, которых переводят в функциональную команду, должны воспринимать себя частью бизнес-подразделения, создающего ценность для клиентов; системные администраторы должны обслуживать проектные команды, а не контролировать их. Команды-специалисты должны считать проектные команды своими клиентами, а не подчиненными и организовывать свои рабочие процессы исходя из этого представления. Они продают свои услуги коллегам из других команд точно так же, как я пытаюсь продать вам свои диссидентские взгляды. (Все-таки хорошо, что вам пришлось купить эту книгу до того , как вы дочитали до этого места.)

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

• В-четвертых, мы знаем, что объем коммуникации, осуществляемой в сложных системах, остается более или менее постоянным независимо от того, как эта система себя организует. Следовательно, задача команд и их менеджеров – выяснить, каким количеством контактных точек они в состоянии эффективно управлять. Слишком малое или слишком большое количество таких точек снижает адаптивность компании.

• В-пятых, команда-специалист бывает виртуальной. Может оказаться достаточным время от времени собирать вместе специалистов по интерактивному веб-дизайну и давать им возможность согласовывать общие стандарты и подходы для применения кросс-функциональными командами, в состав которых они входят. Такие виртуальные команды называются сообществами практикующих или сообществами экспертов.Они представляют собой неплохой компромисс, позволяющий сочетать кросс-функциональные команды с необходимостью координации между специалистами [Augustine 2009: 71–73], [Larman, Vodde 2009: 252/253]. (Примечание: некоторые организации с теми же целями поддерживают центры передового опыта, хотя такие центры обычно имеют более формальный характер.)

Возможной или даже предпочтительной будет ситуация, когда функциональная команда возникает в результате самоорганизации. Команды-специалисты могут формироваться органически с целью решить общую для нескольких команд проблему. Например, возможно объединение в одну команду специалистов по непрерывной интеграции, чтобы на более высоком профессиональном уровне оказывать соответствующие услуги другим командам. Члены проектных команд могут входить в функциональную команду на условиях полной или частичной занятости, также возможна их ротация [Highsmith 2009: 272/280]. Могут создаваться команды, отвечающие за отдельные компоненты, – например, команда будет специализироваться на разработке архитектуры ПО и передавать готовую архитектуру проектным командам. В этом случае проектные команды выступают по отношению к ней в роли заказчиков [Cohn 2009: 185]. Главная причина формирования команд специалистов – повышение эффективности (в результате разделения труда).

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