Оценка сроков проекта
June 8th, 2008 Posted in БизнесСитуация: разботчик получает на руки описание нового модуля, который он должен разработать. Разработчик говорит, что ему потребуется два месяца, чтобы запрограммировать этот модуль.
Вопрос: какой срок должен внести в документацию руководитель проекта?
 |
Начинающий project manager так и запишет срок в два месяца. Более опытный руководитель знает, что данный срок нужно умножать на некий коэффициент, который обычно колеблется в пределах от 1.5 до 4. Чаще умножают на 2 или на 3, а 4 используется только в военное время. |
Почему так происходит? Во-первых разработчики склонны переоценивать свои силы. Во-вторых, разработчик чаще всего оценивает идеальный, кратчайший путь.
Ближайшая аналогия – подъем на гору. Разработчик прикидывает на глаз расстояние до вершины, делит его на свою среднюю скорость и получает ответ. Того факта, что подниматься придется в гору, не по прямой и с остановками он может и не учитывать. Собственно просчет рисков и не входит в круг его обязанностей.
Если вы в одном лице и разработчик и руководитель, на какой коэффициент нужно умножать начальный срок? Мне как-то попался на глаза интересный совет: умножаешь оценку на 20 и делишь на количество лет, которое ты занимаешься данной деятельностью.
Существуют и более научные методы оценки сроков, например Evidence-based scheduling, используемый в FogBugz. Я писал об этом чуть подробнее вот здесь. При наличии достаточного объема исторических данных можно сказать, насколько точна оценка того или иного разработчика.
У «коэффициента поправки» есть и побочный эффект. Допустим руководитель умножил оценку разработчика на два и получил спрок в четыре месяца. Не исключен вариант, когда разработчик будет валять дурака первые два месяца, он ведь считает, что четыря месяца это слишком много.
О зависимости производительности от того, по чьей оценке работает разработчик написано в Peopleware. По результатам ислледований получилось, что производительность наиболее высока, когда никакие сроки не устанавливаются.
К сожалению в реальной жизни обойтись без оценок сроков удается редко. Чаще всего сроки нужны для согласования расписания с другими разработчиками и отделами.
А на какой коэффициент вы умножаете срок названный разработчиком? Или, как советует Peopleware, обходитесь без каких-либо сроков?
21 Responses to “Оценка сроков проекта”
By Konstantin on Jun 8, 2008
IMHO,
нужен не коэффициент, а несколько оценок – оптимистичная, реалистичная и пессимистичная.
Как в PERT (http://en.wikipedia.org/wiki/PERT) или по аналогии.
Тогда получается более-менее нормальная точность.
Это даст срок “для разработчиков” – без рисков.
Также надо не забыть отдельно учесть и все риски.
Тогда получится срок с рисками – срок “наружу”
By Steward on Jun 8, 2008
Разработчику надо говорить – да ты офигел родной – и урезать срок на неделю с двух месяцев
Заказчику надо говорить – мой самый лучший разработчик будет заниматься только этим участком 3,5 месяца
Для себя считать оптимальный срок 2,5-3 месяца
By Alexander Bashkirov on Jun 9, 2008
Я как-то писал об этом: http://www.itblogs.ru/blogs/bashkirov/archive/2008/03/18/26330.aspx
В итоге сошлись на том, что попрака лежит в диапазоне от e до Пи
By Anatoliy Elsukov on Jun 9, 2008
Я стараюсь держать два плана. Один по оценке разаработчика. Второй моя оценка это где то в 1.5 раза больше на задачах где не вижу проблем и где то в 3 раза больше, если есть предпосылки к сложностям.
Два плана позволяют хорошо мотивировать разработчиков, сам назанчил срок – сам в него и вписывайся. (Я не давлю на разработчика по срокам, кроме клиничиски завышиных оценок)
А второй план показывает мне насколько я таки вписываюсь в проект.
By DenisM on Jun 9, 2008
методы функциональных точек уже не в моде ? )
By Anton Vokrug on Jun 9, 2008
без сроков вообще никак. не представляю даже…
возможно стоит держать два срока – реальный и не реальный
реальный сообщать начальству, а не реальным подпинывать разрабов.
слу а ты в какой программе проекты ведешь?
By Anton Vokrug on Jun 9, 2008
сори, комменты выше не прочитал, там все так и думают
By Roman on Jun 9, 2008
Некоторое время назад читал о CCPM (Critical Chain Project Management).
Насколько понял, идея заключается в следующем:
Существует несколько буферов, играющих роль амортизаторов по времени.
Задачи на критическом пути календарного плана подкрепляются буффером по времени. Каждая ветка задач, которая “кормит” критический путь также имеет свой буффер. Кроме того, существуют несколько других буферов, которые “прикрывают” другие проблемы: недоступность ресурсов на момент старта выполнения задач и т.п.
Разработчики подхода верят в обратное относительно мнениям, представленным здесь в комментах: Специалист всегда накидывает больше времени на выполнение задачи, учитывая всевозможные риски и опыт прошлых неудач.
Поэтому …
1. Узнаем оценку специалиста.
2. Делим! ее на коефициент и заносим в план разработчику. Соответсвенно время на выполнение становится меньше, чем изначально оценили.
3. В “своем” плане к этой задаче добавляем буфер времени + другие буферы.
4. Контролируем задачи и процент использования резервных буферов.
Утверждается, что подход позволяет организациям гарантировать выполнение проектов в срок и даже раньше.
Также, деление оценочного времени на опр. коефициент “давит” на исполнителей и мотивирует выполнить работу в максимально короткие сроки (не дает расслабляться).
Сам подход не использовал, но планирую поэксперементировать. Чувствую, что есть в этом что то здравое.
Кроме того, имею несколько вопросов:
1. Как продать такое клиенту?
2. Каким образом расчитывать счета на оплату услуг (например, на почасовую оплату труда разработчиков ПО в outsourcing проектах)? – Подозреваю, что фактическое время, затраченное на выполненных работ. Но нужно обдумать.
3. А стоит ли?
Р.
З.Ы. Читал, в основном, здесь: http://www.prochain.com/resource_center/articles/intro_to_critical_chain.asp
By stussy on Jun 9, 2008
я пока стараюсь коэффициента 1 придерживаться, но он явно уже близок к 1,5 с тенденцией к увеличению.
By ksi on Jun 9, 2008
У нас менеджеры говорят, что за срок в Pi раз больший запланированного получится результат, в Pi раз меньший запланированного
By Влад on Jun 9, 2008
Сроки важны но ставить реальные очень трудно. Как разработчик скажу что очень редко бывает работа точно такая-же как была раньше. Как правило работаешь с чем то что никогда раньше не делал и поставить реальный срок поэтому очень трудно так как приходится догадываться насколько будет сложно это делать. Единственное что можно сделать это по совету того же Джоела разбивать большие задачи на маленькие каждая не более двух дней разработки длинной. Однако если проэкт очень большой то сама разбивка на подзадачи займет немало времени.
By Maxim Kramarenko / TrackStudio on Jun 9, 2008
Критика evidence-based scheduling:
http://maximkr.livejournal.com/11192.html
Если коротко, то проблема с планированием вовсе не с оценкой времени выполнения конкретных задач, а с непредвиденным появлением новых задач.
By Maxim Kramarenko / TrackStudio on Jun 9, 2008
2Влад:
> Единственное что можно сделать это по совету
> того же Джоела разбивать большие задачи на
> маленькие каждая не более двух дней
> разработки длинной. Однако если проэкт очень
> большой то сама разбивка на подзадачи займет
> немало времени.
Мы разбиваем проект на задачи даже по 2-3 часа, но на реальность сроков это не влияет никак.
Когда разработчик оценивает сроки – он уже учитывает возможную сложность задачи, свой опыт, непредвиденные трудности и т.п., но он не знает, насколько его опыт “подходит” для решения именно этой конкретной задачи.
Смысла учитывать влияние тех же факторов и повторно игнорировать влияние других факторов на уровне менеджера нет никакого.
Или представьте себе уровень еще более вышестоящего менеджера, который поручил подчиненным менеджерам этот проект. Он для получения своей оценки тоже должен оценки подчиненных руководителей умножать на 3.14 или может так использовать ?
By Сергей Корнилов on Jun 9, 2008
2Konstantin:
про PERT ничего не слышал.В принципе у Джоэла в EBS используется не коэффициент, а именно вероятность завершения к данному сроку, т.е. можно планировать более агрессивно (оптимистично) и или с запасом (пессимистично).
By Сергей Корнилов on Jun 9, 2008
2Vlad&Maixm:
даже если разбиение на более мелкие задачи не приводит к идеально точной оценке, это делать все равно нужно. Без разбиения вообще никакую более или менее реальную оценку не получишь.
By Сергей Корнилов on Jun 9, 2008
2Maxim,
я прочитал заметку, хорошо написано. Мне кажется тут происходит некоторое смешение понятий.
Если в проект в большом количестве добавляются неучтенные ранее задачи, это уже не проблема оценки сроков, а проблема менеджмента.
Если в процессе увольняется или заболевает разработчик – это не новая задача, это форс-мажор (если он один на проекте).
Если клиент просит включить еще одну-две фичи в плановый релиз и вы соглашаетесь – это проблема руководства. Нужно либо клиенту отказать, либо решить его проблему другим способом.
Если возникают непредвиденные технические трудности, скажем сторонний компонент не поддерживает жизненно нужную вам фичу, это недоработка архитектора того, кто производил сравнительный анализ компонентов. Для таких ситуаций, а также для устранения багов и прочего вводится коэффициент.
By Сергей Корнилов on Jun 9, 2008
В целом мне нравится озвученный здесь многими вариант – дать разработчику работать по его собственной оценке, а для себя контролировать процесс по оценке, умноженной на коэфифциент.
Разработчик, работающий по составленному им самим расписанию, должен чувствовать себя комфортабельно, а это главное.
By Maxim Kramarenko / TrackStudio on Jun 9, 2008
Ну в общем я согласен.
Evidence-based scheduling отвечает на вопрос “когда разработчики закончат все внесенные в систему задачу?”, но не “когда мы сможем выпустить релиз?”.
Тут есть важный момент – разработчики же видят свои оценки и реальные результаты. Если у разработчика средняя задача занимает 2 часа, то за месяц у него будет ~80 задач. За год – почти 1000.
Если он по каждой будет видеть свою первоначальную оценку и сколько времени оно заняло в реальности – он через год прогнозы не хуже багтрекера сможет выдавать и корректировать свои “ощущения”. Если у менеджера 10 таких работников – менеджер научится еще раньше.
Если проект разбивается на задачи, по ним ведется учет запланированного и потраченного времени, а работники знают о своих оценках и реальных результатах – они быстро научатся сами делать правдоподобные прогнозы. Это будет прогноз без учета форс-мажора и прочих непредвиденных обстоятельств, но EBS в этом смысле ничуть не лучше.
By Maxim Kramarenko / TrackStudio on Jun 9, 2008
2Сергей Корнилов:
> В целом мне нравится озвученный здесь многими
> вариант – дать разработчику работать по его
> собственной оценке, а для себя контролировать
> процесс по оценке, умноженной на коэфифциент.
А зачем ? Ведь разработчик тогда будет понимать, что его оценка может быть достаточно произвольной, пролет по срокам в 3 раза никого не беспокоит, так он сам оценивать свою работу не научится.
Мне кажется, что все эти проблемы происходят от того, что разработчика заставляют оценить время решения большой задачи, на недели или месяцы. Если обещали сделать за полгода, а сделали за год – это очень серьезная проблема, она кого угодно “на уши” поставит и следующий шанс “отточить” свое умение оценивать у разработчика появится уже на следующем проекте.
Если разработчику давать задачи на 2-3 часа, то пролет на сроках в разы на ходе полугодового проекта не скажется никак, разработчик поймет в чем именно был не прав и на следующий день оценит работу точнее.
Приведу аналогию: когда хотят научится программировать на каком-либо языке, то пишут сначала одну маленькую программу, запускают, смотрят, немного исправляют, опять запускают и смотрят. Каждый цикл – это очередная порция обратной связи.
А если бы программист полгода писал программу, потом бы 1 раз компилировал, запускал ее и смотрел – работает или нет ? Какие бы вывод он мог сделать после такого прогона ? Что в следующий раз нужно сделать в 3 раза больше проверок на нулевой указатель ?
By Саша on Aug 25, 2008
Критикал чейн – очень здравый и дающий хорошие результаты подход, применяем в компании.
Для клиентов делаем фейковый план, потому что показать “буфер” в пол проекта незнакомым с методологией людям – смерти подобно.
Проект разбиваем на такски 2-4-8-12 часов
Не надо путать длительность и трудозатраты. Программисты могут сказать только трудозатраты, да и то идеальные.
А уже в длительности можно учесть, что норма выработки прогера реально 70-80%, что есть риски на некоторых тасках а для некоторых тасков надо ждать клиента и тп