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