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

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

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

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

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

Глава 1

Стремление к рискам

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

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

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

Компании, избегающие риска и концентрирующие усилия только на том, что наверняка умеют хорошо делать, засевают поле для своих соперников. В 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)

Глава 2

Управление рисками — это управление проектами для взрослых

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

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

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

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

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

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

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

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

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

Риск

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 3

Пересмотр истории международного аэропорта в Денвере

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

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

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

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

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

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

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

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», которое было частью городского управления. Таким образом, городские власти Денвера несли ответственность за управление финансовыми рисками, к чему они не приложили ни малейших усилий.

Глава 4

Доводы в пользу управления рисками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какова оборотная сторона управления рисками?

Находится ли управление рисками в противоречии с принципом «управление ради успеха»?

Есть ли основания верить, что управление рисками окажется совместимым с нашей корпоративной культурой?

Чем плох расчет на несколько счастливых случаев при составлении графика проекта?

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

Глава 5

Доводы против управления рисками

Управление рисками часто показывает вам больше реальности, чем вам хочется.

Майк Эванс (MikeEvans), первый вице-президент корпорации АSC[14]

Следует признать, что есть несколько причин не прибегать к управлению рисками. Мы не стали бы писать эту книгу, если бы считали эти причины достаточными, чтобы лишить привлекательности управление рисками в целом. Тем не менее, вам следует знать о минусах, равно как и о плюсах.

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

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

1. Наши акционеры не являются достаточно зрелыми, чтобы смотреть риску в лицо.

«Если бы мы сказали правду, наши акционеры слишком испугались бы и отказались от проекта, поэтому мы вынуждены им лгать».

В этой ситуации ложь представляют истинным общественным служением.

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

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

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

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

2. Уровень неопределенности слишком велик.

«Я готов указать диапазон, в котором будет дата завершения, но не такой большой».

Многие руководители проектов по созданию программного обеспечения теоретически готовы бороться с неопределенностью в своих проектах, но их ошеломляет размер этих неопределенностей. Если бы они могли использовать методы управления рисками, чтобы показать дату поставки плюс-минус 2% или 5%, они были бы в восторге. Но неопределенность в нашей области значительно больше. Тщательная оценка возможных причин задержки обяжет признать что-то в таком роде: «Поставку можно ожидать между 18-м и 29-м такого-то месяца, причем с 85% достоверностью можно назвать 24-е число».

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

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

3. Заданный в явном виде диапазон неопределенности оправдывает плохую работу.

«Если я скажу нашим разработчикам, что работу нужно сдать в любой момент между июлем и декабрем, они сразу отправятся спокойно спать».

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

4. Подход «управление ради успеха» лучше.

«Смотрите, мы не занимаемся управлением рисками, но следим за рисками и делаем все, чтобы они не происходили».

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

5. Не хватает данных для эффективного управления рисками.

«Мы недостаточно знаем про риски, которые повлияют на этот проект».

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

6. Опасно управлять рисками в изоляции.

«Я не осмелюсь быть единственным, кто честно осуществляет управление рисками».

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

Если вы работаете в организации, где управление рисками не практикуется достаточно широко, вы все же можете использовать в своем проекте некоторые его инструменты и методы, но не стоит афишировать свои открытия. Говорить правду в обстановке, где нормой является оптимизм (ложь) — значит оказаться в крайне невыгодном положении. Если вы утверждаете, что есть лишь 10%-ная вероятность сдать проект в желательный клиенту срок, вы предоставляете возможность коллеге-конкуренту сказать: «Босс, поручите это мне, и я все сделаю вовремя, гарантирую вам».

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

Глава 6

Бремя ответственности за неопределенность

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

Ошибаться — нормально, но неопределенность — не приветствуется.

Если это правило описывает вашу компанию, вы пропали.

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

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

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

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

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

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

ТДМ: Я участвовал в судебном разбирательстве, рассматривая останки проекта, который застрял на полпути. Многое шло наперекосяк, но по-настоящему роковым оказалось то, что субподрядчик был буквально завален обязательствами, которые на себя взял. В итоге он просто пропал. Маленькая фирма прогорела, и больше о ней не было ни слуху, ни духу.

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

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

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

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

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

Глава 7

Удача

ТРЛ: Удачи вашему следующему проекту… но не рассчитывайте на нее.

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

Можете ли вы вообразить реальный риск (нечто плохое, что вполне может произойти и непременно повлечь ужасные последствия), которым нет смысла управлять? Такой, что его даже и в перечень вносить не стоит?

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

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

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

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

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

1. У риска незначительные последствия, и потому он не требует ослабления.

2. Это — чужой риск.

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

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

Почему в каких-то случаях вы не управляете реальными и значимыми рисками, угрожающими вашему проекту, а вместо этого рассчитываете на удачу, надеясь, что она им воспрепятствует? Например, положим, что проект попал к вам в форме личного вызова такого типа: «Я знаю, апрель — это трудный срок, потому-то я и поручаю эту работу вам!»

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

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

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

ТРЛ: Совсем ничего не зная о вашем нынешнем проекте, готов держать пари даже на деньги, что вы опоздаете. В конце концов, значительно больше половины всех проектов бывают сданы с опозданием или в меньшем объеме, чем предполагалось изначальным графиком. Еще хуже дело, когда проект идет по жесткому графику. Исполнители проекта кажутся смущенными, когда я заявляю, что готов держать с ними пари. Они так сильно стараются поверить, что оседлали удачу. Обычно происходит так: все согласны, что сроки сдачи очень жесткие, все трудятся изо всех сил, а затем, когда люди видят, что не справляются, они потрясены, разочарованы и глубоко перепуганы.

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

Хватит с нас пока проектов по разработке программного обеспечения. На следующих нескольких страницах вам предстоит стать водителем Inc Racing League. Вот вы за рулем автомобиля Panther Racing Penzoil Dallara с ревущим мощным мотором Aurora. Это — сильнейшее переживание гонок. Вы включили низшую передачу, идя на третий поворот, и слегка отстали, но вам удалось это славно наверстать, включив высшую передачу и ускорившись. Ваша скорость по прямой может достигать 220-225 миль/час. Вы обходите одну машину, вторую — и уже возглавляете гонку. Вы мечтали об этом так долго, и вот мечты осуществляются.

