Вальсируя с медведями
Шрифт:
Управление рисками и опасения за свой проект – это не одно и то же.
Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.
Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75% [18] .
18
Т.е.
Об этом стоит напомнить, поскольку некоторые компании имеют почти патологическую склонность превращать увертывание от рисков в цель деятельности. В таких компаниях управление рисками является тщетным, все усилия по управлению рисками выглядят не более чем новыми затратами, которые нужно сократить.
ТРЛ: Мой клиент, соблазненный презентационными слайдами вендора, будто песней сирен, согласился купить последнюю версию пакета программного обеспечения. Честно говоря, эта версия еще не была выведена на рынок, но покупатель получил заверения, что все уже готово. Покупатель согласился нанять авторизованного вендором подрядчика для осуществления проекта по установке нового приложения в течение ближайших месяцев, к концу мая.
Подрядчик принял кое-какие меры по управлению рисками. Его представитель составил перечень рисков из двенадцати пунктов. Все они касались возможных нарушений соглашения со стороны покупателя (покупатель мог задержать проект слишком медленным принятием решений, покупатель мог не обеспечить подходящее рабочее пространство для подрядчика и т.п.).
На этом этапе чтения вы уже, видимо, предугадали дальнейшее развитие событий: риск, который на деле погубил проект (программное обеспечение не было вовремя получено от вендора, что сделало нереальной сдачу в мае), не был даже упомянут в перечне рисков. Никто ни разу не назвал этот риск, пока дело не дошло до того, что он перестал быть риском, а превратился в реальную проблему. Положение усугублялось тем, что программное обеспечение было на критическом пути. Первая работоспособная версия программного продукта появилась значительно позднее, чем проект был прерван, и за дело взялись юристы.
Эта история привлекает внимание к сложным проблемам управления рисками в контрактованных проектах разработки. Главная опасность в этих ситуациях кроется в недоразумениях относительно того, кто какими рисками должен управлять. Клиент имеет право указать определенные риски как сферу ответственности подрядчика, и наоборот. Если вы клиент, самая безопасная позиция для вас состоит в признании того, что только риски, конкретно относящиеся к подрядчику, будут его рисками, а остальные – вашими. Поощрения и штрафные санкции в договоре распределяют риски между сторонами.
Риски подрядчика состоят из тех, что ставят под угрозу успешное завершение договора или уменьшают для него ценность завершения. Все остальное подрядчик считает чужими рисками, и потому он исключает их из собственного управления рисками. Это означает, что этими рисками должны управлять вы как клиент, или никто не будет ими управлять.
Часто судебные тяжбы возникают из-за того, что клиента поражает выпадение из поля зрения подрядчика некоторых важных рисков. Как правило, вся проблема – в самом договоре, где не прописана ответственность за эти риски. Обычно не бывает договоров, которые успешно возлагают всю ответственность на одну из сторон. Если вы клиент или подрядчик, рассчитывайте на то, что вам придется взять на себя какую-то долю управления рисками.
Подверженность риску – это ожидание затрат на сдерживание. Ожидание, в том смысле, в котором используется этот термин здесь – это комплексное понятие, заимствованное из теории вероятностей. Это некоторая комбинация вероятностей того, что риск наступит, и затрат, которые вы понесете в этом случае. В простейшем случае:
подверженность риску = затраты * вероятность
Таким образом, если вы определяете вероятность риска в 20%, а его наступление обойдется вам в миллион долларов, то подверженность риску составит $200000.
Можете
Если посчитать подверженность для всех рисков и создать резерв на управление рисками, равный этой сумме, то такого резерва должно хватить, чтобы покрыть затраты на наступившие риски. В итоге вам может немного не хватить в одних проектах, зато останется часть резерва в других, но в долгосрочном плане ваш резерв будет в целом правильным.
Оценка подверженности не относится к четко определенным дисциплинам. Ваши лучшие догадки относительно вероятности наступления риска могут основываться на данных по отрасли, предшествующем опыте или просто откровенной догадке. Не уклоняйтесь от этого существенного действия лишь из-за того, что любой найденный вами ответ никогда не будет стопроцентно правильным. Не так уж важно, будет ли вероятность приближающегося поезда, готового врезаться в ваш проект, 25% или 35%, важно понимание того, что возможно приближение поезда. Внесите риск в свой список и начните изучать горизонт в поисках дыма из трубы паровоза.
Пока мы рассматривали сдерживание как денежный вопрос. Возможно, вам также придется сдерживать риски в плане времени. Подверженность риску можно выразить в месяцах ожидаемой задержки. Если вероятность наступления риска составляет 20% и оно вызовет задержку в пять месяцев, ваша подверженность риску во временном исчислении составляет опоздание в 1 месяц.
При оценке рисков с точки зрения стоимости и вероятности возникновения, вам, может быть, придется столкнуться с такими рисками, которые невозможно оценить, потому что они будут стоить вам всего проекта. Это – риски-катастрофы: если они возникнут, то намертво застопорят дело. Они заставят вас либо найти полностью новый подход к продукту, либо аннулировать весь проект. Определение одного или нескольких таких рисков не упраздняет процесс управления рисками, несмотря на то, что они не могут быть должным образом оценены количественно. Риски-катастрофы представляют собой принципиально иной тип рисков, к которому требуется совершенно иной подход. Этими рисками можно управлять только посредством того, что мы назовем допущениями проекта. Чтобы продолжать свою работу, вы должны предположить, что такой риск не наступит. Если эти допущения не оправдаются, вам придется передать вопрос на более высокий уровень управления. Такие серьезные риски выходят за пределы ответственности и полномочий данного проекта. Вот несколько катастрофических рисков, с которыми мы сталкивались:
19
Сами авторы используют здесь термин showstopper, которым программисты называют устойчивую системную ошибку, исключающую возможность правильной работы прикладной программы (прим. ред.)
• Компания пускается в выполнение проекта, чтобы полностью переделать основной продукт. Руководство проекта рассчитывает, что это займет порядка 2-2,5 лет. Есть опасение, что один из конкурентов начнет выпускать такой же продукт намного раньше предполагаемого срока завершения проекта.
• Новый продукт строится на базе преобладающей на данном рынке операционной системы. Что, если эта ОС будет обновлена и данный продукт будет несовместим с новой версией?
Вы можете быть склонны отнестись к такому риску как фаталисты, говоря, что при наступлении этого риска вы пропали, и потому бессмысленно даже остерегаться его. Раз вы не можете держать такие риски под контролем, следует расслабиться и заняться тем, с чем можно надеяться справиться. В этой логике есть нечто глубоко ошибочное. Например, представьте себе, что вас повысили на две ступени иерархической лестницы. Теперь скажите, не появился у вас внезапно очень большой интерес к такому риску? Вы обнаружили, что занимаются этим риском не члены команды проекта, а люди, которые дали ему путевку в жизнь. Те, кто дали, могут и забрать обратно. Им придется решать, что делать, если какое-то из допущений проекта окажется ложным.