В этой аналогии участками будут самоорганизующиеся команды, а не управляемые подразделения. Их повышенная адаптивность (второй принцип организационного дизайна) в сравнении с участками, организованными согласно иерархическому менеджменту (в соответствии с первым принципом), напрямую вытекает из органического подхода к решению проблем. Каждая из команд пытается решить часть более крупной проблемы. Но из-за связанности команд решение, найденное одной командой, привносит изменения в проблему, решением которой занимаются соседние команды. Адаптивные действия соседних команд в свою очередь изменяют проблемы, решаемые остальными командами. В конечном итоге мы получаем экосистему, в которой команды (или участки) совместно занимаются решением одной крупной проблемы [Kauffman 1995: 252].

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

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

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

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

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

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

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

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

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

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

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