Здесь показано воздействие текучести кадров на одно— и двухгодичные проекты, исходя из среднеотраслевых данных о текучести.
У вас, скорее всего, должны быть приличные собственные данные по этому риску, поэтому стоит заменить ими наши. Инструкции по замене есть на нашем сайте «RISKOLOGY». Чтобы произвести замену вам нужно иметь следующие данные:
• средний процент текучести технического персонала в вашей компании
• ваша собственная наилучшая оценка общих потерь времени при найме для каждой замены
Мы определяем общие потери времени как число месяцев, которое потребуется типичному новичку на достижение того же уровня производительности, который был у замененного им работника. Обычно это время составляет от 2 месяцев на самых простых позициях в IT-отделах до 24 месяцев для компании, производящей очень сложные приложения. Очевидно, что длина этого периода зависит от того, насколько сложна область и насколько она необычна (насколько отличается от опыта и навыков, наличие которых можно ожидать от типичного новичка).
Выдвижение разумной оценки общих потерь времени на замену может быть трудной задачей, но любая хорошо продуманная цифра, выбранная вами, намного лучше, чем 0, до сих пор принимавшийся по умолчанию в гипотезах по управлению проектами.
Главный риск № 4: Нарушение спецификаций
Четвертый главный риск — нарушение спецификаций — несколько иного рода, чем остальные. Он скорее дискретный, чем непрерывный, бинарный по своему воздействию (другими словами, он либо реализуется, либо не реализуется, но не оказывает какого-то неполного воздействия в той или иной степени), если же он реализуется, то это почти всегда фатально. Он не замедляет ваш проект, а губит его.Нарушение спецификаций относится к краху процесса переговоров по установлению требований, которые идут в начале любого проекта. Вы могли бы подумать, что это сравнительно легко отследить, а потому очень легко этому противодействовать: если стороны не могут согласиться по поводу того, какой продукт нужно создать, то можно закрыть проект на ранней стадии, собрать свои вещички и отправиться восвояси без особых потерь.
К несчастью, так редко бывает. Люди обязаны прийти к соглашению. Они обязаны сотрудничать. Когда существует глубокий конфликт, не позволяющий им это сделать, то часто результат маскируют. Проект продолжают с неправильными, двусмысленными целями, которые не радуют никого, но с которыми обе стороны готовы мириться, по крайней мере, до поры.
Пусть, например, конфликт возник по поводу того, кто из участников проекта должен управлять определенной ключевой порцией данных. Спецификации искусственно избегают определения того, где будут находиться данные, какие разрешения требуются для их изменения, какие сотрудники отслеживают эти данные, частью какого архива они должны стать, когда и как их могут замещать и т.д. Люди ворчат по поводу спецификаций, поскольку они не очень-то ясны. Но сохраняется то преимущество, что там не содержится ничего явно неприемлемого для какой-то из сторон. Проект переходит (или кажется переходящим) на стадию внутреннего конструирования и внедрения.
Замаскированная проблема уходит на время, но не навсегда. Хотя возможно описать (специфицировать) продукт двусмысленно, но невозможно создать продукт неоднозначным. В итоге приходится столкнуться с отложенными проблемами, и конфликт разгорается вновь. В худшем случае это происходит на очень поздней стадии проекта, когда потрачены почти все (или совсем все) отведенные на проект ресурсы (деньги и время). Проект очень уязвим в этой стадии, и отказ любой из сторон поддерживать его может привести к быстрому прекращению. Проект успешно уничтожен, без необходимости кому-то признаваться в том, что реальной проблемой было недостаточное согласование.
Нарушение спецификаций проявляется и по-другому. Например, в том, что гуру менеджмента Питер Кин (Peter Keen) называет контр-осуществлением, когда недовольные участники проекта перегружают проект все большим и большим количеством функций. Функции A-F используют для оправдания проекта. Но потом те, кто кажется энтузиастами-сторонниками проекта, добавляют функции G-Z. С таким объемом добавленных функций нет надежды на выгоду, превосходящую затраты. Такого рода «заваливание» обычно происходит в конце работы по анализу и приводит к невозможности договоренности по спецификациям.
Около седьмой части всех проектов в нашей базе данных были прекращены без поставки какого бы то ни было продукта. У других исследователей есть другие оценки доли прекращенных проектов, но большинство попадают в диапазон 10-15%. Мы взяли среднее значение от этого процентного диапазона прекращения проектов и рассматриваем его как фиксированный риск нарушения спецификаций. Для простоты мы предположили, что нарушение спецификаций — единственная причина прекращения проекта. (Возможно, вы сумеете найти где-то проект, прекращенный по причинам, не имеющим ничего общего с конфликтом сторон, но все же постарайтесь убедиться, что заявленная причина не является просто маскировкой глубинного отсутствия согласия между сторонами).
Проявление этого главного риска также уникально в своем роде. Мы предлагаем приписывать этот риск каждому новому проекту, пока не происходит четкого прекращения прений по поводу спецификаций. После чего риск можно убрать.
Для рассмотрения проблемы неоднозначности, используемой для сокрытия разногласий, определим прекращение прений по поводу спецификаций как то, что все стороны подписались под входными и выходными граничными условиями проекта и определениями данных, вплоть до данных элементарного уровня из всех входящих и исходящих потоков данных.
<…>
ными или функциям для создания данных. Хотя соглашение по потокам данных может быть только частью требуемого согласования, но это — ключевая часть. Поскольку описания данных менее склонны к неоднозначности, чем описания функций, мы смело заключаем, что отказ от претензий по входящим и исходящим потокам данных является хорошим показателем согласия. Когда такое согласие достигнуто, риск прекращения следует исключить из рассмотрения.
В этом есть некий псевдонаучный момент, который нельзя обойти вниманием. Мы проигнорировали дополнительные причины прекращения проекта и создали свой симулятор «RISKOLOGY» таким образом, что он вынуждает вас столкнуться с возможностью прекращения проекта, пока не пройдено контрольное событие, обозначающее окончание угрозы, после чего предполагается нулевой риск прекращения проекта. Это — весьма грубый подход к деликатному предмету прекращения проектов, оправданный лишь тем, что очень высока доля проектов, в конце концов прекращенных, для которых оказалось невозможным достичь соглашения, необходимого для наступления данного контрольного события.
Главный риск №5: Низкая производительность
В литературе есть множество свидетельств наличия существенных различий в производительности между группами разработчиков. Различия между командами проектов в целом несколько сглажены и всегда меньше, чем индивидуальные различия. Более того, некоторые различия индивидуальной производительности возникают из-за того или иного из четырех главных рисков, о которых уже шла речь. После устранения воздействия других рисков и распространения индивидуальных различий на команды мы видим следующий результат вариации командной производительности (см. рисунок ниже).Этот фактор, как правило, сбалансирован: по сути, одинакова вероятность как позитивных, так и негативных изменений производительности.
Опасно использовать наши данные для очень малых команд, поскольку индивидуальные различия там могут не сгладиться. Например, команда из одного человека подвержена куда большему воздействию низкой или высокой производительности.
Сбалансированный риск, вроде низкой или высокой производительности, просто вносит шум в процесс. Он расширяет диапазон неопределенности без сдвига среднего ожидаемого показателя, в каком бы то ни было направлении.
Совокупное воздействие главных рисков
Моделирование требует нескольких параметров проекта и дает возможность заменить любой (или все) из главных рисков вашими собственными данными, а затем просчитывает варианты проекта, чтобы определить, какую продолжительность проекта следует ожидать. Данный профиль является результатом 500 отдельных прогонов, даты завершения которых сгруппированы в дискретные диапазоны. Для проекта (названного здесь Amalfi), где N — примерно 26 месяцев, без замещений, результаты моделирования с помощью «RISKOLOGY» похожи на цифры, с которыми вы сталкивались в конце главы 12:
Покажем здесь, как вы могли бы интерпретировать и объяснить результат, если бы таким был ваш проект существует некоторая ненулевая вероятность завершения проекта в период между 26-м месяцем и 27-м месяцем. Значительно вероятнее, однако, что вы будете готовы между 32-м и 34-м месяцами. С 75%-ной достоверностью можно назначить сроком сдачи 38-й месяц. Около 15% прогонов заканчивается прекращением проекта. Это — честная оценка риска прекращения проекта, с точки зрения взгляда на проект с начальной его даты, но за шесть месяцев действия проекта должно стать возможным оценить риск прекращения точнее и, быть может, снять его.
Главные риски как показатель полноты выполнения управления рисками
Главные риски можно также использовать для оценки того, был ли процесс управления рисками осуществлен разумно. Например, если вы представили пять главных рисков, но использовали данные, отличные от наших, вы можете быть достаточно уверены, что осуществили управление рисками, причем осуществили его разумно. Но мы с большим недоверием относимся к проектам, претендующим на управление рисками, когда они не принимали во внимание эти пять главных рисков.
Глава 14
Уточненный процесс обнаружения рисков
Вам следует беспокоиться не только о главных рисках. Может быть немало рисков, свойственных именно вашему проекту, которые нужно учесть в вашем уравнении риска. Например, может быть ключевой исполнитель, чей уход станет роковым для проекта, важный пользователь, который может решить идти своим путем или поставщик, чья необязательность может иметь ужасные последствия.
Как только вы обнаружили и количественно оценили эти риски, ими можно управлять, как и любыми другими. Но выявить их может быть нелегко. Культура наших организаций иногда не позволяет говорить о самых тревожащих рисках. Мы ведем себя, как самые дикие племена, которые пытаются не подпустить к себе дьявола тем, что отказываются произносить его имя. Хранить молчание о риске — это не способ избавиться от него. Например, при подготовке проекта запуска Ariane 5[24], никто не говорил, что есть риск ошибок, связанных с тем, что компилятор не делает проверку граничных значений, и это поставит под угрозу запускаемый спутник. Но это, тем не менее, случилось и привело к полному провалу запуска.
Обычным при обнаружении риска бывает чье-то высказывание «Знаете, если <нечто> случится, мы сильно влипнем…». Обычно говорящий уже какое-то время знал о риске и, возможно, даже самостоятельно его оценил в какой-то такой форме: «Пожалуй, я всерьез займусь своим резюме, если будет похоже, что <это нечто> может случиться». Когда все управление рисками в данном проекте происходит в голове единственного встревоженного индивида, то это говорит о сбое в коммуникации. А конкретнее, это означает, как правило, что существует некое препятствие, перекрывающее потоки важной информации.
У них были те же самые причины, которые не дают людям озвучивать риски в любых других компаниях. Это принимает форму неписаных правил, встроенных в корпоративную культуру:
1. Не имей привычки думать о неприятностях.
2. Не поднимай проблему, если у тебя нет готового решения.
3. Не говори, что нечто является проблемой, если не можешь доказать, что это так.
4. Не будь помехой.
5. Не озвучивай проблему, если не хочешь, чтобы на тебя возложили ответственность за ее немедленное решение.
<……>
суждаются открыто, то их никогда и не приспосабливают к изменяющимся обстоятельствам.
Нам всем велят на работе принимать менталитет «будет сделано». И в этом загвоздка. Назвать риск по имени — значит оказаться в парадигме «не могу сделать». Обнаружение риска находится в глубоком противоречии с этим фундаментальным аспектом наших организаций.
Поскольку подавление стимулов является достаточно мощным, нужен открытый, установленный и хорошо понимаемый процесс, обеспечивающий возможность высказываться. Нужен механизм, способ полного вовлечения всех и каждого при гарантированной безопасности. В основе этого механизма должны быть временные правила, позволяющие, по крайней мере, в данный момент, не повиноваться неписаным правилам. Если ваш начальник публично просит вас исполнить «роль адвоката дьявола для этой идеи», вы явно освобождены от диктата мышления «будет сделано». Это позволяет вам наслаждаться негативным мышлением типа «что если». Именно этого должен достичь наш уточненный процесс обнаружения рисков.
Когда происходит реальная катастрофа, эти три этапа проходят в противоположном порядке, двигаясь от причины по раскручивающемуся сценарию к окончательному результату. Но слишком жутко иметь с ними дело в таком порядке. Отработка «задом наперед» пугает меньше. Она позволяет сначала сконцентрировать внимание на возможном кошмарном результате, совершенно изолированно, отдельно от причины. Но даже при этом людям нелегко высказывать такие опасения:
ТРЛ: В прошлом году мне нужно было сделать операцию на колене при полном обезболивании. Накануне моей отправки в больницу жена спросила, беспокоюсь ли я из-за этой операции. Я быстро ответил, что ни капельки, что тысячи таких операций проходят без всяких проблем. Немного позже я признался ей, что есть у меня какой-то небольшой, как мне казалось, иррациональный страх. Я боялся, что хирург прооперирует другую ногу. Жена посоветовала сказать врачу об этом. На следующее утро меня подготовили к операции, рядом была жена. Хирург вошел рассказать о послеоперационных процедурах. Жена смотрела на меня, удивленно вскинув брови. Я молчал. Прямо перед тем, как уйти готовиться к операции, хирург взял маркер и написал «Да» прямо над коленом, которое предстояло оперировать. Жена улыбнулась, а за ней и все мы.
Механизм должен поощрять людей делиться своими страхами. Если бы доктор прямо спросил Тима в предоперационной палате, чего он особенно боится, проблема была бы тут же выложена. Механизм должен включать просьбу ко всем участникам поделиться своими худшими опасениями. Иногда помогает возможность сказать (как в рассказе Тима), что страх иррационален.
Дальнейший процесс состоит в том, чтобы дедуктивным методом выявить, как мог бы реализоваться этот кошмар. Вся штука в том, чтобы пройти все три этапа более или менее механически, без всяких упреков и обвинений. «У меня есть такой кошмар, вот — сценарий, который мог бы к нему привести, а запустить этот сценарий могла бы такая штука…» Voila, один риск найден.
Чтобы преодолеть табу неписаных правил, процедура обнаружения рисков должна быть изложена в письменном виде и роздана всем перед началом мероприятия. Вы не можете нежданно-негаданно обрушиться на людей и рассчитывать, что они пренебрегут неписаными правилами без надежной, формальной защиты.
Процесс обнаружения рисков не должен состояться лишь один раз в начале проекта. Он должен стать постоянно действующей частью работы над проектом. На каждом совещании по выявлению рисков должен формально провозглашаться подход, которому будут следовать, чтобы неписаные правила были эффективно приостановлены.
Три этапа обнаружения рисков обычно проходят одновременно на одном и том же совещании. Но методы уникальны для каждого из этапов, поэтому стоит рассмотреть по очереди каждый.
1. Ставьте вопрос в явном виде в терминах ночного кошмара: почему-то это также помогает преодолеть действие неписаных правил, независимо от того, насколько присуще было корпоративной культуре позитивное мышление, ведь по-прежнему считается вполне нормальным вскочить ночью из-за жутких мыслей. Спросите людей, каковы их худшие опасения относительно проекта. Когда они просыпаются в холодном поту от ужаса за проект, что пугает их?
2. Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года. Представьте, что это подглядывание в будущее свидетельствует о бедствии, постигшем проект, но что это за беда? Или, представьте, что ваша компания попала в «колонку идиотов» в журнале The Wall Street Journal, которая располагается посредине первой страницы, а причиной стали бы ужасы, которые творятся с этим проектом. Теперь задайтесь вопросом: «Как это могло случиться?»
3. Опишите противоположные виды на будущее: Попросите людей описать свои самые радужные мечты относительно проекта, а затем обсудите прямо противоположную версию.
4. Спрашивайте о провале, в котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?
5. Спрашивайте о провале, в котором есть конкретные виновники: Спросите людей: «Как бы мог проект провалиться по нашей собственной вине? по вине пользователя? по вине руководства? по вашей вине?» (Это работает, если только убедиться, что все повлечены в действие).
6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.
Мозговые штурмы стремительны и яростны, поэтому нужно заранее сделать некоторые приготовления, чтобы не пропустить ни одного предположения. Убедитесь, что обязанность следить за этим возложена не на фасилитатора.
Стоит приписать хотя бы предположительную вероятность этим сценариям. Очевидно, что наиболее невероятные сценарии менее ценны, поскольку не оправдывают усилий по дальнейшему рассмотрению. Но бдительно относитесь к низким вероятностям, которые группа может приписывать определенным сценариям, ведь кто-то предложил их и для этого человека, возможно, это не было вопросом, которым можно пренебречь.
Вместо того чтобы проводить анализ вероятности на месте, можно отложить его для проведения потом в подгруппах. Это даст некоторые эмпирические свидетельства для определения того, стоит или не стоит беспокоиться по поводу данного сценария.
Анализ основных причин сложнее, чем кажется. Причина этого не только во влиянии неписаных правил, но и в сложности понятия «основная» (определении того, достаточно ли глубока причина). Этот процесс успешнее осуществляет группа, чем отдельный индивидуум. За полезными подсказками по проведению сессий анализа основных причин обратитесь к соответствующему разделу ссылок в конце книги.
• жизненный цикл, развивающийся по спирали
• систему показателей (конкретнее, СОСОМО II)
• управление рисками
• «теорию W» группового взаимодействия
Это — способ руководства IT-проектами в свете тех проблем, которые обычно преследуют каждое такое предприятие.
С уникальным подходом Боэма к разработке программного обеспечения стоит познакомиться по причинам, выходящим далеко за пределы данной книги. Однако мы упоминаем об этом здесь, чтобы описать один из незначительных аспектов взаимовыгодной стратегии, бросающий полезный свет на обнаружение рисков.
При взаимовыгодной стратегии проект строится на честном обязательстве отыскать всех участников проекта и узнать у каждого так называемые выигрышные условия, которые, с их точки зрения, обеспечивали бы успех проекта. Согласно этой методологии, требования определены как набор условий выигрыша. Ничто нельзя считать требованием, если никто не идентифицирует его как одно из своих условий выигрыша. Иногда условия выигрыша конфликтуют, особенно по мере роста числа участников проекта. Условие выигрыша, выраженное одной из сторон, может затруднить или сделать невозможным достижение выигрышных условий, выраженных другими сторонами. При взаимовыгодной стратегии любая пара выигрышных условий, между которыми существует конфликт или напряженность, представляет собой риск.
Вы можете суметь использовать модель Боэма для обнаружения рисков, которые иначе было бы невозможно выявить. Очень много рисков, затрагивающих IT-проекты, возникли непосредственно из-за конфликтующих условий выгоды для различных участников, а использование модели Боэма ведет прямо к сути этой основной проблемы. Если даже ваш проект не выполняет формального и полного выяснения выигрышных условий, вы можете сами поразмышлять над условиями выигрыша в процессе определения рисков. Рассматривайте это как одну из уловок, которыми вы пользуетесь. Спросите участников: «Можете ли вы придумать очевидное условие выигрыша для данного проекта, которое находилось бы в конфликте с чьей-то еще выигрышной стратегией?» Каждый выявленный конфликт — это потенциальный риск.
Как только вы обнаружили и количественно оценили эти риски, ими можно управлять, как и любыми другими. Но выявить их может быть нелегко. Культура наших организаций иногда не позволяет говорить о самых тревожащих рисках. Мы ведем себя, как самые дикие племена, которые пытаются не подпустить к себе дьявола тем, что отказываются произносить его имя. Хранить молчание о риске — это не способ избавиться от него. Например, при подготовке проекта запуска Ariane 5[24], никто не говорил, что есть риск ошибок, связанных с тем, что компилятор не делает проверку граничных значений, и это поставит под угрозу запускаемый спутник. Но это, тем не менее, случилось и привело к полному провалу запуска.
Обычным при обнаружении риска бывает чье-то высказывание «Знаете, если <нечто> случится, мы сильно влипнем…». Обычно говорящий уже какое-то время знал о риске и, возможно, даже самостоятельно его оценил в какой-то такой форме: «Пожалуй, я всерьез займусь своим резюме, если будет похоже, что <это нечто> может случиться». Когда все управление рисками в данном проекте происходит в голове единственного встревоженного индивида, то это говорит о сбое в коммуникации. А конкретнее, это означает, как правило, что существует некое препятствие, перекрывающее потоки важной информации.
Выявление препятствий
Рассмотрим эти факторы в реальном контексте: утром 28 января 1986 гола взорвался космический корабль Challenger, что повлекло ужасающие потери человеческих жизней, материальных средств и национального престижа. Расследование показало, что резкое похолодание непосредственно перед пуском вызвало выпадение из заданного температурного режима всей первой ступени и ее компонентов. Система была предназначена для работы при температуре выше нуля, а на деле оказалось куда холоднее. Никто из персонала не думал о кольцевых уплотнителях твердотопливных ускорителей, которые и вызвали беду, но многие люди знали, что компоненты системы чувствительны к низкой температуре, и нельзя рассчитывать, что они смогут нормально функционировать при температуре ниже нуля. Почему они молчали?У них были те же самые причины, которые не дают людям озвучивать риски в любых других компаниях. Это принимает форму неписаных правил, встроенных в корпоративную культуру:
1. Не имей привычки думать о неприятностях.
2. Не поднимай проблему, если у тебя нет готового решения.
3. Не говори, что нечто является проблемой, если не можешь доказать, что это так.
4. Не будь помехой.
5. Не озвучивай проблему, если не хочешь, чтобы на тебя возложили ответственность за ее немедленное решение.
<……>
суждаются открыто, то их никогда и не приспосабливают к изменяющимся обстоятельствам.
Нам всем велят на работе принимать менталитет «будет сделано». И в этом загвоздка. Назвать риск по имени — значит оказаться в парадигме «не могу сделать». Обнаружение риска находится в глубоком противоречии с этим фундаментальным аспектом наших организаций.
Поскольку подавление стимулов является достаточно мощным, нужен открытый, установленный и хорошо понимаемый процесс, обеспечивающий возможность высказываться. Нужен механизм, способ полного вовлечения всех и каждого при гарантированной безопасности. В основе этого механизма должны быть временные правила, позволяющие, по крайней мере, в данный момент, не повиноваться неписаным правилам. Если ваш начальник публично просит вас исполнить «роль адвоката дьявола для этой идеи», вы явно освобождены от диктата мышления «будет сделано». Это позволяет вам наслаждаться негативным мышлением типа «что если». Именно этого должен достичь наш уточненный процесс обнаружения рисков.
Уточненный процесс
Предлагаемый нами уточненный процесс для идентификации рисков включает три этапа продвижения от обнаруженного риска назад, к причинам его возникновения:Когда происходит реальная катастрофа, эти три этапа проходят в противоположном порядке, двигаясь от причины по раскручивающемуся сценарию к окончательному результату. Но слишком жутко иметь с ними дело в таком порядке. Отработка «задом наперед» пугает меньше. Она позволяет сначала сконцентрировать внимание на возможном кошмарном результате, совершенно изолированно, отдельно от причины. Но даже при этом людям нелегко высказывать такие опасения:
ТРЛ: В прошлом году мне нужно было сделать операцию на колене при полном обезболивании. Накануне моей отправки в больницу жена спросила, беспокоюсь ли я из-за этой операции. Я быстро ответил, что ни капельки, что тысячи таких операций проходят без всяких проблем. Немного позже я признался ей, что есть у меня какой-то небольшой, как мне казалось, иррациональный страх. Я боялся, что хирург прооперирует другую ногу. Жена посоветовала сказать врачу об этом. На следующее утро меня подготовили к операции, рядом была жена. Хирург вошел рассказать о послеоперационных процедурах. Жена смотрела на меня, удивленно вскинув брови. Я молчал. Прямо перед тем, как уйти готовиться к операции, хирург взял маркер и написал «Да» прямо над коленом, которое предстояло оперировать. Жена улыбнулась, а за ней и все мы.
Механизм должен поощрять людей делиться своими страхами. Если бы доктор прямо спросил Тима в предоперационной палате, чего он особенно боится, проблема была бы тут же выложена. Механизм должен включать просьбу ко всем участникам поделиться своими худшими опасениями. Иногда помогает возможность сказать (как в рассказе Тима), что страх иррационален.
Дальнейший процесс состоит в том, чтобы дедуктивным методом выявить, как мог бы реализоваться этот кошмар. Вся штука в том, чтобы пройти все три этапа более или менее механически, без всяких упреков и обвинений. «У меня есть такой кошмар, вот — сценарий, который мог бы к нему привести, а запустить этот сценарий могла бы такая штука…» Voila, один риск найден.
Чтобы преодолеть табу неписаных правил, процедура обнаружения рисков должна быть изложена в письменном виде и роздана всем перед началом мероприятия. Вы не можете нежданно-негаданно обрушиться на людей и рассчитывать, что они пренебрегут неписаными правилами без надежной, формальной защиты.
Процесс обнаружения рисков не должен состояться лишь один раз в начале проекта. Он должен стать постоянно действующей частью работы над проектом. На каждом совещании по выявлению рисков должен формально провозглашаться подход, которому будут следовать, чтобы неписаные правила были эффективно приостановлены.
Три этапа обнаружения рисков обычно проходят одновременно на одном и том же совещании. Но методы уникальны для каждого из этапов, поэтому стоит рассмотреть по очереди каждый.
Этап 1: мозговой штурм по выявлению катастроф
Мозговой штурм — это групповое творчество. Идея состоит в использовании групповой динамики для отыскания обходных путей преодоления привычного мышления и возникновения новых свежих мыслей. Мозговой штурм по выявлению катастроф имеет несколько иной характер, хотя и здесь полезны некоторые методы классического мозгового штурма. В поисках хорошего описания этих методов рекомендуем заглянуть в раздел об использовании мозгового штурма (см. ссылки в конце книги). Мозговой штурм использует хитрости, мелкие уловки для помощи группе в преодолении неизбежной зажатости и тупиков. Даже названия, перечисленные в ссылках, предлагают дюжины этих хитростей, каждая из которых полезна для того, чтобы заставить группу придумать полезные ночные кошмары. Ниже представлены несколько хитростей, присущих только мозговому штурму в поисках катастроф:1. Ставьте вопрос в явном виде в терминах ночного кошмара: почему-то это также помогает преодолеть действие неписаных правил, независимо от того, насколько присуще было корпоративной культуре позитивное мышление, ведь по-прежнему считается вполне нормальным вскочить ночью из-за жутких мыслей. Спросите людей, каковы их худшие опасения относительно проекта. Когда они просыпаются в холодном поту от ужаса за проект, что пугает их?
2. Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года. Представьте, что это подглядывание в будущее свидетельствует о бедствии, постигшем проект, но что это за беда? Или, представьте, что ваша компания попала в «колонку идиотов» в журнале The Wall Street Journal, которая располагается посредине первой страницы, а причиной стали бы ужасы, которые творятся с этим проектом. Теперь задайтесь вопросом: «Как это могло случиться?»
3. Опишите противоположные виды на будущее: Попросите людей описать свои самые радужные мечты относительно проекта, а затем обсудите прямо противоположную версию.
4. Спрашивайте о провале, в котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?
5. Спрашивайте о провале, в котором есть конкретные виновники: Спросите людей: «Как бы мог проект провалиться по нашей собственной вине? по вине пользователя? по вине руководства? по вашей вине?» (Это работает, если только убедиться, что все повлечены в действие).
6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.
Мозговые штурмы стремительны и яростны, поэтому нужно заранее сделать некоторые приготовления, чтобы не пропустить ни одного предположения. Убедитесь, что обязанность следить за этим возложена не на фасилитатора.
Этап 2: построение сценария
Теперь вернемся к предполагаемым катастрофам и поочередно будем рассматривать их и воображать сценарии, которые могли бы привести к каждому из результатов. Придумывание сценариев может быть совершенно механическим, но вопрос о вине может повиснуть в воздухе, поэтому можно ожидать здесь некоторой напряженности. Здесь тоже нужно заранее продумать механизм улавливания и сохранения всей информации и использовать его, чтобы внезапно усилившаяся напряженность не помогла упустить те моменты, которые требуют самого пристального внимания.Стоит приписать хотя бы предположительную вероятность этим сценариям. Очевидно, что наиболее невероятные сценарии менее ценны, поскольку не оправдывают усилий по дальнейшему рассмотрению. Но бдительно относитесь к низким вероятностям, которые группа может приписывать определенным сценариям, ведь кто-то предложил их и для этого человека, возможно, это не было вопросом, которым можно пренебречь.
Вместо того чтобы проводить анализ вероятности на месте, можно отложить его для проведения потом в подгруппах. Это даст некоторые эмпирические свидетельства для определения того, стоит или не стоит беспокоиться по поводу данного сценария.
Этап 3: анализ основных причин
Имея перед собой сценарии, все могут вместе определить потенциальную основную причину. Это гораздо легче сделать до того, как сценарий начал по-настоящему реализовываться. Когда сценарий воспринимается всего лишь как абстракция, то есть какая-то ерунда, которая могла бы приключиться, можно рассматривать причины без поиска виноватых: «Ну, не могу вообразить, чтобы это случилось, разве что какой-то идиот украдет часть персонала, чтобы использовать как „пожарную команду“, в другом месте». Такое достаточно легко сказать, пока на самом деле катастрофа не произошла, даже если потенциальный идиот находится вместе с нами в этой комнате. Ваши риски являются основными причинами сценариев, которые могут привести к катастрофическим результатам.Анализ основных причин сложнее, чем кажется. Причина этого не только во влиянии неписаных правил, но и в сложности понятия «основная» (определении того, достаточно ли глубока причина). Этот процесс успешнее осуществляет группа, чем отдельный индивидуум. За полезными подсказками по проведению сессий анализа основных причин обратитесь к соответствующему разделу ссылок в конце книги.
Взаимовыгодная альтернатива
Взаимовыгодная спиральная модель процессов[25] Барри Боэма (Barry Boehmi) соединяет многое из достижений человеческого разума, сделанных до сегодняшнего дня. (См. ссылки в конце книги или сайт RISKOLOGY). Она объединяет:• жизненный цикл, развивающийся по спирали
• систему показателей (конкретнее, СОСОМО II)
• управление рисками
• «теорию W» группового взаимодействия
Это — способ руководства IT-проектами в свете тех проблем, которые обычно преследуют каждое такое предприятие.
С уникальным подходом Боэма к разработке программного обеспечения стоит познакомиться по причинам, выходящим далеко за пределы данной книги. Однако мы упоминаем об этом здесь, чтобы описать один из незначительных аспектов взаимовыгодной стратегии, бросающий полезный свет на обнаружение рисков.
При взаимовыгодной стратегии проект строится на честном обязательстве отыскать всех участников проекта и узнать у каждого так называемые выигрышные условия, которые, с их точки зрения, обеспечивали бы успех проекта. Согласно этой методологии, требования определены как набор условий выигрыша. Ничто нельзя считать требованием, если никто не идентифицирует его как одно из своих условий выигрыша. Иногда условия выигрыша конфликтуют, особенно по мере роста числа участников проекта. Условие выигрыша, выраженное одной из сторон, может затруднить или сделать невозможным достижение выигрышных условий, выраженных другими сторонами. При взаимовыгодной стратегии любая пара выигрышных условий, между которыми существует конфликт или напряженность, представляет собой риск.
Вы можете суметь использовать модель Боэма для обнаружения рисков, которые иначе было бы невозможно выявить. Очень много рисков, затрагивающих IT-проекты, возникли непосредственно из-за конфликтующих условий выгоды для различных участников, а использование модели Боэма ведет прямо к сути этой основной проблемы. Если даже ваш проект не выполняет формального и полного выяснения выигрышных условий, вы можете сами поразмышлять над условиями выигрыша в процессе определения рисков. Рассматривайте это как одну из уловок, которыми вы пользуетесь. Спросите участников: «Можете ли вы придумать очевидное условие выигрыша для данного проекта, которое находилось бы в конфликте с чьей-то еще выигрышной стратегией?» Каждый выявленный конфликт — это потенциальный риск.