• Клинический случай 2. Подрядчик строит систему взамен существовавшей для компании, которая недавно прошла через процедуру слияния с другой компанией. Подрядчик предложил использовать набор модулей программного обеспечения от производителя, поставляющего программные решения, добавив некоторую индивидуальную подгонку, поскольку новая система предназначалась для организаций, прошедших слияние. Пакеты программ закуплены, новое оборудование установлено. Риски перечислены, статусные встречи проведены. С самого начала клиент неоднократно заявляет, что ему необходимо иметь новую систему или какое-то временное решение к Дню труда, поскольку пик активности его бизнеса приходится на промежуток между Днем труда и Рождеством. Все представители клиента повторяют это, как мантру. Ни разу по мере того, как утекали месяц за месяцем, в перечне рисков или в отчетах по проекту не появлялся риск «мы можем не успеть пустить новую систему к сентябрю». Эту возможность просто было слишком страшно рассматривать. Пролетел День труда. Прошел День благодарения, затем и Рождество. В январе руководитель компании-заказчика разорвал договор, выбросил вон весь персонал подрядчика и подал иск в суд.
Интересно, что у проекта был перечень рисков. Когда мы просмотрели все последовательные версии этого перечня с первого дня до прекращения проекта, обнаружилась удивительная вещь: риск того, что фирма-субподрядчик может прикрыться, прозвучал на ранней стадии проекта, но был тогда, очевидно, удален из списка и больше не появлялся.
Это тот же тип избирательной близорукости, о котором мы говорили выше, но проявившийся после совершения события. Руководство взглянуло в ужасе на потенциально роковой риск, появившийся в перечне. Пока он был в списке, большой босс обвиняюще смотрел на всех. Какому-то бедолаге велено было «разобраться с этим риском и убедиться наверняка, что он в достаточной мере под контролем, чтобы можно было его убрать из перечня ровно через неделю».
Возможно, нет лекарства для уже зараженных, но есть вакцина для защиты еще неинфицированных, показавшая многообещающие результаты. Вакцину нужно применять в самом начале любых попыток управления риском. При первом проходе по кругу в процессе определения рисков введите вакцину каждому путем перечисления всех катастрофических результатов, какие только сможете вообразить. Потребуйте, чтобы группа назвала еще больше катастроф. Пока не начинайте никакого управления рисками. Проговорите слова «провал», «неприятие» и «прекращение» (если вы пытаетесь проговорить их, а они у вас не выходят, вы уже заражены и нуждаетесь в профессиональной помощи). Если вы можете проговорить эти слова, убедитесь, можете ли вы заставить также и других произнести их прилюдно. Теперь, отталкиваясь от списка катастроф, потребуйте сценарии, ведущие к каждой из них. Рассмотрите поочередно все сценарии и попытайтесь описать риски, которые вызывают их. Теперь у вас есть первоначальный список рисков, который может отражать будущие факты.
Мы вернемся к этому методу нахождения рисков в главе 14, где будут изложены его процедуры и некоторые хитрости, чтобы он сработал. Пока ограничимся сутью метода: атакуйте свои ночные кошмары, а не только незначительные тревоги, чтобы обнаружить риски, имеющие действительно важное значение для вашего проекта, отслеживайте их в обратном порядке (от результата к причине). Бдительно следите за приближающимися поездами.
Глава 7
Часть III
Глава 8
Вариации на тему
ТДМ: Я участвовал в судебном разбирательстве, рассматривая останки проекта, который застрял на полпути. Многое шло наперекосяк, но по-настоящему роковым оказалось то, что субподрядчик был буквально завален обязательствами, которые на себя взял. В итоге он просто пропал. Маленькая фирма прогорела, и больше о ней не было ни слуху, ни духу.Интересно, что у проекта был перечень рисков. Когда мы просмотрели все последовательные версии этого перечня с первого дня до прекращения проекта, обнаружилась удивительная вещь: риск того, что фирма-субподрядчик может прикрыться, прозвучал на ранней стадии проекта, но был тогда, очевидно, удален из списка и больше не появлялся.
Это тот же тип избирательной близорукости, о котором мы говорили выше, но проявившийся после совершения события. Руководство взглянуло в ужасе на потенциально роковой риск, появившийся в перечне. Пока он был в списке, большой босс обвиняюще смотрел на всех. Какому-то бедолаге велено было «разобраться с этим риском и убедиться наверняка, что он в достаточной мере под контролем, чтобы можно было его убрать из перечня ровно через неделю».
К счастью, существует вакцина
В чем причина болезни «не-могу-увидеть-приближающийся-поезд»? Мы не выделили возбудитель инфекции, но имеется множество признаков. Возможно, у этих организаций нет таких мышц, чтобы суметь выговорить слово «катастрофа». Они убеждают себя, что держат под контролем все риски, то есть потенциальные проблемы, но на самом деле имеют дело только с подгруппой этих потенциальных проблем, для которой у них есть противоядие.Возможно, нет лекарства для уже зараженных, но есть вакцина для защиты еще неинфицированных, показавшая многообещающие результаты. Вакцину нужно применять в самом начале любых попыток управления риском. При первом проходе по кругу в процессе определения рисков введите вакцину каждому путем перечисления всех катастрофических результатов, какие только сможете вообразить. Потребуйте, чтобы группа назвала еще больше катастроф. Пока не начинайте никакого управления рисками. Проговорите слова «провал», «неприятие» и «прекращение» (если вы пытаетесь проговорить их, а они у вас не выходят, вы уже заражены и нуждаетесь в профессиональной помощи). Если вы можете проговорить эти слова, убедитесь, можете ли вы заставить также и других произнести их прилюдно. Теперь, отталкиваясь от списка катастроф, потребуйте сценарии, ведущие к каждой из них. Рассмотрите поочередно все сценарии и попытайтесь описать риски, которые вызывают их. Теперь у вас есть первоначальный список рисков, который может отражать будущие факты.
Мы вернемся к этому методу нахождения рисков в главе 14, где будут изложены его процедуры и некоторые хитрости, чтобы он сработал. Пока ограничимся сутью метода: атакуйте свои ночные кошмары, а не только незначительные тревоги, чтобы обнаружить риски, имеющие действительно важное значение для вашего проекта, отслеживайте их в обратном порядке (от результата к причине). Бдительно следите за приближающимися поездами.
Глава 7
Удача
ТРЛ: Удачи вашему следующему проекту… но не рассчитывайте на нее.
Если вы предпочли игнорировать риск, вы зависите от удачи, которая не допустит, чтобы нежелательная вещь случилась. Это может быть весьма разумно в отношении некоторых рисков, но никак не всех. Здесь существенно, что сказано «не всех», потому что распространенной патологией является решение полагаться на удачу в отношении всех рисков. Однако, просто для сведения, перед рассмотрением этой патологии взглянем на типы риска, которые можно резонно исключить из сферы управления.
Например, часто рассматриваемый на наших семинарах по управлению рисками «астероид, уничтожающий компанию». Каковы характеристики астероидного риска, делающие его совсем не стоящим управленческих попыток? Мы называем две:
1. Вероятность материализации риска достаточно мала, чтобы ее можно было игнорировать.
2. При материализации риска делается ненужным усилие, являющееся объектом управления (создаваемый вами программный продукт).
Может возникнуть искушение добавить сюда третью характеристику: мы мало что можем сделать в отношении этого риска, если бы он материализовался. Хотя это справедливо, но это само по себе не является законной причиной для решения игнорировать какой-либо риск. Некий риск может быть роковым для проекта, но может не быть роковым, с точки зрения некоторых участников проекта. Те, кто скорее всего выживет, должны управлять тем риском, который может оказаться роковым для остальных.
Две указанных выше причины позволяют вам проигнорировать астероидный риск. А вот еще две резонные причины отказаться от попыток управлять риском:
1. У риска незначительные последствия, и потому он не требует ослабления.
2. Это — чужой риск.
Конечно, спокойно проигнорируйте риск типа «Тед может захворать во вторник», поскольку эту потерю времени легко покрыть из предполагаемых мелких расходов. Только убедитесь, что этот риск не из тех, чьи последствия минимальны только при предварительной подготовке к ним. Если он именно из таких рисков, и вы хотите, чтобы с ним можно было справиться небольшими усилиями в случае его материализации, то не забудьте проделать необходимую предварительную работу. Если риск относится к кому-то другому, а не к вам, то обсуждение этого случая смотрите в главе 9.
Мы определили четыре достойных причины не управлять некоторыми рисками. Неудивительно, что большинство рисков, с которыми сталкивается ваш проект, не попадет ни в одну из этих четырех категорий. Именно они и составляют ваши реальные и значимые риски.
Почему в каких-то случаях вы не управляете реальными и значимыми рисками, угрожающими вашему проекту, а вместо этого рассчитываете на удачу, надеясь, что она им воспрепятствует? Например, положим, что проект попал к вам в форме личного вызова такого типа: «Я знаю, апрель — это трудный срок, потому-то я и поручаю эту работу вам!»
Когда проект появляется как вызов, он вынуждает рассчитывать на некоторую долю удачи. Если босс говорит вам, например, что вы и восемь ваших подчиненных — последняя и главная надежда компании сделать основную часть работы к апрелю (стон: «Президент компании опять разговаривал прессой!»), что еще вам остается? Что, если ваш босс смотрит вам прямо глаза и умоляет совершить это ради всего святого? В такой ситуации вы должны будете лишь постараться приложить все усилия и скрестить пальцы в надежде на удачу.
Вы сознаете, что невозможно сделать работу к апрелю, если вам не будет сопутствовать везение в каких-то важных вопросах. Ловля этих счастливых случаев становится составной частью вашего плана работы над проектом. Это являет собой полную противоположность управлению рисками, где ваше планирование проекта уделяет пристальное внимание тому, что делать, если вам не улыбнется удача.
Проекты, начатые как личные вызовы, редко отличаются разумным управлением рисками. Они зависят от удачи. Вы вряд ли сможете с этим что-то поделать, если проект попал к вам таким образом, но вы можете сделать выводы на будущее. Если вы сами оказались в роли инициатора проекта, убедитесь, что не преподносите его так, чтобы план строился на везении. Ставьте обоснованные гибкие цели, но убедитесь, что реальные ожидания оставляют место для счастливого случая, который не происходит.
Все же тактика открытого признания в том, что вы потрясены, разочарованы и перепуганы, когда не удается поймать все счастливые случаи, одобряет следование плану, зависящему от поимки этой удачи. Но зависимость от удачи в достижении успеха неприемлема, это — чистое ребячество.
На мгновение оценим перспективу: вы за рулем уже 2 часа 14 минут, немудрено, что вы устали. Это 198 круг. До финиша меньше 5 миль. Чтоб вы ни делали, не ослабляйте усилий. Продолжайте жать на газ, но играйте наверняка, потому что заезд уже почти выигран. На самом деле, единственная реальная угроза — команда Team Green. Они все еще преследуют вас, но вы прилично оторвались. Вы твердо держитесь курса и не расслабляетесь. Только краешком сознания вы следите за чем-то, кроме вождения: этот краешек прислушивается к сигналу тревоги относительно топлива. Вы бросаете взгляд на прибор — стрелка на нуле. Но осталось всего несколько миль. Ваша техническая бригада призывно машет вам, но такая остановка сейчас означает поражение. Звук мотора на редкость ровен. Вы выкладываетесь, сохраняя свое положение между ребятами из Team Green и финишем. Последний круг. Вот оно — вы побеждаете! Но постойте, мотор зачихал. Он кашляет, вы начинаете терять темп. Ну же! Вы подгоняете машину изо всех сил, но мотор уже заглох. «Первым пересечь черту, — думаете вы, — все равно победа, даже если вы двигаетесь накатом». Вы продвигаетесь накатом, ближе, ближе, ближе, еще ближе к линии финиша… но останавливаетесь, не дотянув всего несколько футов. Team Green с ревом проносится мимо.
Что произошло? Вы приняли просчитанное решение пропустить техническую остановку, чтобы сохранить хоть какой-то шанс на победу. Вы охотно пошли на риск не финишировать вообще ради удержания, пусть и отдаленной, надежды на победу.
Это вполне разумно для гонщика Indy 500. Но вы им не являетесь (Извините). Вы — руководитель проекта по созданию программного обеспечения. Такое умонастроение в проекте по созданию программного обеспечения — катастрофа. Когда вы все ставите на карту ради победы, вы можете так увеличить последствия неудачи, что они выйдут далеко за пределы допустимого.
Это — странный, но верный расчет как правило, гораздо важнее ограничивать уровень потерь в процессе разработки программного обеспечения, чем идти на все ради победы. У каждой организации в этой области бизнеса случаются неудачи. Те, кто сильнее пострадал от своего поражения (как ДМА) — неудачники, даже если они в некоторых других случаях одерживали победы.
Когда вы требуете от своих подчиненных работать без остановок и выполнить проект вовремя любой ценой (даже если сроки абсурдны), вы должны понимать, что укомплектовываете ключевые должности гонщиками NASCAR. Они пойдут на любой риск, пренебрегая всевозможными срывами, ради того, чтобы сохранить (по крайней мере, как можно дольше удержать) любой малейший шанс на победу.
Назовите это, как хотите, но это не является управлением рисками.
Если вы предпочли игнорировать риск, вы зависите от удачи, которая не допустит, чтобы нежелательная вещь случилась. Это может быть весьма разумно в отношении некоторых рисков, но никак не всех. Здесь существенно, что сказано «не всех», потому что распространенной патологией является решение полагаться на удачу в отношении всех рисков. Однако, просто для сведения, перед рассмотрением этой патологии взглянем на типы риска, которые можно резонно исключить из сферы управления.
«Мы рискнем в таком случае»
Можете ли вы вообразить реальный риск (нечто плохое, что вполне может произойти и непременно повлечь ужасные последствия), которым нет смысла управлять? Такой, что его даже и в перечень вносить не стоит?Например, часто рассматриваемый на наших семинарах по управлению рисками «астероид, уничтожающий компанию». Каковы характеристики астероидного риска, делающие его совсем не стоящим управленческих попыток? Мы называем две:
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
Как?
• Как мы решаем проблему управления рисками?
• Раз неизвестные нам неизвестны, как мы можем их количественно оценить?
• Какие существуют инструменты для этого?
• Откуда берутся данные для управления рисками?
• Что такое резервы на управление рисками, и как их используют?
• Что можно сделать в отношении риска, кроме отслеживания его?
• Что такое повторяющиеся риски проектов по разработке программного обеспечения, и что о них известно?
• Как мы вообще обнаруживаем риски?
• Раз неизвестные нам неизвестны, как мы можем их количественно оценить?
• Какие существуют инструменты для этого?
• Откуда берутся данные для управления рисками?
• Что такое резервы на управление рисками, и как их используют?
• Что можно сделать в отношении риска, кроме отслеживания его?
• Что такое повторяющиеся риски проектов по разработке программного обеспечения, и что о них известно?
• Как мы вообще обнаруживаем риски?
Глава 8
Количественное определение неопределенности
Разработка программного обеспечения — рискованный бизнес, поскольку весь процесс окутан неопределенностями. Все, что нужно предсказать относительно проекта, будет в какой-то мере неопределенным. Но насколько именно?
Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 6-го числа, но немного сомневалась, будет ли это несколькими днями раньше или позже. Или, возможно, она совсем понятия не имела о сроке завершения. Ясно, что между этими двумя уровнями неопределенности колоссальная разница. Представьте это так: вы — руководитель проекта, и вы стремитесь завершить проект по графику к 30-му октября. У вас есть четкое ощущение, что 30-е октября — абсолютно нереально, но точнее вы ничего сказать не можете. Вы совершенно беспомощны. Ваши подчиненные также в полном неведении. Таким образом, примерно в середине лета, уже отставая от срока на четыре месяца, вы приглашаете консультанта. Выбранный вами консультант — лучший в данной области, способный правильно оценить проект даже во сне и определить его состояние. Через несколько дней погружения в технические условия и промежуточные результаты, а также встреч с исполнителями и акционерами, он заявляет напрямик:
Консультант сказал, что вероятность завершения проекта равна нулю для всех дат до 1 января, но счел почти невероятным предположение, что после 31 декабря следующего года потребуется дополнительное время (поскольку был практически уверен, что проект будет к этому сроку завершен); наиболее вероятной датой завершения проекта он назвал 1 апреля. Исходя из этого, можно заполнить эти два полуинтервала и обозначить пик кривой. Поскольку на вертикальной оси пока не задан масштаб, можно поместить пик произвольно, не заботясь о его точном значении. Это выглядит так:
Остается только заполнить середину, стараясь, чтобы площадь под кривой левее 1-го мая была примерно равна площади справа (подробнее об этом будет сказано дальше). Мягкая кривая, удовлетворяющая этим ограничениям, выглядит так:
Полученный результат представляет собой некий тип диаграммы неопределенности, называемый диаграммой риска. Диаграммы риска рассмотрены в главе 10, где вы узнаете больше об их свойствах и применении. Пока же вы, видимо, уже отметили основное:
• Площадь под кривой представляет собой общую вероятность завершения проекта к данной дате, поэтому, если треть площади лежит слева от 1 апреля, то это значит, что вероятность завершения к 1 апреля или раньше составляет примерно 33%.
• Площадь под всей кривой равна 1,0 в соответствии с оценкой консультанта, что работа будет завершена в период с 1 января до 31 декабря следующего года.
Например, диаграмма сразу же поможет понять многое из того, что происходило в отрасли, производящей программное обеспечение, в последние несколько десятилетий. Одна общая жалоба, которую разделяют с нами руководители проектов, состоит в том, что «самая ранняя из произнесенных дат автоматически превращается в крайний срок сдачи». Если обнародовать слова консультанта о том, что «нет шансов завершить работу до начала следующего года», то это тут же приведет к назначению вам жесткого срока сдачи на 1 января. Но на диаграмме риска площадь под кривой слева от 1 января равна нулю:
Это означает, что вероятность сдачи к этому сроку катастрофически мала. Патология установления срока сдачи по самой ранней из произнесенных дат, по сути, гарантирует, что график будет сорван.
Даже стратегия выбора «наиболее правдоподобной даты» не слишком надежна, поскольку площадь слева от пика едва составляет треть. Это означает, что с вероятностью 2/3 к этому сроку система не будет готова. Да, это наиболее правдоподобная дата из всех, но все же не очень правдоподобная.
Выбор даты прямо посередине (когда половина площади будет справа и половина — слева) дает всего лишь один шанс из двух возможных, что завершение проекта произойдет вовремя. Действительно, выбор любой точечной даты на диаграмме риска проблематичен, зато очень разумно рассматривать вместо этого всю диаграмму риска, как график работ. Нельзя не признать, что в нем есть неопределенности, но простой выбор даты и назначение ее сроком сдачи не устраняет этой неопределенности, а просто скрывает ее от людей, которым вы дали обязательство. Проверка «взрослости» организации состоит в том, что менеджеры всех уровней учатся жить с обязательствами, для которых в явном виде установлены границы неопределенности.
Совершенно бессмысленно брать обязательство на поставку в день N, но тем не менее это — важная дата. Она важна, поскольку является чем-то, к чему у нас есть врожденная привычка. Весь наш опыт оценок до сих пор учил нас тому, как оценить N, но затем ошибочно вел нас к тому, чтобы считать N датой сдачи. Этот второй шаг плох, но наш с трудом обретенный навык вычисления дат с вероятностью нанопроцента может и должен послужить нам во благо.
В явном виде указанная неопределенность позволяет рисковать. Без этого можно идти только на незначительный риск, но серьезные и компетентные руководители никогда не пойдут на большой риск без достоверной оценки того, насколько он велик. Сокрытие размеров неопределенности не помогает обманом втянуть таких руководителей в принятие рисков, которые, возможно, предстоят. Наоборот, при высоких рисках это подрывает доверие руководителей к тем самым людям, на которых им нужно положиться.
Итак, все это легко бы сошло, если бы допуск неопределенности можно было удержать в небольших пределах. Но можно ли это сделать? Конечно, можно быть ярым сторонником диаграмм риска, если диаграмма для вашего проекта выглядит так:
Здесь диапазон неопределенности представляется разумной долей от длительности с начала проекта до N.
Но предположим вместо этого, что ваша диаграмма риска выглядит так:
Совсем несимпатично в этой картинке то, что неопределенность слишком велика по сравнению с интервалом от начала проекта до N.
Если вы такой же, как и остальные из нас, руководителей проектов по созданию программного обеспечения, то вам комфортно при допуске порядка 10-15% времени от интервала с начала проекта до N и тревожно при любых больших значениях, то есть тревога возрастает по мере роста диапазона допуска свыше 15%.
Неудачи прежних проектов и их политики приучили нас к мысли, что подходящим диапазоном допуска является 10-15% от интервала с начала проекта до N. То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления.
Однако всё это не имеет никакого значения. Размер вашего допуска неопределенности является производным от того, сколь велик шум (отклонения) в процессах разработки, принятых в вашей организации, и не имеет никакого отношения к тому, что кому-то кажется подходящим.
Шум — источник отклонений от одного проекта к другому, объяснение того, почему некоторые проекты занимают больше времени, несмотря на все ваши усилия. До некоторой степени шум является количественной оценкой последствий прошлых рисков, величина шума может быть эмпирически определена для любой организации, которая ведет хотя бы элементарные записи деятельности. Эта цифра устанавливает, сколько неопределенности должно быть в вашем следующем проекте. Другими словами, ваша прежняя деятельность определяет размер диапазона допуска.
В целом для отрасли, производящей программное обеспечение, диапазон допуска составляет порядка 150-200% от интервала с начала проекта до N. Таким образом, у проекта с N, приходящимся на 25-е число какого-то месяца, дальний конец диапазона кривой неопределенности придется на 75-е число. От вас не требуется испытывать восторг по этому поводу. Просто так устроен мир. Бесполезно притворяться, что дело обстоит иначе.
Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 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-е число. От вас не требуется испытывать восторг по этому поводу. Просто так устроен мир. Бесполезно притворяться, что дело обстоит иначе.