Новости и статьи об искусственном интеллекте и нейросетях. Мы собираем и обрабатываем самую актуальную информацию из мира AI. О проекте

Статьи

Предсказание 41% задержек проектов с помощью машинного обучения

Машинное обучение позволяет предсказывать 41% задержек в ИТ-проектах заранее, анализируя данные из Jira. Модель на базе Random Forest выявляет риски на основе приоритета, зависимостей и сложности, помогая сэкономить до 10% бюджета. Интеграция данных с экспертизой менеджеров повышает эффективность управления.

17 октября 2025 г.
9 мин
5

Каждому руководителю проекта знакома ситуация, когда на утреннем собрании внезапно выясняется, что ключевой тикет заблокирован, разработчик заболел, зависимость от другого элемента задерживается или важная функция отстает от графика. В миг рушится тщательно спланированный срок, и приходится срочно искать выходы.

В этой публикации рассматривается, как модель машинного обучения заранее выявила 41% задержек в проектах, что позволило снизить расходы и избежать хаотичных мер в последний момент.

Проблема: 62% ИТ-проектов не укладываются в сроки в 2025 году

Работая менеджером проектов в Agile-командах, я неоднократно сталкивался с отсрочками и препятствиями, которые стали обыденностью. Однако отчет Wellington State of Project Management 2025 с данными о том, что в 2025 году 62% ИТ-проектов превышают установленные сроки, заставил меня действовать. Это рост по сравнению с исследованием PMI Pulse of the Profession 2017, где показатель составлял 51% в 2017 году. Задержки достигают критической отметки.

Я осознавал, что отсрочки обычны, но не ожидал такого масштаба. Сегодня доступны инструменты для прогнозирования и глубокого понимания этих угроз. С использованием Python и методов анализа данных я разработал модель для предсказания задержек до их возникновения.

Эта статистика подчеркивает два ключевых аспекта: задержки часто вызваны повторяющимися факторами, и они наносят серьезный ущерб бизнесу. В публикации разбирается, как с помощью анализа данных из тикетов проектов можно создавать прогностические модели машинного обучения, выявляющие риски на ранних этапах.

Согласно отчету Wellington State of Project Management 2020, всего 23% компаний применяют специализированное ПО для управления проектами, несмотря на то что такие системы производят огромный объем полезной информации.

Изучение данных из тикетов позволяет строить модели, предупреждающие о потенциальных проблемах до их обострения.

Именно это я реализовал: проанализировал свыше 5000 тикетов, включая текущий проект и предыдущие задания.

ПО для управления проектами оказывается ценным источником данных, готовым к использованию.

Разрыв в данных управления проектами

В классическом подходе к управлению проектами отчетность занимает центральное место, но редко предоставляет всесторонний обзор всего проекта в деталях.

Например, в Scrum отслеживается скорость команды, динамика графика сгорания и количество завершенных стори-поинтов.

Стандартная отчетность не дает полной картины. Анализ данных способен это изменить.

Менеджеры проектов на основе опыта знают уязвимые места, но подтверждение гипотез данными повышает надежность выборов.

Формирование набора данных

Для проверки концепции я изучил 5000 тикетов в Jira — одном из наиболее полных источников информации о проектах.

Поскольку реальные данные проектов не всегда можно раскрывать, я сгенерировал синтетический набор в Python, имитирующий реальность с учетом переменных вроде приоритета, стори-поинтов, размера команды, зависимостей и задержек.

С готовым реалистичным набором данных можно приступить к исследованию профилей тикетов. Это подготовка к этапу исследовательского анализа.

Большинство тикетов имеют низкий или средний приоритет, что типично для бэклогов проектов. Такая начальная разбивка указывает на зоны накопления рисков, которые будут рассмотрены в анализе.

Тикеты высокого и критического приоритета составляют меньшую долю, но значительно чаще подвержены задержкам.

Эта диаграмма подтверждает тенденцию: тикеты высокого приоритета тесно связаны с отсрочками. Это может объясняться двумя механизмами:

  • Тикеты высокого приоритета по природе сложнее и поэтому более подвержены рискам.
  • Некоторые тикеты получают высокий приоритет из-за уже возникших задержек, формируя замкнутый круг эскалации.

