Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как 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/
ссылка на оригинал статьи https://habr.com/ru/articles/1031294/