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

Критерии DCMA 2. Опережения (lead) Суть: использование опережений (отрицательного сдвига между задачами) признаётся недопустимым. Почему:       Опережения — это источник дополнительных рисков. Они означают, что задача-последователь начинается до завершения предшественника, что технически или организационно часто необоснованно.       Они вносят неопределённость: если предшественник задерживается, то опережение либо сжимается (что нарушает технологию), либо просто игнорируется, и план перестаёт быть управляемым.       Вместо опережений следует использовать декомпозицию задач и установление связей типа «Финиш–Старт» между более мелкими работами. Например, вместо опережения на 3 дня между «Разработкой ТЗ» и «Началом кодирования» лучше выделить промежуточные этапы, которые естественно заканчиваются раньше.             DCMA рекомендует стремиться к 0% задач с опережениями. Этот пункт должен быть включён в оценочные показатели качества плана и выявлять строки плана с отрицательными задержками для их последующего устранения.

Критерии DCMA: логика сети Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1. 1. Логика сети (не более 5% исключений) Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи. Почему это важно: Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования. Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы. Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения. Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).

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

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