Вальсируя с медведями

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

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

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

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

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

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

Аналогия с автогонками 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

Как?

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

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

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

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

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

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

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

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

Глава 8

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

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

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

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

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

Та же идея в графическом изображении

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

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

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

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

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

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

Что говорит нам диаграмма риска о распространенной сегодня практике

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

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

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

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

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

Дата с вероятностью нанопроцента[16]

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

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

Да, допустимый диапазон, но насколько он велик?

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

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

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

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

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

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

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

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

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

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

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

Глава 9

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

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

Поль Рук[17]

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

Может быть, мы не так уж плохо оцениваем

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

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

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

Вчерашняя проблема

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

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

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

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

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

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

Ладно, мы перечислили риски, и что теперь с ними делать?

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

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

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

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

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

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