×Закрыть

Как оценить сроки проекта с нуля: метод «критического пути»

Дисклаймер. Данный опус поможет понять за что «хвататься» при оценке проекта с нуля, но не является исчерпывающим ответом «как правильно».

Вашей команде поручили реализовать проект — мобильное приложение. Приложение не сложное, но заказчик, он же владелец продукта, просит оценку по времени реализации. С чего начать?

В новом проекте, вводные которого поступили на оценку, первым делом нужно определить «критический путь». Без команды это сделать практически не реально, поэтому как и на остальных этапах, нужна техническая экспертиза исполнителя/консультанта.

Выявляем «критический путь»

Если просто описать суть данного метода — нужно найти участки выполнения проекта, которые не могут происходить параллельно, и определить максимальную длину. Для понимания приведу пример строительства дома:
Копание ямы -> заливка фундамента -> возведение стен -> накрытие крышей.

Сколько бы не было ресурсов на проекте, фундамент не сможет выстояться быстрее чем за 28 дней (строительные нормы). И сколько бы не было ресурсов на подготовку крыши, если только один строитель будет класть кирпич, то остальной ресурс будет просто простаивать в данный момент.

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

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

Рассчитываем длину

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

Суть метода — спросить реальную оценку, минимально возможную и максимальную. Далее умножить реальную на 4, сложить с максимальной и минимальной и разделить на 6:

Оценка = (4Р + Мин + Макс) / 6.

Это и будет нормализованная оценка. Но она все же будет вероятно отличаться от финального результата на отклонение — шестую часть разницы между минимальной и максимальной оценкой:

Отклонение = (Макс - Мин) / 6.

Таким образом, пусть для стандартного «ползунка сравнения» мы часто получим такие оценки от исполнителя: «Реально его сделать за день, хотя если подойдет telerik-like, то и за 4 часа можно управиться. Ну а если писать полностью кастомный, то может и дня три».

Мы имеем оценки 4, 8 и 24. По формуле получаем: (4 + 8*4 + 24) / 6 = 10 часов с отклонением в плюс-минус (24 — 4)/6 = 3,33 часа.

Результаты

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

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

Лучшие комментарии пропустить

Управление проектами в СССР. ВУЗФИЛЬМ 1976.
youtu.be/I5xhs3T2jX8

93 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

— Когда вы уже сдадите проект!?
— Семь раз отмерь — один раз отрежь.
— Вы затянули сроки уже в два раза!
— Поспешишь — людей насмешишь.

(источник)

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

Наезжать на автора и писать, что метод фуфло потому как не учитывает это и то — полное невежество и глупость. Все равно, что комментировать статью «Что такое абстрактный класс в ООП» в стиле «программу на одних абстрактных классах не построиш, поэтому это фуфло» или привести пример когда нужно использоват интерфейс с тем же выводом, или «статья фуфло, потому что я и так знаю что такое абстрактный класс» — полный неадкват.
Я б на месте HRов на основе таких комментариев составлял черные списки кого не стоит звать на интервью.

Я б на месте HRов на основе таких комментариев составлял черные списки кого не стоит звать на интервью.
Я первый в очереди на попадание в их черный список. Уже в обном топике просил их об этом, так сказали $150 за нахождение вверху черного списка в течение месяца.

