Всім привіт,
Ніде не можу знайти ясної статті по естімейту проекту під час написання проектного плану. Маю на увазі естімейту скільки часу займе проект та естімейт бюджету. Наприклад, маючи естімейти дівелопера в годинах на кожну фічу.
також як після естімейту of project duration, правильно заестімейтити бюджет. І які дані потрібно вносити в план проекта?
Буду вдячний за будь яку суттєву інформацію!
Вспомнил принцип раздувания и сжатия сроков.
Менеджер просит девелопера оценить таску. Девелопер думает: месяц, но перестраховывается и умножает на два. Менеджер тоже перестраховывается и сообщает топ-менеджеру, что на таску надо четыре месяца. Топ-менеджер тоже имеет свой коэффициент умножения и сообщает директору, что на таску надо восемь месяцев.
Директор все это выслушивает и говорит: «Вы что, совсем там охренели восемь месяцев на такую простую таску? Даю вам не больше четырех месяцев.» Топ-менеджер, поскольку больше нет запаса, требует от менеджера закончить таску через два месяца. Менеджер ставит девелоперу закончить таску через месяц.
Работаю фрилансером, естимейты(интуитивные) делаю пару раз в день, проверяю в среднем раз в месяц.
Итак.
Если клиент не поменяет требования в процессе, и у вас эстимейт в часах
до 10 — скорее всего точный, множьте на
от 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
и ужаснись ))
посмотрите методики оценки затрат времени в пм бук, то что вы используете эстимейты от девелопера — это называется экспертной оценкой, лучше конечно опросить
на ДОУ було декілька:
— dou.ua/...stimate-development-time
— dou.ua/...articles/quick-estimates
— dou.ua/...icles/ob-otsenke-vremeni
— dou.ua/...nta/columns/road-to-hell
— dou.ua/...a/articles/critical-path
— dou.ua/...evolyuciya-odnoj-metriki
— dou.ua/...icles/dou-labs-evergreen
— dou.ua/...rticles/pm-best-practice
— dou.ua/.../articles/time-breakdown
Починайте з чіткого визначення скоупу та припущень (версіі, енви, розподіл обовязків та ін.), якщо це можливо. Без цього естімейти нічого не варті. Потім зробіть WBS, оцініть девелопмент по кожній тасці, додайте буфер 5 — 30 % в залежності від таски. Помножте на три (це не жарт), для тестування, менеджменту, мітінгів, девопс та ін. Додайте всі таски та ще буфер
Можу розписати більш детально, пишіть в лічку.
Запостите статью
Щоб запостити статтю, треба її спочатку написати :) Це в планах. Виклав презентаху на слайдшер.
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 долларов забабахать «как вк но лучше» и оно сразу принесет миллионы.
Беги
То кому тогда нужны твои эстимейты? Тут бинарная оценка — либо сделаешь, либо не сделаешь.
В эстимейтах самая большая проблема — оптимизм и недооценивание, поэтому эстимейт девелопера нужно умножать на
1) насколько хорошо детализированы требования по которым делали эстимейт? иногда одна недописанная (или недочитанная) строчка в требованиях это +100 часов работы, а выяснится это после начала работы. Чем детальнее требования тем точнее эстимейт.
2) насколько хорошо этот девелопер раньше укладывался в сроки?
3) это новый для него проект или он уже почти такой же делал и погрешность оценки в пределах 15%
4) сколько девелоперов будет работать?
5) учтите праздники, болезни, отпуска если вам нужно сказать дату, к которой проект будет готов
Ну наприклад
мені в проджект плані треба надати проджект таймлайн і 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 год, на всі заплановані фічі
Я конечно не знаю как выкручиваются опытные менеджеры когда клиент хочет эстимейта на такой проект, но имхо при таком количестве часов любой эстимейт — наугад
умножайте на два
На пи.
яке пояснення, чому саме число пі?
Традиція з часів башу
«x» вообще мало, лучше «y» !
Ну тут всё логично. Так как оценка идёт сроков исполнения идеального сферического проекта в вакууме, то объём работ равен объёму сферы V = 4/3 Пи R^3. R^3 — даёт разработчик, а 4/3 и Пи ты добавляешь в формулу сам.
Пи больше чем 2 и звучит и прикольнее и научнее. Если уверены, можно еще на e в квадрате, так даже лучше(больше).
На пи — это ПИссиместичный сценарий.
На e — ReАлистичный
На O — оптимитичный (но с точностью до константы)
Maksym Ganenko
anonymous
anonymous
Alexander Merkulov
Дмитро Дем'яненко
mobile mobile
Ruslan Shevchenko
Oleksandr Katrusha
Роман Иваненко
Oleksandr Katrusha
Volodymyr Spodaryk
Олексій Пєніє
Gremlin
Олексій Пєніє
Dmitry Panfilov
Александр Шевченко
Gennady Dogaev
Mike Gorchak
Olena Sharovar
Olena Sharovar
Victor Musienkо
Alexander Merkulov
Vasily Nekrasov
Котэ
54 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів