Восприятие рисков и иллюзия безопасности

Меня не раз удивляло, что при отключенных светофорах на Хофплейн, одной из самых оживленных площадей с круговым движением в Роттердаме, движение транспорта только улучшается. Несмотря на возникающую в результате анархию, людям удается добраться до противоположной стороны площади быстрее, чем при работающих светофорах. И это относится не только к водителям, но и к пешеходам и велосипедистам.

В своей статье «Дорожное движение безопаснее, когда нет правил» эксперт в этой области Ханс Мондерман отмечает, что в случаях, когда на перекрестках отключали светофоры и убирали все дорожные знаки, их пропускная способность возрастала, а аварийность снижалась [Sprangers 2007]. Причина состоит в том, что при отсутствии правил и указаний светофоров люди вынуждены брать на себя ответственность и самостоятельно решать, как им безопасно миновать перекресток.

Причина этого парадокса — в восприятии рисков и иллюзии безопасности. Уберите зеленый сигнал светофора (иллюзия безопасности), и водители начинают проявлять осмотрительность, вместо того чтобы проезжать перекресток на полной скорости, не глядя по сторонам, поскольку они уверены, что имеют приоритет перед всеми остальными. Этот психологический феномен также называется компенсация риска. Сотрите зебры, и пешеходы начинают внимательно смотреть по сторонам (их восприимчивость к возможным рискам обостряется). Мондерман утверждает, что во всех без исключения ситуациях, когда на дорогах создавались подобные условия, количество транспортных происшествий снижалось, а пропускная способность возрастала. Эта новая концепция дорожного движения называется общее пространство и подразумевает равенство всех участников движения и необходимость для всех учитывать действия друг друга. Приоритета перед другими нет ни у кого.

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

В большинстве проектов целесообразно относиться к существующим правилам не как к законам, а как к набору практических приемов. Да, в большинстве случаев следование правилам приводит к желаемому результату, но далеко не всегда. Иногда правила нужно отменить именно для того, чтобы помешать людям слепо им следовать. В ходе некоторых из самых успешных проектов, в которых мне доводилось участвовать, мы игнорировали правила и принимали более оптимальные решения, руководствуясь конкретной ситуацией. Объезжая дорожные препятствия и игнорируя светофоры, мы могли вовремя и безопасно добираться до места назначения.

Я обычно не спешу соглашаться с теми, кто в качестве реакции на возникающие в ходе проекта проблемы сразу же призывает создать дополнительные правила, которые помогут предотвратить возникновение аналогичных проблем в будущем. Если бы я соглашался с ними, то превратился бы в средней руки бюрократа вроде тех, что развешивают все новые и новые дорожные знаки на перекрестках в попытке предотвратить все до единого происшествия, с которыми кому-то где-то приходилось сталкиваться ранее. Некоторые называют это принципом предосторожности, и им пользуются многие правительства, включая Европейский союз. Фундаментальный смысл этого принципа в том, что, если что-то когда-нибудь может пойти не так, надо на всякий случай, превентивно, просто принять еще один закон. Мне этот подход совсем не нравится.

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

К счастью, разработчики программных продуктов сейчас поумнели. Они все лучше осознают, что не существует универсальных методологий. Это признает Ивар Якобсон, один из основателей унифицированного процесса, в своей состоящей из трех частей статье «Хватит процессов: давайте сосредоточимся на практике» [Jacobson 2007]. В целом лучшие результаты достигаются, когда правила создаются на месте точно под текущую задачу. К такому же выводу пришли и три других исследователя, утверждающие, что лучший способ применять Agile-методологии — адаптировать их под свои задачи [Wailgum 2007].

Я езжу на автомобиле по голландским дорогам вот уже двадцать лет и ни разу не был в ДТП с участием других водителей или пешеходов. Причина в том, что я постоянно слежу за действиями всех водителей, пешеходов и велосипедистов вокруг меня. Я предпочитаю полагаться на свою оценку ситуации, а не на указания светофоров и знаков. Мой партнер, наоборот, не сдал свой первый экзамен на водительские права, поверив зеленому сигналу светофора и чуть не задавив пешехода, переходившего улицу на красный. С тех пор он научился доверяться в первую очередь своим органам чувств и лишь во вторую — официальным правилам.