Простите, а в чем суть такого планирования? Ну ладно, для стройки я понимаю — составили план-график, каждое утро бежим к вокзалу (если в Киеве), на «биржу строителей», нанимаю 3-х нужных на сегодня каменщиков, 4-х штукатуров, 5 монтажников и вперед. Завтра все по-новой.
А при разработке SW? У вас программист Вася начал писать свой кусок и заболел? На какую биржу бежать, что-бы нанять на три дня его болезни Петю, который восполнит такую потерю? Ждем, пока Вася не выздоровеет? А сроки?
А если ваш проект включает разные ветки, в которых есть и работа с БД, и разработка фронт-энда, и хорошая часть какого-нибудь крутого датамайнинга? А программистов — по одной на каждое направление. И если сегодня он делает одну задачу, то вторую (по своему направлению) сможет начать не тогда, когда у вас это в плане стоит, а тогда, когда первую закончит. А свободного спеца по мобильной разработке не станете же посыдать писать бэк-энд?
Программисты не разнорабочие, взаимозаменяемость тут близка к нулю.
Ну и сколько у нас параллельных ветвей и «сколько ресурсов нам нужно»?
А что будете делать, если посреди разработки прибежит заказчик и скажет, «вот тут надо делать не так, а так»? Куда это в план впихнуть?
А есть еще такие прекрасные и никому не нужныенепонятные штуки, как всякие «PERT», «COCOMO», «FPA» и пр.....
Вот и получается, что теория прекрасна, да вот применение ее для нашей отрасли — ой какая проблема. Не даром на эту тему написаны сотни(без преувеличения) книг, а бОльшая часть проектов — все равно ни в график, ни в ресурсы не укладывается.
Поэтому ответ на вопрос

за что «хвататься» при оценке проекта с нуля
надо формулировать, наверное так — «в изучение прождект-менеджмента, причем желательно — именно для ПО-разработки и в собственный опыт его применения».
Простите, а в чем суть такого планирования?
Ты веротяно спутал слова суть и смысл.
Смысл есть, но в планировании большими блоками, частями. Чтобы, например, осознавать сложность проекта, понимать, где ты находишься во время реализации. Но заметка — муть ни о чем.

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

Или я чего-то не понял, или...
Что такое

Mой метод
???

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

Мой метод позволяет
Не позволяет, потому как ты не можешь предсказать будущее и все твои планы и картинки запросто будут только мешать тебе. А вообще всем этим играм с критическими путями 100 лет в обед. В СССР оное детально расписали ибо все пытались запланировать, почитай советские учебники.
Но, я не говорю, что такие картинки не нужны, они помогают, но нужно быть готовым их постоянно корректировать.
Конечно, задача менеджера — заказать бетон и кирпич уже на этапе копки ямы, а на этапе кладки кирпича иметь готовый проект крыши и понимание, какой тяжести крышу может данная конструкция выдержать.

Не надо так. Это не «оджайл», где MVP можно набросать на коленке, а потом выкинуть. В реальном мире проект дома надо сделать (и посчитать выдерживаемые нагрузки) ещё до начала работ над фундаментом.

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

«Хаки реальной жизни»?! Вы путаете нормальные инженерные практики с киевским строительным беспределом.

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

Подпорная стена чисто техническое сооружение никак не «при плохом изучении».

Самый надежный способ, эстимейт умножить как минимум на полтора-два. Еще ни разу не подводил.

Можно еще на три-четыре умножать, вообще не подведет.
Только какое отношение это имеет к управлению проектами?

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

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

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

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

На самом деле это нужно, чтобы складывать вероятностные оценки. То есть средние величины складывать можно. А также можно складывать квадраты отклонений.

Но тут вылазит другая проблема — как найти критический путь. Потому что один путь может быть, допустим 100 дней, с отклонением +/-10, а другой — 120 дней, но отклонением +/-30. Тут уже не получится их даже сравнить между собой.

А если еще есть итерации ... короче, спасает только Монте-карло в конечном итоге.

Имхо для войти-в-айти, не надо эти вероятностные эстимейты упоминать, это ж такой can of worms.

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

Вот пример схемы для небольшого проекта: dl.dropboxusercontent.com/u/1738774/WPlan.png

Позволю себе процитировать классику:

Закон Мэрфи

Дональд Мичи

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

Если какая‑нибудь неприятность может случиться, — она случается.

