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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С моей точки зрения, слабость Agile-манифеста состоит в том, что в нем (в явном виде) не сказано, что в любых проектах по разработке программных продуктов необходимы умные, дисциплинированные и способные фокусироваться люди. Прекрасно, что гибкие методологии «ценят людей выше, чем процессы», но это до тех пор, пока вы не обнаружите, что ваша команда состоит из двух троллей, одного попугая, одного парикмахера и одного довольно способного проектного менеджера, который, к сожалению, слеп, глух и нем. Никакой коучинг не поможет такой команде волшебным образом самоорганизоваться и создать успешный продукт. Я называю это слепой зоной гибких методологий. Они хороши (в том виде, как описаны в манифесте) только при условии, что у вас подобралась прекрасная (или как минимум достаточно хорошая) команда. Ради справедливости надо признать, что вне контекста гибких методологий компетентность сотрудников раза в два важнее, чем с ними. Но это не отменяет того факта, что Agile-манифест оставляет вопрос компетентности за скобками.