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