Критиковать легче, чем самому стать мастером.

Зевксис, художник (V век до н.э.)

Люди часто пытаются предотвратить будущие проблемы, вводя в организации правила примерно в таком виде: «Когда возникает ситуация X, надо делать Y». Я с готовностью признаю, что и сам был виновен в подобных попытках. Сейчас же я уверен, что создание правил менеджерами — далеко не идеальный способ обеспечить устойчивость организации.

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

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

Самообучающиеся системы

В своей книге «Невидимый порядок: Как адаптация создает сложность» (Hidden Order: How Adaptation Builds Complexity) Джон Холланд, психолог и специалист в области информатики, таким образом описывает идею, лежащую в основе исследований самообучающихся классифицирующих систем: способность сложных адаптивных систем к самообучению имеет общие закономерности [Holland 1995: 42–80].

Интерпретатор

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

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

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

Присвоение коэффициентов доверия

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

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

Возникновение новых правил

Последний компонент самообучающихся классифицирующих систем связан с возникновением новых правил. Холланд объясняет, что новые правила могут возникать в результате рекомбинации элементов уже существующих. Примерно так функционирует и ДНК — путем рекомбинации генов и их аллелей.

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

Правила в сравнении с ограничениями

Эксперт по компьютерной графике Крейг Рейнолдс в свое время обнаружил, что поведение птиц в стаях может быть смоделировано на компьютере при помощи простого алгоритма [Reynolds 1987]. Этот тип поведения, широко распространенный в природе среди разных биологических видов, возникает в результате соблюдения трех простых ограничений (рис. 10.1):

• Все особи должны двигаться в одном направлении (согласованность).
• Нельзя сталкиваться друг с другом (разделение).
• Нужно держаться вместе с группой (сплоченность).

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

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

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

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

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

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

1. Рассчитать среднее положение птиц, которых я вижу.
2. Рассчитать среднее направление движения птиц, которых я вижу.
3. Если расстояние от меня до среднего положения > константы A, то нужно скорректировать направление моего движения на X градусов по отношению к среднему направлению.
4. Если расстояние от меня до какой-либо другой птицы < константы В, то нужно отклониться от нее в сторону на Y градусов.
5. Если направление моего движения отклоняется от среднего направления движения стаи больше, чем на C градусов, то нужно скорректировать мое направление на Z градусов в сторону среднего направления.
6. И так далее…
7. Повторять до тех пор, пока кто-нибудь не крякнет, что пора садиться.

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

Ошибка, которую часто совершают наивные менеджеры, такова: они пытаются в буквальном смысле «запрограммировать» сотрудников на выполнение конкретных правил. «Если ты получаешь документ этого типа, ТОГДА ты должен выполнить вот это действие» или «Если клиент сообщит об ошибке в программном обеспечении, ТОГДА ты должен инициировать эту процедуру». Но сила сложных адаптивных систем в том и заключается, что их агенты могут самостоятельно управлять созданием правил. Менеджерам следует сосредоточиться на установлении ограничений и позволить, чтобы интерпретатор в головах сотрудников включился и проявил свои возможности при решении возникающих задач. Кроме всего прочего, устанавливаемые менеджментом правила все равно не приводят к оптимальному результату. В конце концов, самый эффективный способ поставить организацию на колени — заставить людей строго следовать всем без исключения правилам и не делать ничего, кроме этого [Stacey 2000a: 59].

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

Под креативностью понимается способность решать задачи способом, отличным от установленных, или даже бросать вызов общественным нормам… В определенном смысле креативные люди бросают вызов правилам — даже те из них, кто не привлекает к себе внимание своим антисоциальным поведением. Таким образом, креативность можно воспринимать как «неспособность» подчиняться общепринятым нормам.

Гибкие методологии — органичный способ управлять проектами и сотрудничать с креативными людьми. В этих методологиях устанавливаются ограничения вроде «сотрудничество с клиентом обязательно», «мы готовы вносить частые изменения в продукт», «передаем клиенту только работающее программное обеспечение». Но все остальные правила выбирает и устанавливает команда: «Если из-за снегопада невозможно добраться до работы, ТОГДА мы проведем нашу еженедельную демонстрацию софта по Skype», «Если клиент попросил внести в софт изменения, ТОГДА мы создадим новую ветку в системе контроля версий» или «Если кто-то при сборке допустит ошибку, ТОГДА мы все наденем смешные заячьи ушки».

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

И в результате ваши команды утратят гибкость.

Слепая зона гибких методологий

