Почему классический Project Manager больше не нужен

Это первая статья из серии «Иллюзия контроля управления сроками» о том, почему современные ИТ-команды системно не укладываются в сроки даже при наличии опытных проджект-менеджеров, внедренного Agile и современных инструментов.

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

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

Project Manager — это иллюзия контроля в системе, которую никто не контролирует. Большинство ИТ-компаний до сих пор верят, что Project Manager управляет сроками. На практике он управляет только отчетностью о том, почему сроки снова сдвинулись.

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

И это не проблема конкретных людей или недостатка компетенций. Это системная ошибка, где роль Project Manager создавалась для мира, в котором сроки можно было контролировать. Сегодня этого мира больше не существует, но именно под него до сих пор построена система управления.

Историческая роль Project Manager: тогда, когда это действительно работало

• требования можно зафиксировать заранее;
• объем работ (scope) относительно стабилен;
• изменения — редкое исключение, а не норма.

• декомпозировал проект;
• управлял ресурсами и рисками;
• контролировал сроки, бюджет и объем (scope);
• налаживал коммуникацию со стейкхолдерами;
• обеспечивал достижение целей проекта.

Система была линейной и предсказуемой, а значит, и управляемой.

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

Однако ключевое предположение осталось неизменным: сроки по-прежнему можно контролировать, но просто другими инструментами.

На практике же изменился сам процесс, но не природа системы.

• множественные команды;
• сложные зависимости;
• внешние интеграции;
• постоянные изменения приоритетов;
• постоянное давление стейкхолдеров.

В такой среде исходные допущения, на которых строилась роль классического Project Manager, перестают работать.

Вывод: Project Manager был эффективен не потому, что лучше управлял, а потому что система, в которой он работал, была предсказуемой.

Project Manager — это лицо, назначенное исполняющей организацией для руководства командой проекта и достижения целей проекта (PMBOK).

Waterfall — это линейная и последовательная модель управления проектом, в которой каждая фаза начинается только после полного завершения предыдущей.

Читайте также

Корпоративный мессенджер для вашей компании: редакция IT-World тестирует Битрикс24

Какая боль! Какая боль! Куча задач, а решенных — ноль! Договорились на созвоне — никто не записал. Настрочили в Telegram — потерялось. Задача появилась через неделю — уже не актуально. Переписка разбросана по десяткам чатов, важные файлы — в разных папках, а сроки выполнения задач никто не отслеживает.

Agile — это подход к управлению проектами и разработке ПО, ориентированный на гибкость, быстрые итерации и постоянное взаимодействие с клиентом.

Scrum — это фреймворк Agile, который помогает командам организовать работу в итерациях (спринтах), с регулярными встречами для планирования, оценки прогресса и ретроспектив.

PMBOK и попытка «скрестить два мира»

Project Management Institute выпустил PMBOK Guide как стандартизированное руководство по управлению проектами. Изначально оно создавалось для предсказуемых, линейных проектов (Waterfall), где требования фиксированы, а процессы можно формализовать.

• Predictive (предсказуемый): традиционная каскадная разработка, фиксированный scope, строгий контроль сроков и бюджета.
• Adaptive (гибкий): Agile, Scrum, постоянные изменения и итеративная разработка.

Каждое новое издание PMBOK добавляет практики, подходы и методики для работы с Agile и другими гибкими фреймворками. Это выглядит как попытка формализовать то, что по природе невозможно формализовать — неопределенность, внешние интеграции, человеческий фактор, бизнес-приоритеты.

Вывод: PMBOK эволюционирует не потому, что становится лучше, а потому что пытается описать мир, который невозможно формализовать. Он пытается дать Project Manager инструменты для контроля того, что контролировать невозможно.

Что сделало линейное управление невозможным?

Современные ИT-проекты больше не похожи на предсказуемые каскадные Waterfall-проекты. За последние годы изменились несколько ключевых факторов, которые сделали линейное управление невозможным:

Рост неопределенности

Требования больше не фиксируются раз и навсегда. Бизнес-среда меняется слишком быстро: новые фичи, конкурентные условия, законодательные и регуляторные изменения — все это почти ежедневно влияет на объем проекта.

Сложные интеграции

Практически каждый проект зависит от внешних систем: API сторонних провайдеров, интеграции с платежными шлюзами, внешними сервисами аналитики и CRM. Любое изменение со стороны провайдера способно замедлить весь процесс.

Кросс-командные проекты

В крупных ИT-проектах одновременно работает несколько команд: backend, frontend, QA, интеграционные, compliance и другие. Каждая команда имеет свои приоритеты, скорость работы и зависимости. Координация становится критически сложной.

Постоянные изменения требований

