Проектный менеджер будущего – оператор нейросетей или политический архитектор?

В 2025 году меня пригласили в банк на проект по внедрению автоматизированной банковской системы (АБС), потому что предыдущий проект провалился еще на этапе обследования. Как показывает практика, это довольно типичная история:

• Бизнес растет, акционеры в предвкушении.
• СТО, видя, куда движется вектор развития, понимает, что текущая АБС «не вывезет» нагрузку и инициирует проект по замене. Логично, разумно.
• Финансисты понимают, что грядет тяжелый период: внедрение таких систем – всегда дорого.
• Операционный директор понимает, что скоро у него будет «валерьяновый» период, когда нужно тянуть текущие задачи и параллельно тянуть новый функционал теми же ресурсами.

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

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

Это статья про проектный менеджмент в ИТ-сфере, потому что это моя вотчина. Строительство, маркетинг, производство – уважаю, но туда не лезу.

Эволюция проектного менеджмента – три ключевые эры

Надеюсь, ПМы узнают себя в этой истории.

1. Эра инженера: Waterfall (1960-2000-е)

• ПМ = планировщик и контролер.
• Ценность – точность, документированность, предсказуемость.
• Метрика успеха – соответствие плану.

ПМ сутками корпит над диаграммой Ганта, выстраивает этапы, подзадачи, связи, критические пути, вычисляет сроки, трудочасы, прописывает ответственных. Потом считает точный бюджет, рисует карту рисков с экспертными оценками по типу: «Если и случится, то жить будем». А потом сроки плывут, и начинается жонглирование объемом работ и ресурсами, лишь бы не вылезти из плана. В итоге что-то получалось, что-то нет. Но в целом всех устраивал такой подход: времена были менее техногенные, методология работала.

2. Эра фасилитатора: Agile (2000-2020-е)

• ПМ = слуга команды, убиратель препятствий.
• Ценность – скорость адаптации, ритм, коммуникация.
• Метрика успеха – скорость команды и удовлетворенность заказчика.

Казалось, все проектные проблемы будут решены, стоит только внедрить новые подходы (Agile, Scrum, SAFe, Kanban), перейти на спринты, начать делегировать и просто помогать команде двигаться вперед. Для маленьких проектов на пять человек с одним заказчиком – может, и выход. Но в корпоративном сегменте модные веяния не спасали. Как проекты плыли по срокам, так и плывут. Просто аргументация стала другой, отчеты переехали из Ганта в бэклоги. Суть от этого не изменилась.

3. Эра стратега: ИИ + политика (2025-...)

• ПМ = политический архитектор + оркестратор ИИ-агентов.
• Ценность – навигация в сложных оргструктурах, управление реальной властью, а не формальными ролями.
• Метрика успеха – реализованный результат в условиях максимальной неопределенности.

Казалось бы, в наше время чат-боты, агенты, RAG, AGI, генерация контента – все это стало нормой жизни для человека, который более-менее в контексте технологий. И ПМ должен быть в авангарде. Но так ли это? Ответ: нет. Как показывает мой опыт общения с коллегами: методологии те же, инструментарий дополнился общением с GPT, но в остальном «Agile – наше все». Лопатим бэклоги, строим планы, вилами на воде оцениваем риски. Хотя пора бы уже переключиться на то, чем ПМ должен заниматься, когда его автоматизируют.

Как выглядит автоматизация работы проектного менеджера

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

Итак, пятница руководителя проекта:

9:00: кофе, ноутбук, почта.

9:30: ежедневная короткая встреча с командой – собрать статус, обсудить итоги недели.

10:00-13:00: встречи, обсуждения, решения проблем, протоколирование и рассылки, письма вендорам, передача задач в другие подразделения.

13:00: через час комитет, надо подготовиться: лезем в Jira, смотрим задачи за период, приоритеты, расходы, подбиваем план-факт. В сотый раз смотрим на матрицу рисков и думаем, есть ли что добавить. Делаем слайды или страницу в Notion / Confluence / что-то в этом роде.

