Текст книги "Вальсируя с медведями"

Автор книги: Том ДеМарко

Соавторы: Тимоти Листер
сообщить о нарушении

Текущая страница: 5 (всего у книги 12 страниц) [доступный отрывок для чтения: 5 страниц]

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

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

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

Подверженность риску

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

подверженность риску = затраты * вероятность

Таким образом, если вы определяете вероятность риска в 20%, а его наступление обойдется вам в миллион долларов, то подверженность риску составит $200000.

Можете быть совершенно уверены в том, что реальные затраты, которые принесет вам данный риск, никогда не будут в точности равны подверженности риску. Указанный выше риск, например, либо наступит, либо – нет. Если он наступит, то он обойдется вам в миллион долларов, если нет, то не будет стоить ничего. Тем не менее, подверженность этому риску составляет $200000.

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

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

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

Слово о рисках-катастрофах[19]19
  Сами авторы используют здесь термин showstopper, которым программисты называют устойчивую системную ошибку, исключающую возможность правильной работы прикладной программы (прим. ред.)


[Закрыть]

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

• Компания пускается в выполнение проекта, чтобы полностью переделать основной продукт. Руководство проекта рассчитывает, что это займет порядка 2-2,5 лет. Есть опасение, что один из конкурентов начнет выпускать такой же продукт намного раньше предполагаемого срока завершения проекта.

• Новый продукт строится на базе преобладающей на данном рынке операционной системы. Что, если эта ОС будет обновлена и данный продукт будет несовместим с новой версией?

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

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

Резерв на управление рисками

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

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

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

Оптимистичный план проекта (обозначен серым) показывает более раннюю дату поставки, чем было запланировано (серый + белый) проектным планом. Разница между этими датами – ваш резерв времени. Установив резерв бюджета и резерв времени, равным подверженности этим рискам, вы закладываете резерв, примерно достаточный для сдерживания ваших рисков.

Затраты на ослабление риска

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

На двух следующих графиках мы показываем, как высшее руководство ДМА могло оценить стоимость строительства туннелей двойного назначения, чтобы ослабить риск от опоздания сдачи программного обеспечения. Первый рисунок показывает план проекта без ослабления риска:

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

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

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

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

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

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

Показатели наступления и мониторинг рисков

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

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

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

За каждым выкатившимся мячом последует бегущий ребенок.

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

Ваш выбор показателя события риска требует тщательной оценки быстроты реакции и затрат на срабатывание ложно-позитивных сигналов.

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

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

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

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

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

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

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

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

Замечание по поводу обнародования перечня рисков

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

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