На мгновение оценим перспективу: вы за рулем уже 2 часа 14 минут, немудрено, что вы устали. Это 198 круг. До финиша меньше 5 миль. Чтоб вы ни делали, не ослабляйте усилий. Продолжайте жать на газ, но играйте наверняка, потому что заезд уже почти выигран. На самом деле, единственная реальная угроза — команда Team Green. Они все еще преследуют вас, но вы прилично оторвались. Вы твердо держитесь курса и не расслабляетесь. Только краешком сознания вы следите за чем-то, кроме вождения: этот краешек прислушивается к сигналу тревоги относительно топлива. Вы бросаете взгляд на прибор — стрелка на нуле. Но осталось всего несколько миль. Ваша техническая бригада призывно машет вам, но такая остановка сейчас означает поражение. Звук мотора на редкость ровен. Вы выкладываетесь, сохраняя свое положение между ребятами из Team Green и финишем. Последний круг. Вот оно — вы побеждаете! Но постойте, мотор зачихал. Он кашляет, вы начинаете терять темп. Ну же! Вы подгоняете машину изо всех сил, но мотор уже заглох. «Первым пересечь черту, — думаете вы, — все равно победа, даже если вы двигаетесь накатом». Вы продвигаетесь накатом, ближе, ближе, ближе, еще ближе к линии финиша… но останавливаетесь, не дотянув всего несколько футов. Team Green с ревом проносится мимо.

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

Это вполне разумно для гонщика Indy 500. Но вы им не являетесь (Извините). Вы — руководитель проекта по созданию программного обеспечения. Такое умонастроение в проекте по созданию программного обеспечения — катастрофа. Когда вы все ставите на карту ради победы, вы можете так увеличить последствия неудачи, что они выйдут далеко за пределы допустимого.

Это — странный, но верный расчет как правило, гораздо важнее ограничивать уровень потерь в процессе разработки программного обеспечения, чем идти на все ради победы. У каждой организации в этой области бизнеса случаются неудачи. Те, кто сильнее пострадал от своего поражения (как ДМА) — неудачники, даже если они в некоторых других случаях одерживали победы.

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

Назовите это, как хотите, но это не является управлением рисками.

• Как мы решаем проблему управления рисками?

• Раз неизвестные нам неизвестны, как мы можем их количественно оценить?

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

• Откуда берутся данные для управления рисками?

• Что такое резервы на управление рисками, и как их используют?

• Что можно сделать в отношении риска, кроме отслеживания его?

• Что такое повторяющиеся риски проектов по разработке программного обеспечения, и что о них известно?

• Как мы вообще обнаруживаем риски?

Глава 8

Количественное определение неопределенности

Разработка программного обеспечения — рискованный бизнес, поскольку весь процесс окутан неопределенностями. Все, что нужно предсказать относительно проекта, будет в какой-то мере неопределенным. Но насколько именно?

Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 6-го числа, но немного сомневалась, будет ли это несколькими днями раньше или позже. Или, возможно, она совсем понятия не имела о сроке завершения. Ясно, что между этими двумя уровнями неопределенности колоссальная разница. Представьте это так: вы — руководитель проекта, и вы стремитесь завершить проект по графику к 30-му октября. У вас есть четкое ощущение, что 30-е октября — абсолютно нереально, но точнее вы ничего сказать не можете. Вы совершенно беспомощны. Ваши подчиненные также в полном неведении. Таким образом, примерно в середине лета, уже отставая от срока на четыре месяца, вы приглашаете консультанта. Выбранный вами консультант — лучший в данной области, способный правильно оценить проект даже во сне и определить его состояние. Через несколько дней погружения в технические условия и промежуточные результаты, а также встреч с исполнителями и акционерами, он заявляет напрямик:

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

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

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

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

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

• Площадь под кривой представляет собой общую вероятность завершения проекта к данной дате, поэтому, если треть площади лежит слева от 1 апреля, то это значит, что вероятность завершения к 1 апреля или раньше составляет примерно 33%.

• Площадь под всей кривой равна 1,0 в соответствии с оценкой консультанта, что работа будет завершена в период с 1 января до 31 декабря следующего года.

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

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

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

Даже стратегия выбора «наиболее правдоподобной даты» не слишком надежна, поскольку площадь слева от пика едва составляет треть. Это означает, что с вероятностью 2/3 к этому сроку система не будет готова. Да, это наиболее правдоподобная дата из всех, но все же не очень правдоподобная.

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

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

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

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

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

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

Здесь диапазон неопределенности представляется разумной долей от длительности с начала проекта до N.

Но предположим вместо этого, что ваша диаграмма риска выглядит так:

Совсем несимпатично в этой картинке то, что неопределенность слишком велика по сравнению с интервалом от начала проекта до N.

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

Неудачи прежних проектов и их политики приучили нас к мысли, что подходящим диапазоном допуска является 10-15% от интервала с начала проекта до N. То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления.

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

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

В целом для отрасли, производящей программное обеспечение, диапазон допуска составляет порядка 150-200% от интервала с начала проекта до N. Таким образом, у проекта с N, приходящимся на 25-е число какого-то месяца, дальний конец диапазона кривой неопределенности придется на 75-е число. От вас не требуется испытывать восторг по этому поводу. Просто так устроен мир. Бесполезно притворяться, что дело обстоит иначе.

Глава 9

Механика управления рисками

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

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

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

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

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

В основе этого подхода лежит следующий принцип:

Вчерашняя проблема — это сегодняшний риск.

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

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

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

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

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

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

• Вы можете его избежать.

• Вы можете его сдерживать.

• Вы можете его ослабить.

• Вам удастся от него увернуться.

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

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

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

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

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

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

Управление рисками и опасения за свой проект — это не одно и то же.

Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.

Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75%[18].

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

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

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

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

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

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

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

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

подверженность риску = затраты * вероятность

Таким образом, если вы определяете вероятность риска в 20%, а его наступление обойдется вам в миллион долларов, то подверженность риску составит $200000.

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

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

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

Пока мы рассматривали сдерживание как денежный вопрос. Возможно, вам также придется сдерживать риски в плане времени. Подверженность риску можно выразить в месяцах ожидаемой задержки. Если вероятность наступления риска составляет 20% и оно вызовет задержку в пять месяцев, ваша подверженность риску во временном исчислении составляет опоздание в 1 месяц.

При оценке рисков с точки зрения стоимости и вероятности возникновения, вам, может быть, придется столкнуться с такими рисками, которые невозможно оценить, потому что они будут стоить вам всего проекта. Это — риски-катастрофы: если они возникнут, то намертво застопорят дело. Они заставят вас либо найти полностью новый подход к продукту, либо аннулировать весь проект. Определение одного или нескольких таких рисков не упраздняет процесс управления рисками, несмотря на то, что они не могут быть должным образом оценены количественно. Риски-катастрофы представляют собой принципиально иной тип рисков, к которому требуется совершенно иной подход. Этими рисками можно управлять только посредством того, что мы назовем допущениями проекта. Чтобы продолжать свою работу, вы должны предположить, что такой риск не наступит. Если эти допущения не оправдаются, вам придется передать вопрос на более высокий уровень управления. Такие серьезные риски выходят за пределы ответственности и полномочий данного проекта. Вот несколько катастрофических рисков, с которыми мы сталкивались:

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

