Пользовательский поиск

Книга Вальсируя с медведями. Содержание - Глава 13 Основные риски проекта по разработке программного обеспечения

Кол-во голосов: 0

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

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

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

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

Вальсируя с медведями - pic_9.jpg
Ладно, мы перечислили риски, и что теперь с ними делать?

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

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

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

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

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

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

• Вам удастся от него увернуться.

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

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

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

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

Первые три способа стоят денег: избежание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. Только когда вам удается увернуться от риска, это дается бесплатно.

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

Управление рисками и опасения за свой проект – это не одно и то же.

Как оказалось, вам удалось увернуться от всех трех рисков. Как судовладелец в примере Клиффорда, вы не подтвердили свою правоту. Просто ваша ошибка не всплыла. Есть разница.

Всем нам случается порой увернуться от каких-то рисков, чему мы бываем очень рады. Однако планировать проект с учетом того, что вам удастся увернуться от рисков, вряд ли является хорошей стратегией. Даже краткий перечень рисков, состоящий всего из дюжины пунктов, предполагает весьма низкую вероятность того, что удастся уклониться от всех двенадцати. Если у каждого из них вероятность всего лишь 10%, то шансы, что хотя бы один из них по вам ударит, составят почти 75%[18].

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

Чужой риск

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

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

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

вернуться

18

Т.е. они равняются 1 – 0.9¹² (прим. ред.)

14
© 2012-2016 Электронная библиотека booklot.ru