Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

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

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

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

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

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