Agile и Scrum позволяют гибко реагировать на изменения, но это не устраняет системную проблему. Изменения приходят постоянно и часто неожиданно, а роль Project Manager, сформированная под линейную модель, не имеет полномочий влиять на все внешние зависимости и бизнес-принятия решений.

Project Manager продолжает отвечать за сроки и отчетность, но не управляет теми факторами, которые реально определяют результат.

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

Вывод: система перестала быть линейной, но роль осталась прежней.

Почему Agile не решил проблему контроля

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

Убран жесткий план, но не проблема зависимости

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

Читайте также

Claude Mythos помог обойти одну из ключевых защит macOS

Владельцы Mac привыкли считать свои компьютеры почти неуязвимыми, но новый кейс Calif показывает, что даже продвинутые защиты Apple не являются непробиваемыми.

Команды стали автономными, но зависимости остались

Команды могут принимать решения самостоятельно, но проект по-прежнему требует координации между ними. Backend, frontend, QA, compliance — каждая имеет свои приоритеты. Даже идеально работающая команда не сможет компенсировать задержки другой.

Ирония в том, что чем автономнее команда, тем сложнее глобально управлять delivery.

Scrum Master не равно delivery

Scrum Master помогает команде работать эффективнее: устраняет препятствия, улучшает процессы, фасилитирует коммуникацию. Но он не управляет сроками на уровне проекта, не согласует внешние интеграции, не решает бизнес-проблемы и не контролирует roadmap-провайдера.

Agile не ломает систему, он лишь меняет рамки работы команд. Роль контроля смещается внутрь команд, но тот, кто формально отвечает за дедлайны, остается без рычагов влияния.

Именно здесь возникает вопрос: как на самом деле формируются сроки и кто за них отвечает?

Для ответа мы возьмем кейс запуска платежной системы в Латинской Америке. На его примере разберем, где теряется контроль, почему Project Manager формально отвечает за результат, но не может его гарантировать и какие решения сверху создают системные срывы.

Вывод: Agile перераспределил ответственность, но не создал механизм управления сроками.

Иллюзия управления сроками

В большинстве ИT-компаний сроки проекта воспринимаются как управляемая величина: их можно оценить, зафиксировать и проконтролировать, но на практике это не так.

• «нужно успеть к запуску сезона»;
• «важно выйти раньше конкурентов»;
• «это приоритет квартала».

После этого команда должна «подтвердить» эти сроки, даже если данных для точной оценки недостаточно.

И как раз в этот самый момент происходит подмена — срок перестает быть расчетом и становится обязательством.

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

И что получается в результате? Чтобы соответствовать бизнес-решению, оценки занижаются, риски игнорируются, а неопределенность не учитывается. Изначально неточного прогноза становится недостаточно, и появляется искаженный прогноз под ожидания.

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

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

Проблема не в том, что план составлен плохо. Проблема в том, что сама идея точного планирования в сложной системе изначально некорректна.

Читайте также

Олег Бунин: «Для меня промышленный ИИ — это ИИ, обладающий пространственным мышлением»

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

Чтобы понять, почему это происходит, важно посмотреть, где именно в системе теряется контроль и какие факторы на самом деле определяют сроки.

Где реально теряется контроль

Если убрать формальные планы и посмотреть на реальную работу проекта, становится очевидно, что сроки определяются не планированием, а системой зависимостей.

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

В такой системе срок определяется не тем, «как быстро работает команда», а тем, где возникнет следующий блокер.

Это звучит как теория — пока не посмотреть на реальный проект.

Микрокейс: как одна зависимость остановила весь проект

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

• запуск привязан к началу спортивного сезона
• жесткий дедлайн от бизнеса
• несколько внутренних команд и внешняя интеграция

• Backend (core platform)
• Payments (интеграции)
• Frontend (checkout)
• QA (end-to-end)
• Compliance / Legal

Delivery Manager в проекте присутствовал, но контролировал только внутренние процессы, внешние зависимости оставались вне зоны влияния.

Что произошло

Backend- и Payments-команды завершили свою часть в срок, однако за неделю до начала интеграционного тестирования провайдер изменил API: обновились параметры antifraud и изменилась логика валидации.

Изменения не были заранее стабилизированы через versioning или полноценный changelog.

• интеграция перестала работать
• frontend оказался заблокирован
• QA не смог начать тестирование
• релиз сдвинулся на четыре недели 

При этом ни одна из внутренних команд формально не «сорвала сроки».

Project Manager продолжал отвечать за дедлайн, не имея никакого влияния на происходящее.

Бизнес-влияние

Задержка релиза на четыре недели в пиковый сезон привела к потере до 30% нового трафика, снижению конверсии из-за отсутствия локальных методов оплаты и упущенному обороту в миллионы долларов.