С моей точки зрения, слабость Agile-манифеста состоит в том, что в нем (в явном виде) не сказано, что в любых проектах по разработке программных продуктов необходимы умные, дисциплинированные и способные фокусироваться люди. Прекрасно, что гибкие методологии «ценят людей выше, чем процессы», но это до тех пор, пока вы не обнаружите, что ваша команда состоит из двух троллей, одного попугая, одного парикмахера и одного довольно способного проектного менеджера, который, к сожалению, слеп, глух и нем. Никакой коучинг не поможет такой команде волшебным образом самоорганизоваться и создать успешный продукт. Я называю это слепой зоной гибких методологий. Они хороши (в том виде, как описаны в манифесте) только при условии, что у вас подобралась прекрасная (или как минимум достаточно хорошая) команда. Ради справедливости надо признать, что вне контекста гибких методологий компетентность сотрудников раза в два важнее, чем с ними. Но это не отменяет того факта, что Agile-манифест оставляет вопрос компетентности за скобками.

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

«Википедия» утверждает, что в моей родной Голландии самый низкий в мире уровень смертности в ДТП. И тем не менее у нас проживает целых 17 миллионов человек, и в стране 136 000 километров автомобильных дорог, которые уместились на территории размером с Западную Вирджинию. При этом я точно знаю, что окружающие меня водители ничуть не умнее водителей в остальном мире. (По правде говоря, уровень смертности в ДТП в Сан-Марино, на Маршалловых и некоторых других островах еще ниже, но мы не можем конкурировать с горой на территории Италии и несколькими скалами в Тихом океане.)

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

• Культура. Как сказал мне друг (специалист по организации дорожного движения), решающий фактор в обеспечении относительной безопасности на дорогах Голландии — местная культура. Голландцам не все равно. Они ценят свои автомобили, свои деньги и жизни других людей (боюсь, что именно в таком порядке). Перевод: независимо от того, какими другими методами вы будете пользоваться, компетентность социальных систем в конечном итоге зависит от отношения людей.
• Инструкторы. Получить водительские права в Голландии можно только при условии, что вы обучались с инструктором. Просто поставить на крышу знак «За рулем ученик» или попросить отца научить водить машину не получится. Надо посетить 20 или 30 занятий с инструктором, который целыми днями ездит с учениками по городу и получает за эту привилегию огромные деньги. (Я тоже попросил бы платить мне побольше, если бы мне приходилось по сорок раз в неделю ездить по одному и тому же маршруту.) Перевод: научите людей должным образом выполнять необходимые действия. Много раз подряд.
• Водительские удостоверения. Необходимо сдать экзамен и доказать, что вы можете быть участником дорожного движения, в противном случае вас на дорогу не выпустят. Перевод: перед тем как разрешить людям участвовать в сложных проектах, их необходимо протестировать.
• Дорожные знаки. Я думаю, что ни в одной стране мира нет такого количества дорожных знаков. Не осталось ни одного километра дорог, который не имел бы каких-нибудь аккуратно расставленных знаков, разметки, светофоров, камер или чего-нибудь подобного. (А когда идет дождь, у нас даже коров выстраивают в одном направлении.) Перевод: снижайте количество возможных проблем, предоставив своим командам интеллектуальные проактивные инструменты; заставьте их пользоваться чек-листами; создайте систему уведомлений, предупреждений, напоминаний и так далее.
• Дорожная полиция. Да, мы все ее ненавидим. Я тоже. В прошлом году я заплатил штрафов на многие сотни евро. (Предпочитаю называть эти штрафы налогом на скорость). Перевод: пусть менеджер по управлению процессами время от времени прохаживается по офису и на выборочной основе проверяет качество сделанной работы. А если качество не на уровне… тут вам решать.
• Звуковые сигналы. Это моя любимая опция. Очень важно иметь возможность предупреждать людей, что они подвергают опасности вашу или чью-то еще жизнь, — это помогает свести количество жертв к минимуму. Перевод: пусть у ваших сотрудников будет возможность посигналить или показать друг другу средний палец. Фигурально выражаясь, конечно.
• Правительство. Когда все остальное не работает, вмешивается правительство. Оно расследует, что пошло не так, вводит новые правила и ограничения и решает, кто прав и кто виноват. Перевод: роль менеджмента — устранять беспорядок, сотворенный другими.

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

Важная тема: профессиональное мастерство

Вы, наверное, заметили, что я люблю поговорить о вождении. Это свойственно всем мужчинам и, скорее всего, запрограммировано где-то в Y-хромосоме. Я радуюсь каждой возможности сесть в автомобиль и куда-нибудь поехать. И, как каждому мужчине на планете, мне кажется, что я хороший водитель — в отличие от всех остальных идиотов за рулем.

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

