Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

Естімейт проекту

Всім привіт,

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

також як після естімейту of project duration, правильно заестімейтити бюджет. І які дані потрібно вносити в план проекта?

Буду вдячний за будь яку суттєву інформацію!

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Известная взаимная глупость. От нее обычно только ИБД и просраные сроки.

Опрашиваешь спецов, сколько у них запланированные тобой таски займут. Это оптимистичная оценка — в нее гарантировано не уложишься.
Дальше просишь спецов подумать и озвучить риски, которые они видят (часть рисков они не увидят). Оцениваешь сколько займет решение этих рисков — получаешь пессимистичную. Где-то в нее в среднем вложишься. Иногда быстрее получится, но редко, чаще медленнее выйдет.

Работаю фрилансером, естимейты(интуитивные) делаю пару раз в день, проверяю в среднем раз в месяц.
Итак.
Если клиент не поменяет требования в процессе, и у вас эстимейт в часах
до 10 — скорее всего точный, множьте на 1.1-1.2
от 10 до 40 с выполнением точно в эту неделю, без других проектов ОДНИМ человеком — множьте на 1.5
от 10 до 40часов с выполнением больше чем за неделю либо более чем одним но менее чем четырьмя — множте на 2.
больше 4 человек и меньше 100*количество человек часов — множьте на 3.
больше 100*количество человек часов и/или больше 5 человек — смело множьте естимейт одного девелопера на 5 если он сеньйор или на 10 если мидл. Если естимейт выдал teamlead или techlead с опытом от 5 лет — множьте на 2 или 3 в зависимости от вашего к нему доверия.
Если получены 3+ естимейта от ключевых разработчиков, множите(больший) сначала на 2, потом на вашу оценку разницы производительности лучшего и худшего разработчика. Если получены только два эстимейта — берете больший и поступаете как с одним.

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

Если клиентом выступает более одного человека — множте на 10, не ошибетесь.

Прочти по — critical chain project management
и ужаснись ))

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

Починайте з чіткого визначення скоупу та припущень (версіі, енви, розподіл обовязків та ін.), якщо це можливо. Без цього естімейти нічого не варті. Потім зробіть WBS, оцініть девелопмент по кожній тасці, додайте буфер 5 — 30 % в залежності від таски. Помножте на три (це не жарт), для тестування, менеджменту, мітінгів, девопс та ін. Додайте всі таски та ще буфер 5-15 %. Вийде більш-менш реалістична оцінка проекту розробки за умови адекватних вхідних даних.

Можу розписати більш детально, пишіть в лічку.

Щоб запостити статтю, треба її спочатку написати :) Це в планах. Виклав презентаху на слайдшер.
www.slideshare.net/...​opment-project-estimation

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

Підтримую колегу, напишіть статтю — ця задача доволі актуальна і постійно викликає купу питань.

Дякую, підвищу пріорітет таски

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

Дуже дякую за презентацію, з естімейтом часовим розібрався.
А як після вирахування годин заестімейтити бюджет?

Ну, тот вже треба знаит кост однієї години. Якщо внутрішній -то у фінансистів, якщо зовнішній — то по ставках контракторів, простим множенням. І не забути додати інші кости — ліцензії, хард, закупки та ін. То вже парафія фінансистів — як ведеться облік, ща відонситьсядо косту проектув організації, а що ні.

Тобто PM по вирахованому естімейту, множить погодинний рейт на естімейт годин, + інші кости , таким чином отримую бюджет проекту , правильно ?

Шо саме мається на увазі під іншими коштами, чи можна тут по детальніше?

Дякую.

Приблизно так, хоча мої естімейти закінчувалися в основному на годинах. Інші кости (витрати) — відрядження, ліцензіі на софт, залізо, роялті, мита, субпідряники, зарпата, аренда, та ще мільйон можливих статей. Залежить від компанії, проекту, оточення, облікових політик і т.п.Тут краще звернутися до літератури по фінансам або спеціалістів.

але наскільки я розумію це вже не турбота ПМ-а?

:) Все, що стосується проекта — робота ПМа, але він може комусь делегувати частину. Відповідальність все одно на ньому (ній).

скажіть будь ласка, contingency та risk, заклдаються в бюджет як два різних показники, чи як один?
взагалі це одне й те саме, чи це різні поняття?

По суті це різні ризики. contingency — ризик по конкретній задачі. Risk — загального проекту, більше відноситься до взаємозвязку задач. Алек ен всі клієнти розуміють це. Можливо, доведеться сховати

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

Плохо спланированное дело занимает в 3 раза больше времени, на него отведённого. Хорошо спланированное — только в 2 раза.

Плохо спланированное дело занимает в 3 раза больше времени

в 3.14 раза

Кстати, именно на этот коэффициент необходимо умножить изначальный реальный эстимейт.

Можно, наверно, обойтись и без коэффициента, но для этого нужны
требования\оформленные вменяемые реквайрменты
анализ, дизайн, итп — в отсорсе этим не принято заморачиваться,
потому что если один баран написал эстимейт 4 ч от фонаря,
то после него никто уже ничего обычно не анализирует,
таска просто скидывается деву на бОшку, и фперёд.

