При поиске PM в наш PMO я отвечаю на отклик потенциальным коллегам исключительно с инженерным бэкграундом. Насколько это объективно?

По основному образованию я инженер-теплоэнергетик, до перехода в проектное управление работал на ТЭЦ. Даже сейчас, несмотря на должность Head of PMO, эта база включается почти на каждом совещании — и именно её отсутствие у РМ я считаю причиной значительной части сорванных сроков в проектах цифровизации. Почитав статьи на эту тему, узнал, что большинство проектов цифровизации в мире не доходят до полного успеха: основная часть заканчивается частичным результатом или провалом. Часть причин организационные — сопротивление изменениям, нечёткая стратегия. Но есть и менее заметная: РМ, который не понимает инженерную суть проекта, не может проверить оценку инженера — он может только транслировать её дальше, в диаграмму Ганта и статус-репорт. Разница между подходами у двух PM с разным бэкграундом будет велика. Когда специалист говорит «интеграция с АСУ ТП Заказчика займёт три недели», РМ без инженерного бэкграунда фиксирует это как вводную и закладывает в план с регламентным резервом. РМ, который понимает суть, спрашивает: по какому протоколу идёт обмен; есть ли у контроллера штатный API (интерфейс от производителя, с которого можно брать данные) или нужен шлюз; кто уже подключался к этому оборудованию и с какими проблемами столкнулся. После такого разговора оценка либо подтверждается, либо превращается в шесть недель — но на этапе планирования, а не когда расхождение с базовым планом уже видно по факту. На одном из проектов — системе для диспетчеров теплосетей — понимание того, как реально устроен контур телеметрии на объектах, позволило верно оценить интеграцию со старыми узлами учёта: формально задача выглядела типовой, но часть приборов передавала данные с нюансами. «Зоопарк» оборудования на различных ЦТП теплосети был огромным — что-то стояло ещё с нулевых. В итоге дешевле оказалось заменить его, чем писать драйвер интеграции. РМ без инженерного взгляда узнал бы об этом уже на приёмке, когда сроки горят, а стейкхолдеры ждут подписания акта. Поэтому на собеседованиях РМ мы перестали ограничиваться вопросами про PMBOK, RACI-матрицу и опыт работы по Agile или Waterfall и добавили три метрики на инженерное мышление: а) число уточняющих технических вопросов до озвучивания сроков (у сильных кандидатов в среднем 5–7 против 1–2 у слабых); б) способность самостоятельно пересчитать критический путь при изменении вводной, без «уточню у инженера» (справляется около трети); в) момент, когда в разборе кейса впервые всплывает вопрос про протокол или архитектуру — чем раньше, тем увереннее кандидат в итоге вёл тестовые задачи Практический вывод: если РМ не может своими словами объяснить, что с чем интегрируется в его проекте и куда идут данные, — он управляет расписанием, а не проектом.

Проверяете ли вы у себя техническую грамотность РМ отдельно от управленческих компетенций — или полагаетесь на то, что рядом всегда есть технический эксперт?