Я сам выбрал для себя такое поведение на дороге. И хотя некоторые идеи и правила скопированы мною у других, выучить их и всегда им следовать было моим личным выбором.

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

В книге «Шесть лет спустя: О чем не было сказано в Agile-манифесте» (Six Years Later: What the Agile Manifesto Left Out) Брайан Мэрик, один из подписантов первоначальной версии этого документа, пишет, что, к сожалению, профессиональные умения и дисциплина так и не были в нем упомянуты в явном виде [Marick 2007]. (Стоит отметить, что на второй странице среди двенадцати принципов в нем все же упоминается «постоянное внимание качеству технических решений».)

Как следствие, не увидев в манифесте прямого упоминания профессиональных умений и дисциплины, многие неверно интерпретировали это либо как отсутствие в гибких методологиях дисциплины вообще (что неправда), либо как доказательство, что тема развития умений и дисциплины в этих методологиях просто забыта. Об этом писал Скотт Эмблер в статье «Дисциплина в гибких методологиях» (The Discipline of Agile) [Ambler 2007]. Истина же состоит в том, что дисциплина имеет решающее значение в проектах по разработке ПО (как и во множестве других профессий). Многие разработчики пришли к тем же выводам, так что теперь у нас появился Манифест в защиту мастерства программирования, в котором напрямую говорится о «хорошо сделанном ПО» и «сообществе профессионалов».

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

Сторонники гибких методологий воспринимают мастерство программирования как данность.

И лишь немногие работают над совершенствованием своего мастерства.

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

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

Положительная обратная связь

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

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

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

Звук из громкоговорителя, проходя обратно через микрофон, моментально усиливается до невыносимого визга [Gleick 1988: 61]. Высокотехнологичные компании стремятся обосноваться в Кремниевой долине, потому что там уже находится много высокотехнологичных компаний [Waldrop 1992: 17]. Команда разработчиков пользуется хорошо известными ей средствами программирования только потому, что это позволяет ей поднять скорость разработки; в результате она приобретает еще больший опыт работы с этими средствами программирования [Weinberg 1992: 11]. Моральное состояние в команде снижается, когда из нее уходят лучшие сотрудники; в результате нагрузка на оставшихся возрастает, что еще больше ухудшает их моральное состояние [Yourdon 2004: 154]. Но самоусиливающиеся циклические процессы не будут по определению нежелательными. Например, высокое качество программного продукта может снизить затраты на его поддержание и повысить производительность, что, в свою очередь, создает условия для дальнейшего повышения его качества [DeMarco, Lister 1999: 22].

Следует помнить, что слово «положительный» в названии циклических процессов — это математическая условность. Полезная обратная связь может быть нежелательной. В целом самоусиливающиеся циклические процессы будут одним из основных механизмов самоорганизации [Waldrop 1992: 34].

Положительная обратная связь становится причиной как нестабильности, так и возникновения эффекта блокировки и эффекта снежного кома. Они лежат в основе механизма, который экономисты называют возрастающей отдачей (известного также как «деньги к деньгам» или «успех притягивает успех»). Кевин Келли называл самоусиливающиеся циклические процессы третьим божественным законом [Kelly 1993: 469]. Этому закону мы обязаны как своей жизнью, так и своими несчастьями.

Важно развивать в себе способность распознавать самоусиливающиеся (положительные) циклические процессы. Они помогают понять, почему организации могут оказаться затянутыми в деструктивные циклы развития, и позволяют найти способы изменить ситуацию к лучшему. Распознавание положительной обратной связи (и влияние на нее) — одна из центральных идей системного мышления (глава 3 «Теория сложности»). Столь же важно научиться видеть и уравновешивающие процессы (отрицательную обратную связь).

Отрицательная обратная связь

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

Увеличение содержания CO2 в крови стимулирует движение легких и учащение дыхания, что приводит к снижению содержания CO2 [Solé 2000: 90]. Когда температура в улье понижается, пчелы прижимаются друг к другу и быстро машут крыльями, в результате чего температура повышается [Miller, Page 2007: 15]. Согласно закону убывающей отдачи, рост предложения товара на рынке приводит к снижению его цены и наступлению момента, когда дальнейшее наращивание производства становится нецелесообразным [Waldrop 1992: 34]. При росте организации накладные расходы растут опережающими темпами, в то время как производительность повышается линейно; это снижает относительную экономическую отдачу [Coplien, Harrison 2005: 104]. Когда сотрудник нарушает принятые в команде нормы, та может обсудить создавшееся положение и принять корректирующие меры [Arrow 2000: 202]. А если проект идет с существенным превышением бюджетов и сроков, то по результатам технологического аудита можно запустить в системе несколько отрицательных циклических процессов и с их помощью спасти положение [Weinberg 1992: 95].

