Почему ищут “менеджеров проектов ИТ”?

В вакансиях руководителей проектов очень часто встречается указания, что нужен именно руководитель проектов ИТ. А если взять PMBOK или PRINCE2, то какой-то особой разницы между управлением проектами ИТ или, например, бизнес проектами, нет. Ты либо умеешь управлять проектами либо нет. Примерно то же самое в тексте Ашманова: “Управление программистами - не магия. Управлять программным проектом может даже гуманитарий. Но для этого обязательно нужно вообще уметь управлять людьми и проектами. Как и в любой отрасли, менеджеру достаточно знать некоторые особенности технологического процесса и не поддаваться "мифам индустрии". Всё остальное зависит от обычного умения менеджера наладить работу.”

Почему же сотни вакансий написаны именно вокруг конструктива, а не фнкционала работы? Ответ, короткий и понятный, дала Пион на тренинге по (онто)логическому фитнесу.
Итак, люди договариваются с помощью знаков/описаний, и, если не могут договориться по значению (т.е., не могут однозначно указать 4Д индивид, на который знак/описание указывает), объединить свои различающиеся концепты 4Д индивида, то просто идут к этому индивиду и стучат по нему со словами “я говорю об этом”.

Например:
https://hh.ru/vacancy/24599084
Восстановленный из концептов вакансии домен деятельности этой позиции, требуется проверять при собеседовании, тот самый вопрос “что бы вы хотели узнать о нашей компании?”

• Конкретная команда разработки (состав, квалификация, культура, НИР?)
• Конкретные развернутые у заказчика экземпляры автоматизированных систем (какие, где, сколько таких проектов было?)
• Конкретные летные и инженерно-технические команды заказчиков (сколько их, кто это, коммерческие или государственные, какие это были госзакупки, удовлетворенность этих заказчиков, как происходит сдача-приемка и обслуживание?)
• Конкретные отзывы/отклики заказчиков (что значит нравится людям, каким людям, почему это вообще важно?)
• Конкретная компания-работодатель (Что значит молодая? Что значит активно развивающаяся и за счет чего? Стратегия и архитектура компании, а хоть бы и по Остервальдеру?)
• Конкретные проекты разработки (какие были завершены, срывы сроков-бюджетов, по каким методам идет работа, формализованы ли эти методы и соблюдаются ли они, какие идут сейчас, кто руководитель, можно ли с ним поговорить и что он скажет?)
• Персонал конкретных проектов (организация подчиненности, переработки, квалификация, система мотивации, текучесть, количество проектов, в которых в среднем участвует разработчик, порядок решения конфликтов и как выглядит решение конфликтов на разных уровнях). Руководители конкретных проектов и спонсоры (кто по именам, откуда пришли, почему занимаются именно этим в “молодой перспективной компании”, какая культура лидерства?)
• Конкретные артефакты конкретных проектов (форма - электронная или бумажная, системы управления документооборотом, количество документов и количество изменений документации в проектах, скорость прохождения изменений - важно, сильно влияет на критический путь!, какая отчетность существует и кто и как ей пользуется?)
• Конкретные реализовавшиеся риски проектов (были ли они предусмотрены, какие были планы действий, сработали они или нет, анализ причин, как реагирует руководство на реализацию непредусмотренного и предусмотренного риска, приведите примеры)
• Конкретные ситуации исполнения договорных условий (насколько строгие и сложные контракты, какую силу имеют юристы и бухгалтера в компании, какие договора основные и с кем, система управления договорными отношениями, основные проблемы с договорами и контрагентами?)
• Конкретные субподрядчики (кто, сколько, какие объемы поставок и разработок, почему именно такая структура договорных отношений, риски и проблемы поставок, планы избегания?)
• Конкретные аналитики, конкретные технические задания и конкретные экземпляры процессов их разработки (сколько ТЗ разрабатывается, их сложность, кто специализируется на их разработке, пример какого-нибудь ТЗ и проблемы с изготовлением по нему, со сдачей и приемкой, есть ли процесс непрерывных улучшений разработки ТЗ и ведется ли база знаний?)
• Конкретный архитектор и конкретные артефакты архитектурного процесса (какие артефакты архитектурного проектирования есть, как они используются и переиспользуются, есть ли платформы, сколько времени тратится на архитектурное проектирование?)
• И т.д., и т.п.

И во время собеседования в случае непонимания концептов собеседника всегда можно уточнять свое понимание, “стуча по 4Д индивиду из предметного домена”, например “приведите, пожалуйста, конкретный пример такой ситуации”.

Но есть ряд ситуаций, когда 4Д индивида не существует и/или постучать по нему нельзя, и ситуация с разработкой ПО именно такая. Это не здание, не магазин, не автомобиль, а предложение идти и постучать по серверной ферме, на которой кроме вашего приложения работает еще пара тысяч других будет не прагматичным, не поможет договориться. Что же делать? Писать как можно более качественные требования к результату работ. И это похоже на правду, если посмотреть на данные PMI:

"Для проектов, которые начались в вашей организации в последние 12 месяцев, и были выполнены с ошибками, какая была ведущая причина ошибок?" - Некорректный сбор требований 37%.

Другими словами, чтобы успешно делать ИТ проекты, надо уметь подробно описывать альтернативную реальность, уметь детально вообразить и затем точно описать будущее. Может, именно поэтому ИТ-шники так любят хорошие фантастические произведения?
Моя гипотеза состоит в том, что на позиции руководителей проектов ищут не столько людей с опытом исполнения проектов ИТ, сколько людей, умеющих хорошо воображать несуществующее и требовать реализации этого несуществующего, как будто это 523 тысячи тонны бетона и металлоконструкций. И это ключевое дополнение текста про правила руководителя проектов.

Такому прагматичному мышлению и учат на тренинге по онтологическому фитнесу.