Чтобы эффект Готорна помог и вам, следует применять только нестандартные подходы. Существующие стандарты должны быть краткими и мягкими. Общий объем стандартов для ваших людей не должен превышать 10 страниц. (Это не причуды; во многих организациях, распрощавшихся с подходом «Методология – это Закон», в конечном итоге стандарты ограничиваются десятью страницами.) Будьте готовы делать исключения даже для правил на этих 10 страницах. И тогда ваша среда разработки станет сообразна взглядам знаменитого мудреца бизнеса Мао Цзе-Дуна:
Пусть расцветают сто цветов,
И пусть состязаются сто школ мысли.
Мао, конечно, лукавил, а вот мы говорим всерьез.
30
. Танцы с рисками
Наша книга «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения» обличает две противоположные модели поведения: принятие рисков без управления рисками и уклонение от рисков, которое делает невозможными хоть сколько-нибудь амбициозные достижения. Сегодня нам все чаще встречаются организации, умудряющиеся совершать сразу обе ошибки. Они безнаказанно сражаются с одной разновидностью рисков, в то же время избегая тех рисков, которые могут указывать на возможность значимых преобразований.
Идея человеческого фактора, состоящая в том, что наши коренные проблемы, вероятнее всего, имеют природу социологическую, нежели технологическую, нигде столь не уместна, как в области рисков. Механика управления рисками хорошо изучена; когда такое управление не осуществляется, причина, скорее всего, в политике и культуре организации.
Не стоит бежать от рисков
Прежде всего стоит сказать, что риск в проекте – позитивный фактор, вероятный признак ценности проекта. Проекты, обладающие реальной ценностью, но при этом безрисковые или почти безрисковые, все уже были реализованы давным-давно. Все важные проекты на сегодняшний день в обязательном порядке нагружены рисками.
Представьте, что вас наняли управлять проектом Barnes & Noble по созданию программного обеспечения для электронной книги Nook. И вот что вам предстоит: ваш основной конкурент, компания Amazon, попросту захватила рынок; вы очень поздно включаетесь в игру; ваше устройство не имеет особенных преимуществ (используется та же базовая технология); вы только-только начинаете вести с издателями переговоры о приобретении прав на электронные публикации; и вряд ли вам удастся когда-нибудь догнать Amazon по числу книг, которые эта компания предлагает своим покупателям уже сегодня. Что станете делать?
История гласит, что заблудшие темные души, действительно оказавшиеся в этом положении, пошли на огромный риск. Они решили предложить что-то, о чем конкуренты вообще не подумали: библиотечное заимствование электронных публикаций. Однако задумайтесь, какую работу требовалось проделать, чтобы эта схема заработала: провести переговоры не только с издателями, но также с библиотеками и авторами; спроектировать и реализовать протоколы сети заимствования; встроить в «читалку» программное обеспечение, блокирующее доступ к материалам по истечении периода заимствования, а еще создать систему отчислений для авторов книг, которые берутся «почитать». Риски, риски, сплошные риски. А помимо рисков навигации в неисследованных водах всегда есть шанс, что рынок просто пожмет плечами. Кто знает, насколько будет большой спрос на заимствование книг?
В данном случае риски окупились. Необычное устройство Nook появилось в продаже, и рынок его принял.
Подумайте, как выглядел бы ваш список рисков в этом проекте. Многие вещи могли пойти не так в ходе создания продукта, и управление этими рисками стало бы значительной составляющей вашей работы. Если вы составили (навскидку и по-быстрому) перечень таких рисков, готовы поспорить, вы упустили один важный пункт.
Риск, который почти всегда неуправляем
Риск, который мы склонны исключать из управления рисками, – это риск нашего собственного провала. Если вы и доверенная команда должны взаимодействовать с подрядчиком, который находится на расстоянии тысяч километров и десяти часовых поясов, причем в городе, о котором вы никогда не слышали, разумеется, риск, что этот подрядчик вас подведет, окажется в начале списка рисков. Это очевидно. А как быть с тем, что вы и ваша собственная команда не сможете выполнить поставленные перед вами цели? Разумеется, вы об этом беспокоитесь; и, быть может, вы даже просыпаетесь ночью в холодном поту, думая об этом. Причина, по которой этого риска, вероятно, нет в списке, такова: когда люди таскают за собой риск своего провала, это выглядит как пораженчество. В конце-то концов, вам ведь доверили достижение результата; это ваша роль и ваша ответственность.
Чтобы понять, почему опасно исключать этот единственный риск из управления рисками, следует рассмотреть истинную причину необходимости управления рисками. Управление рисками вовсе не служит тому, чтобы риски исчезали, его назначение – в смягчении последствий рискованных событий, когда они все же происходят. И смягчение лучше планировать и готовить заранее.
Печально известная система управления багажом денверского международного аэропорта может послужить хорошим примером. Власть предержащие решили, что своевременная сдача системы настолько важна, что опоздание риском считать не следует. Какой же это риск, если мы просто не позволим этому произойти. Так что по соглашению руководителей этот риск просто отмели.
Управляя этим риском, они были бы вынуждены спланировать ручной или полуавтоматический резервный план перемещения багажа на случай неготовности системы. Это не было сделано. Поэтому когда сдача системы задержалась, пришлось задержать и открытие аэропорта. Капитальные затраты на более чем годовую эксплуатацию второго нефункционального аэропорта в конечном итоге исчислялись миллиардами.
Этот риск материализовался, когда система оказалась недоступна в день открытия, и было уже слишком поздно начинать планировать смягчение. С другой стороны, если бы меры были приняты заранее, аэропорт открылся бы по-старинке – с участием временного персонала и небольших транспортеров для багажа, и тогда задержка сдачи программной системы свелась бы к небольшому разочарованию. Вам, как и всем другим людям, никогда не пришлось бы узнать о системе управления багажом денверского аэропорта; о ней знали бы только участники проекта.
Вполне разумно исключать из управления риски, вероятность возникновения которых крайне мала. И неразумно так поступать, то есть оставить без управления риск, если его последствия «слишком ужасны, чтобы о них думать».
Почему риск провала часто исключают из управления
Управление рисками часто подменяется «спортивным мышлением», когда исход предприятия определен через понятие вызова. Люди отвечают на вызовы; они рады вызовам. Они проводят исчерпывающие исследования, чтобы выстоять в неблагоприятных условиях. Последнее, что им нужно, – потратить время на планирование и подготовку к собственному провалу. Время не ждет, особенно когда вызов заключается в том, чтобы сделать что-то за короткий срок. Чем больше важность графика сдачи, тем меньше остается времени на планирование смягчения рисков и тем меньше люди склонны этим заниматься.
Необязательно, чтобы все было так ужасно. Если руководитель и его команда не собираются управлять рисками, пусть это делает кто-то другой. В такой ситуации хороший руководитель сумеет сказать: «Слушайте, мы готовы ответить на этот вызов, принять эти жуткие сроки сдачи, и мы сделаем все, что от нас зависит, чтобы выполнить проект в указанных рамках. Но у нас не будет времени управлять риском не уложиться в срок, несмотря на все приложенные нами усилия, поэтому нужен кто-то, кто сделает это для нас. Если мы не увидим, что на случай задержки сдачи сформулированы конкретные планы, мы не сможем считать этот проект вызовом; это будет скорее глупая, крайне рискованная затея для отчаянных».
Руководители и исполнительные лица среднего уровня часто обладают навыком, позволяющим считать желаемый результат вызовом. Они позиционируют вызов как нечто, что станет доказательством превосходства. Однако во многих случаях их действительная цель состоит не в том, чтобы вознести команду на вершины превосходства, но в том, чтобы заставить участников команды доделать проект задешево. Извращенная логика: чем меньше выгоды от реализации проекта, тем важнее сдать его с минимальными затратами. Неудивительно, что дешевая реализация как средство замаскировать отвратительно низкую выгоду – не особенно удачная мотивация, поэтому руководители в подобных ситуациях могут говорить что-то вроде: «Это настолько важная работа, что мы должны закончить ее к первому января». На самом деле они имеют в виду: «Эта работа настолько