Comments 11
Основная проблема не в угадывании сроков реализации, а в том, что реальные сроки всегда выше, чем ожидания. Всем хочется закончить проект как можно раньше и желательно с минимальными затратами бюджета.
Говоришь, что проект займёт 3 месяца, а в ответ слышишь, что другая компания ему пообещала сделать всё за месяц. В результате проект уходит другой компании, которая делает проект уже полгода с постоянными переносами срока его окончания.
Это если у вас тендеры и аутсорс, наверное? Взаимоотношения между компаниями, предоставляющими и потребляющими услуги всегда разные. Звучит как совсем другая (хоть и очень наболевшая) проблема :)
Но мы тут говорим что прогноз первоначальный всегда надо обновлять, просто есть стат данные в не-аутсорс компаниях что на основе этой метрики считать честнее и корректнее.
А так - всегда есть миллион факторов, которые влияют на прогнозы, потому и обновляем. Также как в метеорологии первоначальные прогнозы никогда не сбываются, и они дают их с уверенностью в 30%.
В АйТи параметров прогноза меньше, но без обновления все равно никуда.
...и, почему-то, мне кажется, что, точно так же, как и на фондовом рынке, коррелируемость задач между собой приведёт к тому, что такая оценка не покроет тяжёлые хвосты.
Поясню проще: в моем опыте главные проколы по срокам возникали не из-за того, что отдельные задачи делались дольше, а из-за того, что по мере реализации вскрывались принципиальные требования к системе, которые невозможно было вскрыть на этапе бизнес-анализа. Соответственно, когда такое событие наступает, то нарастает снежный ком. Критичное непопадание одной задачи в срок ведёт не только к тому, что другие задачи ждут ее, но ещё и к тому, что они теперь тоже потребуют больше времени, ибо та, первая проблемная задача, была сделана сложнее и объёмнее, чем в плане. И так по цепочке
Это всегда так. Именно поэтому мы обновляем прогноз каждую итерацию (раз в две недели, например). Мы можем построить прогноз на throughput + wip + Lead Time (в predictable.team есть epic forecasting в Monte Carlo, там можно тыкнуть на +1 эпик и наполнить его в соответствии с вашими задачами. Тогда разброс в прогнозе будет учитывать одновременное историческое количество элементов в работе + параллельную работу + Lead Time и 50 и 85 перцентилей). Тогда ваша историческая информация о времени завершения задач будет учитывать и хвосты.
Да у вас похоже bootstrap, а не MC.
это про UI?
нет, про статистику.
В целом по статье - мне понравилось:
что не SP, а задачи заходят достаточно,
в целом про интервальные истории. точечные оценки в теории вероятностей имеют вероятность 0 для непрерывнозначащих случайных величин.
random.choice все же больше похож на стат. метод бутстрэп. когда для оценки интервалов статистики используют подвыборки. так, придирка. монте-карлой было бы если бы вы взяли распределение, извлекли бы из выборки его параметры, потом бы сэмплили.
тут все это не сказать что край как принципиально. идейно все ок
Есть ли примеры, когда реально благодаря такому подходу удалось назвать приближенную оценку? К примеру изначально была меньше, а статистику посмотрели назвали большее число и так оно и получилось?
Если я правильно понял, то как раз в примере, где сравнивались для небольшого проекта SP / Issue Count, оказался Issue Count точнее.
Но я опять повторю, что прогноз надо постоянно обновлять потому что динамика работы команды может сильно поменяться (зависимости, болезни, увольнения, инфра, ...) - поэтому каждый спринт (минимум) мы должны итерировать прогноз, чтобы после этого его обновлять и коммуницировать со стейкхолдерами.
Если прям приводить кейсы, то есть вот такой пост https://www.prokanban.org/blog/trustingmcs
+ бложик Мэтт Филипа https://mattphilip.wordpress.com/wp-content/uploads/2018/02/to-estimate-or-not-to-estimate-is-that-the-question_-by-matt-philip.pdf
Throughput: как научиться перестать гадать сроки и начать их предсказывать через симуляцию Monte-Carlo