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

1. Наши акционеры не являются достаточно зрелыми, чтобы смотреть риску в лицо.

«Если бы мы сказали правду, наши акционеры слишком испугались бы и отказались от проекта, поэтому мы вынуждены им лгать».

В этой ситуации ложь представляют истинным общественным служением.

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

В этот период в IT-индустрии воцарилось патерналистское отношение «нам лучше знать». Возможно, это даже срабатывало, способствуя при случае созданию полезных систем.

Однако сегодняшние участники проектов – совсем иные. Они, как правило, более могущественны, чем их IТ-партнеры, и они уже больше разбираются в предмете. Они соображают в вопросах автоматизации. Более того, у них отличная память.

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

2. Уровень неопределенности слишком велик.

«Я готов указать диапазон, в котором будет дата завершения, но не такой большой».

Многие руководители проектов по созданию программного обеспечения теоретически готовы бороться с неопределенностью в своих проектах, но их ошеломляет размер этих неопределенностей. Если бы они могли использовать методы управления рисками, чтобы показать дату поставки плюс-минус 2% или 5%, они были бы в восторге. Но неопределенность в нашей области значительно больше. Тщательная оценка возможных причин задержки обяжет признать что-то в таком роде: «Поставку можно ожидать между 18-м и 29-м такого-то месяца, причем с 85% достоверностью можно назвать 24-е число».

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

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

3. Заданный в явном виде диапазон неопределенности оправдывает плохую работу.

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

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

4. Подход «управление ради успеха» лучше.

«Смотрите, мы не занимаемся управлением рисками, но следим за рисками и делаем все, чтобы они не происходили».

Можно управлять рисками, но нельзя полностью от них избавиться. Любой подход «управление ради успеха», основанный на убежденности, что риски не материализуются, обрекают проект на катастрофу, если они все-таки случатся. Для любого разумно организованного проекта риски присущи цели проекта, они связаны с полем действия. Как будет подробнее рассмотрено позднее, устранение этих внутренних рисков может быть достигнуто только путем отказа от значительной части ценности проекта.

5. Не хватает данных для эффективного управления рисками.

«Мы недостаточно знаем про риски, которые повлияют на этот проект».

Многие риски, грозящие данному проекту, являются уникальными для этого проекта. Уникальные риски происходят от самого продукта, а также от культурной и политической среды проекта. Данных относительно некоторых из этих рисков немного или нет вовсе. Однако главные риски, с которыми сталкивается большинство проектов, являются общими для всех IТ-проектов. Если вы располагаете данными по общим рискам, у вас есть необходимые средства, чтобы сдерживать большинство рисков.

6. Опасно управлять рисками в изоляции.

«Я не осмелюсь быть единственным, кто честно осуществляет управление рисками».

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

Если вы работаете в организации, где управление рисками не практикуется достаточно широко, вы все же можете использовать в своем проекте некоторые его инструменты и методы, но не стоит афишировать свои открытия. Говорить правду в обстановке, где нормой является оптимизм (ложь) – значит оказаться в крайне невыгодном положении. Если вы утверждаете, что есть лишь 10%-ная вероятность сдать проект в желательный клиенту срок, вы предоставляете возможность коллеге-конкуренту сказать: «Босс, поручите это мне, и я все сделаю вовремя, гарантирую вам».

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

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

Ошибаться – нормально, но неопределенность – не приветствуется.

Если это правило описывает вашу компанию, вы пропали.

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