Comments 38
Опробуем)
Блин, я фигею, дорогая редакция :)
Ну честно, все команды уникальны, проекты уникальны - что вы в таких условиях хотите мерять? Ну да, статистически можно подсчитать любую математическую ересь типа "ПМ завшает сроки сдачи проекта в среднем на 11%, если срок проекта не больше года, и на 23,5% - если больше". Серьезно?
Ну давайте трезво, что у вас есть?
Скоуп в виде backlog либо иного списка, в зависимости от методологии. Точность оценки длительности выполнения каждой задачи? Я думаю, будет плюс минус половина срока, и то - хорошо если так. Понято, есть опция, когда вы много лет пилите один и тот же продукт, и тогда оценки будут лучше. Но извините, в таком случае вы вообще практически в тепличных условиях, по сравнению с разработкой решения с нуля, особенно если оно в принципе новое для организации.
Да и зачем все это. Вы же либо четко знаете дедлайн и требования, если живете в fixed price/fixed scope (на самоми деле нет, но в любом случае, есть контракт и дополнения к нему, и если что - все пойдут его читать). Если же вы относительно гибки, то вопрос в том, не как мерять, а в том, как управлять процессом прихода в продукту, имеющую ценность. Но и в этом случае есть какой-то контракт со сроками и условиями.
Даже если вы внутри организации, и над вами не нависают документы, имеющие прямую юридическую силу - есть практически аналогичные обязательства по внутренним процедурам.
Намного проще и правильнее не "добавлять", а "отнимать". К примеру, вам надо выйти на рынок в день Х. Вы считаете назад. У вас есть пилот на выбранных пользователях, фиксы после него. Условного заложили 3 недели. Тут сложно ошибиться, так как если вы ошиблись, значит имел место быть эпический косяк. Итого имеем день Х - 21 день. Дальше финальные тесты пользователями с фиксами. Условно 4 недели. Отлично, имеет день Х - 49 дней. Вот после этой точки мы, к примеру, не берем новые требования. Значит до того закладываем условно 2 недели, на финализацию того, что есть, полировку и т.д.. Даты и milestones условны, так как зависят от целей проекта, размеров поставки, методологии и кучи всего. Но так намного безопаснее, когда вы от главного milestone отняли длительность обязательных шагов + буффера. И все
У вас есть точка заверщения разработки.
Идете по "гибкой" методологии. Да пожалуйста, все тоже самое, просто надо четче пояснить продакту, что "бантики" пора сворачивать и за пару спринтов трезво посмотреть, что успеваем допилить до дня Х, а что лучше не начинать, так как не успеем.
Но это реально какой-то ... я даже не знаю. Если вы не успеваете, это и так понятно. Вы расставили себе milestones по ходу проекта. Если вы начинаете их проваливать - все, вы не успеваете, и надо чего-то делать. Добавлять людей, чего-то менять внутри, с кем-то прощаться. Для этого есть план при waterfall либо разумный взгляд на backlog.
----------------
Как по мне, скорее "горе от ума". Подмена project execution какими-то ненужными теложвижениями
Для применения метода Монте-Карло не нужны оценки длительности отдельных задач.
Конечно, применять его лучше для той же команды, для которой у нас есть данные.
Всё, что вы описали, расчёт назад от "когда надо", расстановка и контроль промежуточных точек, имеет место, конечно. Но разве это отменяет другие методы?
В чём посыл вашего комментария? Метод не рабочий? Это не так.
Метод не надо применять? Не применяйте. Для нас он работает и результат лучше, чем экспертные оценки "да, вот это мы сделаем тогда-то". Что их не отменяет, но методом они прекрасно проверяются на адекватность.
Просто трата времени. Либо просто презентация руководству некой "супер-пупер" техники :)
Он ничего не дает, если управлять проектов. А если не управлять - не дает тем более :)
Инструмент решает вполне конкретные задачи и не пытается заменить управление проектами. Всё зависит от того, какой вопрос вы ставите.
Предлагается в качестве альтернативы или в дополнение к экспертным оценкам, чтобы не "закладывать", "добавлять", "отнимать".
Ну, такое.
К примеру: тим лид оценил в 8 попугаев, метод - в 5. Вы заложили 5. А итоге сделали за 8. Дальше вам светит короткая лекция на тему важности не поддавать сомнению экспертное мнение, и хорошо, если без сильных выражений. В любом случае, вам менеджерить, а людям делать. Они "подписываются", явно или нет, на свои оценки. Это вопрос психологии на проекте.
Вы ж в проекте не фишки двигаете, а управляете людьми и их взаимоотношениями. Базовая основа планирование - исполнитель оценивает.
Если вам надо оценить некий объем задач для больших планов - тогда вы попадаете в ловушку неточных данных. Это ж тоже математика. Если вам нравится туда идти, то представьте, какая погрешность будет у расчетов, где изначальные данных даны з погрешностью 50%? Это почти тоже самое, что просто кидать монету, так как итоговая погрешность будет плюс минус бесконечность.
----------------
Тем более, ну смотрите. Вам надо чего-то оценить. Собираем лидов, чай, кофе, плюшки. И оцениваем задачи по сложности, 3-5 категорий. Потом попарно сверим некоторые, чтобы понять адекватность оценок и после пары кругов получаем результат. Плюсы:
вы провели время с командой, а не с компом. Это безценно
вы получили оценки, за которыми подписались лиды, и теперь они же будут подсознательно стараться им соответствовать
вы услышали команду и смогли узнать о куче потенциальных проблем
люди, посидели, обдумали фронт работ и тоже придумали кучу интересных идей/возможных проблем
вы дали всем понять, что их мнение важно и даже необходимо
Итого позитив, как ни посмотри.
Если эти данные прокрутить через любой "движок", вы все это потеряете. Именно поэтому он useless. Даже не потому, что он что-то там насчитает. А потому что применив его, вы рискуете весь позитив от такого упражнения помножить на ноль
А все потому, что люди и отношения во стократ важнее, и такого рода вопросы лучше решать в виде совместной работы
Конечно, потом это все надо прокрутить, наложить риски и прочее - вы ведь ПМ. Но базовые оценки, данные командой, важно оставить как есть, иначе ... ну вроде как понятно
-----
Единственное мы можете использовать технику "якоря", использовав движок как некую начальную оценку. Да, это может сработать. Но вопрос в том, что правильный "якорь" имеет цель и именно поэтому он вводится. А тут полагаться на не пойми что
Если у вас есть расхождение в 3 попугая — это повод обсудить, почему тим-лид оценивает на 8, а математика на 5. Есть какие-то риски? Блокеры? Что важно учесть в проекте?
Точность и полезность экспертных оценок тема отдельной статьи.
Ну можно.
Но тогда возвращаемся к вопросу, для чего изначальная "5". Если как "якорь" - стремно все таки. Не проще ли классически опросить всех? Либо довериться лиду
Все равно ему за свои оценки отвечать, а не за ваши
Там выходит. тим лид дам 8 и сделал за 8. Все пучком.
А с движком сплошная "каша из топора". Лишние обсуждения, вопросы. А в конце риск нарваться на лекцию о важности экспертного мнения :)
То есть Вам в любом случае нужен эксперт с его оценкой, который подтвердит, что Вы намеряли не среднюю температуру по больнице, а действительно учли все риски, блокеры и тонкие моменты.
Я понимаю, что очень хочется взять данные, которые есть, скормить умной машине, а уж она разберётся. Но реальность - она другая. Если у Вас однообразные задачи, то оценку Вы дадите и без метода Монте-Карло. А если разнообразные, то погрешность сравнится с оценкой и сделает оценку бесполезной. "Вероятность встретить слона на улице 50% - или встретите, или нет"
Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов:
а) с какой вероятностью к какой дате будут сделаны вот эти N задач?
б) Сколько и с какой вероятность задач мы сделаем за период?
Ни в одном из этих случаев попугаи не фигурируют. Тратить время на попытки экспертно предсказать будущее тоже не нужно.
Если у вас эксперты хорошо умеют давать такие предсказания и трудозатраты на этот процесс вас устраивает, вам не нужен Монте-Карло, смело проходите мимо. Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов:
а) с какой вероятностью к какой дате будут сделаны вот эти N задач?б) Сколько и с какой вероятность задач мы сделаем за период?
На этот вопрос может дать ответ только оракул, так как методу на вход надо давать некоторые числовые значения, которые как-то характеризуют разимер и сложность задачи :)
Некоторые сейчас используют ChatGPT :)
Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Как раз имеют, причем связь обычно близка к линейной :) У вас есть оценка в трудоднях, есть размер команды, далее несложные арифметические действия :)
В случае, если команда бежит спринтами, вообще все сводится чуть ли не к тупой формуле , в которую входят:
производительности команды за спринт
обьем бэклога
длина спринта
К итогу добавляем коэфициент неопределенности и "говнистости" заказчика и в общем-то все
Если большим проектом и "водопадом", то чуть сложнее, так как заказчик обычно просит план, который надо чуть ли не включить как дополнение к конктракту. Но на расчет общего срока это не сильно влияет :)
P.S. Но у именя есть стойкое ощущение, что после "оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы" разговор надо сворачивать :)
методу на вход надо давать некоторые числовые значения, которые как-то характеризуют разимер и сложность задачи
Нет, не надо. Практика показывает, что никакой корреляции между размером/сложностью и сроками завершения нет. Ладно, иногда слабая корреляция есть, у очень продвинутых команд с хорошо стабилизированным процессом. Эти выводы мы делаем на основании большого массива накопленных данных.
Как раз имеют, причем связь обычно близка к линейной
Данные покажете? Мы то собирали и проверяли эту корреляцию. (Не мы одни, конечно).
В случае, если команда бежит спринтами, вообще все сводится чуть ли не к тупой формуле , в которую входят:
производительности команды за спринт
обьем бэклога
Ой, вы описали подход, лежащий в основе метода, только упустили, что производительность команды за спринт не константа, она "плавает". И метод Монте Карло это как раз позволяет учесть и дать вероятности того или иного исхода. Справедливости ради, для очень многих случаев точность такого прогноза не сильно отличается от МК.
Нет, не надо. Практика показывает, что никакой корреляции между размером/сложностью и сроками завершения нет.
Да уж конечно :) А чего на вход давать то надо?
Данные покажете? Мы то собирали и проверяли эту корреляцию. (Не мы одни, конечно).
А чего показывать? Есть оценки команды перед спринтом, есть результат в конце + демо. Упражнение раз в две недели на "живом" проекте :)
Так же есть N контрактов, где была сделана оценка в целом и вписаны сроки. В том числе указанным методом экспертных оценок
Ой, вы описали подход, лежащий в основе метода, только упустили, что производительность команды за спринт не константа, она "плавает".
Я вас расстрою, оценивая пул задач с погрешностью она и так выравнивается :) Чисто по этой причине. дальнейший творческий онанизм з числами - чисто чтобы себя занять :)
Вы расставили себе milestones по ходу проекта.
Вот для этого авторы и предполагают использовать Монте-Карло. При условии стабильности среды, когда на всех ваших уникальных командах и проектах начинает хоть как то работать закон больших чисел, why not?
А как вы видите тут Закон больших чисел?
Во-первых: команды различны, проекты тоже, среда все время меняется. Ничего похожего там нет, обычно. Поэтому у вас получится очень большой разброс и маленькая выборка. А это прям скажем, не лучшие стартовые данные для применения метода :)
Во-вторых: закон больших числе не зря про большие числа :) К примеру, у вас есть сценарий, вероятность которого 0.01%. Фигня, скажете вы. Но если у вас 1000000 транзакций в день, то этот случай скорее рутина, чем что-то редкое. Перенося в практическую плоскость, это значит что такой случай должен быть учтен во время разработки, тестирования и вообще. Ну или на масштабе страны, условно 100 миллионов человек == почти любое отклонение будет иметь место быть. Просто такое большое число автоматом делает реальным события, для отдельно взятого человека практически нереальными. Это на пальцах, но для понимания масштабов. Теперь возьмите даже большую организацию. Ну сколько там будет проектов? 1-2 самых важных, 5-10 больших, 20 мелких и куча мелкого, что всем на них по фиг (можете поделиться своим опытом). Так где вы тут примените этот закон?
В-третьих, среда меняется, все время. За условные 10 лет работы на одном месте вы почти точно словите один экономический кризис, к примеру. А это резкое срезание бюджетов, смена стратегии. А за ним отмена проектов, урезание скоупов, битва за ресурсы. Это колосально влияет на проекты, какой уж тут Монте-карло? А есть локальные перетрубации, смена собственника, новый директор - тут тоже похуже революции. Может быть, вы бежали прямо за много денег, пришла новая метла и за много денег вас развернула в другую сторону.
------------
Практически ... у вас уже есть куда более сильные "milestone" в виде ожиданий. Все ж условно происходит не так. У бизнеса есть идея, либо набор идей. Не важно, это что-то с нуля или продолжение. Есть бюджет, на год например. Есть продукт, или целое подразделение, которое расписало стратегию, как потратив Х, они заработают Y. При этом к дате Z надо чтобы продукт был на рынке. Эта концепция прошла защиту на некотором "бюджетно-ресурсном" процессе и дали денег и ресурсы. Все. Просто так вам денег не дадут, не важно, у вас выделенная команда либо ситуативная на реализацию конкретной идеи (вариант, когда вы "жена цезаря" и вам дали освоить много денег просто так мы не рассматриваем). Вот в процессе "защиты" идеи и можно сесть и прикинуть CBA, где за букву "C" как раз отвечают ПМ, лиды, архитектор, ну и вообще, находится наша задача. Но тогда важно получить оценки ОТ ЛЮДЕЙ, так как потом вам это ДЕЛАТЬ. И если оценки даны людьми, они будут с вами, так как дав их - они подписались что в итоге выдадут продукт на рынок, и бизнес заработает Y денег (либо не заработает, но тут уже не наша проблема).
А вы дали, потом не вложились, и ... вы тогда лох, потому что исполнители вам скажут, что сам дурак, мы же предупреждали, и заказчик вам это Монте Карло может засунуть куда-то туда, куда природа не предполагало, но неожиданно стало возможно. Оно вам надо?
Ух, было бы очень интересно прочитать рассказ про то, как же метод монте-карло тут используется. В смысле, применяемого мат-аппарата и допущений, что берём, что и как считаем, вот это всё.
Статья, по сути, говорит, "есть эксель табличка, которая считает". Хорошо, что есть какой-то готовый инструмент.
Но было бы интересно почитать, что происходит внутри этого инструмента.
Вот тут можно познакомиться с подробностями самого расчёта как раз на примере ИТ проекта: https://tinkoff.github.io/dm-knowledgebase/docs/roadmap/management/job/tasks/planning/monte-carlo-method
Казалось бы, и методы не новые совсем, и попытки прикрутить их к оценке проектов я еще в середине 200х видел в исполнении того же Дорофеева, но как-то результатов положительных достигнуто так и не было.
Интересно, почему….
Не одна мат.модель насколько бы она сложной не была, не может быть рассмотрена как целевое решение такой проблемы как сроки, у которой есть десятки параметров влияющих на них.
К тебе приходит сейлз, приносит контракт и плевал он на твой анализ и данные, когда у него тендер в огне, это как один из примеров, таких можно найти сотни которые будут ломать о колено все эту "красоту"
А где вы смотрели результаты? Они таки есть. И у Дорофеева и у других.
Во-первых, Дорофеев описывал не Монте-Карло, а более простой способ расчёта, тоже на исторических данных, но без учёта распределения. И даже он даёт достаточно неплохие результаты.
Во-вторых, сравнение результатов прогнозов его методом и методом Монте-Карло, на реальных данных и проектах, он как раз проводил https://youtu.be/xt27W5WhMrs?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wn
Целиком плейлист тут https://www.youtube.com/playlist?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wn
И не он один, конечно, сверял результаты прогноза МК с реальностью. Так же как и результаты прогноза экспертов :)
Да все так. Результата нет. Вариативность слишком высокая
Какого результата нет, простите?
Никакого. Любая попытка в айти что-то оценить/предсказать абсолютно любым методом не более чем игра в угадайку с случайным исходом. Иногда удается угадать, но в большинстве случаев - нет. Хаосрепорт в подтверждение моих слов.
Абсолютной точности не достичь, конечно, но приемлимая вполне достижима. Как минимум, методом Монте Карло можно получить дату, раньше которой точно не надо ждать завершения. Волшебным образом она чаще всего гораздо позже, чем хотелось бы.
Хаосрепорт такой как раз потому, что люди пытаются угадать будущее, а не спрогнозировать на основе знаний о прошлом. Было бы меньше фантазий, больше расчётов, глядишь, и репорт был бы другим.
Ну и конечно, никак не спрогнозировать в сложном домене, когда мы не знаем предстоящего объёма работ.
Так вот вопрос. Методам в обед сто лет. Подходы к статистическому управлению разными процессами делаются хз сколько лет уже в совершенно разных областях науки и техники. Вы пишите, что их применимость гарантирует хорошие результаты.
Что то же мешало их начать массово применять лет эдак 10 назад ? Почему до сих нет готового фреймворка вида «вставь циферки - получи другие с приемлемой точностью циферки»?
Как человек, когда то давно применявший Монте-Карло при разработке торговых систем, давайте сразу перейду к сути критики этого метода.
Основная проблема в том, что вероятностные распределения компонентов процесса IT-разработки неизвестны и процесс нестационарен. В этих условиях метод Монте-Карло порождает явление ложной регрессии. Более подробно можно почитать, например, в этой статье
"Кирилюк, Сенько. Исследования соотношений между нестационарными временными рядами на примере производственных функций" )
В вашем посте содержится хороший рецепт приведения системы в состояние, пригодное для анализа методом Монте-Карло.
Что повлияет на точность прогноза? Стабильность системы.
Именно. Метод будет давать хоть что-то полезное только при условии стабильности наблюдаемого процесса.
Однако, в IT-организациях часто возникают ситуации, в которых невозможно заранее предсказать будущую продуктивность. Вот у вас новая команда. Одному Богу известно, сможет ли она сыграться и выйти на некое плато продуктивности в рамках вверенного ей функционала. Или у вас стабильная команда, но ей передали в ответственность новые подсистемы, после того как на этом участке не справились другие команды. Или команда стабильная, и функционал ее, но внезапно изменилась внешняя среда, невозможно больше пользоваться Jira, Miro, Idea и AWS. В этих ситуациях Монте-Карло не поможет, скорее навредит, создав ложные ожидания.
И такие ситуации возникают в большой IT-организации постоянно. Они влияют на общую стабильность и с ними необходимо работать. В этом суть менеджмента, приводить систему к стабильности каждый день, неделю и месяц. Иначе никакого менеджмента не будет.
Поэтому давайте не впадать в иллюзии и писать такие утверждения:
Чем такие прогнозы отличаются от экспертных прогнозов аналитиков? Они учитывают всю неопределенность, с которой встречалась команда,
Конечно же Монте-Карло не учитывает всей неопределенности. Более того, он не учитывает главной составляющей этой неопределенности, именно той, которую при планировании больших задач мы хотим избежать. Поэтому решить за нас проблемы оценки сложных проектов он не сможет. Хотя инструмент красивый.
Спасибо за комментарий. Конечно, чем выше стабильность системы тем точнее прогноз. И прогноз не только по Монте-Карло, но и экспертная оценка будет лучше работать в стабильной среде.
Монте-Карло учитывает предыдующую неопределенность, выбросы, которые у команды встречалась и повторяет её в прогнозе. Но понятно, что будущую неопределенность он не может предсказать достоверно. Как и эксперт не сможет предсказать черного лебедя.
Спасибо за конструктивный комментарий!
На практике, даже с учётом нестабильности, метод зачастую оказывается не хуже, чем экспертные прогнозы. При этом на порядки дешевле по трудозатратам.
В худшем случае, он даёт оценку снизу, "раньше чем Ч не сделаем точно", что уже очень ценный результат, позволяющий запустить полезные дискуссии о скоупе работ, ресурсах и, таки, сроках.
Аминь, брат! У меня курс матстатов в институте был давно, но даже я догадываюсь, что, давая прогнозы по статистике, мы делаем предположения о природе распределения вероятности сроков задач.
Почему-то всегда случалось так, когда этот метод презентовали, мне часто давали ссылки на книги 10-15-летней давности, но сами обоснование и границы применимости метода не могли сформулировать.
Я работаю с проектами и программами -- это крупные изменения, когда делаем что-то принципиально новое. Система (её логика, модель данных, процессы вокруг них, да и сама команда) существенно меняется. Проект по определению дестабилизирует систему. И тут в чат входит моделька, построенная на стабильности.
Есть гипотеза, что вы противопоставляете "модельке, построенной на стабильности" экспертные оценки. Явно в вашем комментарии этого нет, но сложилось такое ощущение.
Если так - разве экспертные оценки не построены на предпосылке, что мир стабилен и мы можем предвидеть? А если нет разницы - зачем платить больше и нагружать людей?
разве экспертные оценки не построены на предпосылке, что мир стабилен и мы можем предвидеть
отчасти так и есть, но эксперты могут быть в курсе внешних (по отношению к проекту/команде) факторов: текучка на местах, грядущая реструктуризация, лицензионные риски, колебания курса валют, производственный цикл конечного потребителя продукта и т.д.
Как реальный пример из моей практики: РП от подрядчика планирует сбор неких полевых показателей, на которых будет обучаться ML модель, на определённый период в N месяцах от старта проекта (длительность этапа взята из предыдущего проекта). К счастью, на обсуждении присутствует эксперт по полевым работам, который говорит, что сроки нереальны, ибо площадка, где планируется сбор данных, в это время будет представлять собой непроходимое болото, в котором тонут даже гусеничные вездеходы и, например, никакое увеличение объёма ресурсов, задействованных в проекте, не приведёт к выполнению этапа в расчётный срок.
Мне, как выпускнику соответствующей кафедры, очень нравятся статистические методы, но слепо доверять им, не будучи экспертом в предметной области, всё же, не стоит.
Как ответить на вопрос «Когда будет готово?» на основе статистики