Коммуникация — это не «поговорить», это «не переделывать дважды»
Каждый PM сталкивался: задача ушла в чат, ответа нет, сроки горят. А через неделю выясняется, что все поняли задачу по-разному. Итог — переделка, задержки, нервотрёпка.
Исследования показывают: внедрение инструментов для управления коммуникациями позволяет снизить риски дублирования задач и повысить скорость принятия решений в среднем на 15–20%. А оптимальное соотношение времени на коммуникации и индивидуальную работу — 25–30% к 70–75% соответственно.
Хаос в коммуникациях — это не «мелочь». Это сорванные сроки, потерянные документы, переделки и штрафы.
Решение не в том, чтобы проводить больше совещаний. А в том, чтобы создать единую информационную среду, где задачи не теряются, файлы не дублируются, а ответы не ждут по три дня.
И да, если ваша команда до сих пор обсуждает статусы задач в пяти разных чатах — вы не управляете проектом. Вы играете в «найди информацию». А это совсем не весело.
Каждый PM сталкивался: задача ушла в чат, ответа нет, сроки горят. А через неделю выясняется, что все поняли задачу по-разному. Итог — переделка, задержки, нервотрёпка.
Исследования показывают: внедрение инструментов для управления коммуникациями позволяет снизить риски дублирования задач и повысить скорость принятия решений в среднем на 15–20%. А оптимальное соотношение времени на коммуникации и индивидуальную работу — 25–30% к 70–75% соответственно.
Хаос в коммуникациях — это не «мелочь». Это сорванные сроки, потерянные документы, переделки и штрафы.
Решение не в том, чтобы проводить больше совещаний. А в том, чтобы создать единую информационную среду, где задачи не теряются, файлы не дублируются, а ответы не ждут по три дня.
И да, если ваша команда до сих пор обсуждает статусы задач в пяти разных чатах — вы не управляете проектом. Вы играете в «найди информацию». А это совсем не весело.
5 правил, чтобы коммуникации перестали тормозить проект
Мессенджеры ускорили общение, но одновременно убрали границы между обсуждением и принятием решений. Проект начинает «плыть» — договоренности теряются в переписке, участники по-разному понимают, о чём договорились.
1. Составьте план коммуникаций
Документ, где фиксируют правила общения команды: где переписываются, как хранят знания, как описывают задачи, как часто собираются.
Зачем: экономить время команды, выстроить понятные процессы, повысить прозрачность работы.
2. Разграничьте каналы
Мессенджеры — для оперативного обсуждения. Почта и документы — для фиксации решений.
Чем быстрее вы общаетесь, тем важнее отдельно фиксировать, о чём договорились. Если обсуждения, задачи и решения не разделены — проект начинает расползаться по переписке.
3. Ведите регулярные встречи
Ежедневные короткие встречи с командой — обсудить планы и статусы. Регулярные встречи с заказчиками — для отчётов.
И главное: заранее согласовывайте повестку. Вопросы, которые становятся неожиданностью, вызывают только раздражение.
4. Используйте единую систему
Создание единой информационной среды — эффективный способ избежать хаоса. Когда нет единой платформы, сотрудники тратят время на проверку сообщений в разных каналах, поиск файлов, а критичная информация теряется.
5. Назначьте ответственных за потоки информации
Используйте RACI-матрицу — назначайте ответственность не только за задачи, но и за конкретные информационные потоки: кто должен быть в курсе, а кто — утверждать.
Коротко
Коммуникации тормозят проект не потому, что их много. А потому, что они хаотичны.
Правила, единая среда и чёткое разделение каналов превращают хаос в управляемый процесс. И тогда проект перестаёт быть игрой в «найди информацию».
Мессенджеры ускорили общение, но одновременно убрали границы между обсуждением и принятием решений. Проект начинает «плыть» — договоренности теряются в переписке, участники по-разному понимают, о чём договорились.
1. Составьте план коммуникаций
Документ, где фиксируют правила общения команды: где переписываются, как хранят знания, как описывают задачи, как часто собираются.
Зачем: экономить время команды, выстроить понятные процессы, повысить прозрачность работы.
2. Разграничьте каналы
Мессенджеры — для оперативного обсуждения. Почта и документы — для фиксации решений.
Чем быстрее вы общаетесь, тем важнее отдельно фиксировать, о чём договорились. Если обсуждения, задачи и решения не разделены — проект начинает расползаться по переписке.
3. Ведите регулярные встречи
Ежедневные короткие встречи с командой — обсудить планы и статусы. Регулярные встречи с заказчиками — для отчётов.
И главное: заранее согласовывайте повестку. Вопросы, которые становятся неожиданностью, вызывают только раздражение.
4. Используйте единую систему
Создание единой информационной среды — эффективный способ избежать хаоса. Когда нет единой платформы, сотрудники тратят время на проверку сообщений в разных каналах, поиск файлов, а критичная информация теряется.
5. Назначьте ответственных за потоки информации
Используйте RACI-матрицу — назначайте ответственность не только за задачи, но и за конкретные информационные потоки: кто должен быть в курсе, а кто — утверждать.
Коротко
Коммуникации тормозят проект не потому, что их много. А потому, что они хаотичны.
Правила, единая среда и чёткое разделение каналов превращают хаос в управляемый процесс. И тогда проект перестаёт быть игрой в «найди информацию».
«Pulse of the Profession 2026: Driving Success in Complex Projects»
Интересные цифр приводит PMI в своем ежегодном отчете:
· 81% проектных менеджеров признали: проекты стали сложнее, 37% —значительный рост сложности
· 97% за последний год вели хотя бы один сложный проект, более половины — «исключительно сложные»
· ~31% сложных проектов проваливаются — почти вдвое выше среднего (13%)
Драйверы — внедрение ИИ, сдвиг ожиданий стейкхолдеров, экономическая волатильность, взаимосвязь систем.
Что делать? Не пытаться ужесточить контроль. Смещать фокус с задач на системы, с активности — на результат, с соблюдения процедур — на согласованность.
Сложность не исчезнет. Меняйте подход.
#управлениепроектами #PM #PMI #PulseOfTheProfession #сложность
Интересные цифр приводит PMI в своем ежегодном отчете:
· 81% проектных менеджеров признали: проекты стали сложнее, 37% —значительный рост сложности
· 97% за последний год вели хотя бы один сложный проект, более половины — «исключительно сложные»
· ~31% сложных проектов проваливаются — почти вдвое выше среднего (13%)
Драйверы — внедрение ИИ, сдвиг ожиданий стейкхолдеров, экономическая волатильность, взаимосвязь систем.
Что делать? Не пытаться ужесточить контроль. Смещать фокус с задач на системы, с активности — на результат, с соблюдения процедур — на согласованность.
Сложность не исчезнет. Меняйте подход.
#управлениепроектами #PM #PMI #PulseOfTheProfession #сложность
Замена ресурсов в MS Project: когда VBA спасает ваш график
Представьте: несколько десятков, а то и сотен задач. В них задействованы по 2–3 исполнителя. Один выбывает. Нужно заменить только его, оставив остальных с их сохранить все расчетные трудозатраты.
Штатная замена ресурсов в MS Project работает грубо — меняет все назначения на выбранного ресурса по всем задачам. При нескольких ресурсах на задаче это ломает пропорции: либо добавляет нового поверх старого, либо перезаписывает всё целиком.
VBA решает точечно:
· Анализирует все назначения в выбранных задачах
· Находит конкретного сотрудника
· Заменяет его на нового, не трогая остальных исполнителей
· Копирует объём работ и единицы измерения со старого назначения
Итог:
Никакого ручного перебора сотен задач. Никакого риска задеть чужие трудозатраты. Только точная замена выбывшего — с сохранением остальной структуры.
#управлениепроектами #PM #MSProject #VBA #ресурсы
Представьте: несколько десятков, а то и сотен задач. В них задействованы по 2–3 исполнителя. Один выбывает. Нужно заменить только его, оставив остальных с их сохранить все расчетные трудозатраты.
Штатная замена ресурсов в MS Project работает грубо — меняет все назначения на выбранного ресурса по всем задачам. При нескольких ресурсах на задаче это ломает пропорции: либо добавляет нового поверх старого, либо перезаписывает всё целиком.
VBA решает точечно:
· Анализирует все назначения в выбранных задачах
· Находит конкретного сотрудника
· Заменяет его на нового, не трогая остальных исполнителей
· Копирует объём работ и единицы измерения со старого назначения
Итог:
Никакого ручного перебора сотен задач. Никакого риска задеть чужие трудозатраты. Только точная замена выбывшего — с сохранением остальной структуры.
#управлениепроектами #PM #MSProject #VBA #ресурсы
Риск-менеджмент: твой план A умер в 7:15. Что дальше?
Сегодня мой аккумуляторный триммер совершил героический переход в разряд «исторических артефактов». Ровно за 15 минут до выхода на важную встречу с заказчиком.
Никакого предупреждения. Никаких «низких батарей» или посторонних звуков. Просто щелчок — и ротор встал. В этот момент ты осознаешь разницу между оптимизмом и реальностью. Очень не хочется идти на встречу, когда выбрито пол-лица.
Но, будучи PM, я подсознательно заложил себе подстраховку ещё несколько лет назад. В глубине шкафа пылилась древняя упаковка безопасных бритв, купленная «на всякий случай».
Итог:
— Встреча не сорвана.
— Клиент не увидел «небритого чувака из лесу».
— Триммер уехал в корзину с чувством выполненного долга. Кстати ему исполнилось ровно 2 года.
Короткие выводы для наших рабочих реалий:
1. Реестр рисков должен быть не в только в таблице Excel. Вы обязаны знать хотя бы 3 сценария отказа любого критического элемента. Даже если это просто ваш личный гаджет.
2. План Б не обязан быть изящным. Он обязан быть рабочим. Старая бритва, резервный ноутбук, флешка с презентацией в кармане пиджака — это не архаизм, это ваш «святой Грааль».
3. Кризис наступает в самый неподходящий момент. Не когда у вас есть свободные 2 часа, а когда на счету каждая минута. Если ваш план отказоустойчивости не рассчитан на форс-мажор в 7 утра — это не план, это иллюзия.
И да, сегодня я побрился как мой дед в 80-х — медленно, страшно, но эффективно. Главное — результат, а не инструмент.
Проверьте свои «запасные бритвы» в проектах, пока они ещё лежат на полке.
Ваши риски управляемы? Или вы до сих пор верите, что триммер не сломается?
Напишите в комментариях, с чем вам приходилось сталкиваться на проектах и в быту.
#УправлениеРисками #ProjectManagement #БытоваяАналогия #Антикризис #ПланБ
Сегодня мой аккумуляторный триммер совершил героический переход в разряд «исторических артефактов». Ровно за 15 минут до выхода на важную встречу с заказчиком.
Никакого предупреждения. Никаких «низких батарей» или посторонних звуков. Просто щелчок — и ротор встал. В этот момент ты осознаешь разницу между оптимизмом и реальностью. Очень не хочется идти на встречу, когда выбрито пол-лица.
Но, будучи PM, я подсознательно заложил себе подстраховку ещё несколько лет назад. В глубине шкафа пылилась древняя упаковка безопасных бритв, купленная «на всякий случай».
Итог:
— Встреча не сорвана.
— Клиент не увидел «небритого чувака из лесу».
— Триммер уехал в корзину с чувством выполненного долга. Кстати ему исполнилось ровно 2 года.
Короткие выводы для наших рабочих реалий:
1. Реестр рисков должен быть не в только в таблице Excel. Вы обязаны знать хотя бы 3 сценария отказа любого критического элемента. Даже если это просто ваш личный гаджет.
2. План Б не обязан быть изящным. Он обязан быть рабочим. Старая бритва, резервный ноутбук, флешка с презентацией в кармане пиджака — это не архаизм, это ваш «святой Грааль».
3. Кризис наступает в самый неподходящий момент. Не когда у вас есть свободные 2 часа, а когда на счету каждая минута. Если ваш план отказоустойчивости не рассчитан на форс-мажор в 7 утра — это не план, это иллюзия.
И да, сегодня я побрился как мой дед в 80-х — медленно, страшно, но эффективно. Главное — результат, а не инструмент.
Проверьте свои «запасные бритвы» в проектах, пока они ещё лежат на полке.
Ваши риски управляемы? Или вы до сих пор верите, что триммер не сломается?
Напишите в комментариях, с чем вам приходилось сталкиваться на проектах и в быту.
#УправлениеРисками #ProjectManagement #БытоваяАналогия #Антикризис #ПланБ
Безопасность VBA в MS Project: защита данных и кода
Автоматизация в MS Project через VBA экономит часы работы, но требует осознанного подхода к безопасности. Рассмотрим ключевые риски и способы их минимизации.
Кейс №1: «Случайное удаление»
Планировщик запустил макрос для обновления статусов задач. Из-за отсутствия обработки ошибок и проверки макрос перезаписал даты начала не в той задаче. Результат — потеря данных и ручное восстановление из резервной копии.
Решение: Используйте обработчик ошибок.
Кейс №2: «Несанкционированное изменение»
Разработчик VBA передал коллеге MPP-файл с макросами. Коллега случайно изменил код в одном из модулей, после чего макрос стал работать некорректно, а ошибка проявилась только через месяц.
Решение: Защитите код VBA паролем.
Три базовых правила безопасности работы с VBA обсудим на онлайн-курсе "VBA в Microsoft Project".
Резюме: VBA — мощный инструмент, но его сила требует ответственности. Парольная защита кода, корректная обработка ошибок и осознанные настройки безопасности макросов — минимальный набор, который убережёт ваш проект от потери данных и непредвиденных сбоев.
Автоматизация в MS Project через VBA экономит часы работы, но требует осознанного подхода к безопасности. Рассмотрим ключевые риски и способы их минимизации.
Кейс №1: «Случайное удаление»
Планировщик запустил макрос для обновления статусов задач. Из-за отсутствия обработки ошибок и проверки макрос перезаписал даты начала не в той задаче. Результат — потеря данных и ручное восстановление из резервной копии.
Решение: Используйте обработчик ошибок.
Кейс №2: «Несанкционированное изменение»
Разработчик VBA передал коллеге MPP-файл с макросами. Коллега случайно изменил код в одном из модулей, после чего макрос стал работать некорректно, а ошибка проявилась только через месяц.
Решение: Защитите код VBA паролем.
Три базовых правила безопасности работы с VBA обсудим на онлайн-курсе "VBA в Microsoft Project".
Резюме: VBA — мощный инструмент, но его сила требует ответственности. Парольная защита кода, корректная обработка ошибок и осознанные настройки безопасности макросов — минимальный набор, который убережёт ваш проект от потери данных и непредвиденных сбоев.
8 постов за прошедшую неделю, VBA, ИИ, риски и статистика от PMI.
1. VBA в MS Project автоматизирует до 80% рутины — замена ресурсов, отчёты, календари одной командой.
2. Постановка цели с ИИ устраняет неоднозначности: модель дополняет ограничения, человек принимает финальные решения.
3. Цель проекта — «что сделать», OKR — «как измерить», KPI — мониторинг процесса; ИИ помогает уточнять все три, но не смешивать их.
4. Хаос в коммуникациях — главный тормоз: единая среда, разделение каналов и RACI по потокам информации сокращают переделки на 15–20%.
5. PMI 2026: 81% проектов усложнились, провал сложных — 31% против 13% средних; выход — фокус на системах и согласованности, а не контроле.
6. Штатная замена ресурсов в MS Project ломает пропорции — VBA точечно меняет одного исполнителя, копируя его трудозатраты.
7. Риск-менеджмент: план Б должен быть рабочим, а не изящным — проверьте свои «запасные бритвы» до того, как кризис наступит в 7 утра.
8. Безопасность VBA: защита кода паролем, обработка ошибок и осознанные настройки — минимальный набор против потери данных.
1. VBA в MS Project автоматизирует до 80% рутины — замена ресурсов, отчёты, календари одной командой.
2. Постановка цели с ИИ устраняет неоднозначности: модель дополняет ограничения, человек принимает финальные решения.
3. Цель проекта — «что сделать», OKR — «как измерить», KPI — мониторинг процесса; ИИ помогает уточнять все три, но не смешивать их.
4. Хаос в коммуникациях — главный тормоз: единая среда, разделение каналов и RACI по потокам информации сокращают переделки на 15–20%.
5. PMI 2026: 81% проектов усложнились, провал сложных — 31% против 13% средних; выход — фокус на системах и согласованности, а не контроле.
6. Штатная замена ресурсов в MS Project ломает пропорции — VBA точечно меняет одного исполнителя, копируя его трудозатраты.
7. Риск-менеджмент: план Б должен быть рабочим, а не изящным — проверьте свои «запасные бритвы» до того, как кризис наступит в 7 утра.
8. Безопасность VBA: защита кода паролем, обработка ошибок и осознанные настройки — минимальный набор против потери данных.
❤1
Ваш план управления проектом — это броня или бумага?
Мы все пишем красивые документы. А потом наступает форс-мажор — и оказывается, что бумажный план годится разве что на подставку для кофе.
Давайте без теории. Есть один народный тест на «живучесть» плана:
Если ваш ключевой разработчик заболел, а заказчик не хочет сдвинуть сроки — у вас есть готовый ответ в плане или вы начинаете импровизировать?
А теперь честно: как вы обычно проверяете, что план действительно рабочий?
Может, у вас есть эпичная история, когда план треснул по швам в самый неподходящий момент?
Пишите в комментарии — самые смешные или неожиданные ситуации с планированием. У кого был проект, который шёл строго по плану?
Спойлер: у меня есть «тест плана», но о нём расскажу позже.
Мы все пишем красивые документы. А потом наступает форс-мажор — и оказывается, что бумажный план годится разве что на подставку для кофе.
Давайте без теории. Есть один народный тест на «живучесть» плана:
Если ваш ключевой разработчик заболел, а заказчик не хочет сдвинуть сроки — у вас есть готовый ответ в плане или вы начинаете импровизировать?
А теперь честно: как вы обычно проверяете, что план действительно рабочий?
Может, у вас есть эпичная история, когда план треснул по швам в самый неподходящий момент?
Пишите в комментарии — самые смешные или неожиданные ситуации с планированием. У кого был проект, который шёл строго по плану?
Спойлер: у меня есть «тест плана», но о нём расскажу позже.
Как проверить качество календарного плана проекта
Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология DCMA (Defense Contract Management Agency), включающая 14 точек контроля.
Применение этой методики позволяет снизить количество проблемных мест до единичных случаев.
Критерии DCMA:
1. Логика сети — все задачи должны иметь предшественников/последователей (допустимо не более 5% исключений).
2. Отсутствие опережений — использование опережений (lead) недопустимо, заменяется декомпозицией и связями.
3. Минимизация задержек — не более 5% задач с задержками (lag), без включения резервов.
4. Тип связей — не менее 90% связей типа «Финиш–Старт» (FS).
5. Ограничения задач — не более 5% задач с типом, отличным от «Как можно раньше» (ASAP).
6. Общий резерв — не более 44 рабочих дней (2 мес.) для не более 5% задач.
7. Отрицательный резерв — недопустим.
8. Длительность задачи — не более 44 рабочих дней (требует декомпозиции).
9. Корректность дат — фактические даты не могут быть в будущем.
10. Обеспеченность ресурсами — каждая задача должна иметь назначенный ресурс.
11. Отстающие задачи — не более 5% от базового плана.
12. Тест критического пути — сдвиг критической задачи должен сдвигать срок проекта.
13. Индекс критического пути (CPLI) — целевое значение 1,0, допустимо до 0,95.
14. Индекс выполнения базового плана (BEI) — целевое значение 1,0, допустимо до 0,95.
По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану.
В следующих постах детально обсудим каждый пункт.
Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология DCMA (Defense Contract Management Agency), включающая 14 точек контроля.
Применение этой методики позволяет снизить количество проблемных мест до единичных случаев.
Критерии DCMA:
1. Логика сети — все задачи должны иметь предшественников/последователей (допустимо не более 5% исключений).
2. Отсутствие опережений — использование опережений (lead) недопустимо, заменяется декомпозицией и связями.
3. Минимизация задержек — не более 5% задач с задержками (lag), без включения резервов.
4. Тип связей — не менее 90% связей типа «Финиш–Старт» (FS).
5. Ограничения задач — не более 5% задач с типом, отличным от «Как можно раньше» (ASAP).
6. Общий резерв — не более 44 рабочих дней (2 мес.) для не более 5% задач.
7. Отрицательный резерв — недопустим.
8. Длительность задачи — не более 44 рабочих дней (требует декомпозиции).
9. Корректность дат — фактические даты не могут быть в будущем.
10. Обеспеченность ресурсами — каждая задача должна иметь назначенный ресурс.
11. Отстающие задачи — не более 5% от базового плана.
12. Тест критического пути — сдвиг критической задачи должен сдвигать срок проекта.
13. Индекс критического пути (CPLI) — целевое значение 1,0, допустимо до 0,95.
14. Индекс выполнения базового плана (BEI) — целевое значение 1,0, допустимо до 0,95.
По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану.
В следующих постах детально обсудим каждый пункт.
Критерии DCMA: логика сети
Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1.
1. Логика сети (не более 5% исключений)
Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи.
Почему это важно:
Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования.
Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы.
Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения.
Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).
Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1.
1. Логика сети (не более 5% исключений)
Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи.
Почему это важно:
Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования.
Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы.
Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения.
Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).