Вальсируя с медведями - Том ДеМарко

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

Вычисление и использование ООФ (второй проход)

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

Освоенный объем функционала (ООФ) — это стоимость тех работ, которые были завершены при создании текущей версии продукта. ООФ выражен в процентах от всего бюджета. Запланированные усилия для каждой задачи в ИСР также можно выразить в процентах от целого. ООФ для версии n теперь можно подсчитать, сложив расходы на все те задачи, чье завершение продемонстрировано прохождением приемного испытания (ПИ)n.

Рассмотрим следующий простой пример: проект с 10 работами в ИСР, где есть 100 человеко-недель трудозатрат по графику и план инкрементной поставки n для пяти версий:

Проект целиком завершен, когда версия 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Т-проектов.

Шутка о нас

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

IT-менеджер и нормальный человек оказываются в одинаковой ситуации: работают в Чикаго и после обеда в среду узнают, что надо быть в Сан-Франциско на совещании в полдень пятницы, причем строго необходимо попасть туда вовремя. Нормальный человек (назовем ее Дианой) вылетает вечером в четверг и устраивается в славном небольшом отеле, расположенном всего за квартал от нужного офиса. Она неспешно ужинает в хорошем ресторане и успевает прогуляться до магазина, чтобы запастись фотопленкой. На следующее утро она с удовольствием и не торопясь завтракает, а потом работает на своем портативном компьютере до 11 часов. Она выходит в 11:30 и, совершив променад до офиса, попадает туда за 10 минут до начала совещания.

А теперь IT-менеджер Джек. Он покупает билет на 8:40 в пятницу. Поймав такси в городе в 7:05, попадает в пробку и гневно жалуется на это шоферу всю дорогу до аэропорта. Тупой водитель никак не уразумеет, как важно Джеку не опоздать на этот рейс. Pегистрируясь в аэропорту, он с нажимом объясняет клерку, что самолет должен взлететь и приземлиться точно по расписанию и никаких оправданий он не примет. Он говорит, что будет «весьма и весьма разочарован» в случае любого опоздания. Когда объявляют о задержке рейса, Джек вскакивает и громко ругается. Когда объявляется измененное время отправки рейса, он роется в своих управленческих инструментах и выкапывает оттуда ультиматум: «Если меня не доставят вовремя на совещание в Сан-Франциско, ПОЛЕТЯТ ГОЛОВЫ!»

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

Отважное и робкое руководство

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

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

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

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

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