Статистический анализ проектных оценок, или почему правильные оценки всегда превышаются

В своей работе мне постоянно приходится делать оценки для проектов, задач и работ, которые еще только предстоит выполнить, и поэтому точно измерить их невозможно. Недавно один из крупных клиентов Аксенчер, обратился в нашу компанию с просьбой помочь в разработке более систематизированной методики подготовки таких оценок. Проект так и не случился, но материалы, которые я собрал, оказались чрезвычайно полезными для меня самого. Я смог понять, почему, несмотря на планирование проектов по аккуратно выверенным оценкам, люди почти всегда превышают бюджет. Понял, что, гарантируя вписаться в бюджет с вероятностью в 95%, подрядчики гарантируют, что с вероятностью 95% им столько времени и денег не нужно. Ниже я описал свои выкладки, которые, возможно, вас тоже заинтересуют.

Первое, что я сделал, когда подключился к этому проекту, – я постараться сформулировать суть проблемы, то есть задачу, которую я хочу решить. Почти во всех проектах, в которые я был вовлечен, план строился на точных оценках отдельных задач, на конкретных числах указанных в качестве продолжительности, трудоемкости или стоимости задачи. Лишь некоторые проекты использовали методику PERT, определяя кроме наиболее ожидаемых затрат также оптимистичные и пессимистичные оценки, но даже в этом случае общая оценка проекта представляла собой одно конкретное число. Я же понимал, что в реальности фактические затраты всегда будут больше или меньше первоначальной оценки, а вероятность точного совпадения стремится к нулю. Я был уверен, что любой выделенный бюджет будет или перерасходован, или недотрачен. Нашему потенциальному клиенту и мне лично хотелось получить возможность определять вероятность вписаться в тот или иной бюджет, т.е. с одной стороны избежать ситуации, когда деньги кончаются посреди проекта, а с другой стороны избежать ситуации, когда остаются лишние деньги, которые просто «осваиваются», не принося уже дополнительных прибылей бизнесу.

И тут мне повезло: наша компания, являясь одним из крупнейших в мире поставщиков услуг в области аутсорсинга, обладает огромными массивами данных по выполненным проектам, и я смог довольно быстро получить большую выборку данных от одного из Российских проектов. Я получил значения оценок и фактических затрат по нескольким тысяч заявок с типичными трудозатратами от 1 до 50 ч-часов. После несложных манипуляций в Excel я получил искомое распределение (рис. 1). На гистограмме по вертикали отложено число заявок, а по горизонтали – размер фактических затрат относительно прогнозируемых. Например, если фактические затраты совпадают с оценкой, то на гистограмме такая заявка увеличит на единицу столбик в точке 1. Если фактические затраты составили полдня при оценке в два дня, то заявка попадет в точку 0,25.

Рис.1. Распределение фактических затрат в одном проекте
image

Вот что я увидел, анализируя получившийся график:

Во-первых, оказалось что наши сотрудники делают очень правдоподобные оценки, т.е. указывают те затраты, вероятность которых максимальна (на графике эта точка отмечена зеленым цветом). Если наш специалист говорит, что какая то задача займет 12 часов, то вероятность того, что задача займет именно 12 часов немного выше вероятности того, что реальные затраты составят 11 или 13 часов, и намного выше того, что затраты будут равны 6 или 24 часам.

Во-вторых, когда я подсчитал средние затраты по всем заявкам, то обнаружил, что среднее арифметическое оказались заметно больше, чем первоначальные оценки. В первый год работы проекта средние затраты превышали исходную оценку на 50%, потом разница сократилась до 30%, но никуда не исчезла. Этому странному на первый взгляд факту нашлось простое объяснение. Ошибиться в сторону уменьшения затрат мы можем не больше, чем на первоначальную оценку (размер затрат ведь не может быть отрицательным), а в сторону превышения оценки у нас нет почти никаких ограничений, и фактические затраты могут превысить оценку в два, в три, в четыре или даже в десять раз. Примеры, к сожалению, имеются. В результате ошибки в сторону увеличения затрат перевешивают ошибки в сторону уменьшения, и в среднем реальные затраты оказываются больше самых правдоподобных и вероятных оценок. Говоря языком статистики, получается, что распределение фактических затрат несимметрично, а математическое ожидание больше моды распределения.