14:00: отдуваемся на комитете. Внутренний заказчик проекта не согласен с приоритетами, финансисты прицепились к цифрам, операционка пессимистично смотрит на результаты спринта, СТО дважды закрыл лицо рукой (жди гневного сообщения в мессенджере), инфобез заявил, что такое они не согласовывали и в прод не пропустят. Получил пачку поручений.

15:00-16:00: фиксируем все в протоколе, выделяем поручения, заводим в таск-трекер, пишем письма: «давай сверимся по цифрам», «прошу согласовать системную архитектуру», «коллеги, в чем ваше несогласие с приоритетом».

16:00-16:30: снова кофе, просто, чтобы успокоиться.

16:30-17:00: созвон с СТО или директором по проектам на тему, почему столько хейта на комитете. Решили, что все вокруг «неправы», но надо сделать всем хорошо. Договорились, как это сделать.

17:00-19:00: делаем артефакты, чтобы всем заинтересованным сторонам было хорошо и комфортно. Закрываем ноутбук.

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

Как должен выглядеть день проектного менеджера

• Встречи: приложения типа Circleback распознают звонок, делают запись, транскрибируют и превращают в протокол с инсайтами и выделенными задачами. Да, на русском не всегда идеально, но поправить аббревиатуры и имена займет пять минут.
• Оценка рисков: ИИ нагенерирует рисков больше, чем ПМ себе представляет, если правильно поставить задачу. Достаточно выгрузить проект в Excel / XML / json, скормить нейронке, и получишь сотню рисков, из которых нужно отобрать релевантные на основе опыта. Но лучше всего использовать имитационное моделирование: собрал первичные данные (свои или с рынка), попросил ИИ-агента написать модуль Монте-Карло, дал данные на вход – и вот аргументированное представление о вероятности риска и его стоимости, а не интуитивное «слабо-средне-критично».
• Бюджет: хватит колдовать в Excel. Собираешь все в папку, ставишь задачу агенту, он изучает, формирует, подбивает результат. Ты в это время на встрече. Бегло проверил, и готово. Зная свой бюджет, ошибку видно сразу: либо сам поправил, либо дал задание на корректировку. Экономит уйму времени.
• Статусы и презентации на комитеты: Claude Code / Open Code + MCP (Model Context Protocol) = готовые материалы. Агент имеет доступ к файлам: презентации, расчеты, бюджеты, заметки, прошлые протоколы. Через MCP подключается таск-трекер и база документации. Дальше дело техники: сформируй статус за неделю → обнови презентацию → обнови бюджет (вот новые оплаты) → обнови риски на основании комментариев из Jira. Готово.
• Метрики проекта – это структурированные данные, а значит, ИИ работает с ними тоже. Настраиваем API к таск-трекеру или MCP, и просим агента что-то рассчитать: он лезет в задачи, анализирует, выдает результат быстрее, чем вы заварите кофе. Но главное, можно следить за проектом через метрики опережающего воздействия, а не только постфактум.

Какую работу проектного менеджера ИИ не сделает никогда

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

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

Никакой ИИ не позвонит операционному директору в неформальной обстановке и не спросит: «Слушай, а что тебя по-настоящему беспокоит в этом проекте? Не на уровне официальной позиции, а реально?». Никакой агент не почувствует, что финансовый директор молчит на совещаниях не потому, что согласен, а потому что уже принял решение заблокировать проект при первом удобном случае. Это политика. Корпоративная политика на уровне конкретных людей с конкретными интересами.

Вот, из чего состоит «политическая грамотность» ПМа, которая не поддается автоматизации:

