Comments 18
Да никто оценивать не умеет и не будет уметь.
Статистика говорит обратное. Люди умеют оценивать. По крайней мере в этом отдельно взятом проекте. При этом, они конечно ошибаются, но ошибки имеют четкое и вполне определенное распределение. А при разбиении исходной задачи на несколько более мелких точность существенно возрастает.
Сильно заваисит от специфики задачи. Спланировать разгрузку Камаза с кирпичами можно гораздо точнее, чем разработку нового самолёта, которая требует ещё по дороге изобрести кучу всего.
Без ссылки на конкретные исследования, методики и условия оценивания, подобный материал недостоверен.
На будущее, большинство методик оценивания как раз и существуют для того, чтобы фильтровать подобные «человеческие факторы». Профессиональное оценивание — это прогнозирование на основе архивной статистики и измерений, за калькулятором психологических факторов я почему-то не замечал.
К тому же, учитывая что оценки даются в подобных точечных формах без комментариев, у меня есть серьезные вопросы относительно профессиональных качеств всех, кто подобное публикует, переводит и цитирует.
У оценивания есть много ахиллесовых пят, произростающих из матстатистики, но уж точно не такого вида.
На будущее, большинство методик оценивания как раз и существуют для того, чтобы фильтровать подобные «человеческие факторы». Профессиональное оценивание — это прогнозирование на основе архивной статистики и измерений, за калькулятором психологических факторов я почему-то не замечал.
К тому же, учитывая что оценки даются в подобных точечных формах без комментариев, у меня есть серьезные вопросы относительно профессиональных качеств всех, кто подобное публикует, переводит и цитирует.
У оценивания есть много ахиллесовых пят, произростающих из матстатистики, но уж точно не такого вида.
Я не совсем понял, а что подразумевалось под начальными заявками?
Обычно на каком материале вы намеряли, на таком ваши модели и обладают предсказательной способностью.
Вы достаточно странно трактуете PERT. Это средство планирования, а не оценки. Оценки же являются основной для подобного планирования. Также, это средство для управления ходом проекта на основе плана, построенного на оценках, но никоим образом из этой методики не вытекает оценка проекта в целом.
За рамками этой методики кроме прочего находится такой фактор как преумножение рисков. Задачи на разных этапах и разного характера оказывают влияние на выполнение всех последующих. Как следствие этого и других моментов наиболее важный в оценке эффект, а именно расширение неопределенности оценки относительно текущего состояния проекта отражено плохо.
То, что вы воюеете за 10% точность замечательно, но в свете изложенного вы пытаетесь воевать на всех фронтах, на большинстве из которых подобная точность невозможна.
Я бы посоветовал задуматься, почему сейчас в оценке как правило используются регрессионные модели на основе показателей проектов в целом, ну, и заодно почитать хотя бы Макконнела для понимания того, чем является оценка, объем работ и прочие базовые понятия, чтобы в дальнейшем избегать грубейших ошибок вроде таких:
>Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы.
>Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%.
У вас на руках очень интересные данные, но если вы кинете их в блендер, то они слабо помогут вам в оценке проекта, состоящего более чем из одной унифицированной задачи. Будет хорошо, если вы не дадите им пропасть.
Обычно на каком материале вы намеряли, на таком ваши модели и обладают предсказательной способностью.
Вы достаточно странно трактуете PERT. Это средство планирования, а не оценки. Оценки же являются основной для подобного планирования. Также, это средство для управления ходом проекта на основе плана, построенного на оценках, но никоим образом из этой методики не вытекает оценка проекта в целом.
За рамками этой методики кроме прочего находится такой фактор как преумножение рисков. Задачи на разных этапах и разного характера оказывают влияние на выполнение всех последующих. Как следствие этого и других моментов наиболее важный в оценке эффект, а именно расширение неопределенности оценки относительно текущего состояния проекта отражено плохо.
То, что вы воюеете за 10% точность замечательно, но в свете изложенного вы пытаетесь воевать на всех фронтах, на большинстве из которых подобная точность невозможна.
Я бы посоветовал задуматься, почему сейчас в оценке как правило используются регрессионные модели на основе показателей проектов в целом, ну, и заодно почитать хотя бы Макконнела для понимания того, чем является оценка, объем работ и прочие базовые понятия, чтобы в дальнейшем избегать грубейших ошибок вроде таких:
>Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы.
>Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%.
У вас на руках очень интересные данные, но если вы кинете их в блендер, то они слабо помогут вам в оценке проекта, состоящего более чем из одной унифицированной задачи. Будет хорошо, если вы не дадите им пропасть.
Долго созревал, чтобы ответить на этот коментарий. Попробую разобрать вопросы по пунктам:
1. «Я не совсем понял, а что подразумевалось под начальными заявками?»
В моём случае бралась выборка по запросам надоработку систем и запросам к разработчикам на формирование разовых выборок из системы. Все задачи взаимно независимые поэтому статистика в этом смысле получилась чище, чем в большом проекте с многочисленными взаимосвязями. Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.
2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
3. Перемножение рисков я действительно не обсчитывал — это вообще не самая страшная на мой взгляд проблема, т.к. в проектах разработки отдельные задачи являются практически независимыми событиями. Страшнее ситуация когда паралельно выполняется две задачи — одна с малой неопределенностью, и относительно большими сроками и вторая с вдвое меньшим сроком, но значительно большей неопределенностью. Поскольку общий срок в этом случае определяется максимумом из двух сроков, суммарное распределение получит распределение, не описываемое аналитически. Как, какими приближениями оценивать такие случаи — для меня пока что загадка.
4. Согласен, что стремиться даже к точности в 10% в ИТ проектах смысла нет. Мой ориентир 15-20%.
5. Про грубейшие ошибки не понял — о чем тут речь?
1. «Я не совсем понял, а что подразумевалось под начальными заявками?»
В моём случае бралась выборка по запросам надоработку систем и запросам к разработчикам на формирование разовых выборок из системы. Все задачи взаимно независимые поэтому статистика в этом смысле получилась чище, чем в большом проекте с многочисленными взаимосвязями. Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.
2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
3. Перемножение рисков я действительно не обсчитывал — это вообще не самая страшная на мой взгляд проблема, т.к. в проектах разработки отдельные задачи являются практически независимыми событиями. Страшнее ситуация когда паралельно выполняется две задачи — одна с малой неопределенностью, и относительно большими сроками и вторая с вдвое меньшим сроком, но значительно большей неопределенностью. Поскольку общий срок в этом случае определяется максимумом из двух сроков, суммарное распределение получит распределение, не описываемое аналитически. Как, какими приближениями оценивать такие случаи — для меня пока что загадка.
4. Согласен, что стремиться даже к точности в 10% в ИТ проектах смысла нет. Мой ориентир 15-20%.
5. Про грубейшие ошибки не понял — о чем тут речь?
> Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.
Подмена оценок целями, в данном случае политического характера. Если есть желание срубить денежек на переоцененном проекте все равно нужна внутренняя оценка сколько фактически он займет и уже после этого раскидывать в ценнике свою наценку по разным работам. Атсрономическая эта наценка или нет не очень виляет на необходимость проверки все ли в порядке с бюджетом на фактически работы.
>2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
PERT практически не содержит в себе методик оценки, например что будет с одним звеном, если вылетит в трубу другое и т.д. оценки на определенные этапы задаются привносятся извне.
4. 20% это тоже оптимистично :) мало того, странно давать точность без вероятности с какой вероятностью рамки оценки окажутся корректными.
>5. Про грубейшие ошибки не понял — о чем тут речь?
>Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%.
В принципе некорректно рассматривать проект как совокупность его задач. Если мы говорим о системе массового обслуживания, то да, обслуживание 10 заявок при определенных условиях могут обладать свойствами 100 заявок, что дает возможность экстраполировать.
Но, если мы говорим о последовательности некоторых этапов работ, то мы не можем в начале однозначно определить объем этих работ и количество подзадач.
Даже если требования приколочены и мы детально все разбили в начале проект на 1000 задач с предсказуемым сроком выполнения, то выполнив 100 из них (например проектирование и выбор платформы) мы можем обнаружить, что осталось 1500, выполнив 500 из них (например, прототипирование) мы можем обнаружить, что осталось всего 500. Течет не обхем работы по отдельной задаче, а их количество и структура, чем удаленнее от нас этап по времени, тем больше возможный разброс в объеме работ. Таким образом знание объема работ по конкретной задаче на удаленных этапах практически бесполезно, так как невозможно оценить само количество задач.
Это касается проектов практически любого размера.
По этой причине в оценке именно проектов используются статистически-регрессионные модели, которые для набора общих исходных данных проекта (пример: высоконагруженный проект, java, малая команда) и наборах функциональых пунктов (пример: около 50 точек i/o, около 120 таблиц в базе, около 250 основных классов) и т.д. делают прогнозы как оно пойдет, не вдаваясь в детали этапов и отдельных задач. Пока ничего надежнее не придумали. Если они основаны на внутренних данных организации — отлично, если на внешних данных — хуже. Если оценка ближайших этапов работ сильно отличаются от подобных общих оценок, это тревожный сигнал.
>Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы.
Мне показалось, что имеет место подмена оценки целями проекта, но сейчас, перечитав, не уверен что полностью понял написаное.
Еще одна упущенная проблема заключается в том, что при работе с маленькими атомарными подзадачами (ими занимается один человек) объем работ по ним фактически эквивалентен времени выполнения. Это делает их удобными для оценки. Но их оценки недостатчно, если, конечно, речь не идет о системе массового обслуживания.
Но по мере укрупнения задачи все меняется и корректнее говорить об объеме работ, в англ литературе его разделяют более детально как effort и volume, effort удобно выражать в человекочасах, volume в единицах производимого продукта (фичах, строках кода и т.д.). При разных целях (завершить крупный проект за 2 месяца или за 2 года) объем работ будет совершенно разный, чем компактнее сроки и ниже компетентность команды (есть еще масса факторов), тем выше объем и, наоборот. И уже из этого можно высчитывать стоимость и бюджеты, а также принимать стратегические решения вроде стоит ли набирать 20 юниоров или охотиться за 10 сеньорами.
P.S. Я бы посоветовал пролистать хотябы эти три книжки по теме:
www.amazon.com/Software-Management-Practitioners-Donald-Reifer/dp/0471775622/ref=sr_1_1?s=books&ie=UTF8&qid=1336053291&sr=1-1
www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=sr_1_18?s=books&ie=UTF8&qid=1336053237&sr=1-18
www.amazon.com/Software-Project-Management-Readings-Cases/dp/025618545X/ref=sr_1_1?ie=UTF8&qid=1336053365&sr=8-1
Подмена оценок целями, в данном случае политического характера. Если есть желание срубить денежек на переоцененном проекте все равно нужна внутренняя оценка сколько фактически он займет и уже после этого раскидывать в ценнике свою наценку по разным работам. Атсрономическая эта наценка или нет не очень виляет на необходимость проверки все ли в порядке с бюджетом на фактически работы.
>2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.
PERT практически не содержит в себе методик оценки, например что будет с одним звеном, если вылетит в трубу другое и т.д. оценки на определенные этапы задаются привносятся извне.
4. 20% это тоже оптимистично :) мало того, странно давать точность без вероятности с какой вероятностью рамки оценки окажутся корректными.
>5. Про грубейшие ошибки не понял — о чем тут речь?
>Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%.
В принципе некорректно рассматривать проект как совокупность его задач. Если мы говорим о системе массового обслуживания, то да, обслуживание 10 заявок при определенных условиях могут обладать свойствами 100 заявок, что дает возможность экстраполировать.
Но, если мы говорим о последовательности некоторых этапов работ, то мы не можем в начале однозначно определить объем этих работ и количество подзадач.
Даже если требования приколочены и мы детально все разбили в начале проект на 1000 задач с предсказуемым сроком выполнения, то выполнив 100 из них (например проектирование и выбор платформы) мы можем обнаружить, что осталось 1500, выполнив 500 из них (например, прототипирование) мы можем обнаружить, что осталось всего 500. Течет не обхем работы по отдельной задаче, а их количество и структура, чем удаленнее от нас этап по времени, тем больше возможный разброс в объеме работ. Таким образом знание объема работ по конкретной задаче на удаленных этапах практически бесполезно, так как невозможно оценить само количество задач.
Это касается проектов практически любого размера.
По этой причине в оценке именно проектов используются статистически-регрессионные модели, которые для набора общих исходных данных проекта (пример: высоконагруженный проект, java, малая команда) и наборах функциональых пунктов (пример: около 50 точек i/o, около 120 таблиц в базе, около 250 основных классов) и т.д. делают прогнозы как оно пойдет, не вдаваясь в детали этапов и отдельных задач. Пока ничего надежнее не придумали. Если они основаны на внутренних данных организации — отлично, если на внешних данных — хуже. Если оценка ближайших этапов работ сильно отличаются от подобных общих оценок, это тревожный сигнал.
>Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы.
Мне показалось, что имеет место подмена оценки целями проекта, но сейчас, перечитав, не уверен что полностью понял написаное.
Еще одна упущенная проблема заключается в том, что при работе с маленькими атомарными подзадачами (ими занимается один человек) объем работ по ним фактически эквивалентен времени выполнения. Это делает их удобными для оценки. Но их оценки недостатчно, если, конечно, речь не идет о системе массового обслуживания.
Но по мере укрупнения задачи все меняется и корректнее говорить об объеме работ, в англ литературе его разделяют более детально как effort и volume, effort удобно выражать в человекочасах, volume в единицах производимого продукта (фичах, строках кода и т.д.). При разных целях (завершить крупный проект за 2 месяца или за 2 года) объем работ будет совершенно разный, чем компактнее сроки и ниже компетентность команды (есть еще масса факторов), тем выше объем и, наоборот. И уже из этого можно высчитывать стоимость и бюджеты, а также принимать стратегические решения вроде стоит ли набирать 20 юниоров или охотиться за 10 сеньорами.
P.S. Я бы посоветовал пролистать хотябы эти три книжки по теме:
www.amazon.com/Software-Management-Practitioners-Donald-Reifer/dp/0471775622/ref=sr_1_1?s=books&ie=UTF8&qid=1336053291&sr=1-1
www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=sr_1_18?s=books&ie=UTF8&qid=1336053237&sr=1-18
www.amazon.com/Software-Project-Management-Readings-Cases/dp/025618545X/ref=sr_1_1?ie=UTF8&qid=1336053365&sr=8-1
Спасибо!
У меня данные из системы массового обслуживания как раз. Поэтому метод Top-Down — от общего к частному — там не работает. Более того, общая тенденция сейчас — это сокращение числа больших проектов, переход на частые итерации, что сводит задачу к тому же массовому обслуживанию. SaaS это уже не только маркетинговый слоган, а то самое массовое обслуживание.
Что касается больших проектов, то этот подход отлично работает для предварительной оценки всего проекта в целом, когда же доходит дело до детального планирования с учетом специфики каждой конкретной задачи, то от проектного плана никуда не избавиться. И там как раз работает математика, о которой я писал. А относительно ползущего состава работ я и сам написал параграфом ниже.
Главное что я хотел сказать статьей — что одного итогового числа, оценки по проекту, недостаточно. Необходим диапазон значений. Как считать этот диапазон готов обсудить — это как раз самое сложное и интересное.
У меня данные из системы массового обслуживания как раз. Поэтому метод Top-Down — от общего к частному — там не работает. Более того, общая тенденция сейчас — это сокращение числа больших проектов, переход на частые итерации, что сводит задачу к тому же массовому обслуживанию. SaaS это уже не только маркетинговый слоган, а то самое массовое обслуживание.
Что касается больших проектов, то этот подход отлично работает для предварительной оценки всего проекта в целом, когда же доходит дело до детального планирования с учетом специфики каждой конкретной задачи, то от проектного плана никуда не избавиться. И там как раз работает математика, о которой я писал. А относительно ползущего состава работ я и сам написал параграфом ниже.
Главное что я хотел сказать статьей — что одного итогового числа, оценки по проекту, недостаточно. Необходим диапазон значений. Как считать этот диапазон готов обсудить — это как раз самое сложное и интересное.
Зачем помещать теплое и мягкое в одну корзину, причем тут SaaS?! Есть разные типы проектов, с компактным циклом или длинными циклами. Прикол компактного цикла в частых релизах и частом переопределении требований. Объем задач никоим образом не следует из предыдущего этапа, но есть цель сделать его меньше.
Даже сбор требований — это уже этап проекта, так что детальное планирование в момент принятия решение о начале проекта невозможно.
Оценщики всегда представляют свои результаты как диапозон, так как точечная оценка это ни о чем, как и любая средняя температура по больнице, важной частью является и вероятность попадания результата в диапазон. Всегда есть микроскопическая вероятность, что проект займет 1000 лет или один день, чем ближе к диапазону, тем менее эта вероятность микроскопическая.
А есть возможность разбить существующие данные по типам задач, а также отследить в статистике цепочки или ряд задач по поддержке/развитию одного проекта?
Даже сбор требований — это уже этап проекта, так что детальное планирование в момент принятия решение о начале проекта невозможно.
Оценщики всегда представляют свои результаты как диапозон, так как точечная оценка это ни о чем, как и любая средняя температура по больнице, важной частью является и вероятность попадания результата в диапазон. Всегда есть микроскопическая вероятность, что проект займет 1000 лет или один день, чем ближе к диапазону, тем менее эта вероятность микроскопическая.
А есть возможность разбить существующие данные по типам задач, а также отследить в статистике цепочки или ряд задач по поддержке/развитию одного проекта?
Несколько смущает отсутствие критериев предполагаемой долговременности исполнения задачи. Напр. задача выполняемая за 1-3 часа имеет абсолютно отличную погрешность от задачи выполняемой 1-2 месяца. Можно сократить погрешность разбивая на более мелкие задачи, но по временным затратам такое разбиение и анализ может сильно растянуться подчас пиблизившись ко времени выполнения самой задачи. На больших временных интервалах точность полученных результатов оценки обратно пропорциональна времени анализа. Причём, вероятна даже их сходимость. Давно пришел к выводу что сначала надо предложить заказчику сделать полный анализ поставленной задачи и наиболее точно получить сроки её выполнения (одновремменно, частично, совместив анализ и планирование нового продукта) или, в случае нежелания тратиться на анализ сделать более размытые мременные границы проекта. В идиале конечно просто почасовая оплата пока не готово но это редкий случай на который надеяться не приходится. По любому, заказчику надо давать понять, что точность сроков это величина пропорциональная затратам на анализ и планирование.
Лучше бы учились работать, а не оценивать и считать статистику по оценкам
Вот одно интересно — как это у вас такие большие столбики около нуля? Ведь для 99% задач есть некое минимальное время, меньше которого ее технически выполнить невозможно.
Простой пример — дорога от дома до работы может в среднем занимать 40 минут. Естественно, она может занять и 2 дня (зашел в бар и загулял), однако ни при каких обстоятельствах она не может быть менее 10 минут, т.к. 10 минут — это то время, за которое я мог бы добраться на личном вертолете готовом к старту.
А т.к. вероятность наличия личного вертолета практически нулевая, то график должен плавно начинаться от 10 минут, а не от 0 минут, и причем в точке «10 минут» он должен быть бесконечно близок к нулю, а не прыгать вверх сразу столбиком в 20 единиц.
Простой пример — дорога от дома до работы может в среднем занимать 40 минут. Естественно, она может занять и 2 дня (зашел в бар и загулял), однако ни при каких обстоятельствах она не может быть менее 10 минут, т.к. 10 минут — это то время, за которое я мог бы добраться на личном вертолете готовом к старту.
А т.к. вероятность наличия личного вертолета практически нулевая, то график должен плавно начинаться от 10 минут, а не от 0 минут, и причем в точке «10 минут» он должен быть бесконечно близок к нулю, а не прыгать вверх сразу столбиком в 20 единиц.
Под рукой данных нет, но из того что я знаю про проект, подобное происходило, когда выяснилось что данная фича уже реализована и не требует разработки. Т.е. Время по факту тратилось только на анализ требований
А почему тогда на них такой большой прогноз времени? Или прогноз времени делался до анализа, «от балды»?
И в таком случае речь идет про какую-то узкую область, не про проекты. Т.к., согласитесь, что если приходит какой-то проект по созданию какого-то софта или сайта, аналитик и проект-менеджер его оценивают в N часов, то вероятность что он уже полностью есть готовый конечно может быть ненулевой, но вряд ли всего в 5 раз меньше чем столбик наиболее вероятного прогноза.
И в таком случае речь идет про какую-то узкую область, не про проекты. Т.к., согласитесь, что если приходит какой-то проект по созданию какого-то софта или сайта, аналитик и проект-менеджер его оценивают в N часов, то вероятность что он уже полностью есть готовый конечно может быть ненулевой, но вряд ли всего в 5 раз меньше чем столбик наиболее вероятного прогноза.
Если необходимо оценить работу программиста, когда над задачей по работали и аналитик, и проектировщик, и даже менеджер (перепроверивший со всеми спонсорами актуальность задачи), то в этом случае конечно оценка будет значительно точнее. Тут вы безусловно правы.
В реальности я почти не помню таких случаев и всегда приходится давать оценки, исходя из кучи допущений, когда детальные требования и детали реализации в системе еще совсем не ясны. В моей выборке взяты именно такие экспертные оценки
В реальности я почти не помню таких случаев и всегда приходится давать оценки, исходя из кучи допущений, когда детальные требования и детали реализации в системе еще совсем не ясны. В моей выборке взяты именно такие экспертные оценки
Да, кстати, если взять в качестве условия не функциональную постановку задачи, а бизнес-требование — как то «добраться от рабочего места до места я могу поспать» или «добраться от рабочего места до места, где меня ждет любимая жена», то время на реализацию этого требования оказаться меньше 2-х минут.
Sign up to leave a comment.
Статистический анализ проектных оценок, или почему правильные оценки всегда превышаются