Методика оценки трудозатрат или научно-обоснованный подход "попасть пальцем в небо"

Пальцем в небо

Вместо эпиграфа

Тема оценки трудозатрат по задаче/проекту не нова.
И много копий сломано на этом поле брани.
Попробую и я...

Дополнение от 2019-06-23

Внес изменение в раздел Двух-точечная оценка проекта.


Содержание

Условности

Вначале, хотелось бы обратить внимание читателя на то, что, с точки зрения оценки трудозатрат, Проект от Задачи отличается только масштабом. Можно сказать, что Проект - это огромная Задача.
Так вот, для того чтобы дальше по тексту не писать везде "задача\проект", я буду писать "проект", а Вы, уважаемые читатели, будете понимать, что все сказанное можно применять как к проектам, так и к задачам.

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

Предпосылки

Оказывая услуги, особенно по разработке программного обеспечения, постоянно приходится сталкиваться с тем, что заказчика интересует (и это естественно) ответ на вопрос "Сколько это будет стоить?". Причем интересует его это до начала работ (что тоже естественно). И причем он хочет услышать какое-то одно число - фиксированную сумму, на которую он либо готов согласиться, либо нет.

С другой стороны, так же естественно, что опытный исполнитель понимает, что во время выполнения работ, даже если имеется подробнейший план их выполнения, может возникнуть множество рисков, учет которых "размывает" оценку, приводя ее к диапазону (в народе называемому "вилкой"). И таким образом, выдать какое-то одно число становится затруднительно.

Возникает конфликт, который можно привести к чисто ТРИЗ-овской формулировке задачи:

Оценка должна быть одновременно и размытой (диапазон) и точечной (одно число).

О том, как я для себя решил этот "конфликт", и пойдет дальше речь.

Стратегия

Стратегия решения данного конфликта - очевидна.
Нужно взять какую-нибудь одну точку из имеющегося диапазона.

И тут же вспоминается известный менеджерский анекдот о мышах и филине.
А вместе с ним возникает и вопрос: "Какую точку брать?".

Вот в поиске ответа на этот вопрос и заключается методика оценки.

Эволюция методики

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

Излишний оптимизм (желтая шляпа и розовые очки)

Желтая шляпа и розовые очки

Этап, когда исполнитель, в силу недостатка опыта, слишком оптимистично оценивает проект - мы пропустим, т.к. этот этап преодолевается только с накоплением исполнителем опыта.
И перейдем к более интересным моментам чрезмерного оптимизма во время оценки.

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

Если Вы никогда в этом не участвовали, то Вы себе даже представить не можете, к каким фееричным провалам проектов приводит такая стратегия!

А причина этих провалов так же проста, как и выбранная стратегия. Все дело в том, что нижняя граница диапазона - это оптимистичная оценка. Т.е. это оценка трудозатрат по проекту для случая, когда мы учли все-все-все возможные риски (в том числе и риск того, что мы что-то не учли :)) и ни один из них не реализовался.
Понятное дело, что в жизни такого просто не бывает.
Том ДеМарко и Тимоти Листер в своей замечательной книге "Вальсируя с медведями" называют эту оценку нанопроцентной, и говорят о том, что вероятность того, что трудозатраты по проекту будут не более этой оценки - равна 1 нано-проценту (0,000000001%).
Собственно, тот, кто берет эту оценку за ориентир - устанавливает вероятность успеха проекта именно в это значение - 0,000000001% (1 нано-процент)! Вдохновляет! Не правда ли?

Естественно, что в итоге получается, что когда проект только-только начинает набирать обороты, внезапно начинают поджимать сроки и заканчиваться средства. Руководство лихорадочно начинает давить на разработчиков, дергать их, переключая с очень срочных и важных задач на еще более срочные и важные, нагонять на проект новых разработчиков, которые вынуждены писать код, не успев вникнуть в суть дела. В результате, ситуация становится еще хуже. И к моменту, когда сроки уже сорваны вдвое, а бюджет - втрое, проект готов только на треть.
Вот тут и наступает локальный Апокалипсис на проекте и в компании.

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

Для меня такой подход оказался неприемлемым. Что и подтолкнуло меня к поиску возможностей более качественно делать оценку проектов.

Параноидальный пессимизм (глухая оборона)

Джедай с щитом и мечем
Джедай-рыцарь
образца 2005 года

Другая крайность - это уход в глухую оборону.
Как правило, она обусловлена неумением управлять рисками, и вытекающим из этого элементарным страхом потерь.