Следующим важным наблюдением является поведение людей, которые гарантируют, что они впишутся в обещанные затраты. Для того чтобы быть уверенными в этом они подписываются под той оценкой затрат, риск превысить которую не больше 5-10%. А это означает, что вероятность того, что реальные затраты составят меньше обещанного – 90-95%, причем судя по полученному распределению – превысят раза в 2-3. Получается, что гарантированное соблюдение бюджета и сроков выливается в 2-3 кратное увеличение бюджета и сроков, т.е. строгий контроль сроков и бюджетов без оглядки на их адекватность и реалистичность гарантирует падение общей эффективности.

Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы. К сожалению, размер таких резервов редко когда превышает 20%, а как я написал выше, затраты по отдельным задачам в среднем превышают правдоподобные оценки на 30-50%. В рамках большого проекта ошибки по отдельным задачам могут компенсировать друг друга, но, тем не менее, со временем ошибки накапливаются и приводят к гарантированному превышению целевого бюджета.

Чтобы побороть этот пагубный эффект можно воспользоваться одним из двух методов: можно попытаться рассчитать поправочный коэффициент к сумме правдоподобных оценок, или воспользоваться методикой PERT, разработанной еще в 50-е годы прошлого века на основе идей Генри Форда и Фредерика Тейлора. Первый способ — проще, однако второй позволяет не только получить реалистичную оценку, но и понять каково распределение возможных значений фактических затрат.

***

Для того чтобы рассчитать реалистичную оценку на базе наиболее правдоподобной, используя поправочный коэффициент, этот коэффициент для начала нужно рассчитать. Для этого нужно взять не менее 20-40 выполненных задач и рассчитать среднее отношение фактических затрат к исходной оценке. Если размеры оценок различаются более чем в два-три раза, то имеет смысл определить два, три или даже больше коэффициентов для задач разных размеров. В использованных мной данных, поправочный коэффициент для задач с оценкой менее 2 ч-часов оказался в три раза больше коэффициента для задач с оценкой от 12 до 24 ч-часов.

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

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

***

Методика PERT в отличие от предыдущего метода не использует никаких предопределенных коэффициентов и использует несколько оценок по каждой задаче для расчета реалистичной оценки всего проекта.

Для того, чтобы рассчитать реалистичную оценку проекта по методике PERT необходимо указать для каждой задачи три оценки: полученную обычным способом наиболее правдоподобную оценку, оптимистичную – оценив минимальные затраты в случае, если мы переоцениваем сложность задачи, и пессимистичную – оценив максимальные затраты, которые могут потребоваться для завершения задачи. После чего реалистичная оценка по отдельной задаче определяется по представленной ниже формуле. Затраты по всему проекту в целом оцениваются простым суммированием реалистичных оценок по каждой задаче.

μi=(Oi+4*Ei+Pi)/6
μ=Σμi

где

μ – реалистичная оценка затрат по проекту или релизу в целом,
n – число задач в проекте или релизе,
μi – реалистичная оценка затрат по задаче i,
Oi – оптимистичная оценка затрат по задаче i,
Ei – наиболее правдоподобная оценка затрат по задаче i,
Pi – пессимистичная оценка затрат по задаче i

Тут важно обратить внимание на ещё одну особенность полученных данных — вероятность ошибиться в два раза в сторону уменьшения оказалось равной вероятности ошибиться в два раза в сторону увеличения. Т.е. распределение относительной ошибки (в отличие от абсолютной ошибки) оказалось симметричным. Соответственно соотношение реалистичной оценки к оптимистичной должно быть минимально отличаться или равно отношению пессимистичной оценки затрат к реалистичной оценке.

Oi/μi=μi/Pi

Если это не так, то имеет смысл проверить правильность оптимистичной и пессимистичной оценок.

***

Для определения необходимых резервов на непредвиденные нужды требуется рассчитать интервал возможных затрат при заданной оценке (см. рис.2). Если первоначальная оценка по задаче составила 16 ч-часов, то с 50% вероятностью можно говорить о том, что фактические затраты будут находиться в диапазоне от 15 до 24 ч-часов, а с вероятностью 95% можно было утверждать лишь то, что затраты будут в диапазоне от 3 до 56 ч-часов.

Рис 2. Доверительный интервал
image

Наиболее типичным является использование диапазона с вероятностью 90%. В этом случае предполагается вероятности того, что значение затрат превысит пессимистичную оценку, и того, что затраты окажутся меньше оптимистичной оценки, равны по 5%. Вероятность того, что фактические затраты попадут в диапазон между оптимистичной и пессимистичной оценкой равна 90%.

Получение распределения вероятностей фактических затрат по релизу и проекту возможно используя оптимистичные и пессимистичные оценки полученные в методике PERT. Сама методика для получения диапазона возможных значений предлагает просто сложить оптимистичные и пессимистичные оценки, однако простейшее моделирование показывает, что это некорректно. Пессимистичная оценка проекта оказывается меньше суммы оценок, а оптимистичная – больше. Диапазон с вероятностью 90% оказывается меньше простой суммы диапазонов для отдельных задач.

Точной формулы для вычисления нужного нам диапазона случайно распределенных величин не существует, однако хорошее приближение дает следующая формула, говорящая о том, что разброс возможных значений затрат растет пропорционально квадратному корню от числа задач в проекте или релизе:

