У меня данные из системы массового обслуживания как раз. Поэтому метод Top-Down — от общего к частному — там не работает. Более того, общая тенденция сейчас — это сокращение числа больших проектов, переход на частые итерации, что сводит задачу к тому же массовому обслуживанию. SaaS это уже не только маркетинговый слоган, а то самое массовое обслуживание.
Что касается больших проектов, то этот подход отлично работает для предварительной оценки всего проекта в целом, когда же доходит дело до детального планирования с учетом специфики каждой конкретной задачи, то от проектного плана никуда не избавиться. И там как раз работает математика, о которой я писал. А относительно ползущего состава работ я и сам написал параграфом ниже.
Главное что я хотел сказать статьей — что одного итогового числа, оценки по проекту, недостаточно. Необходим диапазон значений. Как считать этот диапазон готов обсудить — это как раз самое сложное и интересное.
Да, кстати, если взять в качестве условия не функциональную постановку задачи, а бизнес-требование — как то «добраться от рабочего места до места я могу поспать» или «добраться от рабочего места до места, где меня ждет любимая жена», то время на реализацию этого требования оказаться меньше 2-х минут.
Если необходимо оценить работу программиста, когда над задачей по работали и аналитик, и проектировщик, и даже менеджер (перепроверивший со всеми спонсорами актуальность задачи), то в этом случае конечно оценка будет значительно точнее. Тут вы безусловно правы.
В реальности я почти не помню таких случаев и всегда приходится давать оценки, исходя из кучи допущений, когда детальные требования и детали реализации в системе еще совсем не ясны. В моей выборке взяты именно такие экспертные оценки
Долго созревал, чтобы ответить на этот коментарий. Попробую разобрать вопросы по пунктам:
1. «Я не совсем понял, а что подразумевалось под начальными заявками?»
В моём случае бралась выборка по запросам надоработку систем и запросам к разработчикам на формирование разовых выборок из системы. Все задачи взаимно независимые поэтому статистика в этом смысле получилась чище, чем в большом проекте с многочисленными взаимосвязями. Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.
2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
3. Перемножение рисков я действительно не обсчитывал — это вообще не самая страшная на мой взгляд проблема, т.к. в проектах разработки отдельные задачи являются практически независимыми событиями. Страшнее ситуация когда паралельно выполняется две задачи — одна с малой неопределенностью, и относительно большими сроками и вторая с вдвое меньшим сроком, но значительно большей неопределенностью. Поскольку общий срок в этом случае определяется максимумом из двух сроков, суммарное распределение получит распределение, не описываемое аналитически. Как, какими приближениями оценивать такие случаи — для меня пока что загадка.
4. Согласен, что стремиться даже к точности в 10% в ИТ проектах смысла нет. Мой ориентир 15-20%.
5. Про грубейшие ошибки не понял — о чем тут речь?
Я хочу ещё отметить, что во многих случаях разработка замешана с сопровождением систем, когда кроме простых доработок, нужно ещё и инциденты устранять и пользователей консультировать. При этом в «цех» валится большое число «заказов» принципиально разного размера и управлять этим хозяйством надо именно как Ж-тип производства (с большой буквы Ж)
Под рукой данных нет, но из того что я знаю про проект, подобное происходило, когда выяснилось что данная фича уже реализована и не требует разработки. Т.е. Время по факту тратилось только на анализ требований
Точность оценки сроков пропорциональна корню от числа задач на критическом пути, а затраты на оценку этих задач и на само разбиение пропорциональны этому числу, так что в принципе можно даже подсчитать оптимальный уровень детализации плана.
Статистика говорит обратное. Люди умеют оценивать. По крайней мере в этом отдельно взятом проекте. При этом, они конечно ошибаются, но ошибки имеют четкое и вполне определенное распределение. А при разбиении исходной задачи на несколько более мелких точность существенно возрастает.
У меня данные из системы массового обслуживания как раз. Поэтому метод Top-Down — от общего к частному — там не работает. Более того, общая тенденция сейчас — это сокращение числа больших проектов, переход на частые итерации, что сводит задачу к тому же массовому обслуживанию. SaaS это уже не только маркетинговый слоган, а то самое массовое обслуживание.
Что касается больших проектов, то этот подход отлично работает для предварительной оценки всего проекта в целом, когда же доходит дело до детального планирования с учетом специфики каждой конкретной задачи, то от проектного плана никуда не избавиться. И там как раз работает математика, о которой я писал. А относительно ползущего состава работ я и сам написал параграфом ниже.
Главное что я хотел сказать статьей — что одного итогового числа, оценки по проекту, недостаточно. Необходим диапазон значений. Как считать этот диапазон готов обсудить — это как раз самое сложное и интересное.
Как вы думаете, где на идеальной схеме потоков находится репутация?
В реальности я почти не помню таких случаев и всегда приходится давать оценки, исходя из кучи допущений, когда детальные требования и детали реализации в системе еще совсем не ясны. В моей выборке взяты именно такие экспертные оценки
1. «Я не совсем понял, а что подразумевалось под начальными заявками?»
В моём случае бралась выборка по запросам надоработку систем и запросам к разработчикам на формирование разовых выборок из системы. Все задачи взаимно независимые поэтому статистика в этом смысле получилась чище, чем в большом проекте с многочисленными взаимосвязями. Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.
2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
3. Перемножение рисков я действительно не обсчитывал — это вообще не самая страшная на мой взгляд проблема, т.к. в проектах разработки отдельные задачи являются практически независимыми событиями. Страшнее ситуация когда паралельно выполняется две задачи — одна с малой неопределенностью, и относительно большими сроками и вторая с вдвое меньшим сроком, но значительно большей неопределенностью. Поскольку общий срок в этом случае определяется максимумом из двух сроков, суммарное распределение получит распределение, не описываемое аналитически. Как, какими приближениями оценивать такие случаи — для меня пока что загадка.
4. Согласен, что стремиться даже к точности в 10% в ИТ проектах смысла нет. Мой ориентир 15-20%.
5. Про грубейшие ошибки не понял — о чем тут речь?