Глава 17
Стратегия максимального ослабления рисков
Позвольте предложить вам небольшой мысленный эксперимент. Вам понравится. Представьте, что вы работаете на территории своего клиента в Чикаго. Среда, вторая половина дня. Вы узнаете, что очень важное совещание назначено в Сан-Франциско на полдень пятницы. Обстоятельства требуют вашего присутствия там, а сложные характеры некоторых участников превращают опоздание в катастрофу. Вам просто необходимо быть там вовремя.
Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за пять-десять до начала совещания.
Но на этом задержим внимание: план, зависящий от того, что вам должна везде улыбаться удача, вряд ли можно назвать свободным от риска. Если вам не будет сопутствовать везение на каждом шагу, то вы опоздаете. Ничего хорошего. Итак, вы теперь переходите в режим ослабления риска. Как поменять план, чтобы защитить себя от очевидных рисков?
Тут не требуется быть семи пядей во лбу. Не требуется умения читать чужие мысли, чтобы угадать, что вашим первым импульсом будет найти возможность более раннего вылета. Рейс на рассвете (в б утра) не вызывает восторга, но зато оставляет в запасе пару часов. А что если прилететь накануне вечером и обосноваться в отеле рядом с офисом?
Ваш «проект» в данном случае состоит в попадании в Сан-Франциско. Самое важное для вас – выполнить его своевременно, наиболее естественное решение для вас – раньше приступить к проекту. Это каждому понятно, то есть, разумеется, кроме разработчиков IТ-проектов.
Шутка о нас
Можно слегка пошутить на тему отличия нашего («айтишного») подхода к сдерживанию риска от всех прочих. Эта шутка звучала бы примерно так:
IT-менеджер и нормальный человек оказываются в одинаковой ситуации: работают в Чикаго и после обеда в среду узнают, что надо быть в Сан-Франциско на совещании в полдень пятницы, причем строго необходимо попасть туда вовремя. Нормальный человек (назовем ее Дианой) вылетает вечером в четверг и устраивается в славном небольшом отеле, расположенном всего за квартал от нужного офиса. Она неспешно ужинает в хорошем ресторане и успевает прогуляться до магазина, чтобы запастись фотопленкой. На следующее утро она с удовольствием и не торопясь завтракает, а потом работает на своем портативном компьютере до 11 часов. Она выходит в 11:30 и, совершив променад до офиса, попадает туда за 10 минут до начала совещания.
А теперь IT-менеджер Джек. Он покупает билет на 8:40 в пятницу. Поймав такси в городе в 7:05, попадает в пробку и гневно жалуется на это шоферу всю дорогу до аэропорта. Тупой водитель никак не уразумеет, как важно Джеку не опоздать на этот рейс. Pегистрируясь в аэропорту, он с нажимом объясняет клерку, что самолет должен взлететь и приземлиться точно по расписанию и никаких оправданий он не примет. Он говорит, что будет «весьма и весьма разочарован» в случае любого опоздания. Когда объявляют о задержке рейса, Джек вскакивает и громко ругается. Когда объявляется измененное время отправки рейса, он роется в своих управленческих инструментах и выкапывает оттуда ультиматум: «Если меня не доставят вовремя на совещание в Сан-Франциско, ПОЛЕТЯТ ГОЛОВЫ!»
В проектах, где критичен срок сдачи, реальным ослаблением риска является раннее начало. Это, пожалуй, единственный эффективный способ сдерживания риска опоздания для большинства проектов. Да, мы знаем, что уже слишком поздно, чтобы начать наш проект рано, он начался, когда начался, и вы уже влипли. И вы читаете эту книгу не для того, чтобы узнать, как вы могли бы так не влипнуть. Вы хотите найти выход из этого положения. Все это правда. Но выбор раннего старта все равно для вас полезен, как будет показано ниже.
Отважное и робкое руководство
Во-первых, следует разобраться с одним деловым поверьем, которое иначе будет мешаться у нас на дороге: представление о том, что начинать проект без малейшего запаса времени – признак по-настоящему отважного стиля руководства, а противоположное является признаком трусости.
Чтобы убедиться в этом, следует рассмотреть обстоятельства принятия типичного решения о начале проекта. Это может выглядеть примерно так:
Сейчас в экономике некоторый спад, но в ближайшие пару кварталов дело должно выправиться. Начиная сейчас создавать новую версию нашего продукта, мы опередим своих конкурентов, когда рынок оживет, следовательно, нам нужно браться за осуществление этого проекта. Но что будет, если рынок не восстановится в ожидаемые нами сроки? Может, лучше подождать, пока это произойдет на самом деле. Если спрос возрастет в начале следующего года, тогда мы и начнем этот проект. А если спячка продержится до лета, мы сможем до той поры легко обойтись без затрат на этот проект.
Это – робкое руководство в худшем своем проявлении.
С другой стороны, дерзкое руководство стремится идти на возможное увеличение рисков, если это окупится. Всегда требуется мужество, чтобы начинать проекты достаточно рано. Это всегда требует от кого-то решения, которое еще не оправдано рынком. Это означает трату денег на что-то не вполне надежное.
Ирония состоит в том, что множество проектов оказываются под угрозой срыва сроков поставки из-за того, что руководители ушли от другого риска, куда более важного, связанного с ранним стартом.
Почему важна возможность раннего старта, даже если вы не можете ее реализовать
Проекты, которые завершаются с опозданием – это почти всегда те проекты, которые слишком поздно начаты. А слишком поздно начатые проекты – признак нехватки видения и мужества у высшего руководства. Если вам грозят снести голову за недостаточно быстрое завершение работы, вы быстро понимаете, что проект был начат недостаточно рано. Это – заклинание, которое многим организациям следовало бы принять на вооружение.
ТДМ: В начале 1996 года одна из моих клиенток была менеджером крупного проекта по разработке встроенного программного обеспечения. Ее задача состояла в создании системного программного обеспечения новой линейки товаров, которую отдел маркетинга рвался срочно запустить на рынок. Главным заказчиком для нее был руководитель службы маркетинга Ганс, который выдвинул этот проект и получил на него финансирование. Ганс рассердился, когда команда моей клиентки назначила сроком сдачи четвертый квартал 1997 года. Он настаивал на сдаче 31 марта 1997 года. Он заклеймил ее расчеты на публичном совещании, объявив их недостаточно напористыми, и завершил свою речь словами (к несчастью для него): «Я берусь доказать, что каждый месяц после марта компания будет терять в виде упущенной прибыли 110000 долларов, если не будет готова отгружать эти товары».
Я уточнил у него по поводу этого заявления: «Ганс, а эта цифра относится к сроку завершения до 31 марта? Если бы мы завершили к концу февраля, например, получили бы мы дополнительно 110000 долларов прибыли, сверх запланированного вами дохода?»
«Да, – сказал он. – Наверняка».
«А если бы закончили к концу января? – настаивал я. – Дало бы это еще 110000 долларов прибыли?»
«Да», – ответил он.
«А если бы мы могли вручить вам готовый продукт сегодня (это было в феврале 1996 года, когда только было открыто финансирование проекта) вы бы получали дополнительно по 110000 долларов ежемесячно до конца года?»
«Да», – ответил он, теперь несколько потеряв былую самоуверенность.
«Ну тогда, Ганс, очевидно, что вы слишком поздно начали этот проект. Если бы вы дали старт 18 месяцев назад, мы бы могли уже отгружать этот продукт и получать все эти месяцы по 110000 долларов дополнительной прибыли…» Я предоставил ему самостоятельно понять, что подразумевалось.