O=μ-SQRT(Σ(Ei-Oi)²)
P=μ-SQRT(Σ(Pi-Ei)²)

Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мы теоретически можем получить погрешность менее 800 ч-дней или менее 2%. График теоретической зависимости разброса затрат в зависимости от детальности плана представлен на рис.3.

Рис.3. Теоретическая зависимость точности оценки затрат в зависимости от количества подзадач в плане:
image

К сожалению, в реальной жизни есть ряд ограничений не позволяющих достигнуть такой точности, и самым существенным является то, что требования и состав выполняемых задач может меняться по ходу проекта. Для большинства компаний типичным является потеря актуальности 10-30% задач, поэтому как бы мы не детализировали наш план, ошибка в первоначальных оценках всё равно неизбежна.

Суммируя полученные выводы, мне удалось понять следующее. Используя для оценки большого проекта сумму наиболее правдоподобных оценок затрат, мы гарантировано занижаем оценку, суммируя пессимистичные оценки – гарантировано её завышаем. Для того, чтобы получить реалистичную оценку необходимо использовать предварительно рассчитанный поправочный коэффициент или методику оценки PERT. Воспользовавшись оценками в методике PERT мы также можем получить диапазон затрат, про который можно говорить, что фактические затраты попадут в него с вероятностью 90% и в котором нет излишних резервов. А детализируя план проекта и аккуратно оценивая каждую задачу, можно существенно сократить этот диапазон, в итоге достигая требуемого размера резервов.
Поделиться публикацией

