Матричная команда: ответственность есть, ресурса нет

Человека назначили. Время забыли выделить

Сотрудника включили в проект. Основную работу никто не снял. Время не выделили. Срок поставили. Через две недели начинается разбор: почему не готово, где смотрел проектный менеджер и почему эксперт опять недоступен.

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

Это моя управленческая позиция. Дальше разберу, какие наблюдения поддерживают исследования, где нужны оговорки и как организовать работу без очередного слоя отчетности.

В матрице есть иерархия и несколько источников требований

Матричная команда объединяет специалистов разных подразделений. Функциональный руководитель отвечает за свою деятельность и людей, проектный руководитель координирует изменение. Их запросы могут конкурировать за время одного человека. Полномочия различаются в зависимости от устройства организации.

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

Исследование Ebbers и Wijnberg, опубликованное в 2017 году, рассматривает ролевой конфликт при двойном руководстве на примере кинопроектов. Оно показывает и риски, и возможность договориться о ролях гибче. Это полезная аналогия, но не доказательство, что любая матрица устроена одинаково.

Профильные знания помогают, но эксперт вправе возражать

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

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

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

Сколько проектов потянет менеджер

Количество проектов само по себе мало говорит о нагрузке. Несколько предсказуемых инициатив с самостоятельными владельцами направлений могут требовать меньше внимания, чем один проект с постоянно меняющимися требованиями.

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

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

Кто отвечает за неверные данные

У числа в отчете должен быть понятный источник и человек, который подтверждает его содержание. Для важного показателя нужны период, метод расчета и дата обновления. Если исходные данные предварительные, это должно быть видно до решения.

Руководитель проекта отвечает за согласованный порядок проверки и обязан реагировать на обнаруженное противоречие. Эксперт отвечает за проверку в своей области в пределах назначенной роли. Человек, принимающий решение, должен видеть существенные ограничения данных.

Фраза «мне так прислали» не объясняет, почему непроверенное число стало основанием для обязательства. Но заставлять менеджера заново выполнять работу каждого специалиста тоже бессмысленно. Глубину проверки выбирают по риску, а спорный факт возвращают владельцу с конкретным вопросом.

Пример: врач участвует в проекте, приём продолжается

Это учебный пример, не описание конкретного учреждения. Для согласования требований к системе проект рассчитывает на восемь часов врача в неделю. Врач продолжает вести прием, а его руководитель эти восемь часов не выделял. В трекере стоит пятница, в реальном расписании свободного времени нет.

На встрече выясняется, что в эту неделю доступны только два часа. Команда делит результат на части: сначала врач проверяет критичные требования, остальное переносится либо передается другому согласованному эксперту. Заказчик выбирает между сроком, объемом и дополнительным ресурсом.

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

Что дают RACI, журнал решений и ограничение незавершенной работы

RACI помогает обозначить исполнителя, ответственного за результат, консультируемых и информируемых участников. В практике PRACI добавляется роль участия. APM отдельно предлагает проверить, что указанные люди приняли свои роли. Заполненная таблица без этого согласия создает ложную определенность.

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

Журнал решений сохраняет вопрос, варианты, выбор и последствия. Ограничение незавершенной работы помогает закончить уже начатое: перед новой задачей команда проверяет доступность и решает, что придется сдвинуть. Срочные и обязательные работы требуют отдельного правила. Останавливать все новые задачи ради чистоты эксперимента нельзя.

Метрики, после которых можно что-то решить

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

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

SPACE, опубликованная в 2021 году, предлагает измерять продуктивность разработчиков по нескольким измерениям, включая удовлетворенность, результативность, активность, взаимодействие и поток работы. Перенос на другие виды интеллектуального труда здесь является моей адаптацией. Из числа карточек нельзя вывести качество медицинского заключения или сложность переговоров.

Как часто встречаться

Ниже мой стартовый вариант для команды с частичной занятостью в проекте. Через месяц его нужно пересмотреть по числу блокировок и стоимости встреч.

Раз в неделю: 30 минут с владельцами работ. Сверяем доступность на следующую неделю, ближайший результат, блокировки и решения. Статус обновляется до встречи, чтобы не читать карточки вслух.

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

Раз в месяц: 45 минут на повторяющиеся сбои. Выбираем одно изменение процесса, владельца и дату проверки. Конфликт приоритетов и существенный риск не ждут планового совещания: для них действует отдельный срок эскалации.

Вводные меняются. Обязательства тоже нужно пересогласовать

Запрет на изменение требований не подходит живому проекту. Новые данные, ограничения или потребности могут сделать прежнее решение неверным. Важно сохранить след изменения.

Запрос должен объяснять, что меняется и зачем. Команда оценивает влияние на объем, срок, ресурс, качество и риск. Уполномоченный владелец выбирает вариант, после чего обновляются план и критерии приемки.

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

Доступность и дополнительная работа

Я бы не объяснял отношение к переработкам возрастом. У людей разная нагрузка и разные обстоятельства. Для проекта важны согласованное рабочее время, режим связи и правила действий в действительно срочной ситуации.

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

Google в Project Aristotle связывает эффективность изученных команд с психологической безопасностью, надежностью, ясностью, смыслом и влиянием работы. Это наблюдения внутри Google. Для меня практический вывод такой: сотрудник должен иметь возможность заранее сказать о перегрузке и ошибке, чтобы команда успела отреагировать.

Как оценивать менеджера и руководителя PMO

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

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

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

С чего начать

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

Через две недели посмотрите, какие вопросы перестали зависать, где сохраняется очередь и какие обещания снова не совпали с ресурсом. Это основание менять план, правила или состав команды.

Мне близка простая последовательность: подготовка, планирование, анализ, решение, реализация, проверка и обратная связь. Она требует участия руководителей и заказчика. Работать в такой системе бывает утомительно: приходится видеть, кому что обещали и сколько на самом деле стоит результат. Именно в этом ее польза.