Меметика

Я пишу эту главу сразу после Рождества — одного из самых удачных примеров массового помешательства. Я всегда с нетерпением жду этого праздника, и не только из-за многочисленных возможностей вкусно поесть. Должен признаться, что мне, как и многим другим, нравятся все эти милые глупости — наряжать рождественскую елку, зажигать свечи, покупать подарки, ходить в кино, петь рождественские гимны.

Идеи, концепции, представления, теории, идеологии, массовые увлечения и моду часто называют мемами [Dawkins 1989]. Люди копируют эти единицы информации друг у друга путем подражания, через взаимодействие и обучение [Stacey 2000a: 168]. Примерами мемов будут Санта-Клаус и рождественская елка, обычай класть подарки в чулок (в Голландии мы прячем их в ботинки) и олень Рудольф. Рождение Иисуса Христа, ангелы и эльфы — тоже мемы.

Аналогичным образом дело обстоит с правилами, процедурами и практиками, которые используются при разработке программных продуктов. Они тоже представляют собой идеи, концепции и мнения, которые люди копируют друг у друга путем подражания, через взаимодействие и обучение. Мемами будут короткие совещания, проводимые стоя (стендапы), парное программирование, рефакторинг, итеративный подход к разработке ПО и пользовательские истории. Меметика — изучение эволюционных моделей передачи информации, часто в культурологическом контексте.

Мемплекс — это собрание взаимозависимых мемов (рис. 10.5). Типичным мемплексом будет Рождество. А также Agile-методологии разработки ПО. Теория универсального дарвинизма показала, что мемы объединяются в мемплексы, поскольку совместное копирование осуществляется более успешно (аналогичное поведение демонстрируют гены, объединяющиеся в генные комплексы). Рождество — успешный мемплекс, потому что входящие в его состав мемы, несмотря на разное происхождение, в настоящее время усиливают друг друга, становясь практически неуничтожимыми. Олень Рудольф вряд ли выжил бы в качестве отдельного мема. Но теперь этот мем в буквальном смысле прочно привязан к Санта-Клаусу и тем самым, по всей видимости, обрел надежду на бессмертие.

Аналогичным образом Agile-практики в разработке ПО также имеют тенденцию усиливать друг друга. Рефакторинг совместим с разработкой через тестирование, пользовательские истории хорошо вписываются в еженедельные итерации, а стендапы более эффективны, если при их проведении используется доска задач. Большинство Agile-практик существовало и до возникновения Agile-методологий. Этот аргумент часто приводят люди, скептически относящиеся к гибким методологиям. Но это не имеет отношения к делу. Важно то, что возникновение Agile-мемплекса стало катализатором для лихорадочного копирования Agile-практик в массовом масштабе, который, скорее всего, был бы невозможен в любом другом случае [Kruchten 2007].

Я на своем опыте убедился, что Agile-мемплекс гораздо сильнее, чем входящие в него индивидуальные мемы. Мои изначальные попытки внедрить только тайм-боксы и требования высокого уровня полностью провалились, потому что я выбрал лишь отдельные практики, которые, как мне казалось, будут полезны. Но они не привились, и отнюдь не из-за отсутствия усилий с моей стороны. Все это напоминало попытку заставить сотрудников петь песенку про оленя Рудольфа летом. Это просто не работает. Отдельных мемов оказалось недостаточно. В один прекрасный момент я понял, что лучше просто попробовать Scrum с соблюдением всех правил. Scrum гораздо конкретнее, у него шире сфера применения, поэтому в результате он оказался значительно успешнее моих самодеятельных попыток улучшить рабочие процессы. Scrum — это мемплекс. Мемы взаимно усиливаются и помогают друг другу копироваться в головах людей. Поэтому легче внедрить Scrum в полном объеме, чем, например, только тайм-боксы и требования высокого уровня.

