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

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

Обычным при обнаружении риска бывает чье-то высказывание «Знаете, если <нечто> случится, мы сильно влипнем…». Обычно говорящий уже какое-то время знал о риске и, возможно, даже самостоятельно его оценил в какой-то такой форме: «Пожалуй, я всерьез займусь своим резюме, если будет похоже, что <это нечто> может случиться». Когда все управление рисками в данном проекте происходит в голове единственного встревоженного индивида, то это говорит о сбое в коммуникации. А конкретнее, это означает, как правило, что существует некое препятствие, перекрывающее потоки важной информации.

Рассмотрим эти факторы в реальном контексте: утром 28 января 1986 гола взорвался космический корабль Challenger, что повлекло ужасающие потери человеческих жизней, материальных средств и национального престижа. Расследование показало, что резкое похолодание непосредственно перед пуском вызвало выпадение из заданного температурного режима всей первой ступени и ее компонентов. Система была предназначена для работы при температуре выше нуля, а на деле оказалось куда холоднее. Никто из персонала не думал о кольцевых уплотнителях твердотопливных ускорителей, которые и вызвали беду, но многие люди знали, что компоненты системы чувствительны к низкой температуре, и нельзя рассчитывать, что они смогут нормально функционировать при температуре ниже нуля. Почему они молчали?

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

1. Не имей привычки думать о неприятностях.

2. Не поднимай проблему, если у тебя нет готового решения.

3. Не говори, что нечто является проблемой, если не можешь доказать, что это так.

4. Не будь помехой.

5. Не озвучивай проблему, если не хочешь, чтобы на тебя возложили ответственность за ее немедленное решение.

<……>

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

Нам всем велят на работе принимать менталитет «будет сделано». И в этом загвоздка. Назвать риск по имени – значит оказаться в парадигме «не могу сделать». Обнаружение риска находится в глубоком противоречии с этим фундаментальным аспектом наших организаций.

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

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

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

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

Дальнейший процесс состоит в том, чтобы дедуктивным методом выявить, как мог бы реализоваться этот кошмар. Вся штука в том, чтобы пройти все три этапа более или менее механически, без всяких упреков и обвинений. «У меня есть такой кошмар, вот – сценарий, который мог бы к нему привести, а запустить этот сценарий могла бы такая штука…» Voila, один риск найден.

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

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

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

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

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

2. Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года. Представьте, что это подглядывание в будущее свидетельствует о бедствии, постигшем проект, но что это за беда? Или, представьте, что ваша компания попала в «колонку идиотов» в журнале The Wall Street Journal, которая располагается посредине первой страницы, а причиной стали бы ужасы, которые творятся с этим проектом. Теперь задайтесь вопросом: «Как это могло случиться?»

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

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

5. Спрашивайте о провале, в котором есть конкретные виновники: Спросите людей: «Как бы мог проект провалиться по нашей собственной вине? по вине пользователя? по вине руководства? по вашей вине?» (Это работает, если только убедиться, что все повлечены в действие).

6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.

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

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

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

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

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

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

Взаимовыгодная спиральная модель процессов Барри Боэма (Barry Boehmi) соединяет многое из достижений человеческого разума, сделанных до сегодняшнего дня. (См. ссылки в конце книги или сайт RISKOLOGY). Она объединяет:

• жизненный цикл, развивающийся по спирали

• систему показателей (конкретнее, СОСОМО II)

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

• «теорию W» группового взаимодействия

Это – способ руководства IT-проектами в свете тех проблем, которые обычно преследуют каждое такое предприятие.

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

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

Вы можете суметь использовать модель Боэма для обнаружения рисков, которые иначе было бы невозможно выявить. Очень много рисков, затрагивающих IT-проекты, возникли непосредственно из-за конфликтующих условий выгоды для различных участников, а использование модели Боэма ведет прямо к сути этой основной проблемы. Если даже ваш проект не выполняет формального и полного выяснения выигрышных условий, вы можете сами поразмышлять над условиями выигрыша в процессе определения рисков. Рассматривайте это как одну из уловок, которыми вы пользуетесь. Спросите участников: «Можете ли вы придумать очевидное условие выигрыша для данного проекта, которое находилось бы в конфликте с чьей-то еще выигрышной стратегией?» Каждый выявленный конфликт – это потенциальный риск.