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

Вы, наверное, заметили, что я люблю поговорить о вождении. Это свойственно всем мужчинам и, скорее всего, запрограммировано где-то в 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].