Данная стратегия заключается в том, чтобы в качестве оценки проекта брать верхнюю границу диапазона.
Т.е. исходить из того, что дороже этой оценки проект не обойдется, и следовательно мы ничего не потеряем, а скорее всего даже выиграем (сэкономим).

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

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

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

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

"Золотая" середина (русская рулетка)

Русская рулетка

Очевидным дальнейшим развитием стратегии оценивания является выбор точки где-то внутри диапазона.
И чаще всего в качестве такой точки выбирают средину диапазона.

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

В итоге, применение такой стратегии оценки начинает напоминать игру в русскую рулетку - если повезет, то хорошо заработаем, если нет, то можно закрываться.
Как говорят в народе в таких случаях: "Пан или пропал"(С)Народ.
И так как, при получении оценки проекта, мало кто рассматривает маловероятные риски (которые ведут к варианту "пан"), а в основном, в первую очередь, учитываются сильно вероятные риски, то вариант "пропал" бывает чаще.

Управляем рисками (математическая точность)

Диаграмма риска

И вот мы уже осознали необходимость управлять рисками.
И тут же возникает вопрос: "А как это - управлять рисками? Что делать то?".

Из всех попадавшихся мне в руки книг по управлению рисками, меня больше всего впечатлила уже упоминаемая выше книга Тома ДеМарко и Тимоти Листера "Вальсируя с медведями". В ней можно найти детальное описание того, что нужно и чего не нужно делать с рисками.
Здесь же я приведу краткую выжимку моего понимания из нее, чтобы дальнейшее повествование было понятным для тех, кто этой книги не читал (хотя я настоятельно рекомендую с ней ознакомиться).

Первое, что нужно сделать с рисками - это все их записать. И каждый в отдельности обработать.

Под обработкой риска понимается:

  • Оценка вероятности его реализации.
  • Оценка влияния риска на сроки в случае его реализации.
  • Оценка влияния риска на стоимость в случае его реализации.
  • Классификация риска (решить будем ли мы предпринимать какие-либо действия для уменьшения вероятности возникновения риска или степени его влияния в случае, если риск реализуется).
  • Создание плана мер по уменьшению вероятности реализации риска.
  • Создание плана мер по уменьшению степени влияния риска в случае его реализации.

Далее создаем трехточечную оценку проекта.
Оценка проекта при условии, что ни один из рисков не реализуется, считается оптимистичной.
Оценка проекта при условии, что реализуются все риски, считается пессимистичной.
А ожидаемая оценка проекта рассчитывается как

Ожидаемая оценка = Оптимистичная оценка + Сумма учитываемых влияний всех рисков
Где
Учитываемое влияние риска = Влияние риска * Вероятность реализации риска

На первый взгляд, нужно в качестве оценки проекта брать вот эту ожидаемую оценку. Но не все так просто. Ожидаемая оценка устанавливает уровень успешности проекта в 50%. Т.е. по статистике, при таком подходе, каждый второй проект будет провальным.
Естественно, что такой "расклад" человеку разумному не подходит, поэтому реальную оценку обычно сдвигают в сторону пессимистичной оценки.

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

В теории все прекрасно, и казалось бы, вот оно!.. решение найдено!...
Но суровая действительность вносит свои коррективы.

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

Очевидно нужно искать какие-то другие - менее трудозатратные методы.

Моя "джедайская" методика (интуиция-опыт и расчет)

Джедай ковбой
Джедай-рейнджер
образца 2018 года

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

Недостатком этой методики является зависимость от опыта эксперта. Именно поэтому данная методика не очень подойдет начинающим разработчикам. Но со временем, по мере накопления опыта экспертом, она показывает все лучшие и лучшие результаты.

Рассмотрим эту методику подробнее.

Декомпозиция работ

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

Во время декомпозиции следует помнить о следующих закономерностях.

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

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

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

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

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

Оценка каждой задачи

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

О - П (Р) часов
где
  • О - Оптимистичная оценка оставшихся по задаче трудозатрат.
    Ее можно читать как "Вряд ли удастся сделать задачу быстрее чем за О часов".
    Это та самая "нанопроцентная оценка", в терминологии книги Тома ДеМарко и Тимоти Листера "Вальсируя с Медведями", которую следует трактовать как "Вероятность того, что задача будет готова через О часов равна 1 нано-проценту". Иными словами она есть, но она фактически нулевая.
  • П - Пессимистичная оценка оставшихся по задаче трудозатрат.
    Ее можно читать как "С вероятностью 95% затраты по задаче не превысят П часов".
    Или говоря простым языком "Вряд ли затраты по задаче превысят П часов".
  • Р - Реалистичная (или еще можно сказать Ожидаемая) оценка оставшихся по задаче трудозатрат.
    Ее можно читать как "Скорее всего затраты по задаче будут составлять близкое к Р количество часов".
    Или говоря научным языком "Вероятнее всего, что затраты будут составлять Р часов".

