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

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

В случае функциональных команд необходима координация между ними при реализации проектов, направленных на создание бизнес-ценности для клиентов. В то же время необходимость в координации между кросс-функциональными командами возникает в случаях, когда нужно распространить на них лучшие практики и одинаковые стандарты, урегулировать вопросы, связанные с использованием общих ресурсов, привести к общему знаменателю какие-то виды деятельности. Поэтому возникает вопрос: « Как именно должна осуществляться такая координация между командами?»

В предыдущем разделе мы видели, что у вас есть две возможности организовать координацию: применить либо первый, либо второй принцип организационного дизайна. Оба подходят как функциональным, так и кросс-функциональным командам. Возможные комбинации типов команд и организационных принципов дают четыре организационных стиля, показанных в табл. 13.1 и на рис. 13.7.

В целом кросс-функциональные команды работают лучше, чем функциональные, а второй принцип организационного дизайна удачнее первого. По этим причинам многие консультанты по Agile-методологиям предпочитают организационный стиль № 4. Но, как всегда, все зависит от контекста. Вам может потребоваться выбрать одну из двух других разумных альтернатив, представленных организационными стилями № 2 или № 3, – либо потому, что этого требует недостаточная зрелость команд или порядок коммуникаций, либо для того, чтобы осуществить постепенный переход от организационного стиля № 1 к № 4 (рис. 13.7).

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

Кросс-функциональные команды без координации со стороны менеджеров – отличная идея. Но они могут как решать, так и создавать проблемы. Хорошие менеджеры должны быть в состоянии самостоятельно выбирать оптимальный организационный стиль, который обеспечит как адаптивность, так и безопасность.

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

Часто утверждают, что кросс-функциональные команды помогают избежать проблемы локальной оптимизации. Имеется в виду тенденция функциональных команд оптимизировать свою собственную эффективность, снижая при этом эффективность бизнеса в целом. Например, команда тестировщиков реализовала серьезную оптимизацию процедур, до минимума сократив время тестирования продуктов. Эта «эффективная» практика может иметь серьезные последствия для других фаз проекта, например связанных с разработкой продукта и его технической поддержкой после релиза. Но действительно ли эта проблема возникает из-за того, что команда тестировщиков организована по функциональному признаку? Или дело просто в том, что тестировщики не рассматривают разработчиков и специалистов по технической поддержке в качестве своих клиентов?