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

Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.

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

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

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

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

2. Чат – хранилище

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

3. Daily – статус-театр

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

4. Созвон – обезбол

Созвон даёт приятное ощущение движения: все собрались, поговорили, вроде бы договорились. Но если после него не обновились backlog, таблицы зависимостей, реестр рисков и журнал решений, проект не стал управляемее и по факту ничего не изменилось.

Как Project Manager должен работать сегодня? 

Роль менеджера  — не в том, чтобы быть «на связи», а в управлении задачами, рисками и решениями. На практике это означает:

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

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

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

• Встречи проходят не потому, что тревожно, а потому, что без них нельзя! Хорошее правило простое: нет повестки — нет встречи; нет предварительных материалов — нет решения; нет ответственного — нет дальнейших действий.

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

Артефакты, без которых PM превращается в синхронизатора

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

1. Реестр рисков – это список всех значимых рисков проекта с оценкой вероятности и влияния, а также планом действий. Нужен, чтобы риски не «всплывали внезапно», а управлялись заранее — с понятной ответственностью и мерами реагирования.

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

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

Антикризисный набор, план

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

• Заморозки создания новых рабочих чатов без явной цели и владельца.

• Внедрения простых правил: нет повестки — нет встречи; нет предварительных материалов — нет решения; нет ответственного — нет дальнейших действий.

• Назначьте единственный источник правды по статусу: доска, backlog или project page.

• Создайте три таблицы: риски, зависимости, решения.

• Зафиксируйте условия по сроку, качеству и риску: когда эскалируем, кому и в каком виде.

• Введите правило: каждое важное критичное решение вопроса должно быть записано в течение 24 часов.

Если после этой статьи вы сделаете только одно — перестаньте решать задачи в чатах. 

Зафиксируйте три вещи: риски, зависимости и решения.

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

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

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

Всё остальное вторично. Как только это появляется в системе, проект становится управляемым.

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

Подробно об этом написала здесь — https://habr.com/ru/companies/viju/articles/1028914/