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

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

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

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

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

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

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