Том ДеМарко - Вальсируя с медведями
Ваш выбор показателя события риска требует тщательной оценки быстроты реакции и затрат на срабатывание ложно-позитивных сигналов.
Глава 10
Правила управления рисками
Осталось описать только детали. В предыдущих главах было уделено достаточно внимания основным представлениям, поэтому уже можно перейти к изложению общих правил того, что понимают под управлением рисками.
Что понимают под управлением рискамиУправление рисками, по сути, состоит в осуществлении следующих девяти шагов, включаемых в проект:
1. Использовать процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту.
2. Убедиться, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Провести всю указанную предварительную подготовку по каждому из рисков:
• Дать наименование риску и присвоить ему уникальный номер.
• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).
• Оценить влияние риска на стоимость и расписание проекта.
• Оценить вероятность наступления риска.
• Рассчитать подверженность риску по отношению к графику и бюджету.
• Определить заранее, какие меры придется принять, если и когда событие риска наступит.
• Определить, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включить действия по ослаблению риска в общий план проекта.
• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделать первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект.
6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.
7. Выразить, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом.
8. Отслеживать все риски на предмет наступления или исчезновения и осуществлять планы на случай непредвиденных обстоятельств всякий раз, когда риски наступают.
9. Поддерживать в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Эти шаги достаточно легко перечислить, но труднее осуществить. Уместно сделать несколько замечаний:
Календарное планирование на основе NПосылка, на которой строится наш подход к календарному планированию на основе N, состоит в том, что природная склонность к оптимизму и имеющийся опыт (вместе с любыми имеющимися у вас инструментами для решения этой задачи) делают нас достаточно искусными в вычислении N, самой оптимистичной из всех возможных дат завершения проекта. Отличие нашего подхода от традиционного состоит в том, что мы предлагаем не брать обязательств сдать работу в срок N, а использовать N как входные данные в процессе определения более разумных обязательств, приемлемых с точки зрения ограниченной неопределенности, показанной на вашей диаграмме риска.
Разумеется, график, построенный на основе N, может быть нарушен. Например, кто-то, горя желанием заставить вас взять обязательство завершить проект через 12 месяцев, может пытаться убедить вас, что N составляет 4 месяца, поэтому ваша диаграмма риска должна основываться на 4. Но бремя доказательств в этом случае возлагается на того, кто вас уверяет: ему придется доказать, что проект за 4 месяца, по крайней мере, технически осуществим, и это не противоречит лучшим аналогичным примерам прошлых проектов.
Обязательства и целиПредположим, что диаграмма риска для вашего проекта показывает N в марте, а готовность с вероятностью 75% – в сентябре. На этой основе вы можете предпочесть убедить участников проекта получить продукт в сентябре. Сентябрь – разумный срок для обязательств, но совсем не идеальная цель для вдохновения членов команды проекта. Никто не хочет работать ради цели, имеющей 75%-ную вероятность, то есть с очень низкой эластичностью. Аналогично, N – также неудачная цель для проекта, поскольку никто не хочет работать ради цели, имеющей вероятность 0%, все мы слишком большую часть жизни тратим на бесплодные усилия. Наилучшим решением является установление в качестве цели эластичной даты сдачи проекта где-то между N и установленным сроком сдачи.
Это – новое и отличное от прежнего: проект с установленной датой сдачи, отличающейся от эластичной цели. Долгое время в большинстве компаний было принято:
График = Цель = N действительно дурацкое уравнение
N – не вдохновляющая цель, потому что она недостижимая. По той же причине она будет катастрофической как обязательство по завершению проекта. Вместо этого мы предлагаем:
График > Цель > N более разумно
Если мы убедили вас, что это разумно, не стоит автоматически считать, что все в вашей организации посмотрят на дело таким образом. Глубоко укоренилась дурная привычка брать N как обязательство по сдаче. Необходимо отделаться от нее, но следует ожидать, что избавление от нее, как и от любой другой дурной привычки, будет болезненным процессом.
ТРЛ: Мой отец – математик, профессор на пенсии. Однажды он разворчался на меня по поводу всех проектов по разработке программного обеспечения, которые выполнялись с тем или иным опозданием, что относится почти к 100% проектов. «Почему так?» – вопрошал он.
Я ответил: «Видишь ли, у проекта есть всего два возможных варианта: своевременное выполнение и запаздывание. Полагаю, что перевес в пользу запаздывания, за исключением нескольких весьма примечательных случаев».
«Вариантов не два, Тим, – ответил он. – Есть и третий – досрочная готовность».
Это заставило меня задуматься. Я все время бывал в компаниях, для которых опережение графика совершенно немыслимо. Менеджера, который завершил бы проект раньше срока, обвинили бы в недобросовестном манипулировании графиком и, возможно, изгнали бы с позором.
Делая третий вариант – досрочную готовность – по сути незаконным, мы сокращаем шансы на выполнение проекта в срок почти до нуля. Наши меры противодействия превратили манипулирование графиком скорее в правило, чем в исключение.
Нужно реабилитировать раннее достижение результата, чтобы внушить доверие к нашим обязательствам. А это также требует серьезной работы над корпоративной культурой. Как только мы обеспечим, чтобы досрочное выполнение проекта было безопасным, участники проекта могут рассчитывать на своевременное завершение. Мы можем реалистично назначать цели, отличные от обязательств, и начинать долгожданную демонстрацию своей способности выдерживать обязательства по срокам.
Компромиссы неопределенностиВы, конечно, легко можете представить себе проект, дата сдачи которого должна быть определена заранее и не допускает никакой задержки. Вам не пойдет на пользу попытка показывать боссу диаграмму риска с низкой вероятностью успеть к заданной дате.
К счастью, есть некоторые возможности поменять неопределенность в соблюдении графика на функциональную неопределенность. Если дата полностью фиксирована, то вам нужно выразить неопределенность проекта с помощью подобной диаграммы риска:
Дата теперь фиксирована, и неопределенность полностью относится к тому, что именно будут сдавать в этот день. Если ни один риск не наступит, могут быть сданы все версии от 1 до 24 (представленные как В24). Поскольку шансы избежать все риски крайне малы, это нанопроцентная функциональность – не то, чтобы невозможно, но исключительно неправдоподобно. Если судить по площади под кривой слева от В21, вероятность сдать все версии от 1 до 21 становится примерно 50%-ной к этой дате. Если участники проекта непреклонны в том, что для них не подойдет ничего, что будет меньше, чем В22, то диаграмма показывает, что вероятность предоставить им то, что они хотят, едва достигает 30%. Опять же, хотя это может оказаться неприятной новостью, скрывать ее – лишь отложить (и усугубить) день окончательной расплаты.
Здесь нужно сделать три предостережения: во-первых, этот подход осмыслен, только если заранее предполагается строго пошаговая разработка и вы заранее твердо определили, каким будет функционал каждой версии. Если вы собирались поставить всего две-три версии, полученная диаграмма неопределенности практически бессмысленна. А если вы откладываете решение того, какие функции будут включены в какую из версий, то пользователи не смогут определить, какие функции под угрозой риска.
