Устойчивость и возмущения

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

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

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

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

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

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

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

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

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

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