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

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

Затем Клиффорд возвращается к тому же примеру, слегка изменив его. Пусть теперь кораблю удалось все-таки завершить рейс и никто не погиб. Будет ли хозяин менее виновен?

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

До Клиффорда существовало мнение, согласно которому ваша вера не могла рассматриваться с точки зрения этики. Можно было верить в любую чушь, какая вам по праву. Можно было верить даже в совершенно невозможные вещи, как это делала Белая Королева в книге «Алиса в Зазеркалье». Когда Алиса возражала ей, утверждая, что просто нельзя поверить в невозможные вещи, Королева отвечала:

«Просто у тебя мало опыта… В твоем возрасте я уделяла этому по полчаса каждый день! В иные дни я успевала поверить в десяток невозможностей до завтрака!»[7]

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

«Вот поэтому-то мой выбор пал именно на Вас» — уверенно говорит начальник.

Дилемма такова: вам доверяют работу, для вас это — вызов, вопрос престижа… но вам придется поверить в этот график. Это — цена, которую вы платите. Вы, сглотнув с трудом, говорите, что справитесь. Позднее вы укрепляете свою веру. Конечно. А почему бы и не к Рождеству? Другие проекты удавалось ведь выполнить в такие же сжатые сроки, не так ли? Вскоре вы можете почувствовать себя на самом деле уверенным. Время может доказать обратное, но на данный момент вы практически уверены, что сумеете выполнить работу.

Но тут-то, однако, вопрос Вильяма Кингдона Клиффорда должен вернуться, чтобы преследовать вас. Да, в это вы верите, но есть ли у вас право верить в это? Есть ли у вас право верить в этот график на основании имеющихся у вас фактов?

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

Часть I Почему?

• Зачем нужно управлять рисками, почему бы просто не избегать их?

• Что такое риск и что такое управление рисками?

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

• Достаточно ли иметь хорошие технологические процессы, чтобы считать, что меры против риска приняты?

• Почему нам нужна эта новая дисциплина?

Глава 1 Стремление к рискам

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

Не беритесь за проект, если в нем нет рисков.

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

Бегство от выпавшего шанса

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

1. Компании переводили приложения и базы данных от архитектуры «мейнфрейм с терминалами» к модели «клиент/сервер»[8].

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

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