Прогноз срока проекта по пропускной способности: диапазон вместо одной даты

Срок завершения набора задач нельзя надёжно получить простым делением объёма на среднюю скорость команды. Когда команда сначала обсуждает сложность каждой задачи через Planning Poker, она видит и неопределённость исходного объёма. В одни недели завершается больше работы, в другие меньше: появляются срочные запросы, зависимые решения и задачи разного размера. История пропускной способности позволяет построить диапазон дат и открыто показать, насколько вероятно уложиться в нужный срок.

Такой прогноз отвечает на вопрос «когда закончится известная очередь при условиях, похожих на прошлые?». Он не заменяет разговор о составе проекта, качестве и внешних вехах. Зато помогает отличить рискованное обещание от даты, которая опирается на наблюдаемую работу команды.

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

Нужны отдельные значения по периодам, а не только одно среднее. Последовательность 2, 3, 4, 4, 5 и 6 показывает колебания, которые среднее число 4 скрывает. Именно эти колебания влияют на риск даты. Проверьте, были ли недели сопоставимы: не входил ли в выборку праздничный период, длительный простой или временное удвоение команды.

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

При малом числе завершений в неделю дневной throughput будет часто равен нулю, и картина станет шумной. Недельный шаг помогает увидеть движение, но скрывает, что важное внешнее решение может потребоваться в середине недели. Выбирайте размер периода по ритму работы и частоте решений. Если команда поставляет много мелких запросов каждый день, дневная история даст более точную картину; для редких крупных поставок лучше рассматривать недели.

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

Большой элемент, который скрывает несколько поставок, может сделать число карточек обманчивым. Перед расчётом разбейте такие элементы по проверяемым результатам, но не дробите их искусственно ради удобного прогноза. Если объём пока неизвестен, обозначьте диапазон количества элементов или выделите короткое исследование, которое уточнит состав. Точная дата при неясном объёме — лишь точное оформление незнания.

Отдельно отметьте обязательные внешние события. Если проект ждёт разрешение регулятора не раньше определённого дня, поток задач не сможет перескочить эту дату. Прогноз по throughput можно использовать для внутренней работы, а внешнюю веху показать как ограничение. Смешивание этих причин создаёт иллюзию, что увеличение скорости команды решит любую задержку.

Уточните критерий «готово» для каждой оставшейся карточки. Если часть задач завершена технически, но ещё не принята, включите оставшуюся проверку в прогноз. Иначе число элементов быстро уменьшается на доске, а реальные обязательства перед заказчиком остаются открытыми. Прогноз хорош настолько, насколько честна граница результата, к которому он относится.

Если осталось 20 сопоставимых задач, а в последние недели команда завершала в среднем четыре, грубый ориентир — около пяти недель. Он полезен для разговора, но не показывает вероятность. В истории из шести недель были и периоды с двумя завершениями. Несколько таких недель подряд сдвинут дату; обещать ровно пять недель на основании среднего рискованно.

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

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

Не превращайте самый оптимистичный сценарий в план только потому, что он выглядит привлекательнее. Если заказчик требует конкретную дату, обсудите, какой риск опоздания он готов принять и какие меры доступны: уменьшить объём первой поставки, убрать внешнее ожидание, изменить порядок работ или увеличить мощность после проверки ограничений.

Простой вариант моделирования: случайно выбирайте значения завершённых задач из исторических недель, складывайте их, пока сумма не покроет оставшиеся элементы, и записывайте число потребовавшихся недель. Повторите много раз. Получится распределение возможных сроков, а не одна усреднённая дата. Это часто называют моделированием Монте-Карло.

Например, при истории 2, 3, 4, 4, 5 и 6 завершённых задач за неделю и остатке в 20 задач один воспроизводимый расчёт из 10 000 случайных сценариев дал ориентиры: половина сценариев завершилась к пятой неделе, около 85% — к шестой, около 95% — к седьмой. Эти числа относятся только к указанным входным данным и способу выборки; они не являются нормой для другой команды.

Представьте результат заказчику обычными словами: «при составе работы и условиях, похожих на последние недели, к концу шестой недели завершение выглядит вероятнее, чем к концу пятой». Укажите дату расчёта и допущения. Не называйте сценарные 85% гарантией: неожиданные изменения могут сделать прошлую выборку непохожей на будущее.

