ну так в проекте SW так же все. Для примера — строится подпорная стена при плохом изучении геологии и геодезии — оползни там, плавуны, торфяники. Так же и в разработке — вышел крутой фреймворк, супер быстрый, только вот связи с БД приходится пилить web api :)

ни в коем случае не претендую на новаторство и авторство — мой т.е. который я описал, а не придумал.

Опять таки, не управлять неопределенностью, потому что нет информации — это такой себе «авось» управления с проектами. Тогда ПМ вообще не нужен — пусть себе идет разработка как идет, а там в конце глянем, на сколько мы вышли за сроки и бюджет.

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

Вы моделируете частные случаи, из которых и состоит проект. Запары, отпуска, болезни и т.п. Это все круто, но основная задача ПМа, как не крути — концентрация на результате, фокусировка если угодно. Мой метод позволяет найти за что «зацепиться» глазу, выяснить что есть ядром проекта, что его суть. Все остальное что Вы перечислили, является оперативной работой, которая решается ресурсами. Проекты реализуются для получения прибыли, а не минимизации затрат, и адекватный менеджмент согласится что основной функционал проекта не может разрабатываться с BUS Factor = 1.

Полностью с Вами согласен, я упростил для понимания систему и очередность.

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

Хорошо, когда бюджет позволяет эти x3 :)

Дмитрий, я понимаю о чем Вы, но статья рассчитана, как указывал ниже на #войтиВайти

Ну видать сегодня у IT плохой день — перестала отрасль быть инженерной, стала творческой.

Ну уволится, и что? Если проект не закрывается, то будет реализован с принятием/уклонением от данного риска. Методы никуда не пойдут, а будут скорректированы на величину неопределенности. П.С. Очень плохо когда на проекте лидерство с bus factor = 1.

Не вижу смысла меряться с гуру хоть бы чем. Можно долго говорить о теории управления проектами, бросать в друг друга сертификатами и наградами, но успешных проектов от этого больше не становится. Видя какой поток Junior PM рвется на рынок, решил поделиться. Думаю ГУРУ так же не стоит читать мою следующую статью — о рисках на проекте. Так как там не будет формул дискриминантной модели, а всем известные стратегии управления на мой лад.

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

Никакой этот путь не эмпирический. Это beta-распределение, которое в данной ситуации намного точнее уже упомянутого «треугольного распределения». 4рка «сдвигает» результат в зону мат.ожидания ± сигма. Вероятность события Р — 68%, Мин — 13,6%, Макс — 13,6%. Так как существует еще 4,6% вероятность не попасть вообще в данный диапазон, то целое число — 4рка(хотя я б 4.66 округлял до 5и :)). Ну а про 6 я думаю понятно, так как деление на 6 «оценок».

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

Даже и не думал ничего изобретать. Статья — не более чем поддержание тренда #войтиВайти.

Да, но я так понимаю, это крупный аутсорс, а там любят собирать всю команду, либо ПМ с той стороны.

Канбан хорош, но если посмотреть, то использовался любым саппортом задолго до названия своего )