Целью отрицательной обратной связи часто бывает стабилизация системы или гомеостаз, чтобы эффекты, вызванные положительной обратной связью (которые часто бывают полезными), не вышли из-под контроля. Специалист по теории сложности Питер Корнинг утверждает, что «обратная связь» будет обратной связью только тогда, когда она ставит себе подобные цели:

Типичным примером будет термостат, который измеряет температуру в помещении и соответственно включает либо отключает обогреватели. Если использовать классическую формулировку ученого-системолога Уильяма Пауэра, полученное на входе значение сравнивается с внутренним «контрольным значением» и соотношение между ними определяет последующее поведение системы. Любое использование термина «обратная связь», которое отклоняется от этой ориентированной на достижение определенной цели и основанной на обработке информации модели, в лучшем случае будет метафорическим, а в худшем — введет в заблуждение.

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

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

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

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

Дисциплина × умения = компетентность

Уверен, что все мы сталкивались с этой ситуацией. Вы спешите, и некогда проверять, все ли вы взяли с собой из составленного заранее списка. Через полчаса вы возвращаетесь домой, чертыхаясь и проклиная все на свете, потому что забыли бумажник и теперь вам надо торопиться еще больше.

Я считаю дисциплину одним из двух главных измерений компетентности. Как бы вы оценили пилота, который постоянно забывает проверить двигатели перед вылетом? Или хирурга, который иногда забывает вымыть руки? Или актера на сцене, который не выучил свою роль? Будучи потребителем или пациентом, примете ли вы извинения типа «Прошу прощения, я очень торопился»?

Очевидно, что дисциплина важна в любой профессии. Джеральд Вайнберг описывает эффект бумеранга, который возникает, когда люди не выполняют необходимые процедуры. Сначала они пропускают какой-либо элемент процесса контроля качества, что увеличивает количество дефектов в готовом продукте, и это приводит к росту жалоб со стороны клиентов, в результате чего возникает необходимость отрываться от других проектов, чтобы решить возникшие проблемы, что ведет к возрастанию давления на команду разработчиков, вследствие чего не выполняются еще какие-либо процедуры [Weinberg 1992: 278–282]. Мы все знаем из опыта, что нарушения производственной дисциплины не ускоряют, а замедляют процесс. Это поистине порочный круг.

Мэри и Том Поппендик говорят о том же, указывая, что высокая скорость разработки невозможна, если качеству не уделяется должного внимания [Poppendieck 2007: 190]. Когда мы не сверяемся с чек-листами и перескакиваем через необходимые этапы, поначалу действительно складывается впечатление, что процесс ускорился. Но вскоре нежелательные компромиссы с точки зрения качества продукта (известные также как технический долг) доконают вас окончательно.

Вайнберг описывает шесть уровней зрелости при исполнении процессов [Weinberg 1992: 23]:

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

Вайнберг использует эти шесть уровней для классификации организаций, но я предпочитаю оценивать только отдельных исполнителей и только за конкретную деятельность. Что в итоге произойдет с самой компанией, будет результатом взаимодействия между людьми, которым при выполнении разных видов деятельности свойственны весьма разные уровни дисциплины. Например, меня иногда хвалят за то, насколько дисциплинированно я подхожу к написанию книг. Возможно, в этом смысле с точки зрения приведенной классификации я нахожусь на пятом («учет предыдущего опыта») или шестом уровне («согласованность»). Но если вы вдруг услышите громкую ругань и проклятия, то не исключено, что это я возвращаюсь за забытым бумажником — в таких делах я все еще нахожусь на первом уровне (когда «о процессах даже не вспоминают»). (Ругань и проклятия могут также исходить от моего партнера. Потрясающе: когда я писал этот абзац, он как раз вернулся, потому что десять минут назад вышел из дома, забыв взять бумажник…)

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

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

Есть два подхода к описанию уровней профессионального мастерства. Система гильдий, распространенная в средневековой Европе, предусматривала три уровня: ученик, подмастерье и мастер. Практически ничем не отличается японская система сюхари, в которой выделяются три уровня владения боевыми искусствами: сю, ха и ри. И в той и в другой системе люди, находящиеся на первом уровне, изучают основные техники; на втором уровне акцент делается на исключениях и рефлексии; а на третьем уровне думать уже не надо, все дается легко и естественно.

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