Ключевой вывод

В подобных системах достаточно сбоя в одном элементе (чаще всего внешнем), чтобы остановить весь delivery. На анализ и исправление ушло две недели при том, что сама проблема была в изменении только одного параметра API.

Читайте также

Российские low-code BPM-решения

Российский рынок low-code BPM-платформ уже предлагает решения для документооборота, сервисных процессов, финансового сектора и импортозамещения SharePoint. Какие системы подходят разным типам компаний и на что смотреть при выборе — разбирался IT-World.

Именно здесь становится очевидно, что Project Manager не управляет сроками, а просто наблюдает за тем, как система их формирует.

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

Почему Project Manager не может контролировать сроки (даже если он опытный)

После разбора реального кейса возникает логичный вопрос: если проблема очевидна, почему Project Manager не может ее предотвратить?

Ответ в том, что ограничения заложены в самой роли.

• он не контролирует внешние интеграции;
• не управляет загрузкой всех команд;
• не принимает финальные бизнес-решения по приоритетам.

В результате возникает системный разрыв: ответственность за результат есть, но контроля над системой нет.

Если упростить, то причина не в навыках и опыте, а в несоответствии роли и системы.

Система сложнее роли

• команды
• сервисы
• внешние провайдеры
• бизнес-решения

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

Project Manager не может контролировать систему, потому что система слишком сложна для централизованного управления.

Зависимости вне зоны контроля

• внешние API
• подрядчики
• другие команды с собственными приоритетами

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

Решения принимаются вне роли

• дедлайны устанавливаются бизнесом;
  
• приоритеты меняются сверху;
  
• scope расширяется без учета capacity.

PM оказывается между системой и ожиданиями, но не управляет ни тем, ни другим.

Вывод: Project Manager отвечает за сроки, но не управляет переменными, от которых они зависят.

А нужны ли Delivery- и Program-менеджеры?

Чтобы закрыть этот разрыв, в компаниях начали появляться новые роли — Delivery Manager и Program Manager. Но решают ли они проблему или просто усложняют систему? Обе роли — это только попытка закрыть разрыв между ответственностью и контролем.

Где они действительно помогают:

Управление зависимостями

Delivery и Program менеджеры фокусируются не на задачах, а на связях между ними: синхронизация команд, выявление блокеров, управление cross-team-зависимостями.

Читайте также

Когда внутренние ИТ-решения становятся драйвером роста корпорации

В крупных компаниях внутренние ИТ-системы по-прежнему чаще воспринимаются как поддерживающая инфраструктура и центр затрат, а не как источник роста бизнеса. При этом именно они обеспечивают управляемость процессов, ускоряют масштабирование и в ряде случаев становятся основой для новых направлений выручки. В условиях импортозамещения и взрывного роста ИТ-структур отечественный бизнес все чаще задумывается о том, как превратить внутренние решения в драйвер роста. Мария Терешкина, Senior Product Manager направления Daily Banking в Т-Банке – о том, в каких случаях внутренний софт действительно начинает влиять на экономику компании.

Повышение предсказуемости

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

Связка бизнеса и разработки

Они переводят бизнес-цели в delivery-планы, вводят управление ожиданиями и выравнивание приоритетов.

Где они начинают мешать

Дублирование ролей

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

Бюрократия вместо управления

Появляется больше встреч, отчетности и координации. А это не всегда означает больше контроля. Система становится «более описанной», но не более управляемой.

Иллюзия контроля 2.0

Даже с новыми ролями внешние зависимости остаются, бизнес-дедлайны продолжают «назначаться», а неопределенность никуда не исчезает. Меняется лишь уровень управления, но не устраняется корневая проблема.

Ключевой вывод

Delivery и Program менеджеры — это не решение проблемы, а реакция на рост сложности системы. Они помогают лучше видеть происходящее, но не дают полного контроля над сроками.

Так, если Project Manager больше не управляет сроками, а Delivery- и Program-менеджеры не могут контролировать все зависимости, то возникает главный вопрос: сроками вообще можно управлять или это всегда иллюзия?

Разберем это во второй части.

Читайте также

В чьи сети мы попали? Рейтинг розничных игроков от основателя DNS

Рейтинг, традиционно составляемый основателем DNS Дмитрием Алексеевым, ранжирует по числу точек игроков абсолютно разных сегментов отечественной розницы. Такой подход позволяет взглянуть на рыночные тенденции под новым углом. Экспансия рынка за счет расширения инфраструктуры неизбежно уйдет в прошлое. Бизнес-стратегии лидеров, построивших сети с удобным физическим доступом практически для каждого потребителей, сменят фокус на комфорт для клиента, качество обслуживания и расширение спектра услуг.