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

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

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

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

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

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

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

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

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