• Новый продукт строится на базе преобладающей на данном рынке операционной системы. Что, если эта ОС будет обновлена и данный продукт будет несовместим с новой версией?

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

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

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

Более сильная оборонная стратегия состоит в том, чтобы создать резерв несколько больше суммарной подверженности рискам, а менее сильная оборонная стратегия состоит в том, чтобы создать резерв несколько меньше. Заложив резерв 0% от рассчитанной подверженности рискам, вы возвращаетесь к тому, с чего начали.

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

Оптимистичный план проекта (обозначен серым) показывает более раннюю дату поставки, чем было запланировано (серый + белый) проектным планом. Разница между этими датами — ваш резерв времени. Установив резерв бюджета и резерв времени, равным подверженности этим рискам, вы закладываете резерв, примерно достаточный для сдерживания ваших рисков.

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

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

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

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

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

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

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

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

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

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

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

За каждым выкатившимся мячом последует бегущий ребенок.

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

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

Глава 10

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

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

Управление рисками, по сути, состоит в осуществлении следующих девяти шагов, включаемых в проект:

1. Использовать процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту.

2. Убедиться, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.

3. Провести всю указанную предварительную подготовку по каждому из рисков:

• Дать наименование риску и присвоить ему уникальный номер.

• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).

• Оценить влияние риска на стоимость и расписание проекта.

• Оценить вероятность наступления риска.

• Рассчитать подверженность риску по отношению к графику и бюджету.

• Определить заранее, какие меры придется принять, если и когда событие риска наступит.

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

• Включить действия по ослаблению риска в общий план проекта.

• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.

4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков вышестоящему руководству.

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

6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.

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

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

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

Эти шаги достаточно легко перечислить, но труднее осуществить. Уместно сделать несколько замечаний:

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

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

Предположим, что диаграмма риска для вашего проекта показывает N в марте, а готовность с вероятностью 75% — в сентябре. На этой основе вы можете предпочесть убедить участников проекта получить продукт в сентябре. Сентябрь — разумный срок для обязательств, но совсем не идеальная цель для вдохновения членов команды проекта. Никто не хочет работать ради цели, имеющей 75%-ную вероятность, то есть с очень низкой эластичностью. Аналогично, N — также неудачная цель для проекта, поскольку никто не хочет работать ради цели, имеющей вероятность 0%, все мы слишком большую часть жизни тратим на бесплодные усилия. Наилучшим решением является установление в качестве цели эластичной даты сдачи проекта где-то между N и установленным сроком сдачи.

Это — новое и отличное от прежнего: проект с установленной датой сдачи, отличающейся от эластичной цели. Долгое время в большинстве компаний было принято:

График = Цель = N действительно дурацкое уравнение

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

График > Цель > N более разумно

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

ТРЛ: Мой отец — математик, профессор на пенсии. Однажды он разворчался на меня по поводу всех проектов по разработке программного обеспечения, которые выполнялись с тем или иным опозданием, что относится почти к 100% проектов. «Почему так?» — вопрошал он.

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

«Вариантов не два, Тим, — ответил он. — Есть и третий — досрочная готовность».

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

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

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

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

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

Дата теперь фиксирована, и неопределенность полностью относится к тому, что именно будут сдавать в этот день. Если ни один риск не наступит, могут быть сданы все версии от 1 до 24 (представленные как В24). Поскольку шансы избежать все риски крайне малы, это нанопроцентная функциональность — не то, чтобы невозможно, но исключительно неправдоподобно. Если судить по площади под кривой слева от В21, вероятность сдать все версии от 1 до 21 становится примерно 50%-ной к этой дате. Если участники проекта непреклонны в том, что для них не подойдет ничего, что будет меньше, чем В22, то диаграмма показывает, что вероятность предоставить им то, что они хотят, едва достигает 30%. Опять же, хотя это может оказаться неприятной новостью, скрывать ее — лишь отложить (и усугубить) день окончательной расплаты.

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

Во-вторых, берегитесь проекта, который представлен как имеющий фиксированный срок сдачи, но на самом деле его не имеет:

ТДМ: Я консультировал в штате Нью-Йорк проект с «жестким, фиксированным сроком сдачи». Продукт должен был быть во что бы то ни стало поставлен к концу второго квартала, никакие извинительные причины не принимались. Но он не был сдан в срок. На самом деле его сдали с опозданием больше чем на 18 месяцев. Оглядываясь назад, я не могу не удивляться, к чему были все эти песни и пляски по поводу «жесткого, фиксированного срока сдачи», поскольку срок с очевидностью не был ни жестким, ни фиксированным.

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

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

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

Здесь изображен проект, который с вероятностью не менее 60% не сможет предъявить к обещанному сроку даже первую работающую версию.

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

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

Глава 11

Возвращение к основам

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

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

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

Можно предварять любой свой ответ словами: «Я не знаю, но…» Но даже если вы не начинаете с этого уточнения, оно неявно подразумевается.

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

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

Что я знаю (или что я мог бы знать) о том, чего я не знаю?

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

Вот пример. Вы возделываете свой сад 31 марта, но поскольку рядом с садом нет воды для полива, вы рассчитываете на дождь, чтобы он полил ваш сад. Итак, денежный вопрос здесь звучит так: «Сколько дождя прольется на ваш сад?» Вы, разумеется, отвечаете: «Я не знаю». Ясно, что это сигнализирует вам о риске, заключающемся в том, что ваши труды и деньги, потраченные на семена, могут пойти прахом, если не будет достаточного количества влаги. Теперь вы задаете вспомогательный вопрос: «Что я знаю (или что я мог бы знать) о том, чего я не знаю?» Быстрый поиск в Интернете или визит к местному агроному может снабдить вас информацией о прошлых дождях в вашем районе:

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

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

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

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

Диаграмма неопределенности показывает набор предыдущих результатов:

Согласно условию, мы так строим вертикальную ось, чтобы сумма всех вероятностей равнялась единице.

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

Перейдем от далекого примера про сад к более волнующей теме: неопределенности относительно того, когда будет готов ваш проект:

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

