Создавайте отдельные команды для решения однотипных задач

Если ты не официальный сторонник какой-либо методологии и не участвуешь ни в каких ассоциациях, альянсах и консорциумах, то можно позволить себе еретические высказывания. Самое худшее, что с тобой могут сделать, — это подвергнуть метафорическому сожжению на какой-нибудь индустриальной конференции. Именно поэтому я пользуюсь огнеустойчивым гелем для волос. Но я заметил, что еретические идеи пользуются спросом. Будучи твердым сторонником рыночных подходов, я люблю использовать малейшие возможности для высказывания диссидентских идей вроде тех, что изложены ниже.

Я считаю, что иногда целесообразнее поручать работу, требующую однотипных профессиональных знаний, отдельным функциональным командам, которые состоят из соответствующих специалистов. Этот подход может оказаться необходимым для проектного менеджмента, разработки отдельных компонентов архитектуры, дизайна пользовательских интерфейсов, конструирования оборудования, тестирования или какой-либо другой работы, выходящей за рамки стандартных видов деятельности в границах проектов. Это идет вразрез с «принятым» в Agile-сообществе способом мышления, выразителями которого стали авторитетнейшие специалисты, полагающие что кросс-функциональные команды эффективнее справляются с любыми видами работ — от создания пользовательских историй до бинарной сборки. Хороший пример — Scrum Of Scrums. Он предусматривает участие представителя каждой команды в ежедневных Scrum-совещаниях, а затем эти представители осуществляют координацию между командами. Такие же рекомендации высказывались в отношении Scrum-мастеров, технических лидов, дизайнеров пользовательских интерфейсов и ведущих тестировщиков.

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

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

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

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

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

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