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

22.1. Представление предположений, заложенных в оценку.

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

• обязательные функции;.

• необязательные функции;.

• глубина проработки тех или иных функций;.

• доступность ключевых ресурсов;.

• зависимость от третьих сторон;.

• основные неизвестные факторы;.

• основные факторы влияния и чувствительность оценки;.

• качество оценки;.

• предполагаемое использование оценки.

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

Пример документирования предположений оценки.

Оценка проекта.

Базовая оценка срока составляет 6 календарных месяцев; по нашему мнению, ее точность лежит в пределах 25 %. Эта оценка может быть взята за основу формирования б)оджета, но не может использоваться для принятия внешних обязательств. Оценка базируется на следующих предположениях.

1.

Три ключевых технических руководителя приступят к работе исключительно над проектом с 15 марта.

2.

Все разработчики и специалисты по тестированию приступят к работе исключительно над проектом с 15 апреля.

3.

Подсистема форматирования графики будет получена от субподрядчика с приемлемым качеством к 1 августа.

4.

Бизнес-правила не потребуют обновления.

5.

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

6.

В проекте потребуется не более 5 новых отчетов.

7.

Новый инструментарий разработки обеспечит прирост производительности на 20 % и более по сравнению с прошлыми проектами.

8.

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

9.

После наступления дат, указанных в пунктах 1 и 2, персонал не будет отвлекаться на поддержку предыдущих версий программы.

10. По крайней мере 80 % кода базы данных из версии 2.0 удастся использовать повторно без модификаций.

В случае нарушения этих предположений оценку придется пересмотреть.

Этот подход также м:ожет пригодиться в ситуациях, когда вас заставляют сформировать оценку на базе предположений, которые вам кажутся нереалистичными (таких, как предположения 7-9). Вы беретесь за дело и составляете оценку, но документируете заложенные в нее предположения. Если работа над проектом пойдет так, что оценка станет недействительной, вы всегда сможете сослаться на предположения как на основу для пересмотра оценки.

СОВЕТ № 104 -.

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

22.2. Выражение неопределенности.

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

Квалификаторы «плюс/минус».

Оценка с квалификатором «плюс/минус» имеет вид «6 месяцев ± 2 месяца» или «$600 ООО +$200 000 -$100 000». В подобных обозначениях указывается как величина, так и направление неопределенности. Формулировка «6 месяцев + 1/2 месяца -1/2 месяца» говорит о том, что оценка весьма точна, и существует достаточно высокая вероятность ее достижения. Формулировка «6 месяцев +4 месяца -1 месяц» означает, что точность оценки оставляет желать лучшего, а шансы на ее реализацию невелики.

При выражении оценки с квалификатором «плюс/минус» следует учитывать величину квалификаторов и их смысл. На практике квалификаторы часто выбираются достаточно большими для того, чтобы они включали одно стандартное отклонение с каждой стороны базовой оценки. При таком подходе все равно остается 16 % вероятность totq, что фактический результат превысит верхнюю границу оценки, и 16 % вероятность того, что он окажется под нижней границей. Если вам нужно обеспечить более 68 % вероятности в середине диапазона в одно стандартное отклонение, используйте соответствующие квалификаторы (в табл. 10.6 приведен список стандартных отклонений и связанных с ними вероятностей).

Подумайте, должен ли «минусовой» квалификатор совпадать с «плюсовым». Для объемов работ и сроков «минусовой» квалификатор обычно меньше «плюсового» по причинам, объясненным в разделе 1.4.

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

Квантификация рисков.

Квантификация рисков представляет собой комбинацию квалификаторов «плюс/ минус» и предположений проекта. В результате квантификации риски ассоциируются с конкретными последствиями, как показано в табл. 22.1.

Оценка: 6 месяцев, +5 месяцев, -1 месяц Последствия Описание риска