Любой учёный, прочитав это, сразу признаёт справедливость и общность закона Мэрфи, даже если он ранее не встречался с его чёткой словесной формулировкой.
Что же делать? Как с этим бороться? Совершенно ясно, что учитывать закон Мэрфи надо в момент составления плана новых исследований. Предположим, вы теоретически рассчитали, какое количество материала вам надо переработать, чтобы получить необходимую информацию. Пусть это теоретическое значение равно X . Это может быть число крыс, которых следует вскрыть, или акров, которые нужно засеять, или образцов почвы, которые необходимо собрать, и т. д. После этого вы пытаетесь разумным образом учесть всё, что может помешать. Пусть каждая отдельная причина маловероятна, все вместе они могут дать, скажем, 30% брака. Поэтому вы решаете увеличить свою смету в 1,43 раза по сравнению с теоретической оценкой (после 30%‑ной усушки и утруски 1,43·X превращается как раз в X ). Множитель, вводимый на этом этапе, я буду называть коэффициентом разумности и обозначать буквой R .
После этого обычно составляется окончательный план, но о его окончательности ещё придётся пожалеть. Оказывается, некоторые из потенциальных неприятностей не материализовались, но с другой стороны значительная часть закупленных крыс скончалась в ужасных конвульсиях, а один ваш коллега спутал препарированные органы, хранившиеся в холодильнике и снабжённые этикетками, с кормом для золотых рыбок и действовал в дальнейшем под влиянием этого заблуждения...
Профилактика против таких несчастий заключается в употреблении коэффициента Мэрфи M вместо R , Между ними существует простая связь
M = R²
Это означает, что в нашем гипотетическом случае, когда идеально неопытный человек купит 100 крыс, а «рационалист» приобретает 143, Мэрфи заказал бы 204 штуки.

Начало описания хорошее, немного не дописали. Мы посчитали PERT — оценку, в которую мы попадем с 50% вероятностью. В указанном примере, если мы скажем заказчику, что эстимейт на эту задачу (4, 8, 24) 10 часов, то с 50% вероятностью мы в него попадем/не попадем. Безусловно это слишком большой риск для нас, поэтому мы не будем давать оценку в 10 часов.
На графике (www.isixsigma.com/.../0228_shermanb.gif?80a08a) вероятность попадания равна площади фигуры под графиком слева от вертикальной линии нашего эстимейта (если посмотреть, то площадь слева от линии перта равна площади справа). Для увеличения вероятности попадания в наш эстимейт нам нужно линию двигать право, т.е. увеличивать эстимейт. Если вы сдвинете на одно стандартное отклонение, то вероятность попадания станет 68% ( en.wikipedia.org/...ki/Three-point_estimation ), что по моему опыту очень мало для бизнеса, но конечно же все зависит от компании, проекта, модели и т.п. Если, например, у вас проект с фиксированной стоимостью, вы захотите дать такой эстимейт, в который вы вложитесь с 99% вероятностью, для этого к перту нужно прибавить ~3 стандартных отклонения, а не одно.
И еще один важный нюанс — описанная модель является вероятностной, т.е. она начинает работать с определенного кол-ва данных, в данном случае ее можно применять если у вас 20-30 задач (на критическом пути). Модель работает потому, что реальное время выполнения отклоняется от нашего эстимейта то в одну сторону, то в другую, и метод позволяет уменьшить эстимейт за счет взаимной компенсации таких ошибок. При малом кол-ве задач такой компенсации не происходит.

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

мне больше нравится формула «максимальное время» х 3. сам пример показывает бессмысленность этой оценки, если чувак сказал что 3 дня делать кастомный, то какого фига оценка намного меньше? а вдруг что-то важное не было учтено. А вдруг какая-то архитектурная лажа вылезет, когда уже 95% написано?

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

другими словами, пм получает вместо одной рандомной цифры, сразу 3, причем почему-то считает, что средняя по величине цифра почему-то в 4 раза более весомая, нежели остальные.... ну так все сразу ясно стало :)

если же серьезно, то на самом деле практика показывает, что программист обычно слишком оптимистичен — хуле там работы, пол часа х**к х**к и в продакшн, беря в рассчет себя свежего, на пике продуктивности и тд. — что конечно же далеко не всегда так... другой вариант, это когда программист просекает все эти штучки-дрючки и начинает откровенно манипулировать своими эстимейтами, чтобы на научной волне подсчета выбить себе наибольшее время. Второй вариант конечно же более предпочтителен, так как пусть даже проект не работается на максимальной скорости, зато сроки придерживаются...

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

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