Означает ли это, что серьезные революции делаются сверху? Совсем нет. Организационные изменения могут быть осуществлены как сверху вниз, так и снизу вверх. (Хотя многие считают, что подход снизу вверх работает лучше.) При проведении масштабных изменений использование мемплексов будет полезно как для менеджеров (подход сверху вниз), так и для членов команд (подход снизу вверх). Это не значит, что в ходе большой революции вы должны принять все новые практики одновременно. В конце концов, некоторым требуется несколько месяцев, чтобы подготовиться к Рождеству.

Рассматривая Agile-практики в качестве мемов, можно сделать несколько интересных наблюдений:

• Порой проще заставить людей принять несколько идей, концепций или практик разом, чем одну-единственную. (Например, обучить сотрудников Экстремальному программированию в целом, а не только юнит-тестированию, а затем немедленно приступить к адаптации Экстремального программирования в контексте данной организации.)
• Не все идеи, концепции или практики в составе мемплекса одинаково полезны. Некоторые могут даже оказаться вредными. Но, поскольку все они входят в данный мемплекс, даже плохие идеи помогают копированию полезных, что нейтрализует их отрицательный эффект. (Вот достаточно рискованный пример: я пока не видел убедительных доказательств, что коллективное владение кодом добавляет в проект какую-либо ценность, но в гибких методологиях эта практика подкрепляет остальные, поэтому в целом не повредит, если она также будет скопирована.)
• Удаление отдельных мемов может ослабить, а то и свести на нет силу всего мемплекса. (Пример: если исключить из мемплекса коллективное владение кодом, то внедрение Agile-практик может потерпеть полную неудачу.)
• Могут существовать конкурирующие мемплексы, которые тем не менее взаимно усиливаются и нуждаются друг в друге, поскольку конкуренция между ними отвлекает внимание от других подходов. (Пример: конкуренция между Экстремальным программированием, Scrum и канбаном в рамках мира Agile привлекает внимание к Agile-брендам в целом.)
• Мемы могут иметь разное происхождение и одновременно входить в состав нескольких мемплексов. (Пример: пользовательские истории возникли как мем в рамках Экстремального программирования, но в настоящее время прочно закрепились также и в мемплексе Scrum.)

Мне представляется продуктивным рассматривать Agile-методологии в качестве мемплексов. Единственная их цель — служить катализатором копирования Agile-практик. Любой, кто утверждает, что Agile-методологии не внесли в разработку ПО почти ничего, что не существовало бы ранее, полностью упускает эволюционные преимущества объединения разных практик под одним брендом.

Момент, когда самореплицирующиеся молекулы начали объединяться в генные комплексы, чтобы способствовать копированию друг друга, стал ключевым в эволюционной биологии. Аналогичным образом если смотреть на ситуацию с точки зрения культурной антропологии, то культуры, религии и науки так и не возникли бы, если бы люди не изобрели механизм группировки идей и их копирования под одним именем. Поэтому, как мне представляется, оглядываясь назад, мы увидим, что возникновение Agile-брендов стало очень важным шагом в эволюции разработки ПО.

Разбитые окна

Дома у меня на рабочем столе царит полный беспорядок. Когда я окидываю его взглядом, то вижу книги, журналы, счета, очки, жуткого вида рождественскую елку, звуковые колонки, внешние накопители, два калькулятора, сканер, принтер, стикеры с заметками, лекарства, визитные карточки, карандаши, ручки, цветные маркеры, линейку, батарейки — и даже желудь (из Киева) и каштан (из Хельсинки). И чем больше на моем столе беспорядка, тем больше этого беспорядка становится. В то же время, если на стол бросить, например, еще и сосновую шишку, то никто этого вообще не заметит.