Если нарисовать две оси, соответствующие дисциплине и умениям, то мы получим матрицу (рис. 10.4). Она позволяет в удобном виде оценивать степень проектной зрелости. Умения можно утратить с возрастом, в результате травмы или отставания от технического прогресса, а дисциплину — в результате потери мотивации или из-за отвлекающих факторов. Компетентность подразумевает как профессиональные умения, так и дисциплину, а следовательно, менеджерам надо заниматься и тем и другим.

Разнообразие правил

В своей деятельности команды руководствуются определенными правилами: как документировать требования, как предварительно оценивать работу, как фиксировать исходный код, как писать тестовый код, как разворачивать готовые решения и так далее. Кроме того, у каждого члена команды есть свой личный набор правил. Один разработчик фиксирует тестовый код в виде ветви до того, как написан окончательный код, в то время как другой откладывает свой код, пока не убедится, что все работает безупречно. Одному дизайнеру нравится использовать Visio, а другой говорит, что лучше доски и маркеров пока еще ничего не придумано. Один тестировщик документирует результаты пользовательской приемки при помощи специально созданного для этой цели инструмента, а другой пользуется простой таблицей в Google Docs. Я предпочитаю, чтобы комментарии к исходному коду были предельно лаконичными, а другим нравятся огромные простыни с максимумом подробностей.

Хорошо ли, когда люди следуют собственным правилам?

Да. Скорее нет. Может быть. Все зависит от ситуации…

Для Scrum-мастера неудобно, если у каждого члена команды есть свой способ калибровки пользовательских историй. Всем приходится договариваться, применять ли единицы истории или часы, — в противном случае невозможно рассчитать скорость команды. Точно так же нуждаются в согласовании даты и время совещаний, длина спринтов и тому подобное.

В то же время часто нет никакой необходимости синхронизировать методы работы с исходным кодом. Как члена команды меня не беспокоит, что у людей свои правила откладывания и фиксации кода или свои правила комментирования — при условии, что код, внесенный в ствол, полностью протестирован. И для меня не имеет значения, какими средствами люди пользуются при дизайне. Меня гораздо больше интересует, чтобы члены команды были мотивированы. Мне также небезразлично, мотивирован ли я сам, поэтому я не буду заниматься парным программированием, если у меня нет настроения (что бывает часто). Я хочу, чтобы оценивали ценность сделанного мной, а не способ, которым я это делаю. Если я могу писать код высочайшего качества, сидя в переговорной комнате голым и с трусами, надетыми на голову, то кому какое дело? (Это просто пример. Я пробовал — это не работает.)

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

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

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

Принцип субсидиарности

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

Субсидиарность — организационный принцип, в соответствии с которым вопросы должны решаться на самом малом, низком или удаленном от центра уровне, являющемся достаточно компетентным. В «Оксфордском словаре английского языка» под субсидиарностью понимается идея, что центральная власть должна иметь субсидиарную функцию, то есть решать только те вопросы, которые не могут быть эффективно решены на более низком или локальном уровне. К областям применения данного принципа относятся государственное управление, политология, кибернетика и менеджмент.

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

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

Абсолютно нормально, если люди и команды копируют идеи друг у друга и синхронизируют применяемые ими правила без участия менеджера. Но также нормально, когда люди отходят от принятых норм и экспериментируют с новыми практиками. А если в дело вступает более высокая инстанция и говорит «Вам не разрешается делать это таким способом», то лучшим ответом будет:

Пожалуйста, объясните, почему установленные вами правила более эффективны, чем те, которые установил я сам?

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

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

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

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

В своей статье «Дорожное движение безопаснее, когда нет правил» эксперт в этой области Ханс Мондерман отмечает, что в случаях, когда на перекрестках отключали светофоры и убирали все дорожные знаки, их пропускная способность возрастала, а аварийность снижалась [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].Некоторые ученые относятся к теории разбитых окон критически. По их мнению, корреляция здесь могла быть ошибочно принята за причинно-следственную связь и привела к неверной интерпретации результатов некоторых исследований, в том числе к ошибке в знаменитом примере с уровнем преступности в Нью-Йорке, который описан в книге «Переломный момент» [Gladwell 2002]. И тем не менее существует достаточно доказательств, что верен сам принцип, лежащий в основе теории разбитых окон [Keizer 2008]. Эта теория стала логическим развитием более общей идеи, выраженной в уравнении Левина:

П = f(Л,ВС).

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

Отправить