Средняя в 4 раза больше, чем крайние — это упрощенный beta-distribution, чтобы не грузиться этими деталями и менеджеров не грузить :) Грузиться надо, если делать всякие монте-карло симуляции.

Управление проектами в СССР. ВУЗФИЛЬМ 1976.
youtu.be/I5xhs3T2jX8

Меня всегда смущали «магические числа». За наличие их в коде всегда хотелось дать «линейкой по пальцам», особенно, если нет объяснения там же в коде, почему именно такое число.

Это я к чему. Откуда взялись 4 и 6?
Самой идее и этой методике рассчета сто лет в обед, но я еще нигде (кажется) не видел объяснения этим числам кроме одного упоминания вскольз про «эмпирический путь».

PS (edited) Пока писал комментарий и прокрастинировал — люди уже задали мой вопрос несколько раз. А так как удалить нельзя, то пусть уже остается, но простите за повтор :)

Потому что такая формула. Как и во многих других математических формулах, были опытным путем установлены некие коэффициенты. Никого ж не смущает правило 3х сигм — почему не 4, 6, 2? Принимается за аксиому. Тут тот же смысл.

3 сигмы — не аксиома, а особенность нормального распределения, заключающаяся в том, что за пределами интервала +/-3 сигмы лежит менее 2% значений выборки. Но это — если выборка из нормального распределения, про не нормальность и тяжелые хвосты (считай, «черные лебеди») сказано и написано до фига и больше.
Так что вопрос, откуда взялись 4 и 6, вполне уместен.

Чтобы узнать ответ на этот вопрос, нужно подымать литературу 50х годов, когда PERT систему придумали и обосновали эффективность. Я вот к чему вел — точно, как мы используем правило 3х сигм, не задумываясь, почему их 3, точно так, когда люди используют эту формулу, они ее просто используют.

как мы используем правило 3х сигм, не задумываясь, почему их 3
Я-то как раз задумываюсь, и уж в любом случае, смотрю с каким распределением имею дело. Иногда в контексте задачи достаточно и одной сигмы, а иногда (что в финансах чаще) и четырех не хватает.
нужно подымать литературу 50х годов
А Вам не кажется, что с 50х годов многие показатели могли устареть?

Еще раз — я имел ввиду, что если есть формула, то обычно не задумываются над происхождением коэффициентов. Примеров масса, я, видимо, взял неудачный, и мне начали указывать на то, что надо думать и т.п. Уточню — если доказано, что у меня выборка подчиняется нормальному закону распределения с вероятностью больше 99%, я использую правило 3х сигм, не задумываясь, почему именно 3. Если у меня треугольник, я не задумываюсь, почему площадь равна произведению высоты на основание с коэффициентом 0.5, а не 3, 6, 9. И так далее.

Показатели могли устареть. Более того, сами эти показатели проверялись на одной конкретной сфере — военной, и для ИТ могут быть неприемлемы. Но вопрос был «откуда они взялись», а не «почему они не пересмотрены». Это отдельная тема, как мне кажется.

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

Все же эмпирический, потому что почему именно бета распределение с такими параметрами? Т.е. это все конечно правильно, просто вы подменили вопрос, почему 4, 1, 1, на вопрос «почему beta-distribution» с подобными параметрами.

бай зе вей, а разве не резоннее в случае графа, а не одного элемента, считать не по нормализованным оценкам?
положим, A(1:3:11)->B(5:10:30)->C(1:3:5)
самый худший сценарий: 46
самый лучший: 7
а если нормализовать: 4 + 12,5 + 3 = 19,5
отклонения тоже суммировать? 2 + 6 + 1 = 9?

как-то выглядит не айс вообще.
даже с учетом сумм отклонений эстимейт едва достигает половины самого худшего сценария.