Отдельная тема — отфонарные эстимейты, добываемые методами
срам-покера и
«вот, быстро, эстимейть, не для себя»
(нет, не получится на них забить, и делать задачу столько сколько надо,
потому что из них складывают планы спринтов, из спринтов — майлстоуны итп.)

Есть и лайфхак: дело пойдёт вдвое быстрее, если убрать эстимейт. Но нужно вменяемое ТЗ.

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

Да, риск серьёзный. Но согласитесь, и выигрыш того стоит.

Кстати, одним из положительных исходов подобного эджайла становится... бесконечный проект. Он «выстреливает», и потому хотелки приобретают лавинообразный характер, и как следствие — низкоприоритетные ложаться в бэклог. Хотя их никогда не отменят официально, и по итогу некоторые могут даже убить проект (особенно если это были требования IT-безопасности). Опять же, серьёзный риск, но выигрыш того стоит.

берете нормальный эстимейт, оптимистичный, песимистичный выводите средне арифмитическое потом помножаете на 2 а может даже 3

Ніде не можу знайти ясної статті по естімейту проекту під час написання проектного плану. Маю на увазі естімейту скільки часу займе проект та естімейт бюджету.

Это рядом с «с++ за 21 день»

аджайл — и не надо эстимейтов!

атжал — и не надо эстимейтов!

якщо клієнт дає лімітований бюджет або дату ?

Значит ему на самом деле нечего делать в этом бизнесе. Многие начинающие рокфеллеры просто думают что можно за 500 долларов забабахать «как вк но лучше» и оно сразу принесет миллионы.

То кому тогда нужны твои эстимейты? Тут бинарная оценка — либо сделаешь, либо не сделаешь.

Тогда делай такой план работы, чтобы заведомо уложиться в этот срок или бюджет. Точнее план работы делаешь на 70% от срока или бюджета. 30% уйдет на то, что не предвидел.
И советую такой проект делать не по новомодному сраму и подобным, а по упрощенному RUP — он тоже итерационный и достаточно гибкий, но без срамного бардака.

В эстимейтах самая большая проблема — оптимизм и недооценивание, поэтому эстимейт девелопера нужно умножать на 1.2-2, в зависимости от:

1) насколько хорошо детализированы требования по которым делали эстимейт? иногда одна недописанная (или недочитанная) строчка в требованиях это +100 часов работы, а выяснится это после начала работы. Чем детальнее требования тем точнее эстимейт.
2) насколько хорошо этот девелопер раньше укладывался в сроки?
3) это новый для него проект или он уже почти такой же делал и погрешность оценки в пределах 15%
4) сколько девелоперов будет работать?
5) учтите праздники, болезни, отпуска если вам нужно сказать дату, к которой проект будет готов

см. youtu.be/HOHEeEXMKcU

Ну наприклад
мені в проджект плані треба надати проджект таймлайн і schedule, ну і в кінці дату закінчення проекту.

Один девелопер дає естімейт на 2000 год, на всі заплановані фічі, на проекті 4 девелопера і 1 QA
Що або які % мені потрібно ще закладати в естімейти, чи змістять вони дату закінчення проекту?
Чи потрібно враховувати час на QA, BA і тд? чи враховужться чисто час на девелопмент?
Чи грає роль за якою методологією буде проект agile\waterfall?

дякую за відео

— лучше чтобы по каждой задаче девелопер давал не одно число, а три — например «в лучшем случае задача займет 4 часа, в среднем — 6 часов, в худшем — 8» — а дальше считайте по методике PERT (вот на доу статья была dou.ua/...​articles/quick-estimates и гуглите PERT)

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

— сейчас ваша главная задача — максимально снизить неопределенность и детализировать требования. На тестирование нужно выделять время (если нужно тестировать во всех браузерах на разных девайсах это огого сколько времени), на митинги, на развертывание окружений (development, staging, production), на багофикс (или ваши девелоперы пишут сразу без багов?)

— спросите самого девелопера какие он ожидает отклонения от данной им оценки? какие он видит риски?

— найдите опытного PMа из вашей же компании и делайте эстимейт вместе =) кто это Вас в чистое поле бросил, без подготовки?

Один девелопер дає естімейт на 2000 год, на всі заплановані фічі

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

Да для этого нужна огромная экспертиза в каждой из задействованных технологий, что бы угадать
Так что ставте наугад, а потом умножайте на два)

умножайте на два

На пи.

яке пояснення, чому саме число пі?

Традиція з часів башу

  1. Пи больше чем 2
  2. С пи начинается хорошее нецензурное слово, описывающее ситуацию на проекте близко к планированному дедлайну

«x» вообще мало, лучше «y» !

Ну тут всё логично. Так как оценка идёт сроков исполнения идеального сферического проекта в вакууме, то объём работ равен объёму сферы V = 4/3 Пи R^3. R^3 — даёт разработчик, а 4/3 и Пи ты добавляешь в формулу сам.

Пи больше чем 2 и звучит и прикольнее и научнее. Если уверены, можно еще на e в квадрате, так даже лучше(больше).

На пи — это ПИссиместичный сценарий.
На e — ReАлистичный
На O — оптимитичный (но с точностью до константы)

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