С помощью этого смоделированного набора мы получаем правдоподобное отражение реальных проектов: тикеты различаются по объему, зависимостям и сложности, и некоторые неизбежно задерживаются. Это отражает повседневные трудности для руководителей.

Далее стоит перейти от простых подсчетов к выявлению скрытых закономерностей. Исследовательский анализ данных (EDA) позволит проверить предположения: действительно ли высокий приоритет и множество зависимостей повышают вероятность задержки? Давайте разберемся.

Исследовательский анализ данных (EDA)

До перехода к моделированию полезно визуализировать взаимодействия переменных. EDA помогает выявить закономерности в:

  • Изменении задержек в зависимости от приоритета.
  • Влиянии зависимостей.
  • Распределении стори-поинтов.
  • Размерах команд, работающих с тикетами.

Эта визуализация подтверждает интуицию: чем выше приоритет, тем больше вероятность задержки.

Зависимости усиливают эффект:越多 их, тем выше риск сбоев.

Как только возникает задержка или угроза, механизмы эскалации поднимают приоритет, образуя петлю обратной связи.

Сложность тикетов также вносит вклад, добавляя неопределенности.

Большинство тикетов попадает в категорию среднего риска. Они требуют наибольшего внимания от менеджеров: изначально не критичны, но риски могут быстро вырасти и вызвать задержки.

Тикеты высокого риска, хотя их меньше, оказывают несоразмерное влияние, если не вмешаться timely.

В то же время низкорисковые тикеты обычно нуждаются в минимальном контроле, освобождая время для приоритетных задач.

Мы видим, что большинство тикетов имеет небольшие стори-поинты, а команды обычно состоят из пяти человек.

Это указывает на соблюдение agile-подходов.

Теперь углубимся в распределение оценок риска по тикетам.

Только малая часть тикетов имеет очень высокий риск, в то время как большинство находится в средней зоне. Это подразумевает, что ранний фокус на самых опасных тикетах позволит предотвратить множество задержек.

Чтобы подтвердить, рассмотрим взаимодействие сложности на человека и приоритета с оценками риска.

Здесь нет четкой зависимости. Оценка риска не сильно коррелирует ни со сложностью тикета, ни с приоритетом, что предполагает влияние других неочевидных факторов на задержки.

Глубокий технический обзор: Прогностическая модель

Сырые данные дают основу, но для надежной модели необходимы знания домена. Чтобы точнее отразить реалии проектов, были созданы новые признаки, учитывающие специфику управления:

  • Сложность на человека = стори-поинты / размер команды.
  • Наличие зависимости = наличие зависимостей от других (dependencies > 0).
  • Взаимодействие приоритета и стори-поинтов = уровень приоритета, умноженный на стори-поинты.

Выбрана модель Random Forest, поскольку она справляется с нелинейными связями и дает понимание важности признаков.

Основной акцент на recall для положительного класса (1 = задержка). Например, recall 0.6 означает, что модель выявляет 60% всех реальных задержек.

Цель — не идеальная точность, а раннее обнаружение. В управлении проектами предпочтительнее отмечать потенциальные проблемы с некоторыми ложными срабатываниями, чем пропустить критические, способные сорвать весь план.

Модель достигла recall 0.41, то есть успешно определила 41% задержанных тикетов.

Это может показаться невысоким, но в контексте управления проектами даже такой уровень предупреждения полезен. Он дает менеджерам сигналы для прогнозирования рисков и подготовки мер.

С доработками модель способна предсказывать больше задержек и предотвращать проблемы заранее.

Для понимания сильных и слабых сторон используем матрицу ошибок.

Модель верно выявила 169 задержек, но дала 373 ложных тревоги — тикеты, помеченные как задержанные, но завершенные вовремя. Для менеджера такой баланс приемлем: лучше проверить лишние, чем упустить серьезное. Это элемент управления рисками.

Тем не менее модель пропустила 245 задержанных тикетов, показывая, что предсказания неидеальны.

