Улучшение точности и другие преимущества исторических данных

Основная причина для использования исторических данных вашей организации заключается в том, что они заметно повышают точность оценки. Использование исторических данных, или «документированных фактов», отрицательно корре- лируется с превышением сроков и затрат — иначе говоря, для проектов, оцениваемых на основе исторических данных, превышения не характерны (Lederer and Prasad 1992).

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

Учет организационных факторов

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

Далее перечислены некоторые организационные факторы, влияющие на результат проекта. Насколько сложна программа, какие ограничения накладываются на ее быстродействие, какую надежность необходимо обеспечить, сколько документации требуется, существуют ли предыдущие аналоги — другими словами, какое место занимает проект в системе факторов Cocomo И, относящихся к типу разрабатываемого проекта (см. главу 5)? Может ли организация определиться с устойчивыми требованиями, или рабочая группа должна учитывать возможные изменения на протяжении всего проекта? Может ли руководитель проекта избавиться от проблемного участника, или же кадровая политика организации затрудняет (или делает невозможной) его увольнение? Может ли группа полностью сосредоточиться на текущем проекте, или ее участникам приходится часто отвлекаться на запросы, связанные с поддержкой предыдущих проектов? Может ли организация включать новых участников в проект, как было запланировано, или она откажется «выдергивать» работников из других проектов вплоть до их завершения? Поддерживает ли организация использование эффективных методов проектирования, конструирования, контроля качества и тестирования? Работает ли организация в регламентированной среде (например, под действием нормативных актов FAA или FDA), предписывающей обязательное следование некоторым правилам? Может ли руководитель проекта рассчитывать на то, что участники группы останутся на работе вплоть до завершения проекта, или для организации характерна высокая текучесть кадров?

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

Предотвращение субъективизма и необоснованного оптимизма

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

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

При наличии исторических данных используется упрощенное предположение

о              том, что следующий проект пойдет примерно так же, как прошлый проект. Вполне разумное предположение. По словам гуру в области оценки Лоренса Путнэма, производительность является атрибутом организации и не может легко изменяться между проектами (Putnam and Myers 1992, Putnam and Myers 2003). Аналогичная концепция представлена в экстремальном программировании в виде «принципа вчерашней погоды»: сегодняшняя погода не всегда будет такой же, как вчера, но она будет похожа на вчерашнюю погоду с большей вероятностью, чем на что-либо другое (Beck and Fowler 2001).

Стройте свои оценки производительности на исторических данных.

Снижение влияния политических факторов при оценке

Одна из потенциальных проблем моделей оценки с большим количеством регулируемых факторов заключается в том, что многие регуляторы верхнего уровня относятся к персоналу. Например, модель Cocomo II требует оценки навыков аналитиков и программистов наряду с несколькими менее субъективными факторами, относящимися к опыту. Оценщик должен дать оценку программистов, выбирая между 90-й, 75-й, 55-й, 35-й и 15-й процентилью (эти значения процен- тилей являются общеотраслевыми).

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

Руководитель: Я знаю, что мы должны выпустить продукт за 12 педель, но мои оценки показывают, что работа займет 16 недель. Давайте проанализируем оценку при помощи этой программы. Вот несколько предположений, которые я сделал. Сначала нужно откалибровать модель оценки. Для фактора «квалификация программистов» я указал, что наши программисты относятся к 35-й процентили...

Начальство: Что?! В нашем штате нет ни одного человека ниже среднего уровня! Нужно быть более уверенным в своих оценках! Что же вы за руководитель? Возможно, у пас есть несколько человек, которые чуть отстают от остальных, но в целом группа не может быть настолько плохой. Давайте предположим, что они по крайней мере на среднем уровне, хорошо? Это можно ввести в программу?

Руководитель: Ладно. Следующий фактор — квалификация разработчиков требований. Мы никогда не ставили себе задачу набрать хороших аналитиков или развить эти навыки в своих работниках, поэтому я использовал 15-ю про- центиль...

Начальство: Постойте! 15-я процентиль? Наши люди очень талантливы, хотя они и не прошли формального обучения в разработке требований.

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

Начальство: Хорошо. Предлагаю компромисс: сойдемся на 35-й процентили.

Руководитель: Ладно (вздыхает).

В результате разговора оценка объема работы, полученная руководителем с использованием регулирующих факторов Cocomo II, сократилась на 23 %. А если бы начальству удалось уговорить руководителя на среднюю оценку специалистов по требованиям вместо 35-й процентили, то оценка бы сократилась на 39 %. Так или иначе, один разговор приводит к весьма существенным различиям.

Руководитель, калибрующий оценку историческими данными, обходит все рассуждения о том, как работают программисты — лучше или хуже среднего. Производительность непосредственно следует из данных. Человеку, ответственному за принятие решений, но не имеющему технического образования, трудно спорить с простыми выкладками типа: «По статистике один человек за месяц у нас выдает от 300 до 450 строк кода; мы откалибровали модель с предположением 400 строк за человеко-месяц. Возможно, это немного оптимистично, но в пределах разумного».

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

СОВЕТ № 36

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