Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как 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/
Комментарии (19)
itGuevara
04.05.2026 14:23Моя градация типов проектных менеджеров \ руководителей проектов:
- базовый уровень
- знаток PMBOK и еще двух десятков подобных (PRINCE2 etc), а также владение всеми перечисленными в статье инструментами и подходами
- "условный Берия" (менеджер советского атомного проекта): супер организатор + необходимый административный ресурс, но не разбирается в сути проекта
- главный конструктор "условный Королев \ Туполев"Это вот к чему. Классика проектного управления подразумевает, что проектный менеджер не обязательно должен хорошо разбираться в сути проекта (номенклатура типов проектов у него может быть "разношерстная"). Т.е. ему нужно хорошо знать ТОЛЬКО теорию и практику проектного управления, но не тематику проекта. А если у проектного менеджера нет достаточных полномочий, то это вообще всего лишь администратор проекта (секретарь проекта), хотя формально их часто все равно называют проектными менеджерами.
Однако большинство "телодвижений" в проекте, в том числе указанных в статье, просто отбрасывается (не нужны), когда менеджер проекта хорошо понимает саму технологию \ результат \ продукт проекта, т.е. фактически является или может быть Главным конструктором (условный Туполев). Это относится и к небольшим проектам (не зависит от масштаба) и к проектным менеджерам со стороны заказчика (со стороны подрядчика - тем более).
Указанное наиболее критично для высокотехнологичных проектов. Для "стройки" слово "главный конструктор" меняем на "главный инженер проекта" (ГИП), но суть остается.
Binataki Автор
04.05.2026 14:23При глубоком понимании предметной области
многие телодвижения отпадают»ъ. На практике они не исчезают, а трансформируются: меньше формализма ради формализма, но больше точечных управленческих решений, завязанных на контекст. У «условного Туполева» просто часть инструментов уходит «в голову» и перестаёт быть явной.Полномочия - без них любой уровень (хоть PMBOK-гуру, хоть «Берия») скатывается в координацию и протоколирование.
В высокотехе, как вы правильно отметили, роль предметной экспертизы критична. Но там же появляется и риск: сильный главный конструктор иногда начинает игнорировать управленческие практики как лишние, и проект начинает зависеть от одного человека.
Georgij19761976
04.05.2026 14:23У меня только ВУЗ со специальностью менеджмент, учился в 90е, ничего подобного нам не рассказывали на лекциях, очень интересная статья(или пост, я в этом не разбираюсь), я ее сохранил.
nmouse
04.05.2026 14:23Так и не понял, а чего нового? Кстати, к вашему обязательному списку добавил бы парочку проектных дашбордов (в зависимости от интересов стейкхолдеров, возможно, от их flight level), еще можно докинуть ЧаВо, который ведёт РП и который помогает по сто раз не обсуждать в чатах одно и тоже. Ааа... Забыл о worklog где-нибудь недалеко от дашбордов, чтобы не рехнуться когда тебя руководитель попросить дать детальный статус по проекту на 20+ команд за месяц... И ты будешь час двадцать из полуторачасовой встречи тараторить )))
Ну и что-то по фидбэку нужно добавить: завести где-нибудь анонимную фидбэколку (можно и неананимную, но работает хуже), где любой из участников забега, а не только рукотдела, тимлиды и другие управленцы), а простой тестировщик Вася сможет излить свою вселенскую боль, а иногда и предложения не только на тему поиска огнетушителя.
Еще у меня как-то пользовалось популярностью: час с РП, куда мог прийти любой Вася и обсудить со мной что угодно, а не только про работу. В основном, приходили тимлиды и системные аналитики... Несколько раз заглядывали SRE и сеньеры разработчики, один раз рукотдела. Благодаря этому собиралось огромное количество информации о том, что реально твориться на проекте и в командах разработки... Делались соответствующие выводы. Один минус: большинство этой информации нельзя было открыто выносить в обсуждение, а тем более писать в MN, приходилось придумывать всяких птичек с хвоста которых что-то падало, ну и если знаешь где что-то чешется можно методом внимательного всматривания и задавания вопросов что-то вдруг обнаружить )))
Binataki Автор
04.05.2026 14:23Нового здесь и не задумывалось. Это скорее про сборку рабочей системы из базовых элементов и акценты на том, как они связаны между собой, а не про изобретение очередного фреймворка.
Вы как раз хорошо дополнили картину практическими штуками: дашборды под разные уровни, FAQ от РП, worklog, фидбэк-каналы и «час с РП»
По сути, это всё про одно и то же: уменьшение шума, ускорение принятия решений и повышение прозрачности. Просто в статье я сознательно не стал разрастаться в полный каталог практик - иначе она превратилась бы в чек-лист на 3 экрана.
nmouse
04.05.2026 14:23Всё-таки прикопаю у себя Ваш дашборд. Назову его: "Как вкатиться в проект на полпути" ))) Чёт на свежую голову покрутил его - может быть полезно, прежде чем что-то своё начинать крутить. Спасибо
Pulso
04.05.2026 14:23Куча лозунгов, ноль решений.
Как вы формируете реест рисков, что это вообще за мифический зверь?
Как вы организуете работу с документаций, групповой работой в оной, версионностью и при этом синхронизирует ваши чаты с этим хранилищем?
Как выстроена воронка и БП проектного управления/изменений?
Куча слов о системном подходе и не одного примера этой системы. Очередной Джун+ набивает себе самооценку поверхностными и эмоциональными статьями на хабре.
Binataki Автор
04.05.2026 14:23Это статья-мнение, а не методическое руководство с пошаговыми регламентами и шаблонами. Её задача - обозначить подход и рамку мышления
Реестр рисков, управление документацией, версионность, воронки изменений -это базовые инструменты проектного управления. Они давно описаны в открытых источниках, и любой, кому действительно нужно углубление, без труда найдёт как определения, так и примеры реализации и шаблоны.
Если есть интерес к конкретным практикам - давайте обсуждать предметно: какой именно аспект вызывает вопросы (например, структура рисков, процессы изменений или организация)
andrevser
04.05.2026 14:23Я не понял загон. Почему проектный менеджмент умер? И почему теперь их не ведут, а только синхронизируют?
Какие-то проекты ведут, другие только синхронизируют, третьи - сначала ведут, а потом только синхронизируют
На каких-то проектах нужен по сути секретарь (как четко выразились выше), на каких-то - полноценный лидер, ведущий и команду и проект. Проекты всегда были разные, и вместе с менеджерами на них разными и остались
ArtiVol
04.05.2026 14:23каждое важное критичное решение вопроса должно быть записано в течение 24 часов.
По возможности, я бы фиксировал до конца рабочего дня. Тут не так важно само время, сколько то, успел ли человек задачу "отложить". А за сутки он гарантированно успеет отложить всю работу разом.
Logotipza
04.05.2026 14:23К сожалению не работал инхаус, но в заказной вытащил для себя несколько столпов работы с проектами:
Сильная, взрослая, ответственная команда либо по ответственному спецу по своему направлению с командой за которую он готов отвечать - это база
РП не мудак и не сыкло. Тут главное, чтобы команда видела и понимала, что чел готов разбираться в том числе с техничкой и готов брать на себя ответственность за конечный результат
В идеале адекватные сейлы, заказчик и руководство. Что это значит: если команда оценила проект в полгода, сейл и руководство не принимают "волевого" решения пообещать заказчику закрыть за месяц, по сути просто осознанно отдавая команду на сожжение. Тут немного задевает второй пункт: если у менеджера есть яйца и он готов рисковать своим местом в том числе, давая правдивую инфу сейлам, руководителям и заказчику, то он имхо хороший менеджер, а не приспособленец, про которых как раз говорят разработчики, что не нужны они
Когда эти 3 элемента есть, тогда можно строить систему и множество огрехов будут сглаживаться тем, что команда понимает нафига тут вообще ты и заказчик в идеале видит, что ты не обманываешь.
Понимаю, что похоже на сферического коня в вакууме, но лучше уж так, чем обращаться книжками и табличками, но делать щит и быть нанавидимым своими реьятами
Croki
Если я не буду отвечать на сообщения, со стороны это может выглядеть как отсутствие на рабочем месте. Для руководителя это может создать ложное впечатление.
Поэтому и приходиться прыгать через задачи
Binataki Автор
Может, имеет смысл договориться о приоритетах: какие вопросы требуют быстрой реакции, а какие могут подождать. Так получится сохранить и прозрачность, и фокус на задачах.