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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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