Вальсируя с медведями - Том ДеМарко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потрясенные, разочарованные и перепуганные

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

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

Аналогия с автогонками Indy 500[15]

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

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

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

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

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

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

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

Часть III

Как?

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

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

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

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

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

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

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

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