Глава 10

Правила управления рисками

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

Управление рисками, по сути, состоит в осуществлении следующих девяти шагов, включаемых в проект:

1. Использовать процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту.

2. Убедиться, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.

3. Провести всю указанную предварительную подготовку по каждому из рисков:

• Дать наименование риску и присвоить ему уникальный номер.

• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).

• Оценить влияние риска на стоимость и расписание проекта.

• Оценить вероятность наступления риска.

• Рассчитать подверженность риску по отношению к графику и бюджету.

• Определить заранее, какие меры придется принять, если и когда событие риска наступит.

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

• Включить действия по ослаблению риска в общий план проекта.

• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.

4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков вышестоящему руководству.

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

6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.

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

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

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

Эти шаги достаточно легко перечислить, но труднее осуществить. Уместно сделать несколько замечаний:

Посылка, на которой строится наш подход к календарному планированию на основе 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%. Опять же, хотя это может оказаться неприятной новостью, скрывать ее — лишь отложить (и усугубить) день окончательной расплаты.

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

Во-вторых, берегитесь проекта, который представлен как имеющий фиксированный срок сдачи, но на самом деле его не имеет:

ТДМ: Я консультировал в штате Нью-Йорк проект с «жестким, фиксированным сроком сдачи». Продукт должен был быть во что бы то ни стало поставлен к концу второго квартала, никакие извинительные причины не принимались. Но он не был сдан в срок. На самом деле его сдали с опозданием больше чем на 18 месяцев. Оглядываясь назад, я не могу не удивляться, к чему были все эти песни и пляски по поводу «жесткого, фиксированного срока сдачи», поскольку срок с очевидностью не был ни жестким, ни фиксированным.

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

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

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

Здесь изображен проект, который с вероятностью не менее 60% не сможет предъявить к обещанному сроку даже первую работающую версию.

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

Как мы намекнули в главе 5, вы только тогда можете безопасно для себя обнародовать перечень рисков, когда то же самое делают и ваши коллеги-менеджеры. (Очень невыгодно быть единственным честным человеком в комнате, которая полна лжецов). Для организации много лучше, когда все списки рисков обнародованы, поскольку пропуск любым из менеджеров одного из ключевых рисков сразу бросается в глаза. Менеджеры, которые берут на себя нереальные обязательства, игнорируя важные риски, сразу проявляются при простом сравнении списков. Вместо того чтобы выглядеть героями, берущими на себя амбициозные обязательства, они выглядят слегка глуповато, поскольку не признают своих рисков.

Глава 11

Возвращение к основам

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

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

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

Можно предварять любой свой ответ словами: «Я не знаю, но…» Но даже если вы не начинаете с этого уточнения, оно неявно подразумевается.

Мы хотим здесь показать, что вам нужно узнавать эти «я-не-знаю» вопросы, потому что они всегда являются показателями риска. У того, чего вы не знаете, есть оборотная сторона, которая может повернуться против вас, в этом и состоит ваш риск. Если бы вы смогли собрать все уникальные «я-не-знаю» вопросы о своем проекте и докопаться до глубинной причины неизвестного в каждом из них, то перед вами оказался бы полный список рисков вашего проекта.

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

Что я знаю (или что я мог бы знать) о том, чего я не знаю?

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

Вот пример. Вы возделываете свой сад 31 марта, но поскольку рядом с садом нет воды для полива, вы рассчитываете на дождь, чтобы он полил ваш сад. Итак, денежный вопрос здесь звучит так: «Сколько дождя прольется на ваш сад?» Вы, разумеется, отвечаете: «Я не знаю». Ясно, что это сигнализирует вам о риске, заключающемся в том, что ваши труды и деньги, потраченные на семена, могут пойти прахом, если не будет достаточного количества влаги. Теперь вы задаете вспомогательный вопрос: «Что я знаю (или что я мог бы знать) о том, чего я не знаю?» Быстрый поиск в Интернете или визит к местному агроному может снабдить вас информацией о прошлых дождях в вашем районе:

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

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

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

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

Диаграмма неопределенности показывает набор предыдущих результатов:

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

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

Перейдем от далекого примера про сад к более волнующей теме: неопределенности относительно того, когда будет готов ваш проект:

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

Можно использовать диаграмму риска для количественной оценки любого рассматриваемого риска. Например, вы ищете точку, для которой площади под кривой слева и справа одинаковы, называя ее риском 50 на 50, это самый ранний срок, когда вероятность успеть вовремя сравнялась с вероятностью не успеть к этому сроку. Вы можете посмотреть правее, где под кривой находится уже 90% площади (похоже, что на рисунке это приходится на май следующего года), и узнать, что при назначении его сроком сдачи вы можете не уложиться лишь с 10%-ной вероятностью. Другими словами, гораздо вероятнее, что вы успеете завершить проект раньше этой даты, чем позже. Вы можете также исключить самые оптимистичные 10% и самые пессимистичные 10% и уверенно считать, что с 80%-ной вероятностью завершите проект в период между нынешним и следующим маем. Диаграмма риска — инструмент для оценки размера риска в любой выбранной вами форме выражения. Но мы собираемся сообщить вам еще более грандиозное понимание диаграммы риска: идею о том, что ситуация, нарисованная диаграммой, и является риском. Это ведет к следующему окончательному определению риска, взамен временного определения, предложенного в главе 2:

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

