Проектный менеджмент умер: почему проекты больше не ведут, а только синхронизируют)

Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как Project Manager стриминга киноviju.ru сама в этом варюсь каждый день — десятки тредов, уточнений, синхронизаций, но в какой-то момент ловишь себя на мысли: чем больше коммуникации, тем меньше реального движения задач. 
Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.
В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.

Давайте разберёмся, почему умирает управление

• Социальность – видимость пользы

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

• Чат – хранилище

Многие сотрудники пишут в тредах информацию по документации, по задачам и по решению проблем. Чат хранит эмоцию, а не решение. Потом что-то забывается, и создаётся дополнительный повод для проведения созвона и +10 тредов. 

• Daily – статус-театр

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

• Созвон – обезбол

Созвон даёт приятное ощущение движения: все собрались, поговорили, вроде бы договорились. Но если после него не обновились backlog, таблицы зависимостей, реестр рисков и журнал решений, проект не стал управляемее и по факту ничего не изменилось.
Как Project Manager должен работать сегодня? 
Роль менеджера  — не в том, чтобы быть «на связи», а в управлении задачами, рисками и решениями. На практике это означает:

• Статус не собирается из чатов. Он идёт из доски, backlog и маркеров риска. Daily — это 15 минут по задачам, а не персональный отчёт каждого участника. На daily обсуждают только то, что мешает цели спринта или ближайшему релизу. Всё остальное - после, точечно и асинхронно. Риски и зависимости отсматриваются отдельно, а не в конце общего синка «если останется время». Риск без owner — это просто тревожная мысль которая теряется. Блокер без даты решения — просто надежда.
  
• Документация хранится в специализированных местах, а не в чатах. Это критично для асинхронной работы знания теряются, решения не воспроизводятся, команда скатывается в созвоны.
  
• Решения принимаются по короткому письменному чек-листу. Есть ответственный за решение, есть тот, кто утверждает, есть дедлайн на комментарии и есть записьрезультата в журналрешений в тот же день. Если понадобился созвон, после него обязательно появляется письменный итог. Если письменного итога нет, решения тоже нет.
  
• Встречи проходят не потому, что тревожно, а потому, что без них нельзя!Хорошее правило простое: нет повестки — нет встречи; нет предварительных материалов — нет решения; нет ответственного — нет дальнейших действий.
  
• Эскалация строится по допускам, а не по настроению. PM заранее фиксирует, при каких условиях по сроку, риску, бюджету или качеству вопрос поднимается выше. Иначе каждый конфликт превращается либо в молчаливое болото, либо в эмоциональный пожар.

Артефакты, без которых PM превращается в синхронизатора
Я выделяю оптимальный набор артефакта для проекта, где есть хотя бы две команды, несколько заинтересованных лиц и хоть один риск релиза:

• Реестр рисков – это список всех значимых рисков проекта с оценкой вероятности и влияния, а также планом действий. Нужен, чтобы риски не «всплывали внезапно», а управлялись заранее — с понятной ответственностью и мерами реагирования.
  
• Таблицы зависимостей – это явное описание того, кто от кого и в какой момент зависит (между командами, задачами, системами). Нужна, чтобы избежать классического «мы ждали их» — зависимости становятся прозрачными, а блокеры прогнозируемыми.
  
• Журнал решений – это фиксация ключевых договорённостей: что решили, почему, когда и кто отвечает. Нужен, чтобы решения не терялись в чатах, не пересматривались по кругу и не зависели от памяти участников.

Антикризисный набор, план
Возвращение контроля не требует «тотальной трансформации». Оно требует:

• Заморозки создания новых рабочих чатов без явной цели и владельца.
  
• Внедрения простых правил: нет повестки — нет встречи; нет предварительных материалов — нет решения; нет ответственного — нет дальнейших действий.
  
• Назначьте единственный источник правды по статусу: доска, backlog или project page.
  
• Создайте три таблицы: риски, зависимости, решения.
  
• Зафиксируйте условия по сроку, качеству и риску: когда эскалируем, кому и в каком виде.
  
• Введите правило: каждое важное критичное решение вопроса должно быть записано в течение 24 часов.

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

• Риски — чтобы заранее видеть, где проект может сорваться. 
  
• Зависимости — чтобы понимать, что и от кого блокирует движение. 
  
• Решения — чтобы не возвращаться к одним и тем же обсуждениям.

Всё остальное вторично. Как только это появляется в системе, проект становится управляемым.
Здесь я разобрала лишь одну из проблем современного проектного управления. Отдельный большой слой — это принятие решений: почему они затягиваются, размываются и в итоге не фиксируются.
Подробно об этом написала здесь - https://habr.com/ru/companies/viju/articles/1028914/-Источник