Можно использовать диаграмму риска для количественной оценки любого рассматриваемого риска. Например, вы ищете точку, для которой площади под кривой слева и справа одинаковы, называя ее риском 50 на 50, это самый ранний срок, когда вероятность успеть вовремя сравнялась с вероятностью не успеть к этому сроку. Вы можете посмотреть правее, где под кривой находится уже 90% площади (похоже, что на рисунке это приходится на май следующего года), и узнать, что при назначении его сроком сдачи вы можете не уложиться лишь с 10%-ной вероятностью. Другими словами, гораздо вероятнее, что вы успеете завершить проект раньше этой даты, чем позже. Вы можете также исключить самые оптимистичные 10% и самые пессимистичные 10% и уверенно считать, что с 80%-ной вероятностью завершите проект в период между нынешним и следующим маем. Диаграмма риска — инструмент для оценки размера риска в любой выбранной вами форме выражения. Но мы собираемся сообщить вам еще более грандиозное понимание диаграммы риска: идею о том, что ситуация, нарисованная диаграммой, и является риском. Это ведет к следующему окончательному определению риска, взамен временного определения, предложенного в главе 2:

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

• «Дело в шляпе, босс!» (по сути 100%-ная уверенность);

или

• «Я думаю, что шансы равны» (50%);

или

• «Разве что рак на горе свистнет!» (меньше 1%).

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

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

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

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

Диаграммы риска часто имеют весьма характерные формы. Можно, например, встретить такие, которые математики называют нормальными или симметричными относительно средней точки:

Обычно более распространены асимметричные диаграммы, которые выглядят так:

<…> в том, что человеческая деятельность имеет тенденцию к именно <…> симметрии, сравнительно сильнее сгруппированной к одному из <…> обычно к левому, что указывает на более быстрое завершение). Наконец, есть класс странно выглядящих диаграмм, подобных следующим:

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

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

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

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

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

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

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

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

Для того, чтобы продемонстрировать следующую идею, придется построить очень грубую диаграмму неопределенности («крупнозернистость» сделает эффект более очевидным). Предположим, мы изучаем небольшие группы учащихся. У нас есть какие-то данные о них, включая вес в фунтах. Мы группируем данные по весу с шагом в 20 фунтов и обнаруживаем, что есть один ребенок в группе 101-120 фунтов, три — в группе 121-140 фунтов и два — в группе 141-160 фунтов:

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

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

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

Теперь вернемся к реальному миру: ниже показана дифференциальная диаграмма риска для срока сдачи проекта и (непосредственно под ней) ее кумулятивный эквивалент:

Здесь снова оба графика показывают одни и те же данные, просто представленные слегка по-разному. Заметно, что шкалу по вертикали при кумулятивной форме несколько легче понять: она показывает непосредственно вероятность от 0 до 100%. Любая дата влево от 1 января безнадежна (0%-ная вероятность), но если мы захотим пройти весь путь до конца декабря следующего года, есть 100%-ная вероятность того, что к сроку все будет готово. Факт, что 1 мая следующего года дает вероятность 50 на 50, сразу виден на кумулятивной диаграмме, а на дифференциальной нужно оценить площади слева и справа отданной точки.

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

Глава 12

Инструменты и процедуры

В этой главе у нас две задачи: (1) снабдить нас удобным инструментом для оценки рисков и (2) дать некоторые основные знания о пользовании им. Инструмент, названный RISKOLOGY, можно бесплатно скачать с нашего сайта в Интернете (http://www.systemsguild.com/riskology/)[21]. Это — модель риска в смысле, описанном в предыдущей главе. Инструмент предназначен для использования вместе с вашей собственной производственной моделью или механизмом параметрического оценивания. Наш инструмент не оценивает, сколько времени будет длиться ваш проект, он всего лишь говорит вам о том, сколько неопределенности следует приписать любой выдвигаемой оценке.

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

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

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

В центре любой модели риска — метод определения объединенного воздействия двух и более неопределенностей:

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

Предположим, что вы — бегун. Вы честно бегаете ежедневно, но время пробежки варьируется в зависимости от других ваших дел. Ваша ежедневная тренировка занимает от 15 минут до 1 часа. Вы ведете записи и обнаруживаете, что совершенно независимо от расстояния (в указанном временном диапазоне) скорость бега варьируется от 6,5 до 9 миль/час. Записи вы ведете так давно, что накоплена вполне приличная статистика:

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

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

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

Эти данные более «зернистые» из-за недостаточного их количества.

Итак, сколько займет ваш следующий забег? Вы помните, что время — это расстояние, деленное на скорость (мили расстояния, поделенные на мили/час). Если расстояние и скорость были бы фиксированными величинами, то нам предстояло бы элементарное арифметическое действие, но в данном случае, оба параметра являются неопределенными, меняющимися в рамках определенного диапазона. Это обеспечивает наличие неопределенности также и в результате:

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

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

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

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

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

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

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

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

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

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

Диаграмма, показанная выше, — это симулятор Монте-Карло для проблемы двойной неопределенности. Он позволяет вам моделировать n случаев проблемы и отображать результаты в форме результирующей диаграммы неопределенности. Вот результат для 100 образцов:

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

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

Скачайте копию симулятора «RISKOLOGY» с нашего сайта: http://www.pmo.ru/riskology

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

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

Для незнакомых с управлением рисками, или тех, кому очень сложно понять неопределенность, мы предлагаем воспринимать это как результат моделирования: «Мы прогнали этот проект 500 раз через симулятор, и получили результат, показанный на рисунке».

«Как вы видите, это показывает, что мы закончим работу до конца 30-го месяца проекта только в 15% случаев, — говорите вы. — Это не значит, что дата недостижима, она всего лишь имеет высокие риски. На нее можно рассчитывать лишь с 15%-ной уверенностью. Если вам нужна 75%-ная уверенность, вам лучше объявить датой сдачи 40-й месяц».

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

Глава 13

Основные риски проекта по разработке программного обеспечения

Если вы хоть сколько-то проработали в области создания программного обеспечения, то знаете, что есть некоторые общие проблемы, от которых страдают все проекты. Пропущенные сроки, установленные расписанием, и меняющиеся требования к проекту — это не то, что случается однажды и больше не повторяется. Они, скорее, неотъемлемая часть этой области бизнеса. Все мы это знаем. Странно только, что мы не планируем свои проекты с учетом этого знания. Вместо этого, мы планируем так, как будто эти проблемы надежно замурованы в прошлом и не грозят нам впредь. Конечно, вы знаете, что это неразумные ожидания. Эта глава поможет вам рассчитать, в каком объеме ваш план следующего проекта должен вмещать в себя проблемы, с которыми вы столкнулись в прошлом. Поскольку мы сами поступаем именно так, мы покажем использование симулятора «RISKOLOGY» в качестве инструмента для применения главных схем поведения, связанного с риском, к новым планам проектов.

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

1. внутренние изъяны календарного планирования

2. раздувание требований (изменение требований)

3. текучесть кадров

4. нарушение спецификаций

5. низкая производительность

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

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

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

Ошибки календарного планирования можно рассматривать как тенденцию неправильно судить о размерах продукта, который предстоит создать. Существует серьезная возможность недооценки, даже если вы прилагаете большие усилия по определению величины программного продукта, скажем, методом функциональных точек, по модели СОСОМО KLOC[22] или любым другим способом. Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.

Если вы не предпринимаете серьезных усилий по определению величины программного продукта, то ваши оценки календарного планирования основаны всего лишь на принятии желаемого за действительное: «Ого! Клиент хочет получить это в мае, до мая еще 7 месяцев, поэтому наугад можно поставить в график 7 месяцев». Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%. Когда семимесячный проект в конце концов занимает 12 месяцев, разъяренные топ-менеджеры редко винят график, вместо этого они ругают тех, кто должен был воплотить этот график (каким бы смехотворным он ни был) и жизнь. Но проблема в ошибочном календарном планировании, а не в плохом исполнении. В ретроспективе это выглядит так: размер продукта был недооценен по приказу; ограничение продолжительности проекта свело его размер к такому, какой мог быть создан за это время, но это ограничение оказалось нереалистичным.

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

Как показывает рисунок, если ничего больше не известно о вашем проекте или вашей организации, то можно с уверенностью утверждать, что первоначальная оценка размера продукта (как вычисленная непосредственно вами, так и декларативная) вынудит вас перерасходовать запланированное время, по крайней мере, на 30%. Например, горизонталь, проведенная на уровне 0,50 пересечет кривую в точке, показывающей увеличение времени в 1.3 или более.

Показанная здесь ситуация значительно хуже, чем ей следовало бы быть. Общеотраслевая тенденция скомпрометирована тем фактом, что так много компаний не выполняет предварительной работы по определению размера проекта, выбирая вместо этого календарное планирование от конца к началу или просто принимая желаемое за действительное. Хотя отрасль в целом управляется с этим не лучше, чем показано на рисунке выше, те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15% и менее. Сбор данных по нескольким проектам относительно масштабов недооценки размера научит вас закладывать необходимый резерв на это в ваших будущих проектах. В конечном счете, вы можете построить сбалансированную диаграмму риска, где точка 50 на 50 соответствует перерасходу на уровне 0%, а вероятность закончить проект досрочно (с учетом только этого главного риска) равна вероятности закончить с опозданием.

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

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

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

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

Сколько именно дополнений разумно ожидать? Если вы согласны с нашим мнением, изложенным в последних двух параграфах, то понимаете, что 0% не будет правильным ответом. Но именно такой ответ подразумевается при нашем обычном планировании нового проекта. Наши рассуждения выглядят примерно так:

Если вы хотите X, мы можем дать вам его через 10 месяцев; если окажется, что вам нужно что-то иное, чем X, это ваши трудности.

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

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

Но какой именно готовностью? В середине 1990-х министерством обороны США было предложено количественное определение того, как должны вести себя хорошо управляемые проекты. Они количественно измерили размер разумно ожидаемых изменений примерно на уровне менее 1% в месяц. Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)). Реальный размер будет где-то посередине, поскольку часть изменений потребует отмены уже выполненных и оплаченных работ.

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

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

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

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

