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