Если вы устали от «угадай дату по глазомеру», попробуйте вероятностный подход. Метод Монте-Карло даёт диапазон дат с понятной вероятностью — без «ганттовой магии» и драматургии созвонов.

Что получите за 15 минут: подготовите исторические данные по throughput, запустите симуляцию, получите P50/P85/P95 для релиза и план спринтов. Внизу страницы — интерактивный калькулятор через шорткод.

Зачем Монте-Карло в продуктовой разработке

Классические оценки «снизу-вверх» проваливаются там, где вариативность высокая: разные типы задач, блокеры, зависимости, люди болеют, приоритеты «плавают». Вероятностное прогнозирование учитывает эту неопределённость: мы моделируем тысячи «альтернативных будущих», а не зашиваем одну детерминированную дату. На выходе — диапазон с вероятностями (P50/P85/P95), который легче объяснить стейкхолдерам и защитить.

Минимум теории: что такое Монте-Карло

Метод Монте-Карло — это множество случайных прогонов модели с выборкой из ваших исторических данных. Для Scrum и Kanban чаще всего берут историю пропускной способности (сколько элементов команда завершала за спринт/неделю). В каждом прогоне мы «тянем» случайное значение throughput и накапливаем результат, пока не «закроем» нужный объём работы. Повторяем тысячи раз — получаем распределение сроков.

Плюс подхода — не требуется «ровнять» задачи по размеру: достаточно стабильного процесса и адекватной WIP. Детали и хорошие практики широко описаны экспертами сообщества Agile и Kanban.

Что подготовить: данные и допущения

  • История throughput за 10–20 итераций (лучше больше): числа вида 8, 12, 7, 10, 9, … — сколько элементов «Done» за спринт/неделю.
  • Объём бэклога в элементах (PBI): сколько нужно завершить до релиза.
  • Длина итерации (например, 14 дней) и дата старта.
  • Ограничения: стабильность процесса, отсутствие крупных «слонов»; если есть, делите работу на тонкие ломтики (slicing).

Подход A: по throughput (рекомендуется)

Берём список «сколько сделали за итерацию» и моделируем, за сколько итераций закроем объём бэклога. Преимущества: простота, не нужны story points, легко обновлять каждую итерацию.

Подход B: по времени цикла

Для Kanban: тянем случайные времена цикла элементов, суммируем до нужного количества. Точнее для поточного режима, но требует качественной телеметрии и чистых данных.

Пошагово: делаем прогноз релиза

  1. Соберите историю завершённых элементов за N спринтов (или недель).
  2. Очистите данные: уберите нули/аномалии, если это исключения процесса. Пустые итерации — сигнал проблем в CFD или перегрузе WIP.
  3. Запустите симуляцию 5 000–50 000 прогонов.
  4. Чтение результата: P50 — «медианная» дата, P85 — «надёжная для внешних коммуникаций», P95 — «консервативная».
  5. Обсудите риски и варианты ускорения: параллелизация, снятие блокеров, «descope» и т. д.

Как «продавать» вероятностные даты бизнесу

Формула из практики: «С вероятностью 85% релиз будет готов к 15 декабря. Если выбираем P50 (более агрессивно), это 5 декабря, но рисков больше». Такой разговор честнее, чем «Будет 10-го — обещаю». Внешние обещания лучше делать на уровне P85, внутренние цели — P50 с планом по снятию рисков.

Онлайн-прогноз сроков методом монте-карло

Вставьте историю throughput, укажите объём бэклога, длину итерации и получите даты с вероятностями.

Калькулятор Монте-Карло (throughput → дата релиза)

β-версия
Минимум 10–12 значений. Нули и пустые значения будут отброшены.
Например: 50,85,95

Типичные ошибки и как их избегать

  • Смешивание разных типов работы в одной выборке. Решение: заведите категории/кластеры или приведите к стабильным «ломтикам».
  • Игнорирование зависимостей. Симуляция не знает про внешние интеграции/одобрения. Явно выписывайте риски и SLA по зависимостям.
  • Один большой «слон» в бэклоге. Делите. Монте-Карло любит стабильность потока.
  • «Прицельная» точность. Не округляйте вероятности до двух знаков и не обещайте одну дату; показывайте диапазон.

Интеграция с процессом и метриками

Комбинируйте прогноз с Flow-метриками: CFD, время цикла, возраст работы в процессе. Если на CFD виден «раздувающийся» слой In Progress — прогноз погорит. Сначала лечим поток, затем уточняем симуляцию.

Где это используется в ВЕБОФИС

  • ВЕБОФИС: AGILE — процесс, метрики и RACI для ролей.
  • ВЕБОФИС: TRACKING — сбор телеметрии по задачам, throughput, KPI, экспорт для симуляций.
  • ВЕБОФИС: HELPDESK — потоки инцидентов и SLA, данные для вероятностного планирования.
Обсудить проект

FAQ

Достаточно 10–12 итераций истории throughput. Чем больше — тем устойчивее распределение. Обновляйте модель после каждого спринта.

Можно использовать velocity, но лучше перейти на штуки (items). Throughput проще интерпретировать и защищать перед бизнесом.

На практике — P85 для внешних обязательств и P50 для внутренней цели улучшений, с явным управлением рисками.