Если нужно назначить дату в календаре, переведите номер недели в конкретный день с учётом праздников, доступности принимающей стороны и времени на финальную проверку. Моделирование завершений карточек не добавляет автоматически несколько дней на приёмку всего проекта. Зафиксируйте эту дополнительную работу отдельно, чтобы диапазон из расчёта не превратился в обещание более широкого результата.

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

Выбирайте период истории, похожий на предстоящую работу. Слишком короткая выборка ловит случайную неделю; слишком длинная может включать уже неактуальный состав команды и процесс. Сравните несколько последних периодов и объясните выбор. Если данных мало, честно покажите широкий диапазон и назначьте ранний пересмотр.

Проверьте, как команда считает завершение. Если раньше карточку закрывали до приёмки, а теперь после неё, сравнение throughput будет нарушено. Аналогично, массовое дробление задач механически увеличит число завершений. Исторические цифры нельзя применять к новой единице работы без поправки или нового периода наблюдений.

Поддержка, ошибки и срочные просьбы отнимают мощность у проекта. Если они регулярно присутствовали в исторических неделях и продолжаются в похожем объёме, их влияние частично уже отражено в throughput. Если впереди ожидается крупный запуск с усиленной поддержкой, прежняя история окажется слишком оптимистичной. Создайте отдельный осторожный сценарий.

Не уменьшайте остаток проекта на вымышленные проценты «на всякий случай». Лучше обсудите конкретные источники новых задач: сколько ошибок обычно возникает после проверки, какие решения заказчик ещё не принял, может ли появиться обязательная доработка. Часть такой работы стоит добавить в границы прогноза, часть — описать как отдельный риск.

При внезапном срочном запросе покажите последствия выбора. Если команда берёт его сейчас, исходная очередь получает меньше мощности. Новый прогноз после решения должен быть виден и инициатору срочной задачи, и владельцу отложенной поставки. Иначе один участник получает обещание без цены для остальных.

Вместо абстрактного «команда станет медленнее» сравните два сценария доступной мощности. Если один специалист две недели занят поддержкой, какие задачи останутся без его навыка и что может делать команда параллельно? Такая проверка дополняет потоковый расчёт планированием загрузки команды. Она особенно важна, когда исторический throughput достигался другим составом людей.

Throughput по неделям помогает оценить, когда закончится набор элементов. Для конкретной начатой карточки важнее история времени прохождения похожих задач и её текущий возраст. Нельзя взять дату из прогноза всей очереди и объявить, что каждая отдельная задача будет готова именно тогда.

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

Обещание сроков по уже начатой работе лучше связывать с историческим распределением времени задачи. Это другой управленческий вопрос, который требует своего набора данных. Не смешивайте его с подсчётом объёма всей очереди только ради одной красивой даты.

Раз в неделю обновляйте остаток, добавляйте завершённые элементы и проверяйте, изменились ли условия. Прогноз, составленный месяц назад, мог быть разумным на тот момент и устареть после нового требования. Пересчёт не является признанием ошибки; он сообщает, что команда использует свежие данные.

Показывайте, почему диапазон изменился. Причина может быть в новом объёме, снижении завершений, зависшем согласовании или изменении состава команды. Если выдавать только новую дату, заинтересованные стороны не поймут, какое решение способно вернуть проект к цели. Сохраните старую версию прогноза, чтобы видеть динамику и качество допущений.

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

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

Не всем нужен график из тысяч сценариев. Руководителю обычно достаточно остатка работы, истории недель, двух-трёх дат с понятной степенью уверенности и ключевых рисков. Покажите, что произойдёт с прогнозом, если появится ещё пять обязательных задач или временно исчезнет специалист. Эти сценарии помогают выбрать объём и приоритет.

Не обещайте, что команда «с вероятностью 95%» уложится в дату, если входные данные явно неполны. Процент описывает модель при её допущениях, а не весь мир. Формулировка должна сохранять это условие. При высокой цене просрочки выберите более осторожную дату или отдельный резерв и объясните, какой риск он покрывает.

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

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