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

Гарантия выживания заключается в гибкости.

В Agile-манифесте ничего не говорится о том, что нужно в обязательном порядке применять Экстремальное программирование, Scrum или какую-либо другую стандартную методологию. Там сказано, что вы должны принимать неизбежность изменений и приветствовать их. Процесс оптимизации функциональных возможностей, качества, компетентности сотрудников и команд, инструментов, графиков и процессов бесконечен. Он должен стать вашим образом жизни. Не довольствуйтесь достигнутым! Продолжайте движение! Лишь иногда останавливайтесь, чтобы взглянуть на адаптивный ландшафт и проверить, как поживают те самые пики. А затем опять становитесь на ролики и продолжайте гонку.

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

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

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

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

Независимо от того, какими стратегиями вы воспользуетесь, важно понимать, что непрерывное улучшение непрерывно в буквальном смысле. Оно никогда не заканчивается.

Посмотрим, как применить некоторые идеи из данной главы в вашей компании:

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

• Обсудите со своей командой, каких именно изменений вам необходимо добиться. Эти изменения достаточно привлекательны для сотрудников? Их отсутствие воспринимается как болезненное?

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

• Возьмите себе за правило обсуждать с командой допущенные ошибки и то, какие уроки из этих ошибок можно вынести.

• Попробуйте поэкспериментировать с изменениями просто потому, что вы можете себе это позволить (без давления со стороны внешней среды и не зная заранее, в правильном направлении вы движетесь или нет). Обсудите с командой, чему вам удалось в результате научиться.

• Попробуйте скомбинировать подходы к разработке, применяемые разными командами. Удалось ли вам в результате получить более эффективный процесс, чем исходные?

• Обсудите с командой, как у них происходит заимствование интересных практик из различных источников. Удостоверьтесь, что процесс заимствования и «публикации» идей идет на постоянной основе.

• Удостоверьтесь, что все команды регулярно проводят ретроспективы.

• Создайте переходную группу, в задачу которой будет входить поддержка изменений в организации.

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

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

Начать мыслить в категориях сложности – все равно что жениться на черной дыре. Чтобы сохранить рассудок, лучше с такими вещами вообще не связываться. И все же это очень привлекательный способ смотреть на окружающий мир. А кроме того, вас все равно затянет, и в результате все, во что вы верили, либо окажется опровергнутым, либо превратится в ничто. А я верю во множество вещей.

Я считаю, что линейное мышление часто приводит нас к неверным выводам (см. главу 1) и что у гибких методологий разработки ПО и теории сложности имеется общий фундамент в виде нелинейного мышления (главы 2 и 3). Я полагаю, что люди – это самый важный элемент организаций и менеджерам необходимо прилагать максимум усилий, чтобы поддерживать в них активность, креативность и мотивацию (главы 4 и 5). Я уверен, что команды способны на самоорганизацию и для этого необходимо предоставлять им широкие права и полномочия, а также распространять на них доверие со стороны менеджмента (главы 6 и 7). В главах 8 и 9 показано, что самоорганизация может приводить к нежелательным последствиям и поэтому необходимо защищать людей и находящиеся в общедоступном пользовании ресурсы, а также ставить перед командами четкие цели. Я также считаю, что некомпетентные команды не смогут достичь поставленных целей и по этой причине в фокусе внимания менеджеров должно находиться развитие компетенций сотрудников (главы 10 и 11). Многие команды функционируют внутри сложных компаний, и поэтому я убежден, что важно уделять внимание созданию организационных структур, в которых коммуникация происходит без затруднений (главы 12 и 13). Я также думаю, что люди, команды и организации нуждаются в постоянном совершенствовании, чтобы в результате момент неудачи наступал как можно позже (главы 14 и 15). И наконец, мне иногда кажется, что поскольку мои выводы в этой книге достаточно просты для понимания, то это может быть симптомом, что они неверны.