Например, запись "2 - 16 (4) часов" означает, что задача будет выполнена не менее, чем за 2 часа, и скорее всего не более, чем за 16 часов. При этом, ожидается, что скорее всего трудозатраты составят около 4 часов.

Отличие этого шага от рассмотренного в разделе Управляем рисками (математическая точность) подхода, заключается в том, что, если при управлении рисками выполняются очень трудоемкие работы по выявлению, систематизации и оценке всех связанных с задачей рисков, а оценка задачи получается в результате их математической обработки, то в рассматриваемой методике интуитивно, исходя из накопленного опыта, сразу получается экспертная оценка задачи.
Естественно, что трудозатраты на ее получение несоизмеримо меньше.

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

Учет риска "Незапланированные задачи"

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

И на этом можно было бы остановиться. Но!
Следует учесть, что при экспертной оценке задач, экспертом учтены риски, которые могут возникнуть при выполнении каждой задачи. Но им совершенно не учтены риски того, что во время декомпозиции какие-то задачи были не запланированы. Это могут быть, например, задачи, которые в начале проекта и предусмотреть было проблематично. А могут быть задачи, которые настолько очевидны, что о них обычно забывают во время составления планов (например, рабочие совещания по проекту, промежуточные демонстрации результатов заказчику и т.п.).

Для того, чтобы учесть риски появления в проекте не запланированных ранее задач, достаточно добавить в проект еще одну задачу (я ее обычно так и называю "Незапланированные задачи"), и сделать ее оценку.
Так как эта задача является чистым риском, то очевидно, что для нее значение Оптимистичной оценки должно быть равно нулю (ведь, в оптимистичном прогнозе ни один риск не реализуется, а следовательно и затрат на риски не будет).
Значения же оставшихся Пессимистичной и Ожидаемой оценок выбираются в зависимости от множества разных факторов.

Как показывает практика, даже в очень хорошо спланированных проектах, все-равно появляются незапланированные задачи (встречи, совещания, демонстрации, администрирование среды разработки и т.п.), которые при нормальных условиях занимают 5-10% от общих трудозатрат по проекту. Соответственно, для получения Пессимистичной и Ожидаемой оценок по незапланированным задачам, можно просто соответствующие оценки для проекта умножить на 5-10%.
В большинстве случаев я именно так и поступаю.

Но очень часто, особенно на больших проектах в крупных организациях, в силу того, что ответственные лица заказчика, как правило, безответственно относятся к нашему проекту (у них и своей работы хватает, а тут еще и вместе с разработчиками нужно думать о том, чего же им требуется для счастливой деятельности), либо, в силу политических причин, всячески стараются саботировать работу по проекту, трудозатраты на незапланированные работы могут составлять, в среднем до 200%, а в клинических случаях и до 1000% от общих трудозатрат по проекту.
Соответственно, если делающий оценку эксперт предполагает подобные ситуации, то имеет смысл, для получения значений Пессимистичной и Ожидаемой оценок по незапланированным задачам, соответствующие оценки для проекта умножить на 100-1000%.

Четырех-точечная оценка проекта

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

Обратите внимание на использование слова "оставшихся". Оно использовано неспроста. Дело в том, что мы оценили трудозатраты по задачам, которые мы еще не делали (мы их только что запланировали), поэтому это оставшиеся трудозатраты. Но ведь на саму декомпозицию работ и оценку мы уже затратили какие-то усилия. И эти усилия - тоже часть затрат по проекту. Их тоже хорошо бы включить в результирующую оценку.

Для того, чтобы это сделать, введем еще один параметр:

  • Ф - Уже фактически затраченные на проект ресурсы (время потраченное на исследование и оценку проекта, выяснение у заказчика деталей проекта и т.п.).
    Это уже детерминированная часть оценки - она не содержит рисков и изменяться не будет.

В результате, на выходе, мы имеем четырех-точечную оценку проекта, которую записываем в виде

Ф + [О - П (Р)] часов
где все используемые обозначения приведены выше.

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

Из нее видно какая часть проекта уже выполнена (Ф), и какое распределение рисков в оставшихся задачах.
Например, если Р тяготеет к О, это означает, что в оставшихся по проекту задачах находятся, в основном, маловероятные, но разрушительные по своим последствиям риски.
И наоборот. если Р тяготеет к П, это означает, что в оставшихся по проекту задачах находятся очень вероятные и не сильно разрушительные по своим последствиям риски.
Также ширина диапазона О - П ("вилка") показывает общую неопределенность по проекту. Если этот диапазон слишком широк, то возможно, если есть такая возможность, следует собрать дополнительную информацию и уточнить оценку проекта.