В этом относительно простом примере внимание направлено исключительно на риски для сроков. В реальной ситуации, помимо последствий рисков для сроков, могут быть перечислены основные последствия рисков для объемов и функциональности. Следует помнить, что речь идет о методике представления оценки. Ее целью является передача информации о рисках нетехническим ключевым участникам проекта. Чтобы не перегружать их подробной информацией о рисках, постарайтесь сосредоточиться на монолитных, укрупненных рисках.

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

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

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

СОВЕТ № 105 -.

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

Коэффициенты достоверности.

Один из вопросов, которые часто задаются о сроках — «Какова вероятность того, что мы управимся к этой дате?» Коэффициенты достоверности позволят вам ответить на этот вопрос и привести оценку вроде той, что представлена в табл. 22.2.

Для приближенной оценки интервалов можно воспользоваться оценкой «наиболее вероятного» результата и множителями из табл. 4.1, соответствующими фазе проекта.

Как упоминалось в главе 2 и в других местах книги, избегайте излишне уверенных («достоверных на 90 %») оценок, если только вы не располагаете количественными показателями, подтверждающими столь высокие проценты.

Таблица 22.2. Пример оценки с коэффициентами достоверности

Также подумайте, стоит ли представлять оценки с низкой достоверностью. Теоретическая возможность результата еще не означает, что его нужно включать в таблицу. Вряд ли кому-нибудь придет в голову приводить варианты, вероятные на 1 % или 0,0001 %. Представление только тех вариантов, вероятность которых составляет не менее 50 % — вполне разумная стратегия оценки.

СОВЕТ № 106 -.

Не представляйте ответственным сторонам проекта маловероятные результаты.

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

Рис. 22.1. Пример наглядного представления оценок с разной достоверностью в процентах.

СОВЕТ № 107.

Подумайте, не заменить ли текстовое представление оценки графическим.

Сценарные оценки.

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

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

Таблица 22.3. Пример сценарных оценок

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

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

На рис. 22.2 показан пример визуального представления информации такого рода.

Янв Фев Мар Апр Май Июн Июл Авг Сен Окт Ноя Дек Дата выдачи.

Рис. 22.2. Пример наглядного представления сценарных оценок.

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

Г рубая оценка дат и периодов времени.

Старайтесь представлять свои оценки в единицах, соответствующих точности базовых данных оценки. Если оценки являются приближенными, используйте очевидно грубые оценки («Мы сделаем это во втором квартале», или «Проект потребует 10 человеко-лет») вместо создающих ложное впечатление точных чисел: («Мы сделаем это к 21 мая» или «На проект потребуется 15 388 человекочасов»). Рассмотрите возможность использования следующих единиц:.

• годы;.

• кварталы;.

• месяцы;.

• недели.

Помимо четкого выражения приближенности оценки, у грубых оценок есть еще одно преимущество: упрощение оценки не приведет к потере информации. Оценка «6 месяцев, +3 месяца, -1 месяц» может быть упрощена до «6 месяцев». Оценка «во втором квартале» защищена от подобных упрощений.

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

22.3. Диапазоны (любого типа).

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

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

Представляя оценку в виде диапазона, попробуйте ответить на следующие вопросы.

• Какой уровень вероятности должен быть включен в диапазон? Ограничиться ли ±1 стандартным отклонением (68 % возможных исходов), или диапазон должен быть шире?.

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

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

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

• Нельзя ли объединить диапазоны с другими приемами представления оценок? Подумайте о том, чтобы представить оценку в диапазонном виде, а затем привести список предположений или воспользоваться квантификацией рисков.

СОВЕТ № 108 -.

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

Полезность диапазонного представления оценок.

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

Два крупнейших профессиональных сообщества разработчиков программного обеспечения — IEEE Computer Society и Association of Computing Machinery — совместно решили, что включение неопределенности в оценку относится к числу профессиональных обязанностей разработчиков. Статья 3.9 этического кодекса разработчика IEEE-CS/ACM гласит:.

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

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

Иначе говоря, включение неопределенности в оценку — это не любезность, а этическая ответственность разработчика.

Диапазоны и обязательства.

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

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

СОВЕТ № 109 -

-.

Не пытайтесь выражать обязательства в диапазонной форме. Обязательства должны быть более конкретными.