Вальсируя с медведями - ДеМарко Том - Страница 29

Проект целиком завершен, когда версия 5 проходит через приемные испытания ПИ5 (поскольку V5 – окончательная версия, то ПИ5 – приемное испытание для продукта целиком). В этой точке 100% объема освоено. ООФ, связанный с прохождением приемных испытаний отдельных версий, составляет:

ПИ1: 30%

ПИ2: 49%

ПИ3: 69%

ПИ4: 78%

ПИ5: 100%

Рисунок реального ООФ, показанною как функция от времени, выглядит так:

Значение завершенного ООФ в единицу времени дает плавную кривую для проекта. Эта плавная кривая – самый сильный из возможных показателей завершенности проекта. Отклонения этой кривой от ожидаемого вида являются безусловным признаком проявления риска и служат призывом к действиям по запуску запланированных стратегий сдерживания риска.

Инкрементный метод в процессе разработки продукта – главный источник показателей завершения, а показатели завершения – пульс проекта. Осуществляя мониторинг ООФ и отслеживание реальной производительности в терминах ООФ, вы используете показатель «голоса продукта». Сам продукт говорит вам: «Я на столько-то % готов и могу доказать это». Доказательством, конечно, служит прохождение приемного испытания версии, которая включает указанный процент освоенного объема всего проекта.

Отслеживание ООФ – основной источник обратной связи по поводу рисков от середины проекта (или даже чуть раньше) до самого конца. ООФ дает показатель «голоса продукта», причем добавляет совсем мало затрат к проекту.

Пока мы говорили только о преимуществах этого подхода, относящихся к рискам. Для справки сообщим, что есть и другие преимущества, включая:

1. больше возможностей для мотивации персонала проекта

2. большая прозрачность

3. большее привлечение пользователя в проекте с середины до конца

4. возможность отмены заключительной части проекта в силу понимания, что она в основном состоит из малополезных частей продукта

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

Глава 17

Стратегия максимального ослабления рисков

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

Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за пять-десять до начала совещания.

Но на этом задержим внимание: план, зависящий от того, что вам должна везде улыбаться удача, вряд ли можно назвать свободным от риска. Если вам не будет сопутствовать везение на каждом шагу, то вы опоздаете. Ничего хорошего. Итак, вы теперь переходите в режим ослабления риска. Как поменять план, чтобы защитить себя от очевидных рисков?

Тут не требуется быть семи пядей во лбу. Не требуется умения читать чужие мысли, чтобы угадать, что вашим первым импульсом будет найти возможность более раннего вылета. Рейс на рассвете (в б утра) не вызывает восторга, но зато оставляет в запасе пару часов. А что если прилететь накануне вечером и обосноваться в отеле рядом с офисом?

Ваш «проект» в данном случае состоит в попадании в Сан-Франциско. Самое важное для вас – выполнить его своевременно, наиболее естественное решение для вас – раньше приступить к проекту. Это каждому понятно, то есть, разумеется, кроме разработчиков IТ-проектов.

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

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

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

Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:

Это – робкое руководство в худшем своем проявлении.

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

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