• «Дело в шляпе, босс!» (по сути 100%-ная уверенность);

или

• «Я думаю, что шансы равны» (50%);

или

• «Разве что рак на горе свистнет!» (меньше 1%).

С нашим уточненным теперь понятием риска, мы отвечаем на этот вопрос диаграммой риска, подобной приведенной выше. Мы не разжевываем ответ для начальника, клиента или контрагента, а просто выкладываем карты на стол: «Как вы прекрасно знаете, в разработке программного обеспечения всегда есть элемент неопределенности, вот посмотрите на его размеры в этом проекте».

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

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

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

Диаграммы риска часто имеют весьма характерные формы. Можно, например, встретить такие, которые математики называют нормальными или симметричными относительно средней точки:

Обычно более распространены асимметричные диаграммы, которые выглядят так:

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

До сих пор мы сваливали в одну кучу риски двух разных типов. Мы приводили как профили рисков для целых проектов, выраженные диаграммами неопределенности, где показаны сроки сдачи, общие затраты и усилия, или версии, которые могли быть готовыми к заданной дате. Кроме того, мы говорили и о сложных (многокомпонентных) рисках, вроде производительности труда персонала или текучести кадров. Первая категория состоит из того, что мы называем совокупными (агрегированными) рисками, поскольку они относятся к проекту в целом; а вторую категорию мы называем причинными (слагающими) рисками. Ясно, что эти категории связаны между собой. Неопределенность относительно совокупного результата является прямым результатом неопределенностей причинных факторов, ведущих к успеху или провалу:

Процесс, происходящий между ними (процесс преобразования набора причинных рисков в совокупный риск) — это то, что мы будем рассматривать ниже в качестве «модели риска».

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

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

Такое чудо служило бы отчасти для параметрического оценивания, отчасти для перекрывания неопределенности. Компонент для параметрического оценивания уже появился на рынке. Возможно, у вас уже есть этот инструмент, который либо приобретен вашей компанией, либо разработан собственными силами. Вы вливаете в него все, что вам известно о проекте (функциональные точки, параметры SLIM, предсказания модели СОСОМО[20] или что-то в этом духе), вместе с некоторой индивидуализирующей информацией об используемых вами процедурах и прошлой истории, а он выдает время, за которое проект может быть завершен.

Мы предлагаем вам продолжать использовать ваш нынешний инструмент оценивания, каким бы он ни был (даже если это мокрый палец на ветру), и объединить его с моделью риска, о которой пойдет речь в следующих двух главах. Этот инструмент — ваша производственная модель, поскольку он показывает, сколько вы можете произвести за какое-то время, а модель риска показывает, сколько неопределенности будет связано с производственной оценкой. Работая вместе, эти две модели взаимодействуют так:

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

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

Для того, чтобы продемонстрировать следующую идею, придется построить очень грубую диаграмму неопределенности («крупнозернистость» сделает эффект более очевидным). Предположим, мы изучаем небольшие группы учащихся. У нас есть какие-то данные о них, включая вес в фунтах. Мы группируем данные по весу с шагом в 20 фунтов и обнаруживаем, что есть один ребенок в группе 101-120 фунтов, три — в группе 121-140 фунтов и два — в группе 141-160 фунтов:

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

Эту диаграмму следует читать несколько иначе: график показывает вероятность того, что ребенок, прыгающий вам на колени, будет принадлежать к указанной весовой группе или одной из предшествующих ей. Ниже первой весовой группы, вероятность нулевая (в классе нет ребят, весящих меньше 100 фунтов). Оказаться в верхней весовой группе и предшествующих ей можно со 100%-ной вероятностью, поскольку все дети в классе отвечают этому определению.

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

Теперь вернемся к реальному миру: ниже показана дифференциальная диаграмма риска для срока сдачи проекта и (непосредственно под ней) ее кумулятивный эквивалент:

Здесь снова оба графика показывают одни и те же данные, просто представленные слегка по-разному. Заметно, что шкалу по вертикали при кумулятивной форме несколько легче понять: она показывает непосредственно вероятность от 0 до 100%. Любая дата влево от 1 января безнадежна (0%-ная вероятность), но если мы захотим пройти весь путь до конца декабря следующего года, есть 100%-ная вероятность того, что к сроку все будет готово. Факт, что 1 мая следующего года дает вероятность 50 на 50, сразу виден на кумулятивной диаграмме, а на дифференциальной нужно оценить площади слева и справа отданной точки.

Обе формы полезны, и если у вас есть данные для одной из них, вы всегда можете использовать их для построения другой.

Глава 12