• Чтение мотиваций. У каждого участника проекта свой интерес. Аналитик, разработчик, техлид, финдир, опердир, СТО, гендир, акционер – у каждого своя мотивация, свои особенности. И в этом надо уметь разбираться. Как гениально ни планируй, все может упереться в простое «так не делаем, потому что я так решил». Раньше могли слить последствия за рутиной, теперь нет.
• Работа с неформальными коалициями. Формальная оргструктура и реальная карта влияния в любой компании – разные вещи. Кто реально принимает решения? Кто может заблокировать? Кто лоббирует конкурирующий проект? Кто находится под давлением своего руководства, поэтому будет голосовать против на комитете? Не потому, что вы неправы, а потому что ему так выгоднее. ПМ, который видит эту карту, работает в принципиально другой реальности, чем тот, кто видит только бэклог.
• Фрактальная зависимость. ПМ должен видеть, как действия команды влияют на каждый уровень оргструктуры: один человек – команда – отдел – департамент – компания в целом. Этим занимается руководитель проектного офиса, который видит все сверху. ПМ должен делать так же, хотя бы в рамках своего проекта.
• Превентивная дипломатия. Звучит пафосно, но речь о простом: заранее переговорить с инфобезом, пока они не стали проблемой на комитете. Зайти к заказчику не с отчетом, а с вопросом. Сходить к операционному директору, потому что три недели назад он был недоволен, и надо понять, изменилось ли что-то. Это нельзя делегировать агенту. Это можно делать только тогда, когда рутина не съедает все рабочее время.

Именно по этой причине гибридная методология – вполне закономерное движение. То, что раньше делегировалось администраторам проектов (этаким референтам у ПМа в зажиточных компаниях), будет заменено ИИ. Все, что можно извлечь из таблицы Excel, видеозвонка, базы данных или взять по API, будет делегировано машине. Нет смысла этому сопротивляться и гордиться олд-скульным подходом. Нужно принимать и использовать инновации.

А что остается человеку:

• Позвонить операционному директору и обсудить его недовольство.
• Зайти к инфобезу и договориться о процессе, чтобы вас не заблокировали на комитете.
• Объяснить заказчику продукта: «Да, вы генерируете доход, вы молодцы, но если ляжет АБС, ваши усилия напрасны, поэтому давайте вот эти три задачи впихнем в следующий спринт».

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

Как project-менеджеру подготовиться к новой роли

1. Освойте хотя бы один инструмент автоматизации рутины, и доведите его до уровня привычки. Не «попробовал пару раз», а «использую каждый день». Circleback для протоколов встреч. Claude или ChatGPT для первичного анализа рисков. Агент с доступом к файлам для подготовки статусов. Один инструмент, доведенный до автоматизма, высвобождает час-полтора ежедневно. Это не мало.
2. Посмотрите на свою работу глазами автоматизатора. Задайтесь вопросом: «Это я мог бы отдать ИИ?». Поверьте, там будет пачка задач, которые вам делать уже необязательно. Ваша роль – валидировать, а не производить.
3. На каком-нибудь большом совещании, где вы в основном слушатель, нарисуйте примитивную схему: кто с кем больше соглашается, кто противостоит, кто держит нейтралитет. Это и есть начало работы с реальной картой проекта – не из Jira, а с той, что в головах людей.
4. Уделите хотя бы один час в неделю на «политические» разговоры – неформальные, без повестки, без протокола. Просто «как дела с проектом» с теми, кто на него влияет. Вы удивитесь, сколько информации там всплывает, и как мало попадает в официальные каналы.

Пример из практики. Для того проекта в банке, чтобы оптимизировать свою работу, я разработал локальный веб-сервис, который регулярно мониторит задачи, метрики, риски и сохраняет историю инкрементально. В чате с агентом я в любой момент мог сделать статус, найти проблемные области, выявить недоработки. Показал это коллегам из смежных команд. Коллеги к такому оказались не готовы, хотя банк прогрессивный и слово «ИИ» там всем знакомо. Просто поглощение рутиной не дает выпрямить спину и оглядеться.

То же самое было внутри моей команды. Когда я заговорил о том, что надо начать использовать ИИ, чтобы ускорить тут, там, здесь – скепсис, неуверенность, осторожный интерес. А потом: «А давайте еще вот тут попробуем». В итоге мы пишем требования, скрипты, маппинги для интеграций с применением ИИ. Да, валидация остается за аналитиками и разработчиками, но уже 60-70% рутины выполняет ИИ-ассистент. За человеком – критический анализ.

Выводы

PMBOK и Agile дали инструменты для управления работой. Следующий шаг – инструменты для управления системами власти, внутри которых эта работа происходит. ИИ ускорил этот переход. Задайте себе один вопрос: «Если убрать из моей работы все, что может делать ИИ, что останется?». Ответ – это и есть ваша реальная профессия, которую стоит развивать.

Также читайте: