Вместо того чтобы проводить анализ вероятности на месте, можно отложить его для проведения потом в подгруппах. Это даст некоторые эмпирические свидетельства для определения того, стоит или не стоит беспокоиться по поводу данного сценария.
Имея перед собой сценарии, все могут вместе определить потенциальную основную причину. Это гораздо легче сделать до того, как сценарий начал по-настоящему реализовываться. Когда сценарий воспринимается всего лишь как абстракция, то есть какая-то ерунда, которая могла бы приключиться, можно рассматривать причины без поиска виноватых: «Ну, не могу вообразить, чтобы это случилось, разве что какой-то идиот украдет часть персонала, чтобы использовать как «пожарную команду», в другом месте». Такое достаточно легко сказать, пока на самом деле катастрофа не произошла, даже если потенциальный идиот находится вместе с нами в этой комнате. Ваши риски являются основными причинами сценариев, которые могут привести к катастрофическим результатам.
Анализ основных причин сложнее, чем кажется. Причина этого не только во влиянии неписаных правил, но и в сложности понятия «основная» (определении того, достаточно ли глубока причина). Этот процесс успешнее осуществляет группа, чем отдельный индивидуум. За полезными подсказками по проведению сессий анализа основных причин обратитесь к соответствующему разделу ссылок в конце книги.
Взаимовыгодная спиральная модель процессов[25] Барри Боэма (Barry Boehmi) соединяет многое из достижений человеческого разума, сделанных до сегодняшнего дня. (См. ссылки в конце книги или сайт RISKOLOGY). Она объединяет:
• жизненный цикл, развивающийся по спирали
• систему показателей (конкретнее, СОСОМО II)
• управление рисками
• «теорию W» группового взаимодействия
Это – способ руководства IT-проектами в свете тех проблем, которые обычно преследуют каждое такое предприятие.
С уникальным подходом Боэма к разработке программного обеспечения стоит познакомиться по причинам, выходящим далеко за пределы данной книги. Однако мы упоминаем об этом здесь, чтобы описать один из незначительных аспектов взаимовыгодной стратегии, бросающий полезный свет на обнаружение рисков.
При взаимовыгодной стратегии проект строится на честном обязательстве отыскать всех участников проекта и узнать у каждого так называемые выигрышные условия, которые, с их точки зрения, обеспечивали бы успех проекта. Согласно этой методологии, требования определены как набор условий выигрыша. Ничто нельзя считать требованием, если никто не идентифицирует его как одно из своих условий выигрыша. Иногда условия выигрыша конфликтуют, особенно по мере роста числа участников проекта. Условие выигрыша, выраженное одной из сторон, может затруднить или сделать невозможным достижение выигрышных условий, выраженных другими сторонами. При взаимовыгодной стратегии любая пара выигрышных условий, между которыми существует конфликт или напряженность, представляет собой риск.
Вы можете суметь использовать модель Боэма для обнаружения рисков, которые иначе было бы невозможно выявить. Очень много рисков, затрагивающих IT-проекты, возникли непосредственно из-за конфликтующих условий выгоды для различных участников, а использование модели Боэма ведет прямо к сути этой основной проблемы. Если даже ваш проект не выполняет формального и полного выяснения выигрышных условий, вы можете сами поразмышлять над условиями выигрыша в процессе определения рисков. Рассматривайте это как одну из уловок, которыми вы пользуетесь. Спросите участников: «Можете ли вы придумать очевидное условие выигрыша для данного проекта, которое находилось бы в конфликте с чьей-то еще выигрышной стратегией?» Каждый выявленный конфликт – это потенциальный риск.
Глава 15
Динамика управления рисками
Несмотря на неоднократно повторявшиеся утверждения, что управление рисками должно быть постоянной деятельностью, у вас могло все же остаться ощущение, что им по-настоящему занимаются в начале проекта, а затем (не считая эпизодического пустословия) спокойно забывают о нем до следующего проекта.
Возможно, так могли бы решать проблемы управления рисками существа, наделенные даром абсолютного предвидения, но не мы. Когда проекты проваливаются, то часто это происходит примерно на середине, поэтому именно в это период управление рисками нужно проводить особенно активно. Причины проблем почти всегда возникают еще раньше, но их осознание приходит примерно на середине проекта: на начальной стадии проекта дело кажется идущим без помех, а затем все разваливается. Эту стадию проекта можно назвать «Возмездие»: к нам возвращаются наши прошлые грехи, включая плохое планирование, пропущенные задачи, плохо построенные отношения, скрытые допущения, излишнюю надежду на везение и т.п.
В этой главе мы рассмотрим роль управления рисками в период Возмездия и далее, вплоть до конца проекта.
Вот наш краткий список мер по управлению рисками, которые нужно осуществлять в период с середины проекта и далее, до самого конца:
1. непрерывный мониторинг показателей наступления рисков в поисках такого риска из списка, который кажется готовым перейти из разряда «всего лишь скверной возможности» в разряд «реальных проблем»
2. продолжение выявления рисков
3. сбор данных для наполнения хранилища рисков (базы данных для определения количественного влияния проблем, наблюдавшихся в прошлом)
4. ежедневное отслеживание показателей завершенности (см. ниже)
Пункты 1 и 2 были рассмотрены в главах 9 и 14, и здесь мы к ним не будем возвращаться. Пункты 3 и 4 относятся к системе показателей: количественным показателям размера, целей и содержания, сложности и состояния проекта. Эти показатели и будут предметом этой и следующей глав.
Мы используем здесь термин «показатели завершенности» но отношению к определенному классу показателей состояния, показывающему состояние исполнения проекта. Совершенная система показателей завершенности (если только такие существуют) уверенно покажет, что выполнено 0% в начале проекта и 100% в конце успешно завершенного проекта. А между ними она будет показывать постепенно возрастающие величины от 0 до 100. В лучшем из миров анализ после завершения проекта приведет к выводу, что значения безупречной системы показателей на каждой стадии проекта точно и ясно предсказывали, сколько еще остается времени и усилий.
Понятно, что совершенных систем показателей завершенности не бывает, но существуют несовершенные, которые невероятно полезны. Мы – сторонники двух из них:
• завершение описания граничных условий проекта
• освоенный объем функционала (ООФ)[26]
Эти показатели дают нам способ отслеживать пять главных рисков, рассмотренных в главе 13. Первая система защищает от главного риска, состоящего в нарушении спецификаций. Вторая представляет собой общий показатель чистого прогресса, используемый для отслеживания влияния остальных четырех главных рисков.
Система – это нечто, предназначенное для преобразования входов в выходы, как показано на следующей диаграмме:
Это – правильное описание, будь система, о которой идет речь, государственным ведомством, бухгалтерской компанией, типичной IT-системой, живым человеком или селезенкой… то есть чем бы то ни было, что мы склонны назвать словом «система».
В этом смысле у IT-систем есть отличие: они преобразуют потоки входных данных в потоки выходных данных. Традиционно задача спецификации таких систем сводилась почти полностью к определению правил преобразования, методики и подходов, применяемых системой при преобразовании входных потоков в выходные. Часто в процессе спецификации пропускают строгое и подробное описание самих потоков. Этот пропуск имеет некоторые непреодолимые причины: работа по определению этих потоков часто рассматривается как задача проектирования, которую программисты будут решать на более поздних стадиях. Она может оказаться очень затратной по времени. Откладывание полного определения разумно в проектах, где можно быть уверенными в успешном завершении проекта, но есть ведь и менее везучие проекты, где подробное определение потоков невозможно успешно провести, поскольку это вызовет обострение некоторых конфликтов среди участников проекта. Существование таких «дефективных» проектов вынуждает нас запихивать работу по описанию потоков обратно на раннюю стадию жизненного цикла с намерением заставить конфликт всплыть на поверхность пораньше, не позволяя ему оказаться замазанным на начальных стадиях и неожиданно появиться позднее.
25
WinWin Spiral Process Model – расширение классической спиральной модели жизненного цикла проекта