Здесь показано воздействие текучести кадров на одно— и двухгодичные проекты, исходя из среднеотраслевых данных о текучести.

У вас, скорее всего, должны быть приличные собственные данные по этому риску, поэтому стоит заменить ими наши. Инструкции по замене есть на нашем сайте «RISKOLOGY». Чтобы произвести замену вам нужно иметь следующие данные:

• средний процент текучести технического персонала в вашей компании

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

Мы определяем общие потери времени как число месяцев, которое потребуется типичному новичку на достижение того же уровня производительности, который был у замененного им работника. Обычно это время составляет от 2 месяцев на самых простых позициях в IT-отделах до 24 месяцев для компании, производящей очень сложные приложения. Очевидно, что длина этого периода зависит от того, насколько сложна область и насколько она необычна (насколько отличается от опыта и навыков, наличие которых можно ожидать от типичного новичка).

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

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

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

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

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

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

Нарушение спецификаций проявляется и по-другому. Например, в том, что гуру менеджмента Питер Кин (Peter Keen) называет контр-осуществлением, когда недовольные участники проекта перегружают проект все большим и большим количеством функций. Функции A-F используют для оправдания проекта. Но потом те, кто кажется энтузиастами-сторонниками проекта, добавляют функции G-Z. С таким объемом добавленных функций нет надежды на выгоду, превосходящую затраты. Такого рода «заваливание» обычно происходит в конце работы по анализу и приводит к невозможности договоренности по спецификациям.

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

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

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

<…>

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

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

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

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

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

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

Моделирование требует нескольких параметров проекта и дает возможность заменить любой (или все) из главных рисков вашими собственными данными, а затем просчитывает варианты проекта, чтобы определить, какую продолжительность проекта следует ожидать. Данный профиль является результатом 500 отдельных прогонов, даты завершения которых сгруппированы в дискретные диапазоны. Для проекта (названного здесь Amalfi), где N — примерно 26 месяцев, без замещений, результаты моделирования с помощью «RISKOLOGY» похожи на цифры, с которыми вы сталкивались в конце главы 12:

Покажем здесь, как вы могли бы интерпретировать и объяснить результат, если бы таким был ваш проект существует некоторая ненулевая вероятность завершения проекта в период между 26-м месяцем и 27-м месяцем. Значительно вероятнее, однако, что вы будете готовы между 32-м и 34-м месяцами. С 75%-ной достоверностью можно назначить сроком сдачи 38-й месяц. Около 15% прогонов заканчивается прекращением проекта. Это — честная оценка риска прекращения проекта, с точки зрения взгляда на проект с начальной его даты, но за шесть месяцев действия проекта должно стать возможным оценить риск прекращения точнее и, быть может, снять его.

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

Глава 14

Уточненный процесс обнаружения рисков

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

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

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

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

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

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

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

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

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

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

<……>

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

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

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

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

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

