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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим компанию «Merrill Lynch». Здесь долго и тщательно изучали так называемые тенденции электронной торговли в режиме реального времени… и решили обойтись без этого. Они скрестили пальцы в надежде, что вернется эра универсальных брокерских операций с солидными гонорарами и брокерами, способными бесконечно заставлять вас ждать на линии, что директ-трейдинг (прямая торговля) окажется лишь мимолетной причудой. Сколь тщетная надежда! Сегодня универсальные брокерские операции стали такими же древностями, как универсальные бензоколонки[9]. И сегодня «Merrill Lynch» приходится предлагать своим клиентам электронную торговлю. В режиме реального времени по сниженным ценам. Причем потребовалось почти десятилетие, чтобы догнать конкурентов. «Merrill Lynch» была самой последней из тех, кто стал применять эти методы торговли.

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

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

• Построение такой системы – полностью за пределами наших нынешних возможностей: придется выучить сетевые протоколы, новые языки программирования и подходы, вроде HTML, Java, PERL, CGI, логику работы серверов, ввести проверку подлинности, создать защищенные Web-страницы и освоить много новых технологий, которые сегодня даже трудно перечислить.

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

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

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

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

• Может оказаться, что люди попробуют электронную торговлю и вернутся к телефонной связи, оставив нас с пропавшими зря инвестициями.