Матричная структура без борьбы за сотрудников: Станислав Андреев, COO SharksCode, о распределении полномочий

Кто принимает решения в такой ситуации, как согласовывать нагрузку и почему регламент сам по себе не поможет — объясняет COO SharksCode Станислав Андреев.

В какой момент матричное управление начинает мешать работе?

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

Какие решения следует возложить на руководителя проекта, а какие — на функционального руководителя?

Руководитель проекта отвечает за цели, приоритеты и сроки реализации конкретного продукта. Функциональный руководитель — за компетенции, профессиональные стандарты и развитие специалистов. Но этого разделения недостаточно. Есть решения, которые затрагивают обе стороны: кого привлечь к новому проекту, отложить ли техническое усовершенствование ради релиза, как перераспределить людей между командами. Здесь нужно заранее определить порядок согласования и лицо, которое примет решение, если договориться не удалось.

Что делать сотруднику, если два менеджера поставили несовместимые задачи?

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

Как закрепить правила без обширного регламента?

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

Как предотвратить скрытую перегрузку специалистов?

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

Кто должен оценивать результаты и принимать кадровые решения?

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

По каким признакам можно понять, что модель нуждается в изменениях?

Я бы обратил внимание на повторяющиеся обострения конфликтов, противоречивые приоритеты и рабочую нагрузку, которая систематически превышает возможности команды. Еще один сигнал — сотрудники не могут объяснить, кто утверждает важные для них решения. Когда такие ситуации повторяются, компании стоит проверить распределение полномочий и качество совместного планирования. Добавлять ещё один уровень согласования наугад — рискованный путь: он может только затянуть процесс принятия решений.

Нужна ли матрица всем компаниям?

Её целесообразность определяется характером работы. Если сотрудники постоянно переключаются между продуктами, а специализации необходимо развивать централизованно, матричная модель может оказаться полезной. Если команда небольшая и все решения проходят через нескольких человек, дополнительная структура порой лишь затрудняет взаимодействие. Я бы начал с ответа на два вопроса: какие проблемы компания хочет решить с помощью матрицы и готовы ли руководители договариваться об общих ресурсах до возникновения конфликта.