Трех-точечная оценка проекта

Для получения ответа на вопрос "Сколько всего будет стоить проект?" нам безразлично какая часть затрат по проекту уже фактически освоена, а какая еще нет. Удобнее оперировать оценкой, в которой фактические и оставшиеся затраты объединены в общие затраты.
Получить такую оценку можно путем внесения фактических затрат (Ф) внутрь квадратных скобок.
Результат такой операции можно записать в виде:

О' - П' (Р') часов
где
  • О' = О + Ф - Оптимистичная оценка трудозатрат по проекту, с учетом уже фактически понесенных затрат.
  • П' = П + Ф - Пессимистичная оценка трудозатрат по проекту, с учетом уже фактически понесенных затрат.
  • Р' = Р + Ф - Реалистичная (или еще можно сказать Ожидаемая) оценка трудозатрат по проекту, с учетом уже фактически понесенных затрат.
Таким образом мы получаем трех-точечную оценку проекта.
Ее можно показывать заказчикам, которые готовы рассматривать не только точечную оценку проекта, но и способны понять (и главное - принять) информацию о заложенных в проекте рисках.

Двух-точечная оценка проекта

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

Поэтому, на пути к одноточечной оценке мы получим еще одну, промежуточную, двух-точечную оценку (мы уже почти у цели :)).

Чтобы ее получить рассмотрим интересы сторон.

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

(О' + П') / 3
При этом она не должна быть ниже, чем Р'.

С другой стороны у нас есть заказчик.
Также очевидно, что нижней границей диапазона, в котором лежат приемлемые для заказчика оценки, является ноль (т.е. получить результат безоплатно). А в качестве верхней границы диапазона, в котором лежат приемлемые для заказчика оценки, можно взять среднее арифметическое между реалистичной и пессимистичной оценками

(Р' + П') / 2

В результате пересечения диапазонов приемлемых для заказчика и исполнителя оценок, мы получим диапазон приемлемых оценок проекта:

[НГ ; ВГ]
где
  • НГ - Нижняя граница диапазона приемлемых оценок:
    НГ = МАКС(Р', (О' + П') / 3)
  • ВГ - Верхняя граница диапазона приемлемых оценок:
    ВГ = (Р' + П') / 2
Этот диапазон находится правее Ожидаемой оценки, что делает взятую из него оценку интересной для исполнителя, т.к. устанавливает успешность проекта выше 50% (т.е. успешных проектов у исполнителя будет больше, чем провальних).
При этом, этот диапазон все-таки тяготеет ближе к значению Ожидаемой оценки, чем к значению Пессимистичной оценки, что делает взятую из него оценку приемлемой для заказчика, т.к. заказчик в этом случае оплачивает лишь небольшую долю рисков исполнителя, достаточную только для того, чтобы исполнитель не разорился в процессе своей деятельности. А оставшиеся риски исполнитель берет на себя.

Одно-точечная оценка проекта

Полученный диапазон приемлемых оценок проекта и есть та самая "вилка", в пределах которой заказчик и исполнитель, в результате торгов, выбирают "фиксированную оценку проекта".
Обозначим ее как Х.

В отличие от изначальной "вилки" [О' ; П'], рассматриваемая "вилка" [НГ ; ВГ] значительно у́же, и самое главное - она математически ограничена интересами\безопасностью сторон.

Итог

Таким образом, в итоге, мы получаем решение озвученного в разделе Предпосылки "конфликта". У нас имеются и точечная и размытая оценки одновременно. Более того, у нас оказывается аж три размытые оценки, хранящие в себе разную информацию - 4-точечная, 3-точечная и диапазон приемлемых оценок.

И все это можно записать в виде:

Оценка: Ф + [О - П (Р)] часов
План: О' - П' (Р') часов
Вилка: НГ - ВГ часов
Договорились на Х часов

Заключение

Рассмотренная в данной статье методика, на мой взгляд (на момент написания статьи), наиболее сбалансирована в соотношении точность оценки / трудозатраты на ее получение.

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

Если же описанная методика для кого-то окажется полезной - буду рад.
Пользуйтесь ею во благо.

Также буду рад отзывам и Вашим соображениям на данную тему.
Присылайте мне их на электронную почту (с темой "Методика оценки трудозатрат") или в Скайп по указанным на странице "Связь" адресам.
Те из них, которые покажутся мне интересными, опубликую на данной странице.