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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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