ТРЛ: В прошлом году мне нужно было сделать операцию на колене при полном обезболивании. Накануне моей отправки в больницу жена спросила, беспокоюсь ли я из-за этой операции. Я быстро ответил, что ни капельки, что тысячи таких операций проходят без всяких проблем. Немного позже я признался ей, что есть у меня какой-то небольшой, как мне казалось, иррациональный страх. Я боялся, что хирург прооперирует другую ногу. Жена посоветовала сказать врачу об этом. На следующее утро меня подготовили к операции, рядом была жена. Хирург вошел рассказать о послеоперационных процедурах. Жена смотрела на меня, удивленно вскинув брови. Я молчал. Прямо перед тем, как уйти готовиться к операции, хирург взял маркер и написал «Да» прямо над коленом, которое предстояло оперировать. Жена улыбнулась, а за ней и все мы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимовыгодная спиральная модель процессов[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-систем есть отличие: они преобразуют потоки входных данных в потоки выходных данных. Традиционно задача спецификации таких систем сводилась почти полностью к определению правил преобразования, методики и подходов, применяемых системой при преобразовании входных потоков в выходные. Часто в процессе спецификации пропускают строгое и подробное описание самих потоков. Этот пропуск имеет некоторые непреодолимые причины: работа по определению этих потоков часто рассматривается как задача проектирования, которую программисты будут решать на более поздних стадиях. Она может оказаться очень затратной по времени. Откладывание полного определения разумно в проектах, где можно быть уверенными в успешном завершении проекта, но есть ведь и менее везучие проекты, где подробное определение потоков невозможно успешно провести, поскольку это вызовет обострение некоторых конфликтов среди участников проекта. Существование таких «дефективных» проектов вынуждает нас запихивать работу по описанию потоков обратно на раннюю стадию жизненного цикла с намерением заставить конфликт всплыть на поверхность пораньше, не позволяя ему оказаться замазанным на начальных стадиях и неожиданно появиться позднее.

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

Освоенный объем функционала — это система показателей готовности проекта. Она должна говорить вам, насколько далеко вы продвинулись по пути от 0% готовности к 100% готовности.

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

Допустим, что мы заглянули внутрь системы, которую вы намереваетесь построить, и изображаем ее разбитой примерно на сотню основных частей:

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

Вы проявляете 0%-ную готовность до самого конца, а затем внезапно она сменяется 100%-ной готовностью. Единственной причиной верить, что дело обстоит иначе (скажем, верить в некоторый момент, что вы находитесь в состоянии 50%-ной готовности), являются косвенные признаки.

ООФ предназначен для обеспечения объективными свидетельствами частичной готовности, которые позволят вам нарисовать такую картинку и поверить в нее:

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

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

Здесь вы соединяете (как можно лучше) входящие <……> частичным продуктом. Разумеется, частичная система <……> все, что должна делать полная система, но что-то <……> можно тестировать. Итак, вы это тестируете. Вы проводите испытания версии 1 и, когда она их проходит, вы заявляете <……>

Версия 2 имеет больше функций:

Теперь с момента, когда версия 1 проходит свои приемные испытания (ПИ1), вы можете построить кривую, показывающую ожидаемую дату каждого следующего приемного испытания (ПИ)[28]. По мере прохождения этих испытаний можно в такой форме проследить ожидаемый ООФ и соотнести его с реальным:

Проявление любого из главных рисков (или какого-то еще серьезного риска) вызовет заметное отставание реального завершения версий от ожидаемого.

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

Глава 16

Инкрементный метод для ослабления рисков

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

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

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

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

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

• Он может подтвердить гипотезы планирования проекта или доказать их несостоятельность.

• Он требует упорядоченности компонентов системы.

• Он может быть использован для оптимизации выгоды от промежуточных результатов (что особенно приятно в случае, если проект перерасходовал время и/или деньги).

• Он обеспечивает обратную связь относительно истинной эффективности разработки.

• Он дает возможность сравнительно безболезненно прекратить проект, если это окажется необходимо.

Побочным достоинством инкрементной поставки является то, что она облегчает сбор данных для оценки ООФ и его объективных показателей прогресса.

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

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

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

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

Такой реактивный подход не имеет ни одного из тех преимуществ, на которые претендует инкрементный метод.

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

• ценность для заказчика

• подтверждение гипотез о возможных рисках

Это требует установления приоритетов компонентов системы.

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

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

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

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

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

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

Наш коллега Том Гилб смотрит на эту ситуацию с крайних позиций: «Как будто бы я как руководитель проекта не имел бы права знать срок сдачи проекта, пока этот срок не настанет. И у меня была бы единственная, полученная заранее инструкция: „быть готовым упаковать все, что окажется готовым на любое указанное утро, чтобы поставить это клиенту к концу того же дня“. Конечно, это вынудит меня создавать множество версий (поэтому время между версиями будет достаточно мало) и убеждаться, что все самое лучшее будет уже включено в самые ранние версии».

План инкрементной поставки — это формальная взаимосвязь между частями трех других артефактов проекта:

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

• иерархическая структура работ (ИСР): сеть задач, которые должны быть выполнены, и их взаимозависимости

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

Рабочий план обычно представлен в форме иерархии модулей или классов

(Здесь мы выдумали абстрактный черновик вместо того, чтобы отдать предпочтение какому-то определенному представлению плана).

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

Процесс, вкратце, таков:

• Версия идентифицируется по рабочему плану.

• Задачи, связанные с этой версией, — это те задачи, завершение которых демонстрируется приемкой версии.

• Приемное испытание для каждой версии — это набор критериев, которым должен удовлетворять продукт, чтобы объявить, что версия завершена.

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

• номер версии

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

• указатель на приемное испытание

• ожидаемая дата приемного испытания завершенной версии

• реальная дата приемного испытания завершенной версии (для заполнения позже)

• список всех работ в ИСР, которые считаются выполненными при завершении версии

• ООФ данной версии (будет рассмотрена в следующем разделе)

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

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

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

Освоенный объем функционала (ООФ) — это стоимость тех работ, которые были завершены при создании текущей версии продукта. ООФ выражен в процентах от всего бюджета. Запланированные усилия для каждой задачи в ИСР также можно выразить в процентах от целого. ООФ для версии n теперь можно подсчитать, сложив расходы на все те задачи, чье завершение продемонстрировано прохождением приемного испытания (ПИ)n.

Рассмотрим следующий простой пример: проект с 10 работами в ИСР, где есть 100 человеко-недель трудозатрат по графику и план инкрементной поставки n для пяти версий:

Проект целиком завершен, когда версия 5 проходит через приемные испытания ПИ5 (поскольку V5 — окончательная версия, то ПИ5 — приемное испытание для продукта целиком). В этой точке 100% объема освоено. ООФ, связанный с прохождением приемных испытаний отдельных версий, составляет:

ПИ1: 30%

ПИ2: 49%

ПИ3: 69%

ПИ4: 78%

ПИ5: 100%

Рисунок реального ООФ, показанною как функция от времени, выглядит так:

Значение завершенного ООФ в единицу времени дает плавную кривую для проекта. Эта плавная кривая — самый сильный из возможных показателей завершенности проекта. Отклонения этой кривой от ожидаемого вида являются безусловным признаком проявления риска и служат призывом к действиям по запуску запланированных стратегий сдерживания риска.

Инкрементный метод в процессе разработки продукта — главный источник показателей завершения, а показатели завершения — пульс проекта. Осуществляя мониторинг ООФ и отслеживание реальной производительности в терминах ООФ, вы используете показатель «голоса продукта». Сам продукт говорит вам: «Я на столько-то % готов и могу доказать это». Доказательством, конечно, служит прохождение приемного испытания версии, которая включает указанный процент освоенного объема всего проекта.

Отслеживание ООФ — основной источник обратной связи по поводу рисков от середины проекта (или даже чуть раньше) до самого конца. ООФ дает показатель «голоса продукта», причем добавляет совсем мало затрат к проекту.

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

1. больше возможностей для мотивации персонала проекта

2. большая прозрачность

3. большее привлечение пользователя в проекте с середины до конца

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

Инкрементный метод хорош для всех проектов… и является обязательным, когда риски высоки.

Глава 17

Стратегия максимального ослабления рисков

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

Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за пять-десять до начала совещания.

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

Тут не требуется быть семи пядей во лбу. Не требуется умения читать чужие мысли, чтобы угадать, что вашим первым импульсом будет найти возможность более раннего вылета. Рейс на рассвете (в б утра) не вызывает восторга, но зато оставляет в запасе пару часов. А что если прилететь накануне вечером и обосноваться в отеле рядом с офисом?

Ваш «проект» в данном случае состоит в попадании в Сан-Франциско. Самое важное для вас — выполнить его своевременно, наиболее естественное решение для вас — раньше приступить к проекту. Это каждому понятно, то есть, разумеется, кроме разработчиков IТ-проектов.

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

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

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

Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:

Это — робкое руководство в худшем своем проявлении.

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

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

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

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

Я уточнил у него по поводу этого заявления: «Ганс, а эта цифра относится к сроку завершения до 31 марта? Если бы мы завершили к концу февраля, например, получили бы мы дополнительно 110000 долларов прибыли, сверх запланированного вами дохода?»

«Да, — сказал он. — Наверняка».

«А если бы закончили к концу января? — настаивал я. — Дало бы это еще 110000 долларов прибыли?»

«Да», — ответил он.

«А если бы мы могли вручить вам готовый продукт сегодня (это было в феврале 1996 года, когда только было открыто финансирование проекта) вы бы получали дополнительно по 110000 долларов ежемесячно до конца года?»

«Да», — ответил он, теперь несколько потеряв былую самоуверенность.

«Ну тогда, Ганс, очевидно, что вы слишком поздно начали этот проект. Если бы вы дали старт 18 месяцев назад, мы бы могли уже отгружать этот продукт и получать все эти месяцы по 110000 долларов дополнительной прибыли…» Я предоставил ему самостоятельно понять, что подразумевалось.

• Сколько риска можно себе позволить?

• Как ценность компенсирует риски?

• Как можно реалистично оценить ценность (выгоду) нового проекта?

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

• Как обращаться с выгодой, которая представляет собой неопределенную величину?

• Какой смысл в обосновании выгод и затрат, которое пытается сравнить неопределенные затраты с неопределенной выгодой?

Глава 18

Количественная оценка ценности

Вначале, на заре IT-индустрии, обоснование для создания новых продуктов было очень простым. Системы, которые тогда устанавливали, обычно заменяли ручной труд клерков. Экономия трудозатрат и была мерилом выгоды, а затраты на разработку системы — издержками. Анализ выгод и затрат и вывел простые соотношения типа:

Прибыль на инвестиции =(Ценность — Затраты) / Затраты

Для демонстрации своего почтения к стоимости денег во времени, мы выражали различные потоки затрат и сбережений в терминах чистой приведенной стоимости (NPV). Мы могли бы и проще выразить это в формулировке типа «решение запустить проект сейчас равноценно добавлению сегодня в денежный сундук корпорации чистой приведенной стоимости в размере 1,3 млн долларов».

Порой обоснование принимало слегка иную форму:

ТДМ: Одной из первых моих обязанностей менеджера было управление проектом по установке программы централизованного биллинга для French National Merchandise Marte La Villette (Париж). Планировалась замена старой системы, находившейся в филиале в Les Halles. В La Villette вся биллинговая информация передавалась в цифровой форме. Ручная система для исполнения той же функции в Les Halles использовала сеть пневматических труб для отсылки квитанций и счетов, которые под давлением воздуха носились со свистом по всему этажу. Сеть пневматических труб была установлена в Les Halles во времена Всемирной выставки в 1897 году. В 1897 году еще почти не было резиновых изделий, чтобы обеспечить герметичность, поэтому трубы были целиком сделаны из свинца. Когда строили Les Halles, цена свинца составляла всего несколько сантимов за килограмм. Когда мы их демонтировали, цена свинца составляла более семи франков за килограмм. А там было очень много свинца. Денег, вырученных при сдаче свинца в утиль, хватило для оплаты всего проекта, включая аппаратное оборудование и программное обеспечение.

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

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

Затраты = $6235812,55

Выгоды = «Нам это необходимо»

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

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

Все это ведет к неизбежному принципу:

Затраты и выгоды следует определять с одинаковой точностью

Когда выгоду нельзя указать точнее, чем «Нам это необходимо», тогда и указание по затратам пусть будет «это окажется дороговато». Если затраты указаны в диаграмме риска, выгоды должны быть указаны в такой же форме (подробнее об этом см. главы 21-23).

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

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

Оправдания для плохо прогнозируемых выгод стали удивительно искусными. Наиболее типичен такой вариант:

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

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

• Система слишком мала для нас, чтобы стоило беспокоиться о ней.

• Нет выбора, создавать или не создавать эту систему.

• Создать систему требует контролирующий орган.

• Выгода полностью определяется соответствием потребности рынка.

• Система является заменой ныне действующей системы.

• Заявка исходит с самого верха.

• Выгода слишком неопределенна и не поддается количественной оценке.

• Заказчик сказал: «Поверьте мне, это стоит сделать».

• Оценка выгоды все равно не будет правдоподобной.

По этому последнему пункту наш коллега Стив МакМенамин, в бытность вице-президентом Edison International, отметил следующее:

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

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

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

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

ТРЛ: В 1990-х годах многие из моих клиентов зациклились на улучшении неправильных процессов. Они все помешались на процессе построения проектов. Единственный по-настоящему значимый процесс — это тот, который определяет какие проекты стоит осуществлять. По иронии судьбы, в некоторых из известных мне компаний, особенно озабоченных процессами, не существует определенного процесса инициации проекта — это делается авторитарным решением.

Настойчивое утверждение того, что ответственность за выгоду от системы эквивалентна ответственности за расходы, ведет к следующей схеме расчета выгоды:

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

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

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

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

• Руководство оценивает фактическое значение выгоды и проводит оценку для получения входных данных для процесса анализа после завершения проекта.

Этот подход примерно совпадает с тем, что Барри Боэм (Barry Boehm) называет разработкой программного обеспечения на основе ценности (Value-Based Software Engineering). Боэм так комментирует необходимость стоимостной основы:

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

Глава 19

Ценность — это тоже неопределенность

Участники проекта часто отговариваются от оценок выгодности новой системы, потому что считают, что она слишком неопределенна для прогнозов. Самое честное, что они могут придумать в ответ на вопрос об ожидаемой выгоде: «Я не знаю». Им нужна та же автоматическая реакция, к которой мы призывали вас в главе II: при произнесении слов «я не знаю» переключаться в режим указания границ неопределенности и начинать строить диаграммы неопределенности.

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

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

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

Легко говорить о будущих рыночных нишах, но существует до крайности мало примеров, которые можно выкопать из прошлого. VisiCalc явно получила свой продукт до того, как заполнилась какая бы то ни было рыночная ниша, но как объяснить Lotus Notes? А всякая рыночная ниша для электронных таблиц была забита до отказа задолго до появления Excel. Как же понять тогда, что Excel стал доминирующей системой электронных таблиц? Или Google, далеко-далеко промахнувшийся мимо своей рыночной ниши, по этой теории никак не мог стать доминирующим на рынке поисковиков, но ведь как-то стал им!

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

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

Картинка, возникшая из этих неформальных мнений, сама похожа на сэндвич, упомянутый в одной из цитат, но все же можно проследить пару занятных тенденций:

1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.

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

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

Глава 20

Анализ чувствительности

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

Проблема, на которую мы здесь нацелились, состоит в том, что большинство проектов разработки программного обеспечения по своей природе комплексные. Проект получает финансирование на основе какой-то ценности — либо имеющей явное количественное выражение, либо нет — которую должен принести полученный в результате продукт. Теперь стоит задать несколько вопросов: «В чем ценность этого продукта? Равномерно ли она распределена между всеми компонентами системы? Одинакова ли ценность этого модуля объемом в сто строк и того модуля (тоже из 100 строк), который восстанавливает конфигурацию после потери питания?»

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

Иногда эта область, концентрирующая в себе основную ценность, составляет не более 10% кода. А остальное… ну, что это может быть? Иногда — необходимое инфраструктурное обеспечение, а в другой раз — явно «прибамбасы», маскирующиеся под необходимую инфраструктуру. Анализ чувствительности и состоит в том, чтобы прорубиться через это маленькое заблуждение.

Как только мы разбили систему на куски (скажем, функции в период спецификации или модули в период разработки), возможно и разумно распределить предполагаемые затраты по карте этого разбиения. Так, доля системы, стоящая порядка $235000, могла бы иметь график затрат такого вида:

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

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

То, что выгода неоднородна внутри системы, дает полезный тактический инструмент IT-менеджеру. Системные проекты отличаются проявлением отрицательных последствий, обусловленных изменением масштаба: при удвоении размера системы следует ожидать, что усилия для ее создания возрастут больше, чем вдвое. Эта нелинейность усилий по отношению к размеру системы хорошо документирована Боэмом[31] и другими:

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

Ладно, посмотрим фактам в лицо: заставить заказчиков предсказывать выгоды — все равно, что удалять зубы. Это большой объем работы, открывающий дверь дополнительному уровню ответственности, причем усилия тех, кто подставляет себя под удар и занимается количественной оценкой, явно не окупятся. Если среди полезных функций затесались «прибамбасы», то люди, которые должны сделать количественную оценку, вполне могут оказаться теми, кто потеряет свои любимые игрушки. Можно ожидать практически от любого заказчика яростных возражений и уверений самым серьезным тоном, что «все это необходимо для поддержки основной функциональности, честное слово». Это та же самая старая и надоевшая песня про равномерно распределенную стоимость, но не рассчитывайте их в этом убедить.

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

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

Глава 21

Выгоды возмещают риски

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

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

Это мышление — порождение одного из самых распространенных, но постыдных стилей работы в нашей отрасли…

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

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

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

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

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

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

Реальное обоснование проекта (вы всегда знали это в глубине сердца) требует сбалансированности риска и выгоды, как показано на рисунке:

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

Глава 22

Уточнение правил управления рисками

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

Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект (пункты 6-12 включают больше всего изменений по сравнению со списком в главе 10, но мы, конечно, рассмотрим заново весь процесс):

1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту

2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.

3. Проведите всю указанную предварительную подготовку по каждому из рисков:

• Дайте наименование риску и присвойте ему уникальный номер.

• Проведите мозговой штурм для выявления показателей наступления события риска.

• Оцените влияние наступления риска на стоимость и расписание проекта.

• Оцените вероятность наступления риска.

• Рассчитайте подверженность риску в терминах расписания и бюджета.

• Определите заранее, какие меры придется принять, если и когда событие риска наступит.

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

• Включите действия по ослаблению риска в обший план проекта.

• Опишите все детали в специальной форме, шаблон которой приведен в Приложении Б.

4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.

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

6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.

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

8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.

9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.

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

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

12. Оцените выгоды с той же точностью, что и затраты.

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

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

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

16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.

17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте отклонения как признак возможного наступления риска.

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

Как узнать, осуществляется ли на практике управление риском или нет?

Глава 23

Тест на управление риском

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

Представьте, что вы — руководитель более высокого уровня, чем тот, на котором находится рассматриваемый проект, а управление риском должно происходить на уровне проекта (внутри проекта или на том же уровне). Ложно-положительный показатель действует на уровне таких рассуждений: «Угу, мои люди ведут рискованные проекты, поэтому, конечно, они управляют рисками. В чем же состоит управление, в конце концов, если не в предвидении и поисках путей обхода различных препятствий, которые могли бы погубить проект? Разумеется, мои менеджеры — профессионалы: они не позволят себе обращать фокусироваться на ерунде и игнорировать реальные опасности».

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

Это — мощные силы. Они могут заставить несомненно думающих людей отказываться от разумного управления и принимать вместо него разумное на вид управление. Есть разница.

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

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

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

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

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

4. Имеются цели и оценки проекта, и они никогда не совпадают. Цели могут быть на уровне «нанопроцентной даты» или рядом с ней, а оценки должны быть гораздо более консервативными. Если целью данного проекта является поставка продукта через 12 месяцев, то оценка должна планировать поставку хотя бы месяцев через восемнадцать. В любом случае, конкретный уровень доверия, который связан с любым обстоятельством, должен быть указан диаграммой неопределенности.

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

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

7. Оценивается подверженность каждому из рисков.

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

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

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

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

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