Как оценить сроки проекта с нуля: метод «критического пути»
Вашей команде поручили реализовать проект — мобильное приложение. Приложение не сложное, но заказчик, он же владелец продукта, просит оценку по времени реализации. С чего начать?
В новом проекте, вводные которого поступили на оценку, первым делом нужно определить «критический путь». Без команды это сделать практически не реально, поэтому как и на остальных этапах, нужна техническая экспертиза исполнителя/консультанта.
Выявляем «критический путь»
Если просто описать суть данного метода — нужно найти участки выполнения проекта, которые не могут происходить параллельно, и определить максимальную длину. Для понимания приведу пример строительства дома:Копание ямы -> заливка фундамента -> возведение стен -> накрытие крышей.
Сколько бы не было ресурсов на проекте, фундамент не сможет выстояться быстрее чем за 28 дней (строительные нормы). И сколько бы не было ресурсов на подготовку крыши, если только один строитель будет класть кирпич, то остальной ресурс будет просто простаивать в данный момент.
Конечно, задача менеджера — заказать бетон и кирпич уже на этапе копки ямы, а на этапе кладки кирпича иметь готовый проект крыши и понимание, какой тяжести крышу может данная конструкция выдержать. Это процессы, которые могут происходить параллельно.
Вернемся к нашему проекту и найдем критический путь разработки такого приложения. Техническая команда проекта сориентирует, что разрабатывать графические эффекты можно только после окончания реализации основного контроллера приложения, чтобы понимать их соответствие требованиям. Сравнение обработанной картинки и оригинала ползунком можно делать после того, как эффекты будут накладываться на изображение. Ну а подключение социальных SDK вполне может происходить параллельно с реализацией экспорта готовой фотографии.
Рассчитываем длину
После того, как критический путь у нас есть, определим его длину. В этом поможет метод оценки по точкам, который помогает выявить завышения/занижения сроков исполнителем из-за рисков.
Суть метода — спросить реальную оценку, минимально возможную и максимальную. Далее умножить реальную на 4, сложить с максимальной и минимальной и разделить на 6:
Оценка = (4Р + Мин + Макс) / 6.
Это и будет нормализованная оценка. Но она все же будет вероятно отличаться от финального результата на отклонение — шестую часть разницы между минимальной и максимальной оценкой:
Отклонение = (Макс - Мин) / 6.
Таким образом, пусть для стандартного «ползунка сравнения» мы часто получим такие оценки от исполнителя: «Реально его сделать за день, хотя если подойдет telerik-like, то и за 4 часа можно управиться. Ну а если писать полностью кастомный, то может и дня три».
Мы имеем оценки 4, 8 и 24. По формуле получаем: (4 + 8*4 + 24) / 6 = 10 часов с отклонением в плюс-минус (24 — 4)/6 = 3,33 часа.
Результаты
Оценив задачи на критическом пути, мы видим, сколько времени минимально потребуется на проект.
Оценив количество параллельных путей, мы знаем, сколько ресурсов нам нужно.
Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU
До обраного В обраному 2
Схожі статті Оценка трудоемкости проектов разработки. Часть 2Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. 72
О роли PM и менеджменте больших масштабируемых проектовПМ — это специалист, способный объединить вокруг себя проектную команду и обеспечить реализацию проекта, удовлетворяющего требованиям Заказчика. Часто требования весьма завышены, сроки крайне сжаты, а бюджеты таковы, что без «магии» проект просто не реализуем. 52
Як створити реєстр ризиків та працювати з нимПроєктів без ризиків не буває, бувають лише неідентифіковані ризики. 5
DOU News #12
Найкращі коментарі пропуститиУправление проектами в СССР. ВУЗФИЛЬМ 1976.youtu.be/I5xhs3T2jX8
94 коментарі— Когда вы уже сдадите проект!?— Семь раз отмерь — один раз отрежь.— Вы затянули сроки уже в два раза!— Поспешишь — людей насмешишь.
коментарии поражают, просто парад неадеквата.Оценка используя критический путь — один из азов планирования, один из простых подходов, понятно что entry level. и если применяется на практике то в комплексе с другими решениями по учету рисков и т. д. и т. п.
Наезжать на автора и писать, что метод фуфло потому как не учитывает это и то — полное невежество и глупость. Все равно, что комментировать статью «Что такое абстрактный класс в ООП» в стиле «программу на одних абстрактных классах не построиш, поэтому это фуфло» или привести пример когда нужно использоват интерфейс с тем же выводом, или «статья фуфло, потому что я и так знаю что такое абстрактный класс» — полный неадкват.Я б на месте HRов на основе таких комментариев составлял черные списки кого не стоит звать на интервью.
Простите, а в чем суть такого планирования? Ну ладно, для стройки я понимаю — составили план-график, каждое утро бежим к вокзалу (если в Киеве), на «биржу строителей», нанимаю нужных на сегодня каменщиков, штукатуров, 5 монтажников и вперед. Завтра все по-новой.А при разработке SW? У вас программист Вася начал писать свой кусок и заболел? На какую биржу бежать, что-бы нанять на три дня его болезни Петю, который восполнит такую потерю? Ждем, пока Вася не выздоровеет? А сроки?А если ваш проект включает разные ветки, в которых есть и работа с БД, и разработка фронт-энда, и хорошая часть какого-нибудь крутого датамайнинга? А программистов — по одной на каждое направление. И если сегодня он делает одну задачу, то вторую (по своему направлению) сможет начать не тогда, когда у вас это в плане стоит, а тогда, когда первую закончит. А свободного спеца по мобильной разработке не станете же посыдать писать бэк-энд?Программисты не разнорабочие, взаимозаменяемость тут близка к нулю.Ну и сколько у нас параллельных ветвей и «сколько ресурсов нам нужно»?А что будете делать, если посреди разработки прибежит заказчик и скажет, «вот тут надо делать не так, а так»? Куда это в план впихнуть?А есть еще такие прекрасные и никому не нужныенепонятные штуки, как всякие «PERT», «COCOMO», «FPA» и пр. Вот и получается, что теория прекрасна, да вот применение ее для нашей отрасли — ой какая проблема. Не даром на эту тему написаны сотни(без преувеличения) книг, а бОльшая часть проектов — все равно ни в график, ни в ресурсы не укладывается.Поэтому ответ на вопрос
Вы моделируете частные случаи, из которых и состоит проект. Запары, отпуска, болезни и т.п. Это все круто, но основная задача ПМа, как не крути — концентрация на результате, фокусировка если угодно. Мой метод позволяет найти за что «зацепиться» глазу, выяснить что есть ядром проекта, что его суть. Все остальное что Вы перечислили, является оперативной работой, которая решается ресурсами. Проекты реализуются для получения прибыли, а не минимизации затрат, и адекватный менеджмент согласится что основной функционал проекта не может разрабатываться с BUS Factor = 1.
Или я чего-то не понял, или. Что такое
ни в коем случае не претендую на новаторство и авторство — мой т.е. который я описал, а не придумал.
Не надо так. Это не «оджайл», где MVP можно набросать на коленке, а потом выкинуть. В реальном мире проект дома надо сделать (и посчитать выдерживаемые нагрузки) ещё до начала работ над фундаментом.
я Вас умоляю, все так же, только затраты больше в % соотношении к готовой конструкции. Иначе не существовало бы «подпорных стен», «доливки фундаментов» и прочих «хаков» реальной жизни. Конструктив просчитывается на этапе проектирования, но запас делается таковым, что бы Вам не пришлось расставлять мебель согласно ограничениям — не на стык плит, не на одной стороне с сейфом и т.д. По этому маневр что с крышей, что с окнами у Вас остается.
«Хаки реальной жизни»?! Вы путаете нормальные инженерные практики с киевским строительным беспределом.
ну так в проекте SW так же все. Для примера — строится подпорная стена при плохом изучении геологии и геодезии — оползни там, плавуны, торфяники. Так же и в разработке — вышел крутой фреймворк, супер быстрый, только вот связи с БД приходится пилить web api :)
Подпорная стена чисто техническое сооружение никак не «при плохом изучении».
Самый надежный способ, эстимейт умножить как минимум на полтора-два. Еще ни разу не подводил.
Можно еще на три-четыре умножать, вообще не подведет.Только какое отношение это имеет к управлению проектами?
Опять таки, не управлять неопределенностью, потому что нет информации — это такой себе «авось» управления с проектами. Тогда ПМ вообще не нужен — пусть себе идет разработка как идет, а там в конце глянем, на сколько мы вышли за сроки и бюджет.
Автор забыл сказать, зачем собственно это все делать. Ведь если сказали, что реально сделать за день, это и есть самый вероятный срок. Если интересует другой перцентиль, то можно попытаться примерно его и спросить.
На самом деле это нужно, чтобы складывать вероятностные оценки. То есть средние величины складывать можно. А также можно складывать квадраты отклонений.
Но тут вылазит другая проблема — как найти критический путь. Потому что один путь может быть, допустим 100 дней, с отклонением +/-10, а другой — 120 дней, но отклонением +/-30. Тут уже не получится их даже сравнить между собой.
А если еще есть итерации . короче, спасает только Монте-карло в конечном итоге.
Имхо для войти-в-айти, не надо эти вероятностные эстимейты упоминать, это ж такой can of worms.
Данный метод не учитывает массу факторов, и многоуровневые взаимосвязи между тасками, а также загрузку конкретных людей. Попробуйте применять ментальные карты, будет гораздо точнее результат.
Позволю себе процитировать классику:
Я думаю, что самое глубокое и прочное впечатление в своей жизни каждый научный работник получает от того, как неожиданно, как несправедливо, как удручающе трудно хоть что‑нибудь открыть или доказать. Многих осложнений и разочарований можно было бы избежать, включив в качестве основного пункта во все программы, пособия и инструкции для начинающих исследователей подробное изложение закона Мэрфи:
Если какая‑нибудь неприятность может случиться, — она случается.
Любой учёный, прочитав это, сразу признаёт справедливость и общность закона Мэрфи, даже если он ранее не встречался с его чёткой словесной формулировкой.Что же делать? Как с этим бороться? Совершенно ясно, что учитывать закон Мэрфи надо в момент составления плана новых исследований. Предположим, вы теоретически рассчитали, какое количество материала вам надо переработать, чтобы получить необходимую информацию. Пусть это теоретическое значение равно 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 стандартных отклонения, а не одно. И еще один важный нюанс — описанная модель является вероятностной, т.е. она начинает работать с определенного кол-ва данных, в данном случае ее можно применять если у вас задач (на критическом пути). Модель работает потому, что реальное время выполнения отклоняется от нашего эстимейта то в одну сторону, то в другую, и метод позволяет уменьшить эстимейт за счет взаимной компенсации таких ошибок. При малом кол-ве задач такой компенсации не происходит.
Полностью с Вами согласен, я упростил для понимания систему и очередность.
мне больше нравится формула «максимальное время» х 3. сам пример показывает бессмысленность этой оценки, если чувак сказал что 3 дня делать кастомный, то какого фига оценка намного меньше? а вдруг что-то важное не было учтено. А вдруг какая-то архитектурная лажа вылезет, когда уже 95% написано?
Оценка по трем точкам не дает четкого ответа «за сколько», она а) выявляет риски (это как раз Ваш вопрос — почему так долго делать, что может вылезти и зачем) и б) показывает «нормальное» время выполнения данной задачи по отношению к другим. Задача менеджера как раз и состоит в том, что бы разобраться, что важное не учтено, вытащить, если угодно, из разработчика его волнения и переживания, которыми он не особо то горит делиться. Так лучше оценивать когда известен конкретный исполнитель, а не «гибкая команда», так как в планнинг покере все равно будет «всплывать» тот минус, что после первого раунда все прислушиваются к оценке «авторитета».
другими словами, пм получает вместо одной рандомной цифры, сразу 3, причем почему-то считает, что средняя по величине цифра почему-то в 4 раза более весомая, нежели остальные. ну так все сразу ясно стало :)
если же серьезно, то на самом деле практика показывает, что программист обычно слишком оптимистичен — хуле там работы, пол часа х**к х**к и в продакшн, беря в рассчет себя свежего, на пике продуктивности и тд. — что конечно же далеко не всегда так. другой вариант, это когда программист просекает все эти штучки-дрючки и начинает откровенно манипулировать своими эстимейтами, чтобы на научной волне подсчета выбить себе наибольшее время. Второй вариант конечно же более предпочтителен, так как пусть даже проект не работается на максимальной скорости, зато сроки придерживаются.
При том исполнитель забывает, что работа на максимальной скорости дала бы ему возможность спокойно сходить в отпуск, в жаркий летний месяцок.
в наших реалиях отпуск мало как связан с продуктивностью. а сделать быстрее таску, нежели было заэстиметчено, это плюс себе в карму. Намного лучше, нежели наоборот — попытался сэкономить деньги и время заказчика, в процессе вылез какой-то нежданчик, и в лучшем случае остаешься на работе вечером и на выходных, в худшем — объясняешь вышестоящим, что не так, и почему не предвидел, когда эстимейтил.
Средняя в 4 раза больше, чем крайние — это упрощенный beta-distribution, чтобы не грузиться этими деталями и менеджеров не грузить :) Грузиться надо, если делать всякие монте-карло симуляции.