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