Комментарии 18

    +2
      0
      Статистика говорит обратное. Люди умеют оценивать. По крайней мере в этом отдельно взятом проекте. При этом, они конечно ошибаются, но ошибки имеют четкое и вполне определенное распределение. А при разбиении исходной задачи на несколько более мелких точность существенно возрастает.
        +1
        Сильно заваисит от специфики задачи. Спланировать разгрузку Камаза с кирпичами можно гораздо точнее, чем разработку нового самолёта, которая требует ещё по дороге изобрести кучу всего.
          +1
          Без ссылки на конкретные исследования, методики и условия оценивания, подобный материал недостоверен.

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

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

          У оценивания есть много ахиллесовых пят, произростающих из матстатистики, но уж точно не такого вида.
          +2
          Я не совсем понял, а что подразумевалось под начальными заявками?
          Обычно на каком материале вы намеряли, на таком ваши модели и обладают предсказательной способностью.

          Вы достаточно странно трактуете PERT. Это средство планирования, а не оценки. Оценки же являются основной для подобного планирования. Также, это средство для управления ходом проекта на основе плана, построенного на оценках, но никоим образом из этой методики не вытекает оценка проекта в целом.

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

          То, что вы воюеете за 10% точность замечательно, но в свете изложенного вы пытаетесь воевать на всех фронтах, на большинстве из которых подобная точность невозможна.

          Я бы посоветовал задуматься, почему сейчас в оценке как правило используются регрессионные модели на основе показателей проектов в целом, ну, и заодно почитать хотя бы Макконнела для понимания того, чем является оценка, объем работ и прочие базовые понятия, чтобы в дальнейшем избегать грубейших ошибок вроде таких:

          >Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные расходы.

          >Соответственно, чем детальнее мы разбиваем большой проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%.

          У вас на руках очень интересные данные, но если вы кинете их в блендер, то они слабо помогут вам в оценке проекта, состоящего более чем из одной унифицированной задачи. Будет хорошо, если вы не дадите им пропасть.
            +1
            Долго созревал, чтобы ответить на этот коментарий. Попробую разобрать вопросы по пунктам:
            1. «Я не совсем понял, а что подразумевалось под начальными заявками?»
            В моём случае бралась выборка по запросам надоработку систем и запросам к разработчикам на формирование разовых выборок из системы. Все задачи взаимно независимые поэтому статистика в этом смысле получилась чище, чем в большом проекте с многочисленными взаимосвязями. Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной ERP в госкомпании процессы оценки по задачам будут определяться не стремлением достичь максимальной точности оценки, а совсем другими мотивами.

            2. Относительно трактовки PERT. Эта методика в целом действительно известна прежде всего подходом к календарному планированию, однако методика оценки также является важной её состовляющей, которая к тому же легко может использоваться по отдельности от сетевого планирования.

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

            4. Согласен, что стремиться даже к точности в 10% в ИТ проектах смысла нет. Мой ориентир 15-20%.

            5. Про грубейшие ошибки не понял — о чем тут речь?
              0
              > Кроме того я уверен, что в каком-нибудь в проекте развертывания никому не нужной 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
                0
                Спасибо!

                У меня данные из системы массового обслуживания как раз. Поэтому метод Top-Down — от общего к частному — там не работает. Более того, общая тенденция сейчас — это сокращение числа больших проектов, переход на частые итерации, что сводит задачу к тому же массовому обслуживанию. SaaS это уже не только маркетинговый слоган, а то самое массовое обслуживание.

                Что касается больших проектов, то этот подход отлично работает для предварительной оценки всего проекта в целом, когда же доходит дело до детального планирования с учетом специфики каждой конкретной задачи, то от проектного плана никуда не избавиться. И там как раз работает математика, о которой я писал. А относительно ползущего состава работ я и сам написал параграфом ниже.

                Главное что я хотел сказать статьей — что одного итогового числа, оценки по проекту, недостаточно. Необходим диапазон значений. Как считать этот диапазон готов обсудить — это как раз самое сложное и интересное.
                  0
                  Зачем помещать теплое и мягкое в одну корзину, причем тут SaaS?! Есть разные типы проектов, с компактным циклом или длинными циклами. Прикол компактного цикла в частых релизах и частом переопределении требований. Объем задач никоим образом не следует из предыдущего этапа, но есть цель сделать его меньше.

                  Даже сбор требований — это уже этап проекта, так что детальное планирование в момент принятия решение о начале проекта невозможно.

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

                  А есть возможность разбить существующие данные по типам задач, а также отследить в статистике цепочки или ряд задач по поддержке/развитию одного проекта?
            0
            Несколько смущает отсутствие критериев предполагаемой долговременности исполнения задачи. Напр. задача выполняемая за 1-3 часа имеет абсолютно отличную погрешность от задачи выполняемой 1-2 месяца. Можно сократить погрешность разбивая на более мелкие задачи, но по временным затратам такое разбиение и анализ может сильно растянуться подчас пиблизившись ко времени выполнения самой задачи. На больших временных интервалах точность полученных результатов оценки обратно пропорциональна времени анализа. Причём, вероятна даже их сходимость. Давно пришел к выводу что сначала надо предложить заказчику сделать полный анализ поставленной задачи и наиболее точно получить сроки её выполнения (одновремменно, частично, совместив анализ и планирование нового продукта) или, в случае нежелания тратиться на анализ сделать более размытые мременные границы проекта. В идиале конечно просто почасовая оплата пока не готово но это редкий случай на который надеяться не приходится. По любому, заказчику надо давать понять, что точность сроков это величина пропорциональная затратам на анализ и планирование.
              0
              Точность оценки сроков пропорциональна корню от числа задач на критическом пути, а затраты на оценку этих задач и на само разбиение пропорциональны этому числу, так что в принципе можно даже подсчитать оптимальный уровень детализации плана.
              –4
              Лучше бы учились работать, а не оценивать и считать статистику по оценкам
                +3
                Если бы люди не оценивали проекты, не вели тяжёлые бои на pre-sale, не планировали бюджет и не перепланировали планы после каждой итерации, вы бы не смогли спокойно кодить, что вы без сомнения очень любите и цените.
                0
                Вот одно интересно — как это у вас такие большие столбики около нуля? Ведь для 99% задач есть некое минимальное время, меньше которого ее технически выполнить невозможно.

                Простой пример — дорога от дома до работы может в среднем занимать 40 минут. Естественно, она может занять и 2 дня (зашел в бар и загулял), однако ни при каких обстоятельствах она не может быть менее 10 минут, т.к. 10 минут — это то время, за которое я мог бы добраться на личном вертолете готовом к старту.

                А т.к. вероятность наличия личного вертолета практически нулевая, то график должен плавно начинаться от 10 минут, а не от 0 минут, и причем в точке «10 минут» он должен быть бесконечно близок к нулю, а не прыгать вверх сразу столбиком в 20 единиц.
                  0
                  Под рукой данных нет, но из того что я знаю про проект, подобное происходило, когда выяснилось что данная фича уже реализована и не требует разработки. Т.е. Время по факту тратилось только на анализ требований
                    0
                    А почему тогда на них такой большой прогноз времени? Или прогноз времени делался до анализа, «от балды»?

                    И в таком случае речь идет про какую-то узкую область, не про проекты. Т.к., согласитесь, что если приходит какой-то проект по созданию какого-то софта или сайта, аналитик и проект-менеджер его оценивают в N часов, то вероятность что он уже полностью есть готовый конечно может быть ненулевой, но вряд ли всего в 5 раз меньше чем столбик наиболее вероятного прогноза.
                      0
                      Если необходимо оценить работу программиста, когда над задачей по работали и аналитик, и проектировщик, и даже менеджер (перепроверивший со всеми спонсорами актуальность задачи), то в этом случае конечно оценка будет значительно точнее. Тут вы безусловно правы.

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое