• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

• Зачем нужно управлять рисками, почему бы просто не избегать их?

• Что такое риск и что такое управление рисками?

• Каковы последствия неуправляемого риска?

• Достаточно ли иметь хорошие технологические процессы, чтобы считать, что меры против риска приняты?

• Почему нам нужна эта новая дисциплина?

Избегать рисков – дело проигрышное. Порой вы встречаете проект, кажущийся полностью свободным от рисков. Раньше вы могли бы отнестись к этому как к неожиданному подарку и благодарили удачу за посланный для разнообразия проект, сулящий безмятежную жизнь на время его осуществления. Мы реагировали так же. Какими глупцами мы были! Проекты без риска – удел неудачников. В них почти всегда и выгоды никакой нет, потому-то их и не осуществили давным-давно. Поберегите свое время и силы и потратьте их на что-нибудь стоящее:

Не беритесь за проект, если в нем нет рисков.

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

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

1. Компании переводили приложения и базы данных от архитектуры «мейнфрейм с терминалами» к модели «клиент/сервер»[8].

2. Компании перестраивались, чтобы взаимодействовать непосредственно со своими покупателями и поставщиками новыми, прежде не представимыми способами: через Интернет и с использованием интегрированных сетей снабжения, аукционов и сделок без посредников.

К сожалению, множество компаний сильно погрузилось в первый процесс и проигнорировало второй. После преобразования к виду «клиент/сервер» остальное получается легко и автоматически. Можно даже не просыпаться. На самом деле, если вы потратили большую часть девяностых на преобразование «клиент/сервер», вы все проспали.

Рассмотрим компанию «Merrill Lynch». Здесь долго и тщательно изучали так называемые тенденции электронной торговли в режиме реального времени… и решили обойтись без этого. Они скрестили пальцы в надежде, что вернется эра универсальных брокерских операций с солидными гонорарами и брокерами, способными бесконечно заставлять вас ждать на линии, что директ-трейдинг (прямая торговля) окажется лишь мимолетной причудой. Сколь тщетная надежда! Сегодня универсальные брокерские операции стали такими же древностями, как универсальные бензоколонки[9]. И сегодня «Merrill Lynch» приходится предлагать своим клиентам электронную торговлю. В режиме реального времени по сниженным ценам. Причем потребовалось почти десятилетие, чтобы догнать конкурентов. «Merrill Lynch» была самой последней из тех, кто стал применять эти методы торговли.

Первыми подхватили новые веяния «Fidelity», «Schwab» и «E-Trade». «Е-Trade» и подобные компании были новичками, специально созданными, чтобы воспользоваться новыми возможностями. Если бы электронная торговля оказалась всего лишь мимолетной причудой, «E-Trade» всплыла бы вверх брюхом, не потеряв ничего, кроме капитала, специально привлеченного, чтобы рискнуть. С другой стороны, «Fidelity» и «Schwab» уже были крепко стоящими на ногах компаниями, которым было что терять. В этом смысле они не очень отличались от «Merrill Lynch». Но «Fidelity» и «Schwab» были готовы рисковать.

IT-специалисты в «Fidelity» и «Schwab» должны были осознавать риски нового предприятия. Вот список, полученный нами в результате двухминутного мозгового штурма, с перечислением рисков, которые были очевидны для «Fidelity» и «Schwab», когда они брались в начале девяностых за электронную торговлю:

• Построение такой системы – полностью за пределами наших нынешних возможностей: придется выучить сетевые протоколы, новые языки программирования и подходы, вроде HTML, Java, PERL, CGI, логику работы серверов, ввести проверку подлинности, создать защищенные Web-страницы и освоить много новых технологий, которые сегодня даже трудно перечислить.

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

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

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

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

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

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

Несомненно, «Merrill Lynch» осознавала те же самые риски. Но «Fidelity» и «Schwab» решились пойти на этот риск, a «Merrill Lynch» избрала путь избежания риска. В результате «Fidelity» и «Schwab» агрессивно росли в 1990-х годах, в то время как «Merrill Lynch» приходилось бороться за выживание.

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

В этот беспокойный период готовность рисковать является необходимым качеством. Она имеет стократ большее значение, чем эффективность. Эффективность сделает вас, в лучшем случае, привлекательным объектом поглощения для менее эффективного, но более рискового конкурента.

Известный автор и эксперт в области управления рисками Боб Шарет (Bob Charette) предложил полезный новый способ отношения к риску в нынешних условиях. Он предложил представить вашу компанию и ее конкурентов как несколько движущихся вниз эскалаторов. Вам необходимо вскарабкаться вверх по своему эскалатору, уносящему вас вниз. То же самое делают на своих эскалаторах и конкуренты. Чем быстрее движутся ступени, тем быстрее нужно карабкаться каждому, чтобы держаться на одном уровне. Если остановиться хоть на мгновение, немедленно отстанешь. И, разумеется, если остановиться надолго, то вылетишь вниз, будучи не в силах продолжать борьбу с соперниками.

Новые конкуренты в этом извращенном мире эскалаторов Шарета вскакивают на свои эскалаторы на полпути вверх. Тогда ваше отставание гарантирует новым конкурентам возможность оказаться выше вас.

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

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

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

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

ТДМ: В качестве члена совета Airlie (экспертной группы министерства обороны, планирующей закупки программного обеспечения) мне приходилось участвовать в брифингах по управлению рисками. Мне было особенно интересно, как один из проектов, за которым я издали следил, справится с рисками, представлявшимися действительно угрожающими. Он был связан с разработкой программного комплекса для замены системы, несовместимой с «проблемой 2000 года», поэтому задержка сдачи проекта грозила настоящей катастрофой. Я слышал, что предстояло написать в шесть раз больше кода, чем когда-либо раньше приходилось делать данному исполнителю за время, предусмотренное данным проектом. Ужасающий риск состоял в том, что проект будет запаздывать и организация останется без какой-либо альтернативной работоспособной системы.

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

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

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

• Что в точности понимают под рисками и как ими управлять? (Глава 2)

• Каковы последствия неуправляемого риска? (Глава 3)

• Зачем беспокоиться об инвестировании в иные решения? (Глава 4)

• Какие проблемы я навлекаю на себя, берясь за управление рисками? (Часть II)

• Как я с ними справляюсь? (Часть III)

• Как достигается равновесие между рисками и возможностями? (Часть IV)

• Как узнать, удалось ли мне преуспеть в этом? (Часть V)

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

Руководитель проекта: Не проводите собрание.

Глава определений, относящихся к управлению рисками, начинается с фразы, вынесенной прямо в название главы: управление рисками – это управление проектами для взрослых.

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

Признак зрелости состоит в том, чтобы в явном виде принимать во внимание риски, под которыми будем понимать все то плохое, что может случиться, и строить планы с их учетом. Хотя в области информационных технологий мы иначе используем слово «зрелость». Мы, специалисты по разработке программного обеспечения, приравниваем зрелость к профессиональной квалификации. У нас даже есть пятиуровневая модель для измерения такой зрелости – Модель зрелости процессов (Capability Maturity Model), или сокращенно СММ.[10]

Но слово «зрелость» в английском языке не имеет ничего общего с профессиональной квалификацией. Это, скорее, качество взрослости, показатель того, что человек или иной организм достиг взрослого состояния.

Раньше, когда мы, будучи руководителями проектов, в явном виде не управляли имевшимися рисками, мы вели себя по-детски. В этом смысле, вся наша отрасль вела себя по-детски. Наше безрассудное увлечение позитивным мышлением и подходом «будет сделано» зацикливало нас на лучших вариантах развития событий, поскольку мы игнорировали различные факты, которые могли сделать такие варианты невозможными (см., в частности, пример, рассмотренный в главе 3).

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

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

Но мы в какой-то мере ставим телегу впереди лошади, определяя управление рисками, не определив предварительно само понятие риска. Итак, что такое риск?

Наше представление о риске в проектах по разработке программного обеспечения сложилось на основе наблюдения за тем, как много таких проектов терпят неудачу. Значительная часть нашей консалтинговой работы в настоящее время состоит в поддержке судебных дел, возникших как последствия провала проектов. Благодаря этому, нам удалось собрать обширные данные относительно провалов. Риски неудавшихся проектов, если посмотреть в ретроспективе, были факторами, приведшими к нежелательным результатам. Это относится и к предстоящим проектам: их риски – это то, что может привести к нежелательным результатам. Так мы приходим к следующему временному определению риска:

Риск

1. Возможное в будущем событие, которое приведет к нежелательным результатам.

2. Сам нежелательный результат.

Первое – причина, а второе – результат, но не пытайтесь обманывать себя, рассчитывая справиться с обоими. Управление рисками как дисциплина целиком занята управлением причинными рисками. Это – те риски, которыми вы можете управлять (Однако оправданность управления рисками, в первую очередь, связана с результатами).

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

В качестве альтернативного рассмотрим следующее «круговое» определение риска:

Риск – это проблема, которая еще не возникла, а проблема – это риск, который уже материализовался.

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

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

Представим себе момент, когда то, что было риском, внезапно превращается в проблему. Было абстракцией, просто возможностью, а теперь уже вовсе не абстракция. Уже случилось. Это и есть момент события риска.

Событие риска – основное понятие в управлении риском. Это – событие, инициирующее меры, которые предполагается принять в отношении риска. Ну, это почти так. Реальное событие риска может быть невидно вам (например, Саддам Хуссейн решил вторгнуться в Кувейт). То, что вы видите, – это индикаторы (симптомы) события риска (скопление войск на границе). У каждого риска, с которым нам нужно справиться, есть какие-то симптомы. Однако некоторые из них более полезны, чем другие. Подробнее об этом будет сказано чуть дальше.

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

Рассмотрим пример ослабления риска из сравнительно далекой от нашего предмета области: судебной системы США. Понимая, что присяжный может заболеть, выбыть, умереть или по какой-то иной причине оказаться неспособным продолжать выполнение своих обязанностей, суды назначают дополнительных присяжных для каждого рассматриваемого дела, чтобы обеспечить возможность альтернативы. Если основной состав присяжных доводит работу до конца, то «альтернативщики» не играют никакой роли; но если требуется замена, то имеется кандидатура, полностью информированная о ходе процесса, поскольку присутствует на заседаниях с самого начала; ввод такого человека в состав присяжных позволяет выполнить требование закона о полноте состава присяжных. Риск здесь состоит в том, что выбытие одного из присяжных ведет к прекращению процесса, повторным слушаниям и всем сопутствующим расходам и задержкам. Ослабляющее действие состоит в присутствии с самого начала одного или нескольких дополнительных присяжных. Если и когда риск материализуется, с ним удастся справиться с минимальными издержками.

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

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

Для того, чтобы поупражняться в использовании всех этих только что введенных терминов, представьте себе, что вы занимаетесь управлением рисками в школе. Предположим, что вы – директор частной школы-интерната для мальчиков и девочек 5-8 классов.

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

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

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

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

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

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

Среди перечисленных могут оказаться такие, которые не стоит пытаться включать в перечень рисков, требующих подготовительных действий («метеорит упадет прямо на здание школы, уничтожив ее вместе со всеми в ней находящимися»). Кроме того, будут и такие вопросы, где ваша ответственность далеко не очевидна. Например, «некоторые аспекты уроков по естествознанию могут подорвать религиозные устои учащихся». Относится ли это к рискам, с которыми вы должны справиться? Вы помечаете это отдельно и продолжаете вести мозговой штурм. После составления перечня вам нужно пройтись по списку и проделать следующий этап работы – качественный анализ рисков. Вам предстоит определить, какими рисками нужно управлять, а какими – нет, то есть провести ранжирование рисков. Для тех, которыми вы решили управлять, вам потребуется, по меньшей мере, выявить триггеры (симптомы наступления риска), составить план предварительных действий по ослаблению риска и оценить относительную значимость данного риска.

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

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

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

• анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.

• планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.

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

• мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.

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

Управление рисками – то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места. В нашей личной жизни нам постоянно грозят болезни и ранняя смерть. Мы ослабляем риск, застраховав жизнь и здоровье и сделав распоряжения относительно того, кто позаботится о наших детях, если с нами что-то случится. Мы не притворяемся бессмертными и не делаем вид, что наша способность заработать себе на жизнь не может пострадать от какого-то несчастья. Каждый раз, когда мы взваливаем на себя новую ответственность (скажем, беря кредит под залог жилья), мы продумываем всякие возможные кошмары, которые могут приключиться, при этом надеясь, что ничего такого не произойдет, но заставляя себя продумать, что будет, если произойдет. Как мы увидим, управление рисками на рабочем месте включает несколько особых проблем.

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

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

В городе Денвер (штат Колорадо) в 1988 году было принято решение построить новый аэропорт вместо существующего Стапльтонского аэропорта. Стапльтонский сочли неспособным к расширению, а в существующем виде он не отвечал потребностям растущего крупного города и способствовал все более очевидному загрязнению окружающей среды (а также был чрезмерно шумным). Новый аэропорт должен был стать более экономичным, покончить с загрязнением среды и задержкой рейсов и иметь возможности для необходимого роста. Новый Денверский международный аэропорт (ДМА) по графику собирались открыть 31 октября 1993 года. Так было запланировано.

Все было подогнано для того, чтобы поспеть к сроку: все шло отлично, но эти проклятые разработчики программного обеспечения опять подвели… 31 октября 1993 года весь огромный комплекс аэропорта был готов к пуску… по-честному готов. На самом деле. Можете поверить. Весь, кроме части программного обеспечения, и из-за нее аэропорт не мог открыться!

Точнее, не была готова вовремя злосчастная система автоматической обработки багажа. Аэропорт не мог открыться без работающего программного обеспечения для обработки багажа[11]. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока эти программисты второпях пытались играть в догонялки. А время – деньги. Это был прямой удар по налогоплательщикам. Тут не нужны замысловатые рассуждения, все просто, как на картинке:

И все это по вине тех самых отвратительных разработчиков программного обеспечения.

Такое упрощенное видение (деньги прямиком летят в контейнер для мусора) было характерно для освещения в газетах и журналах проблем ДМА с первого признака задержки в начале 1993 года до частичного открытия в 1995 году. Столько клеймили команду разработчиков, что и сегодня слова «система автоматической обработки багажа ДМА» – узнаваемый символ некомпетентного проекта по разработке программного обеспечения.

Статья в журнале «Scientific American» открыто возлагала ответственность за разочарования, связанные с ДМА, на всю отрасль разработки программного обеспечения с ее нечеткими стандартами и практикой:

«В сфере производства программного обеспечения годами (возможно, десятилетиями) ощущается нехватка зрелой технологической дисциплины, соответствующей требованиям информационного общества»[12].

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

1. более высокий уровень модели зрелости процессов (СММ).

2. большее использование формальных методов.

3. формализованные языки спецификации (типа В и VDM).

Но является ли это на самом деле проблемой технологических процессов?

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

1. Требования к системе: Что именно должна делать система?

2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?

3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?

4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?

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

6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?

7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?

8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?

9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?

10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?

Даже самый совершенный процесс разработки не может полностью устранить неопределенность при осуществлении проектов по созданию сложных систем. А где есть неопределенность, там появляется риск. При наличии риска нужны осторожные и продуманные усилия, чтобы с ним справиться. Вместо того, чтобы спрашивать: «Как они справлялись с созданием программного обеспечения?», можно гораздо глубже понять, что произошло при строительстве ДМА, задав вопрос: «Как они справлялись с управлением имевшимися рисками?»

Кратко описав события строительства ДМА, мы просили принять на веру часто повторявшееся утверждение, что аэропорт был на 100% готов к открытию, за исключением программного обеспечения для обработки багажа, но что аэропорт нельзя было вообще открыть без этого программного обеспечения. Теперь давайте рассмотрим это утверждение подробнее.

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

Тогда зададим себе несколько важнейших вопросов:

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

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

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

4. Когда автоматизированная система оказалась не готова вовремя, почему нельзя было открыть ДМА, используя один из альтернативных способов транспортировки багажа? Ээээ… Хм. Туннели, предназначенные для обслуживания автоматизированной системой дистанционно управляемых тележек, были слишком низкими для людей и не могли вместить грузовички. Поэтому должна была работать автоматизированная система.

5. Нельзя было переделать туннели, чтобы управляемые людьми грузовички и тележки могли по ним двигаться? Можно, но не было времени. К моменту, когда стало понятно, что программное обеспечение запаздывает, туннели уже были построены. А времени на переделку потребовалось бы больше, чем на доведение программного обеспечения.

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

7. Рассматривалась ли задержка программного обеспечения для обработки багажа как потенциальный риск? Только после того, как это случилось. До этого программное обеспечение разрабатывалось по жесткому графику, и все было нацелено на его успешное выполнение.

8. Случались ли прежде задержки проектов по разработке программного обеспечения? Да, но на этот раз рассчитывали, что будет иначе.

9. Существовала ли история разработки подобных систем? Да. В аэропорту Франца-Иосифа Штрауса в Мюнхене была установлена пилотная автоматизированная система обработки багажа, разработанная по тому же типу.

10. Ознакомилась ли команда разработчиков ДМА с мюнхенским проектом, и, если да, то чему это ее научило? Разработчики программного обеспечения для обработки багажа в ДМА посетили Мюнхен. Разработчики мюнхенского программного обеспечения потратили полных два года на тестирование системы и шесть месяцев на окончательную отладку в режиме круглосуточного функционирования системы перед окончательной сдачей. Они советовали коллегам из ДМА отвести на это времени никак не меньше, а при возможности – даже больше.

11. Последовало ли руководство ДМА этому совету? Поскольку время для такого обширного тестирования и отладки не было запланировано, предпочли обойтись без этого.

12. Делала ли команда проекта достаточно внятные предупреждения об угрожающем запаздывании? Прежде всего, невидимая рука рынка сделала важный жест прямо в самом начале. Когда Совет управляющих ДМА первый раз объявил тендер на выполнение этой системы программного обеспечения, никто не хотел подавать заявку при указанной дате поставки готового продукта. Все подрядчики считали, что начинать проект при таком расписании было надежным способом навлечь на себя неизбежные неприятности.

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

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

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

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

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

В данном случае все издержки в конечном счете падали на головное агентство «Denver Airport System», которое было частью городского управления. Таким образом, городские власти Денвера несли ответственность за управление финансовыми рисками, к чему они не приложили ни малейших усилий.

Ни один план не выдерживает боевого столкновения с противником

(фельдмаршал Гельмут фон Мольтке)

На примере ДМА следует осознать, как велики потенциальные затраты, вызванные тем, что рисками не управляют. Если предыдущая глава нам удалась, то она должна была оставить у вас чувство, что вы определенно не хотите не делать того, что называют управлением рисками. Но тем не менее, она могла не оставить у вас активного желания делать это.

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

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

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

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

Попробуем на минуту посмотреть на ситуацию с противоположной стороны, чтобы понять, как это влияет на шансы начать проект. Поставьте себя на место этого клиента. Теперь вы ищете кого-то, чтобы поручить ему разработку программного обеспечения, которое вам срочно необходимо. Руководитель проекта, предлагающий вам выполнить эту задачу, – славный парень, но часто он обещает выполнить работу к определенному сроку, а потом подводит вас. Когда он говорит «отлично», вы слышите «маловероятно». Что ж, возможно, вы с этим можете смириться. Может быть, неопределенность, которую вы автоматически приписываете всему, что он говорит, для вас приемлема в данном проекте. Но предположим, что она не приемлема. Положим, что опоздание вам слишком дорого обойдется. Какой у вас есть выход, кроме того, чтобы не браться за рискованный проект? Еще одна упущенная возможность.

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

Проблема состоит в том, что у таких клиентов есть воспоминания. Они помнят другие проекты, начинавшиеся с прекрасных прогнозов, которые быстро «стухли». В результате они ожидают худшего и становятся противниками риска.

Но вообразите вместо этого, что руководитель проекта по разработке программного обеспечения приходит к вам и честно показывает ожидаемые неопределенности в предполагаемом проекте: «Смотрите, неизвестно, что нам ждать там-то и там-то. Вот мы составили перечень из 11 пунктов». (Тут он показывает вам свой список рисков). «Вместе взятые, эти неизвестные дают очень большой разброс срока завершения. Некоторые из дат в этом диапазоне, возможно, будут для вас неприемлемыми. Но вот наш продуманный план того, как мы будем сдерживать и минимизировать различные риски, а вот описание того, как вы узнаете в любой точке проекта, как мы продвигаемся».

Если в дополнение к сказанному он покажет вам записи о прежних проектах, демонстрирующие, как реальные результаты соответствовали оценкам неопределенности, то вы можете начать верить тому, что услышали.

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

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

Управление рисками делает приемлемой определенную дозу мышления типа «невозможно сделать». Когда установлена структура управления рисками, людям разрешено мыслить и негативно, по крайней мере, часть времени. Компании, делающие это, понимают, что негативное мышление – единственный путь избежать неожиданных ударов со стороны неучтенных рисков во время осуществления проекта[13].

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

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

Частенько встречаются «неудавшиеся» проекты, где есть все основания полагать, что для выполнения заданной работы у руководства есть необходимые способности и их команды достаточно квалифицированы. Если бы это было не так, им бы давно указали на дверь. Когда один проект за другим объявляют неудавшимся, это просто доказывает, что негодными были установочные условия этих проектов. Управление рисками – способ разрушить этот мрачный цикл, обеспечив набор выполнимых целей и графиков и породив успешные проекты, которые выглядят и ощущаются как успешные с начала и до конца.

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

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

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

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

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

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

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

Проект терпит неудачу. Что еще важнее, подпроекты терпят неудачу. Если вы руководите программой, объединяющей эти подпроекты, то вашей первой заботой должно стать недопущение того, чтобы провал одного из компонентов подвергал опасности целое. Вспомним опять строительство ДМА. Вся программа могла быть защищена, причем сравнительно недорогой ценой, от неудачи одного элемента.

Примечания:

1

Dr. Scuss and Eugene Poddany, The Cai in the Hat Songbook (New York: Random House, 1967). (прим. ред.)

8

т.е. переход от большой машины с терминалами к сетевому серверу и клиентским ПЭВМ (прим. пер.)

9

Концепция бензоколонки в США претерпела в последние десятилетия значительные изменения. До нефтяного кризиса конца 60-х годов служащий бензоколонки заправлял автомобиль, протирал стекла, по просьбе клиента проверял уровень масла и охлаждающей жидкости и давление в шинах. Дорожные карты района предоставлялись бесплатно. После нефтяного кризиса, приведшего к разорению многих колонок, сервис существенно изменился. Ныне бензоколонки чаще всего осуществляют только заправку, на многих введено самообслуживание (прим. ред.)

10

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

11

Система обработки багажа представляла собой 4000 автоматических тележек, управляемых лазерными сканерами, считывающими штрих-коды с багажных бирок, и транспортирующих багаж по туннелям длиной в 21 милю, оснащенным автоматическими «семафорами» на перекрестках (прим ред.)

12

W Wayt Gibbs, «Software's Chronic Crisis» («Хронический кризис программного обеспечения») Scientific American, September, 1994, p. 84 (прим. авт.)

13

Мы обязаны нашему коллеге Полю Руку (Paul Rook) за его элегантное замечание, что «управление рисками реабилитирует риск» (прим авт.)