Критерий DCMA №8
Длительность задачи — не более 44 рабочих дней.
Продолжаем разбор методики DCMA.
Восьмой пункт устанавливает: длительность задачи не должна превышать 44 рабочих дней (около 2 месяцев). Задачи большей длительности требуют декомпозиции.
Почему это критично:
Длительная задача скрывает реальный прогресс, контроль такой задачи становится малоэффективным. DCMA прямо указывает: длинные задачи скрывают детали реальной работы. Аналогичный подход описан в документации Microsoft по работе с длительностью задач.
Кроме того, длительные задачи искажают расчёт критического пути и резервов. Система не может корректно оценить, где именно возникает отклонение, пока задача не завершится.
Как проверять в MS Project с помощью VBA:
Вместо ручного просмотра сотен строк плана можно написать макрос, который автоматически выявит задачи с длительностью более 44 рабочих дней и пометит их для декомпозиции.
Код проходит по всем задачам активного проекта, сравнивает длительность с порогом (44 рабочих дня) и помечает нарушителей в текстовом поле для последующего анализа.
Можно заменить код установкой соответствующего фильтра, но если вы проверяете другие критерии DCMA, то вам придется ставить как минимум 14 разных фильтров.
Практический результат:
Внедрение такой проверки в регламент контроля качества планов позволяет:
- Автоматически выявлять задачи, требующие декомпозиции, до утверждения базового плана.
- Снижать риски срыва сроков за счёт более детального контроля.
- Формировать отчётность по критерию DCMA №8 без ручного труда.
44 дня — разумный порог. Если задача длится дольше, её нужно разбить на подзадачи. А VBA в MS Project делает эту проверку рутинной и безошибочной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Длительность задачи — не более 44 рабочих дней.
Продолжаем разбор методики DCMA.
Восьмой пункт устанавливает: длительность задачи не должна превышать 44 рабочих дней (около 2 месяцев). Задачи большей длительности требуют декомпозиции.
Почему это критично:
Длительная задача скрывает реальный прогресс, контроль такой задачи становится малоэффективным. DCMA прямо указывает: длинные задачи скрывают детали реальной работы. Аналогичный подход описан в документации Microsoft по работе с длительностью задач.
Кроме того, длительные задачи искажают расчёт критического пути и резервов. Система не может корректно оценить, где именно возникает отклонение, пока задача не завершится.
Как проверять в MS Project с помощью VBA:
Вместо ручного просмотра сотен строк плана можно написать макрос, который автоматически выявит задачи с длительностью более 44 рабочих дней и пометит их для декомпозиции.
Код проходит по всем задачам активного проекта, сравнивает длительность с порогом (44 рабочих дня) и помечает нарушителей в текстовом поле для последующего анализа.
Можно заменить код установкой соответствующего фильтра, но если вы проверяете другие критерии DCMA, то вам придется ставить как минимум 14 разных фильтров.
Практический результат:
Внедрение такой проверки в регламент контроля качества планов позволяет:
- Автоматически выявлять задачи, требующие декомпозиции, до утверждения базового плана.
- Снижать риски срыва сроков за счёт более детального контроля.
- Формировать отчётность по критерию DCMA №8 без ручного труда.
44 дня — разумный порог. Если задача длится дольше, её нужно разбить на подзадачи. А VBA в MS Project делает эту проверку рутинной и безошибочной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Atlassian решила: пусть агенты работают
Atlassian анонсировала новые возможности в Jira и DX для управления агентной разработкой. И вот главная цифра: 94% инженерных руководителей используют ИИ, но только 6% имеют системы, чтобы масштабировать его на весь жизненный цикл разработки.
Что теперь умеет Jira:
- Code Context. Агенты получают доступ к знаниям о многопозиционных кодовых базах через Teamwork Graph.
- Agent Context Controls. Платформенные команды решают, к каким пространствам Jira и Confluence агенты имеют доступ.
- Agent loops in Jira. Агенты сканируют бэклог, берут нераспределённые задачи, генерируют код и создают pull-запросы прямо в Jira.
- DX for Agentic Development. Измеряет влияние ИИ на пропускную способность, качество, адоптацию и стоимость.
64% прирост производительности получили команды, чьи ИИ-инструменты использовали больше контекста Atlassian. То есть если дать агенту правильный контекст — он работает. Не дать — получаете код, который «вроде работает, но не так».
https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows
#Atlassian #Jira #AI #AgenticEngineering #ProjectManagement #PMO
Atlassian анонсировала новые возможности в Jira и DX для управления агентной разработкой. И вот главная цифра: 94% инженерных руководителей используют ИИ, но только 6% имеют системы, чтобы масштабировать его на весь жизненный цикл разработки.
Что теперь умеет Jira:
- Code Context. Агенты получают доступ к знаниям о многопозиционных кодовых базах через Teamwork Graph.
- Agent Context Controls. Платформенные команды решают, к каким пространствам Jira и Confluence агенты имеют доступ.
- Agent loops in Jira. Агенты сканируют бэклог, берут нераспределённые задачи, генерируют код и создают pull-запросы прямо в Jira.
- DX for Agentic Development. Измеряет влияние ИИ на пропускную способность, качество, адоптацию и стоимость.
64% прирост производительности получили команды, чьи ИИ-инструменты использовали больше контекста Atlassian. То есть если дать агенту правильный контекст — он работает. Не дать — получаете код, который «вроде работает, но не так».
https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows
Atlassian — австралийская компания-разработчик программного обеспечения для командной работы и управления проектами, основанная в 2002 году в Сиднее Майком Кэннон-Бруксом и Скоттом Фаркуаром. Её флагманские продукты — трекер задач Jira и корпоративная вики Confluence — используются более чем 20 000 организаций по всему миру, включая Microsoft, Oracle, Amazon и NASA. Штаб-квартира компании находится в Сан-Франциско, а сама она является публичной (NASDAQ: TEAM) с рыночной капитализацией около $42,5 млрд.
#Atlassian #Jira #AI #AgenticEngineering #ProjectManagement #PMO
Критерий DCMA №9:
Некорректные даты — недопустимы.
Продолжаем разбор методики DCMA. Девятый пункт устанавливает: в плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате.
Что это значит: если сегодня 16 сентября, а в плане у задачи стоит фактическое начало 20 сентября — это ошибка. Факт — это то, что уже произошло. Будущее может быть только планом, но не фактом.
Почему это важно:
- Некорректные даты искажают реальную картину проекта. Руководитель видит «факт», которого ещё не было, и принимает решения на основе недостоверных данных.
- Это сигнал о некачественном обновлении плана: либо даты проставлены «на автомате», либо план не синхронизирован с реальностью.
- Критерий напрямую связан с достоверностью отчётности. Если факт в будущем — отчёт не отражает реальное состояние проекта.
Как проверять в MS Project с помощью VBA:
Можно сделать ручную проверку путем установки фильтра. Но удобнее при помощи VBA, в нем можно закодировать проверку сразу 14 критериев. Макрос перебирает все задачи активного проекта, сравнивает поля «Фактическое начало» и «Фактическое окончание» с текущей датой и помечает нарушителей в текстовых полях (например, Text1 и Text2). Дальше достаточно поставить фильтр по этим полям — и все проблемные строки перед вами. Такую проверку можно запускать перед каждым формированием отчётности.
Внедрение такой проверки в регламент контроля качества планов позволяет:
· Автоматически выявлять задачи с некорректными фактическими датами до формирования отчётности.
· Снижать риски принятия решений на основе недостоверных данных.
Факт в будущем — это не «почти сделано». Это ошибка в данных. А VBA в MS Project делает проверку быстрой и регулярной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Некорректные даты — недопустимы.
Продолжаем разбор методики DCMA. Девятый пункт устанавливает: в плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате.
Что это значит: если сегодня 16 сентября, а в плане у задачи стоит фактическое начало 20 сентября — это ошибка. Факт — это то, что уже произошло. Будущее может быть только планом, но не фактом.
Почему это важно:
- Некорректные даты искажают реальную картину проекта. Руководитель видит «факт», которого ещё не было, и принимает решения на основе недостоверных данных.
- Это сигнал о некачественном обновлении плана: либо даты проставлены «на автомате», либо план не синхронизирован с реальностью.
- Критерий напрямую связан с достоверностью отчётности. Если факт в будущем — отчёт не отражает реальное состояние проекта.
Как проверять в MS Project с помощью VBA:
Можно сделать ручную проверку путем установки фильтра. Но удобнее при помощи VBA, в нем можно закодировать проверку сразу 14 критериев. Макрос перебирает все задачи активного проекта, сравнивает поля «Фактическое начало» и «Фактическое окончание» с текущей датой и помечает нарушителей в текстовых полях (например, Text1 и Text2). Дальше достаточно поставить фильтр по этим полям — и все проблемные строки перед вами. Такую проверку можно запускать перед каждым формированием отчётности.
Внедрение такой проверки в регламент контроля качества планов позволяет:
· Автоматически выявлять задачи с некорректными фактическими датами до формирования отчётности.
· Снижать риски принятия решений на основе недостоверных данных.
Факт в будущем — это не «почти сделано». Это ошибка в данных. А VBA в MS Project делает проверку быстрой и регулярной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Не так страшны первые девяносто процентов выполнения задачи, как вторые
Прошла неделя работы над задачей. Руководитель подходит к сотруднику:
— Как дела? Сколько процентов готово?
— Ну... процентов семьдесят.
— Семьдесят? Отлично! Значит, к пятнице закончим?
— Ну... наверное. Там ещё пара доработок и что-то по мелочи.
Через неделю выясняется, что «семьдесят процентов» были субъективной оценкой настроения, а не состояния задачи. И что «мелочь» — это в лучшем случае половина оставшегося объёма.
Классика жанра.
Процент выполнения — это часто не информация, а художественный жанр. Трёхдневная задача, идёт второй день, готово на 50%? Звучит убедительно. Пока не спросишь: «Сколько времени нужно, чтобы закончить?»
Правильный вопрос менеджера — не «сколько сделано», а «сколько осталось». И не в процентах, а в днях. Всё остальное — либо отчётность, либо самоуспокоение.
Лучше если есть возможность объективно оценивать состояние задачи. Об этом в следующих постах.
#УправлениеПроектами #PMO #КонтрольПроектов
Прошла неделя работы над задачей. Руководитель подходит к сотруднику:
— Как дела? Сколько процентов готово?
— Ну... процентов семьдесят.
— Семьдесят? Отлично! Значит, к пятнице закончим?
— Ну... наверное. Там ещё пара доработок и что-то по мелочи.
Через неделю выясняется, что «семьдесят процентов» были субъективной оценкой настроения, а не состояния задачи. И что «мелочь» — это в лучшем случае половина оставшегося объёма.
Классика жанра.
Процент выполнения — это часто не информация, а художественный жанр. Трёхдневная задача, идёт второй день, готово на 50%? Звучит убедительно. Пока не спросишь: «Сколько времени нужно, чтобы закончить?»
Правильный вопрос менеджера — не «сколько сделано», а «сколько осталось». И не в процентах, а в днях. Всё остальное — либо отчётность, либо самоуспокоение.
Лучше если есть возможность объективно оценивать состояние задачи. Об этом в следующих постах.
#УправлениеПроектами #PMO #КонтрольПроектов
Критерий DCMA №10: Ресурсы
Каждая задача должна быть обеспечена необходимыми ресурсами
Продолжаем разбор методики DCMA. Десятый пункт устанавливает: все задачи проекта (кроме вех, суммарных задач и работ типа LOE*) должны иметь назначенные ресурсы или стоимость. Если задача есть, а исполнителя нет — это не план, а «набросок» работ.
Почему это критично:
- Без ресурсов нельзя корректно оценить продолжительность. Разные ресурсы – разная производительность. Разная производительность – разная продолжительность.
- Риск перегрузки команд и оборудования. Непонятно кто загружен, а кто простаивает.
- Бюджет, трудозатраты и прогресс становятся недостоверными. План без ресурсов — это чертёж без материалов: выглядит красиво, но построить нельзя.
Целевое значение:
В отличие от других критериев DCMA, здесь нет порога «5%». Для качественного плана значение должно быть 0% — все задачи обеспечены.
Как проверять в MS Project:
В MS Project назначение ресурсов или затрат отображается в представлении «Использование задач» (Task Usage) и в столбцах «Названия ресурсов» / «Затраты». Для быстрой проверки используется фильтр по задачам с пустыми значениями в этих полях.
Если в плане есть задачи без ресурсов — это сигнал: план надо дорабатывать.
#DCMA #ProjectManagement #Scheduling #MSProject #PMO #УправлениеПроектами
Каждая задача должна быть обеспечена необходимыми ресурсами
Продолжаем разбор методики DCMA. Десятый пункт устанавливает: все задачи проекта (кроме вех, суммарных задач и работ типа LOE*) должны иметь назначенные ресурсы или стоимость. Если задача есть, а исполнителя нет — это не план, а «набросок» работ.
Почему это критично:
- Без ресурсов нельзя корректно оценить продолжительность. Разные ресурсы – разная производительность. Разная производительность – разная продолжительность.
- Риск перегрузки команд и оборудования. Непонятно кто загружен, а кто простаивает.
- Бюджет, трудозатраты и прогресс становятся недостоверными. План без ресурсов — это чертёж без материалов: выглядит красиво, но построить нельзя.
Целевое значение:
В отличие от других критериев DCMA, здесь нет порога «5%». Для качественного плана значение должно быть 0% — все задачи обеспечены.
Как проверять в MS Project:
В MS Project назначение ресурсов или затрат отображается в представлении «Использование задач» (Task Usage) и в столбцах «Названия ресурсов» / «Затраты». Для быстрой проверки используется фильтр по задачам с пустыми значениями в этих полях.
Если в плане есть задачи без ресурсов — это сигнал: план надо дорабатывать.
.
Level of Effort (LOE) — это «поддерживающая» задача.
Она не создаёт конкретный продукт, а обеспечивает работу других задач.
Длится ровно столько, сколько длится то, что она поддерживает
#DCMA #ProjectManagement #Scheduling #MSProject #PMO #УправлениеПроектами
18 сентября в Москве прошла отраслевая конференция «От контроля к управляемости»
Организатор — ПАО «Яковлев». Главная цель — перейти от последующего контроля к проактивному управлению сроками в крупных проектах и сформировать единый подход к управлению сводным графиком в кооперации.
Ключевые темы:
- Раннее выявление отклонений
- Прозрачность сводного графика при множестве участников
- Оперативные решения на основе данных
Индустрия обсуждает этот переход уже лет двадцать, но судя по ключевым темам, путь только начат.
https://conference-yakovlev.ru/
#УправлениеПроектами #Промышленность #ПроактивноеУправление #PMO #Конференция
Организатор — ПАО «Яковлев». Главная цель — перейти от последующего контроля к проактивному управлению сроками в крупных проектах и сформировать единый подход к управлению сводным графиком в кооперации.
Ключевые темы:
- Раннее выявление отклонений
- Прозрачность сводного графика при множестве участников
- Оперативные решения на основе данных
Индустрия обсуждает этот переход уже лет двадцать, но судя по ключевым темам, путь только начат.
https://conference-yakovlev.ru/
#УправлениеПроектами #Промышленность #ПроактивноеУправление #PMO #Конференция
😁1