В целом модель эффективна как система раннего оповещения. Она генерирует ценные индикаторы, но требует дополнительной настройки. Главное — дополнять ее экспертизой человека, опытом и суждениями менеджеров для полного обзора проекта.

Интерпретируемость модели, оценка, влияние на бизнес, дашборд и валидация модели

Чтобы разобраться, почему модель выдает такие предсказания, нужно заглянуть внутрь. Какие признаки наиболее влияют на риск задержки? Здесь помогает интерпретируемость модели.

Видно, что сложность и взаимодействие приоритета со стори-поинтами — ключевые факторы точности предсказаний.

Оценка тикетов: выявление реальных угроз.

Почему это важно для менеджеров проектов? Потому что можно продвинуться дальше.

Вычисляется оценка риска для каждого тикета.

Эта метрика подчеркивает наиболее уязвимые задачи, позволяя менеджерам сосредоточиться на них и принять превентивные шаги до эскалации.

Анализ влияния на бизнес.

Тикеты с наивысшими оценками риска подтверждают паттерн: только задачи высокого и критического приоритета несут наибольший риск.

Это знание ценно не только для контроля сроков, но и для оценки финансового воздействия на бизнес. Задержки не просто замедляют выпуск, они повышают затраты, снижают удовлетворенность клиентов и тратят ресурсы команды.

Для количественной оценки можно смоделировать бизнес-ценность предсказаний, рассчитав сэкономленные средства при timely вмешательстве.

Базовый уровень: 27.6% тикетов задерживаются. А если менеджеры сосредоточатся только на 20% самых рискованных? Симулируем целевое воздействие и оценим эффект.

Выявлено 1021 высокорисковый тикет, около 20% от общего числа. Из них 516 (50.5%) действительно задержаны. Таким образом, эти тикеты вызывают примерно 10% всех задержек в проекте.

Чтобы конкретизировать, применим к среднему проекту стоимостью $100 000. При превентивных мерах на высокорисковых тикетах оценим возможную экономию.

Ранние действия позволяют сэкономить $9270, почти 10% от общей стоимости проекта. Это не просто минимизация рисков, а реальное преимущество для бизнеса.

Дашборд для PM

Для практического применения создается дашборд управления проектами. Он обеспечивает обзор здоровья спринта в реальном времени с ключевыми показателями для мониторинга прогресса, прогнозирования рисков и полного контроля.

Валидация модели

Прочность модели проверена 5-кратной кросс-валидацией. Recall выбран как основной метрик, поскольку в управлении проектами важнее ловить задержки, чем добиваться максимальной общей точности.

Значения recall по фолдам варьировались от 0.39 до 0.42. Модель не совершенна, но стабильно выявляет около 40% задержек, предоставляя timely предупреждения для действий до обострения.

Заключение

В итоге публикация демонстрирует, как анализ данных способствует более плавному ходу проектов, раскрывая причины задержек.

Данные не заменяют интуицию менеджера, но усиливают ее, подобно улучшенным приборам для пилота, обеспечивающим точную навигацию и ясный обзор.

Прогнозируя риски и выделяя уязвимые тикеты, удается сократить отсрочки, избежать конфликтов и повысить ценность поставляемого.

Менеджерам проектов стоит интегрировать анализ данных. Сейчас существуют два типа руководителей: традиционные и те, кто использует данные для преимущества.

Урок для менеджеров проектов

Сколько решений в проектах опираются на "лучшие практики", которые на деле — неподтвержденные предположения? Будь то графики встреч, структура команды или способы коммуникации, данные помогают преодолевать предубеждения и находить эффективные подходы.

В зависимости от организации анализ может углубляться: группировка тикетов по фазам проекта, областям или заинтересованным сторонам выявляет скрытые узкие места и системные проблемы.

Например, скорость часто падает на этапе QA. Дело не в слабой работе QA-инженеров — они справляются отлично. Проблема в постоянных обменах с разработчиками: уточнениях тикетов, определении тестов или запросах недостающей информации.

Для решения ввели простую процедуру: разработчики добавляют четкие детали тестирования в тикет и проводят 5-минутный звонок передачи QA. Эта небольшая трата времени повысила продуктивность и скорость команды более чем на 15%.