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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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