Если расхождение такое большое, имеет смысл обсудить с командой дополнительно, скорее всего, что-то непонято/не принято во внимание. Больше времени на ресерч. Нелогично, когда оценка по времени «от дня до недели».

я думал, речь о черновой оценке. больше, чем из трех блоков.

Не более чем интригующее название топика...
Так можно максимум оценить время добавления какой-нибудь фичи...

Это потому что вы работаете по аджайл

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

Я просто к тому что сильно примитивен пример, в нем все кажется просто, хотя в жизни все не так. Необходимо учитывать зависимости загрузки ресурсов, последовательность задач, бюджет в зависимости от выбраного сценария, риски и т.д.
Когда-то я спросил у одного руководителя как вы оцентиваете время выполнения задачи, его ответом было — Умножаю сказанное программистом на 3 + время на тестирование..

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

А если бюджет не позволяет, будем работать овертайм?

Че все набросились на автора, не все матерые пмы с 10+ лет опыта и теоретической подготовкой, это хорошая entry-level статья, нужно больше таких.

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

За инфу для джунов — огромный плюс Вам в карму.

Я аж завидую автору — он же еще не читал Критическую Цепь Голдратта.

Рекомендую, сідати і штудіювати уже. Можу дати кілька порад по ходу справи.

кто-то сходу назовет тулзу(или плагин для JIRA?), чтоб по матрице смежности(p2p зависимости между эпиками: вот это зависит от того и того — без продумывания всей картины целиком) строить граф и показывать критический путь?

На скільки я знаю такого плагіна немає. І в проджекті теж. А ті які є досить специфічні і не популярні

Мсье изобрёл диаграмму Ганта? Сочувствую

Мне кажется Мсье Иван хотел освежить нам память метода «Three point estimation» , где используется распределение двойного треугольника — но завуалированно назвав это методом «Критического пути».

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

Сейчас очень многие решили войти через PM:
jobs.dou.ua/trends/categories

Ну если войттивайти, то мсье должен бы догадаться, что ключевое в диаграмме ГГанта, это точность оценки каждого этапа. Если точность «пол лаптя вправо, пол лаптя влево» как это почти всегда в АйТи, ценность метода понижается практически до нуля.

Ггант применим на устоявшемся производстве, которому уже сотни лет и есть подтверждённая статистика времени затрачиваемого на каждый этап. В ай-ти же такой статистики практически нет и задачи каждый раз новые.

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

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

В ай-ти же такой статистики практически нет и задачи каждый раз новые.
В рамках одного проекта и одного коллектива это вполне можно предсказывать. Посмотрите например на эту статью
www.joelonsoftware.com/items/2007/10/26.html

А если на проекте текучка? В оутсорсе среднее время работы человека на проекте примерно год, если отбросить джуниоров, то два — три года. Как можно в этих условиях что то прогнозировать?

Вы ищете способ планировать точнее или отстаиваете бессмысленность прогнозирования?

Я лишь говорю, что сетевые графики в классическом виде не применимы в столь динамичной сфере.

Конечно применимы. Вопрос только в том, что дадут они не такие блестящие результаты.

Вот смотри, положим заказчик тебе говорит:сколько будет добавить кнопочку?
Ты говоришь:"час". За это время нужно сказать программисту, что надо сделать, убедиться что он понял правильно, ему запрограммировать и оттестировать.

Когда уже прошло пол часа заказчик просыпается:"я тут подумал, подвиньте эту кнопочку вправо и покрасьте в синий цвет. То есть, тебе надо опять донести до программиста, опять убедиться что он правильно понял, ему надо внести изменения собственно в код и в тесты.

Уже получается минимум два часа. И возникает вопрос: как их впихнуть в классический водопад? А это я ещё говорю о простой кнопочке.

К чему я это всё: можно применять оценку на основе диаграммы Гганта когда проект утверждён и изменения в нём не допускаются. Ты много видел айти проектов, которые не меняются со времён подписания техзадания?

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

