Основные принципы оценки

Основные принципы оценки

Глава 1. Что такое «оценка»?.
Глава 2. Какой из вас оценщик?.
Глава 3. О точности оценки.
Глава 4. Откуда берутся ошибки оценки?.
Глава 5. Факторы, влияющие на оценку.
Что такое «оценка»?.
Очень трудно составить энергичное, правдоподобное обоснование для оценки, которая не базируется на количественных методах, практически не поддерживается данными и продвигается в основном усилиями начальства.
Фред Брукс.
Вероятно, вы полагаете, что вам не нужно объяснять, что такое «оценка». К концу этой главы я постараюсь убедить вас, что смысл термина «оценка» отличается от того, что в него вкладывает большинство людей. А хорошая оценка отличается от общепринятого понимания еще сильнее.
Вот определение слова «оценка» из словаря: 1. приблизительный прогноз или вычисление. 2. предварительный расчет стоимости проекта. 3. суждение, основанное на впечатлениях; личное мнение.
Насколько это похоже на то, что вам нужно сделать при оценке программного проекта? Можно ли назвать такой результат приблизительным или предварительным — иначе говоря, предполагается ли, что вы сможете изменить свою оценку позднее?.
Вероятно, нет. Когда начальство требует у вас «оценки», оно часто подразумевает некое обязательство по соблюдению поставленной цели. Различия между оценками, целями и обязательствами чрезвычайно важны для понимания того, чем является оценка, чем она не является и как повысить качество ваших оценок.
1.1. Оценки, цели и обязательства.
Строго говоря, словарное определение термина «оценка» верно: оценкой называется прогноз относительно того, сколько времени или денег потребуется для реализации проекта. Однако в контексте программных проектов оценка увязывается с деловыми целями, обязательствами и контролем.
Целью называется формулировка деловой задачи. Примеры целей.
• Версия 2.1 должна быть готова к демонстрации на выставке в мае.
• Мы должны получить стабильную версию продукта до наступления предпраздничных продаж.
1.2. Связь между оценками и планами 23.
• Затраты на следующую версию ограничиваются двумя миллионами — это максимальный бюджет, который нам удастся получить.
У фирм имеются веские причины для постановки целей, не зависящих от оценки программных проектов. Но тот факт, что цель является желательной или даже абсолютно необходимой, еще не означает, что она достижима.
Если цель может рассматриваться как описание деловой задачи, обязательство является обещанием предоставить некоторую функциональность на согласованном уровне качества к конкретной дате. Обязательство может совпадать с оценкой, может быть более агрессивным или более консервативным. Другими словами, не ставьте знак равенства между обязательством и оценкой; это разные понятия.
СОВЕТ № 1 -.
Не путайте оценки, цели и обязательства.
1.2. Связь между оценками и планами.
Оценка и планирование — взаимосвязанные темы, но оценка не является планированием, а планирование — оценкой. Оценка должна рассматриваться как объективный, аналитический процесс; планирование должно рассматриваться как процесс изначально субъективный, целенаправленный. В контексте оценки было бы рискованно изначально рассчитывать на получение некоторого конкретного ответа. Целью является точность прогноза, а не достижение конкретного результата. С другой стороны, под целью планирования понимается конкретный результат. Мы намеренно (и целесообразно) воздействуем на свои планы для достижения желаемого исхода. Мы планируем конкретные средства, необходимые для достижения конкретной цели.
Оценки формируют основу для планов, но планы не всегда совпадают с оценками. Если оценки радикально отличаются от целей, планы проектов должны распознать этот разрыв и заложить более высокую степень риска. Если оценка близка к цели, планы также становятся менее рискованными.
И оценка, и планирование важны, но фундаментальные различия между ними означают, что попытки их объединения обычно приводят к плохим оценкам и плохим планам. Наличие сильной цели планирования может привести к тому, что цель подменит оценку, полученную аналитическим путем; участники проекта даже могут называть цель «оценкой», придавая ей ореол объективности, которого она в действительности не заслуживает.
Примеры факторов планирования, частично зависящих от точности оценки:.
• построение подробного графика;.
• идентификация критического пути проекта;.
• создание полной декомпозиции работ
;.
• выбор приоритетной функциональности для сдачи на промежуточных этапах;.
• разбиение проекта на итерации.
Точные оценки повышают качество выполнения работы по каждой из этих областей (в главе 21 приводятся более подробные сведения по всем перечисленным вопросам).
1.3. Общение по вопросам оценок, целей и обязательств.
Одним из последствий тесных, а иногда и сбивающих с толку связей между оценками и планированием являются недоразумения, возникающие при общении между критическими фигурами проекта. Пример типичного недоразумения.
Директор: Как вы думаете, сколько времени займет проект? Программа доллсна быть готова через 3 месяца, к выставке. Я не могу дать больше людей в группу, поэтому вам придется обойтись текущим персоналом. Вот список тех функций, которые нам нужны.
Руководитель проекта: Ладно, я немного посчитаю, а потом снова зайду к вам. Позднее...
Руководитель проекта: По моей оценке, проект займет 5 месяцев.
Директор: Пять месяцев?! Вы что, меня не слушаете? Я же сказал, что программа нужна нам через 3 месяца, к выставке?.
Вероятно, после этого разговора руководитель проекта будет считать директора ненормальным, потому что он требует втиснуть 5-месячный объем работы в 3 месяца. Директор же сочтет, что руководитель проекта не понимает деловых реалий и не сознает, как важно, чтобы программа была готова к выставке через 3 месяца.
Обратите внимание: в этом примере директор в действительности не просит оценки, а хочет получить от руководителя проекта план для достижения поставленной цели. Большинство начальников не обладает техническим образованием, которое бы позволило им различать оценки, цели, обязательства и планы. Таким образом, технический руководитель обязан сам преобразовать запрос начальства з конкретные технические термины.
Вот более продуктивный сценарий такого общения.
Директор: Как вы думаете, сколько времени займет проект? Программа должна быть готова через 3 месяца, к выставке. Я не могу дать больше людей в группу, поэтому вам придется обойтись текущим персоналом. Вот список тех функций, которые нам нумсны.
Руководитель проекта: Давайте убедимся в том, что я вас правильно понял. Что для нас важнее — реализовать все возможности на 100% или иметь хоть что-нибудь готовое к выставке?.
Директор: Иметь что-нибудь готовое к выставке. Ну и хотелось бы реализовать все возможности на 100%, если получится.
Руководитель проекта: А что делать, если окажется, что программа не готова на 100% к выставке? Приготовиться показать то, что есть, или перенести дату выхода на более поздний момент?.
1.4. Оценка как вероятностное утверждение 25.
Директор: Мы обязательно должны что-нибудь показать на выставке. Если время будет поджимать
отправим то, что есть, даже если продукт не будет готов на 100%.
Руководитель проекта: Хорошо. Я подготовлю план, который позволит нам реализовать как можно большую долю функциональности за следующие три месяца.
СОВЕТ № 2 -.
Когда вас просят предоставить оценку, определите, что именно нужно спрашивающему — оценка или план достижения цели.
1.4. Оценка как вероятностное утверждение.
Как известно, около трех четвертей программных проектов превышают свои оценки. Вероятность того, что любой отдельный проект завершится к поставленному сроку и без нарушения бюджета, отлична от 100 %. Но стоит нам признать, что вероятность своевременного завершения отлична от 100 %, возникает очевидный вопрос: «Если не 100 %, то сколько?» Это один из центральных вопросов в области оценки программных проектов.
Обычно оценки программных проектов представляются в виде обычных чисел, например: «Этот проект займет 14 недель». Подобные упрощенные точечные оценки бессмысленны, потому что они не включают никакой информации.
о вероятности, связанной с точечной оценкой. Подразумевается ситуация, представленная на рис. 1.1, — возможен единственный исход, которым является заданная точка.
Рис. 1.1. Точечная оценка подразумевает стопроцентную вероятность совпадения фактического исхода с запланированной оценкой. В жизни так не бывает.
Точечная оценка на поверку обычно оказывается целью, замаскированной под оценку. Иногда она возникает в результате удаления осмысленной вероятностной информации из более сложной и содержательной оценки.
Сталкиваясь с точечной «оценкой», спросите себя, действительно ли это число является оценкой или на самом деле перед вами цель.
Точные оценки учитывают, что программные проекты подвергаются влиянию множества факторов неопределенности. В совокупности эти факторы неопределенности означают, что результат проекта подчиняется вероятностному распределению — одни результаты более вероятны, другие менее вероятны, а наиболее вероятная группа результатов сосредоточена где-то в середине распределения. Можно было бы предположить, что распределение результатов проекта будет иметь вид кривой нормального распределения (рис. 1.2).
Рис. 1.2. Часто предполагается, что результаты программного проекта распределяются по нормальному закону. Такое предположение неверно, потому что эффективность выполнения любого заданного объема работы группой, работающей над проектом, является ограниченной величиной.
Каждая точка кривой представляет вероятность того, что проект будет завершен точно к соответствующей дате (или на него уйдет точно эта сумма). Площадь под кривой представляет суммарную вероятность 100 %. Вероятностное распределение такого рода учитывает возможный разброс результатов. Тем не менее предположение о симметричном распределении результатов по отношению к средней величине некорректно. Качество выполнения проекта является величиной ограниченной; это означает, что левый край распределения усекается вместо того, чтобы бесконечно убывать, как в нормальном распределении. И хотя «удачные» результаты проекта ограничены, возможности для «неудач» безграничны, поэтому вероятностная кривая уходит очень далеко вправо.
На рис. 1.3 изображено уточненное представление вероятностного распределения результатов программного проекта.
Вертикальная пунктирная линия изображает «номинальный» результат, или результат 50/50 — существует 50%-я вероятность того, что проект завершится лучше, и 50%-я вероятность того, что он завершится хуже. В статистике такой результат называется медианой.
На рис. 1.4 изображен другой способ представления подобных вероятностных распределений. Если график на рис. 1.3 показывает вероятность завершения проекта к конкретной дате, на рис. 1.5 показана вероятность завершения к конкретной дате или ранее.
На рис. 1.5 идея вероятностных оценок проектов представлена с другой точки зрения. Как видно из рисунка, из голословной оценки «18 недель» пропадает интересная подробность — что срок в 18 недель будет достигнут с вероятностью всего 10 %. Оценка «от 18 до 24 недель» более информативна и несет полезную информацию о вероятном диапазоне результатов проекта.
Номинальный результат
Рис. 1.3. Уточненное представление возможных результатов программного проекта. Возможности удачного выполнения проекта ограничены, но количество потенциальных проблем бесконечно
Рис. 1.4. Вероятность завершения программного проекта к определенной дате или ранее (или без превышения определенных затрат или объема работ)
СОВЕТ № 4 -.
Если вы сталкиваетесь с точечной оценкой, скорее всего, ее вероятность отлична от 100 %. Спросите себя, какова вероятность получения этого Мисла.
Существуют различные способы выражения вероятностей, ассоциируемых с оценками. Можно использовать процентное выражение: «Мы на 90 % уверены в соблюдении 24-недельного срока». Можно описывать оценку в виде диапазона лучший/худший случай, подразумевающем вероятность: «В лучшем случае проект будет завершен за 18 недель, а в худшем — за 24 недели». Наконец, можно.
просто сформулировать предполагаемый результат в виде диапазона вместо точечной оценки: «По нашей оценке, на проект уйдет от 18 до 24 недель». Принципиально здесь то, что любая оценка включает вероятность (явно или косвенно). Явное указание вероятности является одним из признаком хорошей оценки.
Рис. 1.5. Любая точечная оценка связывается с вероятностью (явно или косвенно).
Ваше обязательство может относиться к оптимистичной или пессимистичной границе диапазона оценки — или к любой позиции в середине. Важно знать, к какой части диапазона относится ваше обязательство, чтобы соответственно планировать свои действия.
1.5. Распространенные определения «хороших» оценок.
Даже разобравшись с тем, что такое «оценка», мы остаемся с другим вопросом: что такое хорошая оценка? Эксперты предлагают разные определения хороших оценок. Кейперс Джонс (Capers Jones) утверждал, что точность ±10 % достижима, но только в проектах с высокой степенью контроля (Jones 1998). Хаотичные проекты слишком непредсказуемы для достижения такой степени точности.
В 1986 году профессоры Конт, Дансмор и Шен предположили, что хорошая оценка должна в 75 % случаев отличаться от фактического результата не более чем на 25 % (Conte, Dunsmore, Shen 1986). Этот стандарт до настоящего времени является самым распространенным для выражения точности оценок (Stutzke 2005).
1.5. Распространенные определения «хороших» оценок 29.
Различные компании сообщали о результатах, близких к критерию точности, предложенному Контом, Дансмором и Шеном. На рис. 1.6 показаны оценки и фактические результаты для ряда проектов ВВС США.
Рис. 1.6. Улучшение качества оценок в проектах ВВС США. Предсказуемость проектов существенно улучшилась с переходом организаций на более высокие уровни СММ
На рис. 1.7 изображены результаты аналогичной программы повышения эффективности в компании «Боинг».
Рис. 1.7. Повышение качества оценок в компании «Боинг». Как и в случае с ВВС США, предсказуемость проектов радикально улучшается на более высоких уровнях СММ.
Последний аналогичный пример на рис. 1.8 был получен при улучшении результатов оценки в Schlumberger.
Рис. 1.8. Schlumberger повысила точность своих оценок от среднего превышения в 35 недель до среднего отставания в одну неделю.
Одна из моих компаний-клиентов завершает 97 % своих проектов вовремя и в рамках бюджета. Компания Telcordia сообщает, что ей удается завершать 98 % проектов в срок и без нарушения бюджета (Pitterman 2000). Аналогичные результаты публиковались множеством других компаний (Pitnam and Myers 2003). Организации создают хорошие оценки как по определению Джонса, так и по определению Конта, Дансмора и Шена. Тем не менее в обоих определениях отсутствует одна важная концепция — а именно то, что точность результатов оценки не достигается за счет одних лишь методик оценки. Она также должна поддерживаться эффективным управлением проектом.
1.6. Оценки и управление проектом.
Иногда при обсуждении оценки программных проектов оценка рассматривается исключительно как прогноз. Все выглядит так, словно оценка производится беспристрастным оракулом, находящимся где-то в открытом космосе, никак не связанным с планированием проекта и назначениями приоритетов.
В действительности оценка программных проектов не является столь отвлеченным делом. Если кому-то захочется увидеть пример принципа неопределенности Гейзенберга в области программного обеспечения — достаточно взглянуть на оценку проектов. (Принцип неопределенности Гейзенберга состоит в том, что сам факт наблюдения за явлением приводит к его изменению, и наблюдатель никогда не может быть полностью уверен в том, как повел бы себя объект при отсутствии наблюдения.) Сначала мы формируем оценку, а затем на базе этой оценки берем на себя обязательство обеспечить определенную функциональность и качество к конкретной дате; после этого мы управляем проектом для достижения поставленной.
1.6. Оценки и управление проектом 31.
цели. Типичные операции по управлению проектом включают удаление некритичных требований, переопределение требований, замену менее опытного персонала более опытным и т. д. Схема управления проектом представлена на рис. 1.9.
Рис. 1.9. От отправной точки до завершения проект претерпевает значительные изменения. Обычно эти изменения оказываются настолько значительными, что готовый проект отличается.
от того, который был заложен в основу оценки. Тем не менее, если результат сходен с прогнозом, можно сказать, что проект соответствует своей оценке.
Кроме управляющих операций, проекты часто находятся под воздействием непредвиденных внешних событий. Иногда группе разработчиков приходится создавать промежуточную версию продукта для передачи важному клиенту; персоналу приходится отвлекаться на поддержку старого проекта и т. д.
События, происходящие во время работы над проектом, почти всегда берут верх над предположениями, которые использовались при первоначальной оценке проекта. Изменяется предполагаемая функциональность, изменяются предположения по поводу доступного персонала, изменяются приоритеты. В итоге становится невозможно вынести четкое аналитическое суждение относительно точности оценки проекта, потому что программный проект, полученный в конечном итоге, не идентичен изначально запланированному проекту.
На практике, если проект реализует всю предполагаемую функциональность, более или менее ограничивается запланированными ресурсами и завершается более или менее к назначенному сроку, можно сказать, что «оценка проекта оказалась верной», несмотря на все аналитические неточности, кроющиеся в этой формулировке.
Таким образом, критерий «хорошей» оценки должен базироваться не на качестве прогнозирования, а на способности оценки обеспечить успех проекта. Так мы вплотную подошли к следующей, теме — настоящему значению оценки.
1.7. Настоящее значение оценки.
Предположим, вы собираетесь отправиться в поездку и решаете, какой чемодан с собой взять. Маленький чемодан легко нести, и он хорошо помещается в верхнюю багажную ячейку в салоне самолета. Большой чемодан не так удобен; его придется сдавать, а потом забирать на выдаче багажа, на что потребуется дополнительное время. Вы раскладываете свои вещи рядом с маленьким чемоданом — они почти помещаются. Что делать? Можно попытаться очень тщательно упаковать их, не оставляя ни малейшего пустого места, и надеяться, что они поместятся. Если не получится, можно попробовать запихнуть их в чемодан «грубой силой», сесть сверху и защелкнуть замки. Если и этот вариант не сработает, вы оказываетесь перед выбором: оставить часть вещей дома или взять большой чемодан.
Аналогичная дилемма возникает и в программных проектах. Планировщики проектов часто обнаруживают некоторые расхождения между деловыми целями проекта, оцениваемым по срокам и затратам. Если расхождения невелики, возможно, планировщику удастся довести проект до успешного завершения за счет либо умелого управления, либо «давления» на сроки, бюджет или предполагаемую функциональность. При больших расхождениях придется пересмотреть цели проекта.
Основным назначением оценки программного проекта является вовсе не прогнозирование результата. Оценка должна определить, достаточно ли реалистичны цели проекта, чтобы их можно было достичь за счет управления проектом. Поместятся ли вещи в маленький чемодан или же придется брать большой? А может, удастся взять маленький чемодан, если внести небольшие изменения? Начальство хочет услышать от вас подобные ответы. Обычно ему не нужна точная оценка, которая скажет, что вещи в чемодан не поместятся. Вместо этого начальству нужен план, который позволит взять с собой как можно больше вещей.
Проблемы начинаются тогда, когда разрыв между деловыми целями и сроками/объемом работ, необходимым для достижением этих целей, становится слишком большим. По своему опыту могу сказать, что если исходная цель и исходная оценка расходятся в пределах 20 % в ту или иную сторону, у руководителя проекта остается достаточное пространство для маневра, чтобы за счет управления функциональностью, сроком, численностью группы и другими параметрами добиться поставленных целей; другие эксперты с этим согласны (Boehm 1981, Stutzke 2005). Если разрыв между целью и реальными потребностями окажется слишком большим, руководитель не сможет довести проект до успешного завершения, внося незначительные изменения в его параметры. Сколько бы вы ни перекладывали свои вещи и не сидели на крышке чемодана, большая гора вещей все равно не поместится в маленький чемодан, и вам придется брать большой или оставлять часть вещей. Прежде чем руководитель начнет управлять проектом для достижения поставленных целей, эти цели необходимо привести в соответствие с реальностью.
Оценки должны быть не столько идеально точными, сколько полезными. Комбинация из точных оценок, грамотно выбранных целей и качественного планирования управления позволит привести проект к результату, близкому к «оценке».
(как вы, вероятно, догадались, слово «оценка» взято в кавычки, потому что оцениваемый проект не идентичен завершенному).
Динамика изменения предпосылок проекта является главной причиной, по которой основное внимание в этой книге уделяется неформальным, а не научным методам. Точность в ±5 % окажется бесполезной, если базовые предпосылки проекта изменятся на 100 %.
1.8. Рабочее определение «хорошей оценки».
После всего, что было сказано в предыдущих разделах, мы можем ответить на вопрос, что же следует считать хорошей оценкой.
Хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей.
Это определение заложено в основу всего последующего обсуждения оценок в книге.