Размышления о матричной структуре

В большой организации матричная структура кажется неизбежной. С одной стороны, при наёме сотрудников необходимо убедиться в их компетентности. Лучше всего оценить компетентность Java-разработчика может другой Java-разработчик. Это подталкивает объединить людей с одной компетенцией в группу, чтобы внутри неё распределить нагрузку по оценке кандидатов. С другой стороны, совместная работа над продуктом требует наличия общих соглашений, например, об именовании переменных и классов, или гайдлайнов по дизайну. Это существенно упрощает совместное владение кодом и создание единообразного клиентского опыта. Так группы, объединенные вокруг компетенций, получают ещё и право определять стандарты в своей области. И, наконец, организация заинтересована в том, чтобы опытные сотрудники помогали развиваться менее опытным. Так у этих групп появляется ещё и задача организовать обмен знаниями. Поздравляю, вы только что создали матрицу из продуктовых команд и центров компетенций.

Сторонники agile подходов относятся к матричной структуре негативно. Со временем центры компетенций обрастают процессами и правилами, а для их поддержания – дополнительными ролями, делая компанию неповоротливой. К тому же центры компетенций, стремясь достичь поставленных перед ними целей, ставят цели своим сотрудникам, так что у последних оказывается не одна, а две цели в каждый момент времени. Чтобы как-то обеспечить непротиворечивость этих целей, создаются дополнительные процессы и роли, что усиливает проблему неповоротливости. К тому же, имея несколько целей, разработчики неизбежно сталкиваются с внутренним конфликтом, что негативно сказывается на результатах. Эта проблема известна со времён Иисуса: “Никто не может служить двум господам: ибо или одного будет ненавидеть, а другого любить; или одному станет усердствовать, а о другом нерадеть.” (Мф 6:24)

Получается, что матричная структура, решая одни проблемы, порождает другие. Широкая распространенность матричных структур предполагает, что преимущества перевешивают недостатки, иначе эта практика должна была бы себя изжить. Вполне возможно и то, что матричная структура – один из “организационных вирусов”, о которых говорит Фреек Вермюлен – управленческая практика, дающая краткосрочные выгоды, но в долгосрочной перспективе наносящая вред организации. Оставив вопрос классификации этой практики за рамками данной статьи, рассмотрим вопрос “Можно ли устранить, или хотя бы сгладить недостатки матрицы, сохранив при этом те преимущества, которые она даёт”?

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

Как при этом сохранить преимущества, о которых говорилось в начале статьи? Через установку центрами компетенций ограничений. Образно говоря, вместо того, чтобы определять, куда следует идти, центра компетенций будет определять допустимые параметры движения: каждый час 15-минутный привал, не идти через болота, не нагружать рюкзаки сверх меры и, например, каждый день уделять полчаса обслуживанию снаряжения. А цель движения будет задавать бизнес.

Чтобы эта схема заработала, важно чтобы все участники принимали правила игры. Бизнес должен понимать суть и причины ограничений, вводимых центрами компетенций. Центры компетенций должны понимать цели бизнеса и влияние ограничений на достижение этих целей. То есть потребность в коммуникациях между центрами компетенций и бизнесом не исчезает. При этом коммуникации становятся проще за счёт более четкого разделения ответственности. Бизнес отвечает за продуктовые цели, центры компетенций – за критерии качества продукта. Это, по сути, повторяет разделение зон ответственности в Скраме. Владелец Продукта отвечает за продукт, Разработчики – за способ реализации, в том числе за качество. И именно так устроены способы масштабирования, популярные в agile среде, например, модель Spotify.