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

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

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

• Нельзя сталкиваться друг с другом (разделение).

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

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

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

• Договориться об общем направлении движения команды (согласованность).

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

• Сотрудничать с другими членами команды, не быть одиночкой (сплоченность).

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

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

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

1. Рассчитать среднее положение птиц, которых я вижу.

2. Рассчитать среднее направление движения птиц, которых я вижу.

3. Если расстояние от меня до среднего положения > константы A, то нужно скорректировать направление моего движения на X градусов по отношению к среднему направлению.

4. Если расстояние от меня до какой-либо другой птицы < константы В, то нужно отклониться от нее в сторону на Y градусов.

5. Если направление моего движения отклоняется от среднего направления движения стаи больше, чем на C градусов, то нужно скорректировать мое направление на Z градусов в сторону среднего направления.

6. И так далее…

7. Повторять до тех пор, пока кто-нибудь не крякнет, что пора садиться.

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

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

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

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

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

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

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