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

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

16.1. Формирование оценки в неправильно оцениваемом проекте.

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

Выходные данные, определенные )

для этой конкретной ] Выходные

Нестандартный S

| процесс.

v оценки ).

СОВЕТ № 69 -.

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

16.2. Формирование оценки в правильно оцениваемом проекте.

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

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

Рис. 16.2. Процесс создания оценки в правильно оцениваемых проектах. Входные данные и процесс четко определены. Процесс и результаты не оспариваются; тем не менее входные данные могут подвергаться итеративным изменениям вплоть до получения приемлемого вывода.

В правильно оцениваемом проекте входные данные включают техническую спецификацию, приоритеты и ограничения. Эти входные данные регулируются.

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

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

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

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

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

Р°

Рис. 16.3. Логика создания единой оценки в правильно оцениваемом проекте. Объем работ, срок, стоимость и функциональность определяются по оценке размера.

СОВЕТ № 70 -.

Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость и функциональность по оценке размера.

16.3. Хронологическая последовательность формирования оценки для всего проекта.

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

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

Рис. 16.4. Сводка применимости различных методов оценки в зависимости от типа и фазы проекта.

Формирование оценки в крупных проектах.

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

При переходе к более поздним стадиям крупного проекта следует переходить к более точным, основанным на исторических данных счетным методам, и ориентироваться на микрометоды, обеспечивающие более высокую точность (Symons 1991).

СОВЕТ № 72 -.

Переходите от неточных оценок к более точным по мере продвижения работы над проектом.

Формирование оценки в мелких проектах.

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

СОВЕТ № 73 -.

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

16.4. Уточнение оценок.

При нарушении контрольных точек в проектах возникает вопрос о перекалибровке графика. Допустим, для завершения проекта был установлен 6-месячный срок. Вы намеревались достичь первой контрольной точки за 4 недели, но в действительности для этого потребовалось 6 недель. Как вы будете действовать дальше?.

• Понадеетесь скомпенсировать две потерянные недели позднее?.

• Прибавите две недели к общему сроку?.

• Умножите весь срок на величину ошибки (в данном случае на 50 %)?.

На практике чаще всего встречается вариант № 1. Обычно это обосновывают так: «Требования заняли чуть больше времени, чем предполагалось, но теперь они стабильны, и это позволит нам сэкономить время позднее. Наверстаем при программировании и тестировании». Тем не менее анализ более 300 проектов в 1991 году показал, что проекты практически никогда не наверстывают упущенное время — чаще отставание лишь увеличивается (van Genuchten 1991). Вариант № 1 почти никогда не бывает лучшим.

Вариант № 2 предполагает, что первый этап проекта занял на две недели больше, чем следовало, но все оставшиеся этапы уложатся в изначально отведенные сроки. «Ахиллесова пята» варианта № 2 заключается в том, что ошибки оценки обычно обусловлены системными причинами, распространяющимися на весь проект. Маловероятно, чтобы вся оценка оказалась точной, а нарушение встретилось в той единственной части, которую вы опробовали на практике. За редкими исключениями самой правильной реакцией на результаты, отклоняющиеся от оцениваемых, является вариант № 3.

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

СОВЕТ № 74 -.

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

16.5. Представление измененной оценки другим ключевым сторонам проекта.

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

Таблица 16.1. История изменения точечной оценки

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

Сравните со сценарием, в котором диапазонные оценки сужаются по мере продвижения проекта, как показано в табл. 16.2.

Таблица 16.2. История изменения диапазонной оценки

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

Для применения диапазонов вместо точечных оценок существует еще одна причина: исследователи выяснили, что исходные оценки часто становятся «опорой» для будущих оценок, даже если они не были достаточно хорошо обоснованы (Lim and O’Connor 1996, Jorgensen 2002). Таким образом, одна неудачная точечная оценка может испортить оценки для целого проекта. Использование диапазонных оценок вместо точечных помогает избежать этой проблемы.

СОВЕТ № 75 -.

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

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

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

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

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

Таблица 16.3. Примерный график уточнения оценок для последовательного проекта

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

СОВЕТ № 76 -.

Сообщайте о своих планах повторного проведения оценки заранее.

Что делать, если начальство запрещает переоценку?.

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

Во многих организациях пересмотр оценок планируется заранее. Эта тема более подробно обсуждается в разделе 17.2.

16.6. Критерии правильной оценки проекта.

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

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

Рис. 16.5. Правильно оцениваемый проект. Точечные оценки не попадают в цель, но все диапазоны включают конечный итог.

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

На рис. 16.6 изображен пример систематически недооцениваемого проекта.

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

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