Несколько завершающих практических советов по теме непрерывного улучшения

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

• Регулярно проводите ретроспективы, на которых обсуждайте текущее положение дел и способы внесения в него улучшений. Ретроспективы могут проводиться на разных уровнях в организации, а не только на уровне команд. Вы должны позаботиться о том, чтобы речь на них шла не только об адаптации (реагировании на возникающий в процессе разработки опыт), но и об исследовании(экспериментировании) и прогнозировании (подготовке к возможному развитию событий). Этим вы сможете обеспечить, чтобы двойные циклы обучения учитывали как уже состоявшиеся, так и возможные будущие события. Огромное количество полезных советов об организации ретроспектив можно найти в книге «Ретроспективы в гибких методологиях» (Agile Retrospectives) [Derby, Larsen 2006].
• Ведите журнал улучшений для каждой команды и на разных уровнях в организации, при этом журналы должны быть доступны всем. Это помогает людям отслеживать идеи, которые пока еще не внедрены. Как и в случае с любыми другими журналами, в любое время старые идеи, которые так и не были внедрены, могут быть заменены в них на новые [Cohn 2009: 62–63]. Может потребоваться ежемесячно резервировать для непрерывной оптимизации какое-то время в графиках загрузки, иначе есть риск, что идеи, перечисленные в журнале оптимизации, будут лишь обсуждаться, но до внедрения дело так и не дойдет.
• Создайте в очевидном виде цикл улучшений, состоящий из отдельных этапов. При этом вы можете использовать как те восемь этапов, которые я перечислил при описании обобщенного процесса оптимизации SLIP, так и любую другую серию этапов, которую находите полезной. Как и задачи, представленные на любой доске задач, применяемых в Scrum и канбане, позиции в журнале оптимизации должны пройти определенные стадии проработки, что поможет не пропустить ни одного из важных шагов (например, этапы измерения и проверки).
• Создайте переходную группу сотрудников (их еще иногда называют сообществами лидеров изменений), задачей которой будет продвигать и поддерживать изменения на уровне организации в целом. В эту группу должны входить старшие менеджеры и представители всех подразделений организации, которым предстоит переход на новые методы работы. Задачей «чемпионов изменений» будет не навязывать данные изменения, а помогать людям в их осуществлении [Cohn 2009: 63–70]. Как мы обсуждали ранее, поскольку изменения никогда не заканчиваются, такие группы могут создаваться на полупостоянной основе.
• Изучайте методы канбана, которые представляют собой отличный инструмент для управления непрерывным улучшениям. Канбан — управление изменениями, где в качестве механизма используются ограничения на объем незавершенного производства, а также широко применяется визуализация потоков ценности (или сетей создания ценности) как способ предъявления командам необходимости изменений [Anderson 2010].
• Рекомендуйте сотрудникам своей организации инициировать создание собственных сообществ по оптимизации вокруг тем, которые выходят за рамки отдельных проектов. Примерами таких тем могут быть тестирование, разработка архитектуры или пользовательских интерфейсов [Cohn 2009: 70–78]. Если вы менеджер, то лучше не создавать такие сообщества самому, поскольку это должны делать сами команды в результате самоорганизации и в зависимости от своих потребностей. В случае необходимости вы всегда сможете им помочь. (Такие сообщества будут результатом самоотбора, который мы обсуждали в главе 13.)

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

Продолжайте движение

Изменяющаяся внешняя среда — а в случае коэволюционирующих систем и Гонка Черной Королевы — оказывает огромное воздействие на адаптивные ландшафты. В результате эти ландшафты как будто бы сделаны из резины (по ним было бы удобно передвигаться на роликах). Пики и долины постоянно сдвигаются, растут или понижаются. Система, которая еще вчера была отлично приспособленной, завтра может оказаться совершенно неприспособленной к изменившейся внешней среде. Сегодняшние лучшие практики завтра могут превратиться в худшие. Биологические виды, компании и команды должны постоянно изменять себя, поскольку требуется бежать изо всех сил, чтобы не сорваться с постоянно движущегося пика. А если гора вдруг превращается в долину, нужно уметь перепрыгнуть на соседнюю вершину.

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

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

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

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

Резюме

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

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

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

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

Подумать и сделать

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

• Создайте журнал улучшения и разработайте процесс внедрения улучшений. Чтобы сформулировать, в чем заключаются желательные результаты, и быть в состоянии их отслеживать, вы можете использовать предложенное мною схематическое описание процесса улучшения или любую другую модель. (Не удивляйтесь, если реализованные вами изменения не приведут к немедленным улучшениям или поначалу эффективность даже снизится.)
• Обсудите со своей командой, каких именно изменений вам необходимо добиться. Эти изменения достаточно привлекательны для сотрудников? Их отсутствие воспринимается как болезненное?
• Проанализируйте проблемы, которые ваша команда никак не может решить, несмотря на все принимаемые меры. Попробуйте сосредоточиться на изменении внешней среды, а не на поведении команды, чтобы ликвидировать аттрактор, к которому они постоянно притягиваются.
• Возьмите себе за правило обсуждать с командой допущенные ошибки и то, какие уроки из этих ошибок можно вынести.
• Попробуйте поэкспериментировать с изменениями просто потому, что вы можете себе это позволить (без давления со стороны внешней среды и не зная заранее, в правильном направлении вы движетесь или нет). Обсудите с командой, чему вам удалось в результате научиться.
• Попробуйте скомбинировать подходы к разработке, применяемые разными командами. Удалось ли вам в результате получить более эффективный процесс, чем исходные?
• Обсудите с командой, как у них происходит заимствование интересных практик из различных источников. Удостоверьтесь, что процесс заимствования и «публикации» идей идет на постоянной основе.
• Удостоверьтесь, что все команды регулярно проводят ретроспективы.
• Создайте переходную группу, в задачу которой будет входить поддержка изменений в организации.
• Порекомендуйте своим сотрудникам создавать «сообщества улучшений» вокруг тем, выходящих за рамки отдельных проектов и касающихся сразу многих команд.

Глава 16