Хотите знать, как вотерфолл справляется с «кнопочками»? Во-первых, «избыточные» оценки (или оценочные буферы, позволяющие определенный люфт по каждой задаче), во-вторых строгий процесс принятия изменений, который тут же отражается на стоимости и сроках и оттого сильно дисциплинирует «заказчика», позволяя уделить гораздо больше времени анализу в начале проекта. Изменения не допускаются? Что за бред, конечно допускаются, просто они (относительно) дорогие, так как требуют перепланирования (и переанализа, и так далее). Идеальный ли это процесс? Конечно нет. Но тут ведь вот какое дело: никакой процесс не идеален. Новое время ставит новые задачи.

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

софт для медицинского оборудования. Например, софт для космического спутника. Например, софт для встроенных систем, в которых затруднен апдейт. Во всех системах, где высока цена ошибки и/или дорог апдейт — требования будут очень тщательно проработаны, а каждое изменение пройдет фазу перепланирования — план будет пересчитан, определен новый критический путь, даны новые оценки.
В таких системах есть другая проблема — исследования. Очень мало вопросов ответ на которые уже известен. Наглядный пример — система «Буран». Софт для неё был закончен через 5 лет(!!!) после завершения основной программы.

То есть, ватерфол может конечно применяться, но на очень ограниченном количестве проектов

В таких системах есть вообще другая проблема — это система-прорыв, никто ничего подобного еще вообще не делал. А партия сказала — надо.

такая, что вот прям все встали и вышли строем?
ну будет, скажем, абстрактно 20% новых людей которые дадут абстрактную погрешность в +/-20%

прям, вот, внезапно встали и вышли?

поиграли в русскую рулетку на тимбилдинге, остался один джун, новичкам же везет

Владимир, конечно, чем меньше % неопределенности на проекте, тем легче использовать метрики. Статья не о метриках, и не о Ганте. Статья о реальных методах которые позволяют:
а) сконцентрироваться на основном пути разработки и разбить на этапы.
б) выявить риски и принять адекватные меры (во время оценки).
в) спрогнозировать требуемый ресурс и кост. На средне-малых проектах этого достаточно.

К большим человека без глубоких знаний не допустят.

Ок, допустим уходит у тебя тимлид. Другого на рынке искать долго. Куда пойдут эти твои методы? А ведь ситуация вполне реальная. Что, тимлид или синьор-помидор не может уволиться? Да запросто!

Итого модель Risk Prone. Хотя вопрос текучки кадров стоит вынести отдельно.

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

Ну, сетевые графики — а речь о них — и до Ганта были.
В любом случае — полезная штука, кстати, по воспоминаниям акад. Чертока (ракеты и люди), американцы их у себя успешно внедрили, когда догоняли СССР в космической гонке.

Штука полезная, но в ай-ти неприменима

Ну-ну, ракету построить попроще чем сайт или app склепать будет, да?
Говоря «неприменима», надо либо оговориваться что «у меня не получилось» (и plausible аргументировать, почему у других вряд ли получится), либо ссылаться на достаточно глубокие исследования.

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

Далее умножить реальную на 4, сложить с максимальной и минимальной и разделить на 6:

почему именно коэфициенты 4 и 6?

Чому 6 якщо 4 зрозуміло, а от чому вхідна 4, а не 8, або не 2 мені теж щось не ясно.

Просто есть такая формула в технике PERT — ru.wikipedia.org/wiki/PERT, смотреть Expected Time. Потому вопрос к изобретателям — они ее как-то вывели.

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

Согласен, это все программа ВУЗа по курсу «Проектный менеджмент». Где слом, нежданчик?

Даже у нас был предмет где рассматривались принципы моделирования бизнес-процессов в разных нотациях IDEF0, IDEF1 и т.д., а также обучали использовать Microsoft Project и там вроде бы он и покажет все критические пути, можно организовать параллельную работу, указать что без чего не может начинаться, вроде что то такое я помню :)

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

Это типа для 21 летних ПМ?

Подписаться на комментарии