Идея, что проблемы со временем становятся только хуже, обязана своей популярностью теории разбитых окон. Она утверждает, что, когда люди видят явные следы беспорядка или антиобщественного поведения, это провоцирует их на нарушение общественных норм или совершение правонарушений. А это приводит к распространению криминального поведения в целом. Считается, что если бороться с самыми мелкими проявлениями антиобщественного поведения и чаще наводить порядок, то могут быть предотвращены даже более серьезные преступления [Wilson, Kelling 1982: 2–3].Некоторые ученые относятся к теории разбитых окон критически. По их мнению, корреляция здесь могла быть ошибочно принята за причинно-следственную связь и привела к неверной интерпретации результатов некоторых исследований, в том числе к ошибке в знаменитом примере с уровнем преступности в Нью-Йорке, который описан в книге «Переломный момент»[56] [Gladwell 2002]. И тем не менее существует достаточно доказательств, что верен сам принцип, лежащий в основе теории разбитых окон [Keizer 2008]. Эта теория стала логическим развитием более общей идеи, выраженной в уравнении Левина:

П = f(Л,ВС).

Это уравнение, предложенное психологом Куртом Левином, говорит о том, что поведение человека является функцией личности и внешней среды. Конечно, это не уравнение в научном смысле слова, а обобщение практического опыта. Из него следует, что люди адаптируют свое поведение к среде, в которой живут.

Поскольку люди копируют нормы и поведение друг друга (меметика), то примеры антисоциального поведения, если их сразу не пресекать, с большой вероятностью приводят к его дальнейшему распространению (петля положительной обратной связи). Легко увидеть, что комбинация всех этих идей автоматически приводит к теории разбитых окон.

Какие выводы мы можем сделать из всего этого? С моей точки зрения, их два:

• Крупные проблемы часто начинаются с мелких, которые лучше купировать на начальной стадии, пока они не вышли из-под контроля.
• Если проблема слишком серьезная, чтобы ее можно было решить сразу, необходимо заняться связанной с ней менее крупной проблемой.

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

Резюме

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

Вопрос о том, на каком иерархическом уровне должны создаваться правила, — это вопрос компетентности. В явном виде она не упоминается в Agile-манифесте, что, возможно, является слепой зоной гибких методологий и одной из причин возникновения движения в защиту мастерства программирования. Развитие компетенций осуществляется в двух измерениях: дисциплина и профессиональные умения.

Принцип субсидиарности предполагает, что правила должны создаваться на самом низком иерархическом уровне, достаточно для этого компетентном. Это значит, что полномочия по созданию правил могут делегироваться компетентным командам.

Однако некоторые правила необходимо не столько создавать, сколько отвергать. Когда правил слишком много, у команды может возникнуть иллюзия безопасности и тенденция к компенсации риска.

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

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из этой главы в вашей компании:

• Нарисуйте матрицу «дисциплина — умения» для своей команды. Вы знаете, куда в этой матрице поместить каждого из своих сотрудников? Если нет, то почему? Если да, то соответствует ли данная картина вашим ожиданиям? Если не соответствует, то что можно по этому поводу предпринять?
• Создайте список наиболее важных правил (а лучше — ограничений) для своей компании. В списке должно быть не более десяти правил. Убедитесь, что все сотрудники их знают. Если возникнет необходимость добавить еще одно, уберите одно из существующих. Люди плохо запоминают длинные списки даже важных вещей, поэтому ваш список должен быть коротким.
• Попробуйте реализовать один из своих проектов как «проект, в котором имеется только общее пространство». В этом проекте не должно быть никаких заранее определенных правил, только сотрудники, занимающие одно помещение. Отсутствие заранее заданных правил должно повысить восприимчивость членов команды к рискам и устранить иллюзию безопасности. Разрешите команде самостоятельно установить все до единого правила. Проанализируйте результаты.
• Оцените, в каком состоянии находится применение гибких методологий в вашей компании. Эти методологии имеют общее хорошо запоминающееся название? Легко ли соответствующий целостный набор практик передается от сотрудника к сотруднику? Или ваш подход состоит из отдельных бессистемных фрагментов, которые новым членам команды усвоить не так легко?
• Составьте список небольших проблем, которые вас беспокоят. Занимаетесь ли вы их решением? Или вы инвестируете время только в решение крупных проблем? Может быть, вы позволяете мелким проблемам превратиться в крупные?

Глава 11