в облаке
Попробовать

Насколько субъективна оценка проектов и как повысить точность оценки

24.02.2010 16:50

Mike Cohn в одной из своих презентаций, Введение в оценку и планирование Agile проектов (.pdf) приводит неожиданные результаты исследований по качеству оценки проектов.

 

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

 

Например, детали спецификации, от которых оценка явно не зависит :

  • Группе А дали на оценку спецификацию, оценка оказалась равна 20 часам
  • Группе В дали на оценку точно такую же спецификацию, но добавили в нее несколько не влияющих на оценку подробностей - оценка оказалась в 39 часов (это увеличение в два раза!).

 

Или другой эксперимент, в котором изменялся размер документа спецификаци и:

  • Группе А дали спефицикацию длиной в пару страниц - оценка составила 117 часов
  • Группе В дали спецификацию с точно таким же текстом, но отформатированную иначе: большее междстрочное расстояние, увеличенный шрифт и т.п. - итого 7 страниц. Оценка в данном случае составила уже 173 часа (!).

 

Или вот еще отличный пример с давлением ограничениями :

  • Группе А дали спецификацию на продукт, оценка составила 456 часов
  • Группе В дали точно такую же спецификацию, но сказали, что заказчик расчитывает на 500 часов - в итоге получили оценку в 555 часов
  • Группе С дали точно такую же спецификацию, но сказали, что заказчик расчитывает на 50 часов - в итоге получили оценку всего в 99 часов (!)

 

Конечно, это всего лишь результаты чьих-то экспериментов, которые в некоторых случаях можно и оспорить, но!

 

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

 

Но можно ведь как-то повысить точность оценки, не прибегая к формальным методикам?

 

Конечно можно, вот лишь пара хороших практик:

  • Проводить оценку группой людей, например, используя planning poker - это позволит учесть большее количество влияющих на оценку факторов, при этом мнение ни одного из членов команды не будет доминирующим
  • Давать на выходе вместо одной сразу три оценки: минимальная продолжительность, максимальная и наиболее вероятная (не средняя!) - например для того, чтобы сейлы или руководство брали на себя отвественность, продавая проект заказчику по той или иной из представленных оценок
  • Делать оценки двумя группами, чтобы на выходе можно было получить наиболее вероятную оценку из двух представленных - что так же способно повысить точность оценки (см приведенные выше результаты экспериментов)

Еще интересные статьи на эту тему: