Управление проектами

Как проверить качество календарного плана проекта Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология 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. По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану. В следующих постах детально обсудим каждый пункт.

Ваш план управления проектом — это броня или бумага?  Мы все пишем красивые документы. А потом наступает форс-мажор — и оказывается, что бумажный план годится разве что на подставку для кофе. Давайте без теории. Есть один народный тест на «живучесть» плана: Если ваш ключевой разработчик заболел, а заказчик не хочет сдвинуть сроки — у вас есть готовый ответ в плане или вы начинаете импровизировать? А теперь честно: как вы обычно проверяете, что план действительно рабочий? Может, у вас есть эпичная история, когда план треснул по швам в самый неподходящий момент? Пишите в комментарии — самые смешные или неожиданные ситуации с планированием. У кого был проект, который шёл строго по плану? Спойлер: у меня есть «тест плана», но о нём расскажу позже.

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: защита кода паролем, обработка ошибок и осознанные настройки — минимальный набор против потери данных.

Безопасность VBA в MS Project: защита данных и кода Автоматизация в MS Project через VBA экономит часы работы, но требует осознанного подхода к безопасности. Рассмотрим ключевые риски и способы их минимизации. Кейс №1: «Случайное удаление» Планировщик запустил макрос для обновления статусов задач. Из-за отсутствия обработки ошибок и проверки макрос перезаписал даты начала не в той задаче. Результат — потеря данных и ручное восстановление из резервной копии. Решение: Используйте обработчик ошибок.   Кейс №2: «Несанкционированное изменение» Разработчик VBA передал коллеге MPP-файл с макросами. Коллега случайно изменил код в одном из модулей, после чего макрос стал работать некорректно, а ошибка проявилась только через месяц. Решение: Защитите код VBA паролем. Три базовых правила безопасности работы с VBA обсудим на онлайн-курсе "VBA в Microsoft Project". Резюме: VBA — мощный инструмент, но его сила требует ответственности. Парольная защита кода, корректная обработка ошибок и осознанные настройки безопасности макросов — минимальный набор, который убережёт ваш проект от потери данных и непредвиденных сбоев.