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

Ниже приведены три типа аттракторов, существующих в сложных системах [Gleick 1987: 269]:

• Фиксированные точки. Система сохраняет одно определенное состояние. Хорошим примером такого аттрактора служит организационная иерархия. Почти все компании принимают структуру такого типа, а затем остаются в этом состоянии навечно [Waldrop 1992: 169].

• Замкнутые циклические. Система постоянно повторяет одну и ту же последовательность состояний. Одним из примеров будет динамика развития групп, проходящая стадии формирования, конфликта, нормализации, исполнения работы и расформирования [Arrow 2000: 152].

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

Как правило, аттрактор имеет обширную область притяжения. Теперь предположим, что на устойчивую систему начинает воздействовать какое-либо возмущение. Внезапно одна из ее переменных произвольно перескакивает с одного значения на другое. (Например, один метод развития сменяется другим.) На рис. 14.6 показано, что большинство таких пертурбаций не оказывает значительного воздействия на систему. Она или остается притянутой к аттрактору (S1), или же, если ее оттянуло от аттрактора, но при этом она осталась в его области притяжения (S2), она все равно возвращается в свое конечное состояние. Только когда значение переменных в системе изменилось достаточно сильно, систему может вытолкнуть из области притяжения одного аттрактора в другую область (S3).

Устойчивость, или гомеостаз, это важное свойство сложных систем. Независимо от интенсивности применяемых к ним воздействий, некоторые системы упорно сохраняют свое состояние. Звучит знакомо? Разве это не похоже на тот случай, когда вы пытались внедрить Agile-методологии в своей команде, но она в конечном итоге вернулась к привычным методам работы? Не напоминает ли это вам о том, как вы пытались изменить организационную культуру, но все ваши усилия натыкались на сопротивление?

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

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

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

Давайте я приведу пример… Я пробовал внедрить методы разработки с ориентацией на тестирование (TDD) в нескольких командах, но безрезультатно. Казалось, что все сговорилось против меня – старые версии кода, технические платформы, культура команд и контракты с клиентами. Даже в тех случаях, когда сотрудники хотели перейти на эти методы, им не удавалось довести свои героические усилия до конца. Тогда я решил начать с нуля с новой бизнес-моделью, другими технологиями, другой архитектурой и (что очень важно) с другими клиентскими контрактами. В команду были набраны те же люди, с кем я работал раньше. Но я изменил внешнюю среду вместо того, чтобы пытаться изменить саму команду. В этой ситуации команде удалось найти устойчивое состояние, которое включало методы разработки через тестирование. Внезапно использование этих методов перестало вызывать какие-либо затруднения.

Сейчас я попытаюсь еще сильнее напрячь ваше воображение. Представьте себе еще одно измерение, которое мы добавим к фазовому пространству. Это дополнительное измерение будет соответствовать степени «приспособленности» системы к определенной среде. (Естественно, абсолютной шкалы, которая позволяла бы измерить этот параметр, не существует [Waldrop 1992: 259]. Но, как уже бывало ранее, мы вполне в состоянии определить, что одна система лучше приспособлена к определенной среде, чем другая. «Я узнаю ее, когда увижу!»)

На рис. 14.7 в двух измерениях показана комбинация степени приспособленности и фазового пространства. Горизонтальная ось показывает местонахождение в фазовом пространстве системы (все измерения фазового пространства свернуты в одну линию). Вертикальная ось соответствует степени приспособленности. В результате мы получили то, что системные теоретики называют адаптивным ландшафтом. Он показывает, насколько хорошо функционирует система относительно своего текущего состояния. Немного похоже на Альпы, но без будок, в которых собирают деньги за проезд по платным дорогам.

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