Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

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

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

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

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

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

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

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

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

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

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

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

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