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

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

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

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

Превратите каждую команду в небольшую бизнес-единицу, создающую ценность

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

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

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

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