Зачем нужна матрица

Классическая иерархия проста: один начальник, одна цепочка подчинения. Проблема в том, что компании редко работают по одному проекту. Разработчик участвует в трёх продуктах. Маркетолог ведёт четыре кампании. Финансист обслуживает пять бизнес-юнитов.

Матричная структура возникла как ответ на эту реальность. Джей Гэлбрейт описал её в 1970-х: когда задачи требуют экспертизы из разных функций, нужны «латеральные связи» — горизонтальные механизмы координации поверх вертикальной иерархии.

Суть матрицы: сотрудник одновременно принадлежит функциональному подразделению (откуда его экспертиза) и проектной команде (где эта экспертиза применяется). Два руководителя, две линии отчётности, два набора приоритетов.

Три типа матрицы: слабая, сбалансированная, сильная

Не все матрицы одинаковы. Разница — в балансе власти между функциональным руководителем и руководителем проекта.

Слабая матрица. Власть остаётся у функционального руководителя. Проектный менеджер — скорее координатор: он просит ресурсы, но не распоряжается ими. Часто его называют «проектным координатором» или «планировщиком». Подходит, когда проекты небольшие и не требуют выделенных людей.

Сбалансированная матрица. Функциональный руководитель и проектный менеджер делят власть примерно поровну. Один отвечает за «как делать» (методы, стандарты, развитие людей), другой — за «что и когда» (скоуп, сроки, приоритеты). Самый частый и самый конфликтный тип.

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

Две роли: лид этапа и руководитель проекта

Матрица работает, когда каждый понимает, за что отвечает. Две ключевые роли:

Руководитель проекта (РП) — владеет результатом целиком. Его зона: скоуп, сроки, бюджет, риски, коммуникация с заказчиком. Он не обязан быть экспертом в каждой области — его задача оркестрировать работу специалистов.

Лид этапа (функциональный лид) — владеет качеством работы своей функции. Дизайн-лид отвечает за качество дизайна, тех-лид — за архитектуру, QA-лид — за покрытие тестами. Он решает «как делать» внутри своей зоны.

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