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

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

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

Самое главное – чтобы функциональные и кросс-функциональные команды воспринимали себя в качестве бизнес-единиц, создающих ценность для своих клиентов независимо от того, внешние это клиенты или внутренние. Наша команда системных администраторов считала себя бизнес-подразделением, задача которого состоит в обслуживании клиентов и создании для них определенной ценности. Поэтому они нам так нравились. Они давали нам понять, что мы важны для них в качестве клиентов, независимо от того, сколько раз у нас падают операционные системы или серверы. Функциональные и кросс-функциональные команды должны управляться как небольшие бизнес-подразделения. Тогда они действительно становятся фрактальными группами, и их число в организации может быть неограниченным [Leffingwell 2007: 96].

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

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

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