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

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

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

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

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

(реагировании на возникающий в процессе разработки опыт), но и об исследовании (экспериментировании) и прогнозировании (подготовке к возможному развитию событий). Этим вы сможете обеспечить, чтобы двойные циклы обучения учитывали как уже состоявшиеся, так и возможные будущие события. Огромное количество полезных советов об организации ретроспектив можно найти в книге «Ретроспективы в гибких методологиях» (Agile Retrospectives) [Derby, Larsen 2006].

• Ведите журнал улучшений

для каждой команды и на разных уровнях в организации, при этом журналы должны быть доступны всем. Это помогает людям отслеживать идеи, которые пока еще не внедрены. Как и в случае с любыми другими журналами, в любое время старые идеи, которые так и не были внедрены, могут быть заменены в них на новые [Cohn 2009: 62–63]. Может потребоваться ежемесячно резервировать для непрерывной оптимизации какое-то время в графиках загрузки, иначе есть риск, что идеи, перечисленные в журнале оптимизации, будут лишь обсуждаться, но до внедрения дело так и не дойдет.

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

• Создайте переходную группу сотрудников (их еще иногда называют сообществами лидеров изменений), задачей которой будет продвигать и поддерживать изменения на уровне организации в целом. В эту группу должны входить старшие менеджеры и представители всех подразделений организации, которым предстоит переход на новые методы работы. Задачей «чемпионов изменений» будет не навязывать данные изменения, а помогать людям в их осуществлении [Cohn 2009: 63–70]. Как мы обсуждали ранее, поскольку изменения никогда не заканчиваются, такие группы могут создаваться на полупостоянной основе.

• Изучайте методы канбана

, которые представляют собой отличный инструмент для управления непрерывным улучшениям. Канбан – управление изменениями, где в качестве механизма используются ограничения на объем незавершенного производства, а также широко применяется визуализация потоков ценности (или сетей создания ценности) как способ предъявления командам необходимости изменений [Anderson 2010].

• Рекомендуйте сотрудникам своей организации инициировать создание собственных сообществ по оптимизации вокруг тем, которые выходят за рамки отдельных проектов. Примерами таких тем могут быть тестирование, разработка архитектуры или пользовательских интерфейсов [Cohn 2009: 70–78]. Если вы менеджер, то лучше не создавать такие сообщества самому, поскольку это должны делать сами команды в результате самоорганизации и в зависимости от своих потребностей. В случае необходимости вы всегда сможете им помочь. (Такие сообщества будут результатом самоотбора, который мы обсуждали в главе 13.)

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

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