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

Несмотря на такого рода затруднения, с которыми приходится иметь дело путешественникам во всем мире, я не считаю, что ООН должна принять резолюцию и ввести обязательные для всех общемировые стандарты, касающиеся розеток, валют и единиц измерения. Различные части сложных систем всегда будут стремиться к оптимизации в своих интересах, а следовательно, местные системы стандартов в разных странах изменятся только тогда, когда такой переход окажется для этих стран оптимальным. Именно это произошло в Европе: шестнадцать стран добровольно перешли на новую единую валюту, потому что решили, что открывающиеся в этой связи перспективы и соображения долгосрочной экономии ресурсов перевешивают однократные затраты на такой переход. Другие европейские страны приняли решение пока воздержаться от этого шага, потому что, с их точки зрения, издержки (финансовые, политические и культурные) перевешивают возможные выгоды.

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

Когда мы оцениваем свою эффективность, мы также сравниваем ее с определенными стандартами. В прошлом такие стандарты устанавливались менеджерами, которые фиксировали их на определенном уровне. Но самоорганизующиеся команды могут самостоятельно этим управлять. Их стандарты более динамичны, поскольку по мере развития компетенций люди могут сами пересматривать эти стандарты в сторону повышения [Thomas 2000: 31].

При разработке ПО предметом обсуждения между лидерами компетенций и сотрудниками в этом случае становятся их собственные стандарты, а не те, что навязаны менеджерами. К числу стандартов, устанавливаемых командами самостоятельно, могут относиться протоколы взаимодействия с пользователями, система именования файлов, требования, предъявляемые к коду, структура файлов, используемые инструменты, протоколы регистрации ошибок, правила безопасности [Poppendieck 2007: 193]. Исчезает необходимость в стандартизации сверху вниз, проводимой менеджментом. Но стандартизация снизу вверх произойдет только в том случае, если цели и контрольные показатели не оставляют у сотрудников никаких сомнений, что оптимальнее будет внести изменения в процесс своей работы.

Управляйте системой, а не правилами или людьми

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

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

• Чтобы ускорить принятие лучших практик, вводите их в виде целостных мемплексов, а не по отдельности. Например, большинство идей, использованных Дэвидом Алленом в книге «Как привести дела в порядок» (Getting things done), существовало задолго до появления этого труда. Но в книге все идеи собраны в единый «пакет» под легко запоминающимся брендом, что облегчает задачу применения рекомендуемых автором практик.

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

• Большие проблемы начинаются с маленьких. Нельзя фокусироваться только на крупных проблемах, поскольку за это время небольшие превращаются в огромные. Например, с самого начала установите требования, предъявляемые к качеству кода, чтобы под воздействием эффекта разбитых окон ваш проект не стал похож на местность, где похозяйничали сомалийские пираты [Hunt, Thomas 2000: 5].