Канбан. Альтернативный путь в Agile - [61]

Более ранний пример операционных обзоров

Операционные обзоры придумал не я. Они характерны для многих крупных компаний. Но я научился проводить их объективно и масштабно, когда в 2001 году работал в Sprint PCS. Мой руководитель, вице-президент и генеральный менеджер sprintpcs.com, учредил их примерно с теми же целями. Он хотел повысить зрелость своей организации – подразделения, состоявшего из 350 человек, отвечавшего за сайт, всю электронную коммерцию и онлайновую поддержку клиентов в компании Sprint, занимавшейся сотовой связью. В sprintpcs.com операционный обзор проводился каждую третью пятницу месяца в два часа дня. Он продолжался два часа, участвовали около 70 старших сотрудников и менеджеров соответствующего подразделения, приглашались также директора или старшие менеджеры наших партнеров по цепочке создания ценности. Часто бывали и высшие руководители, в том числе директор по маркетингу и вице-президент по стратегическому планированию. Формат очень походил на то, что было позднее реализовано в Corbis. Все проводилось исключительно на основании объективных данных. Каждый менеджер представлял собственные данные. Открывалось совещание финансовой информацией. Расписание было распланировано и четко соблюдалось. После совещания все уходили домой пораньше, тем более что была пятница. Совещание проводилось не на территории офиса, а в кампусе местного колледжа. Хотя методы гибкой разработки ПО в целом давались sprintpcs.com тяжело, операционный обзор был ключевым элементом в развитии зрелости организации и совершенствовании управления ею. Он демонстрировал сотрудникам, что менеджеры знают, как руководить, а сотрудники и руководители направления имеют возможность показать высшему руководству, чем они могут помочь и где менеджерам необходимо вмешаться, чтобы повысить эффективность. На основании двух экспериментов, проведенных за последнее десятилетие, я убедился, что операционные обзоры – это необходимый элемент успешного перехода к бережливым или agile-принципам и жизненно важный компонент развития зрелости организации.

Выводы

• Операционный обзор проводится в масштабе всей организации.

• Операционный обзор должен придерживаться объективных данных.

• Каждый отдел сообщает свои данные.

• Презентации должны быть короткими и в основном содержать показатели и индикаторы вроде тех, о которых говорилось в главе 12.

• Начинать нужно с финансовой информации: это подчеркивает, что разработка ПО – часть более обширного бизнеса, а хорошее управление имеет большое значение.

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

• Совещания должны быть короткими – желательно около двух часов.

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

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

• Эффективный операционный обзор создает взаимное доверие между менеджерами и сотрудниками.

• Внешние заинтересованные лица, посещая операционные обзоры, видят, как функционируют группы IT и разработки, узнают об их проблемах. Это усиливает доверие и сотрудничество.

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

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

• Хорошая организация питания на таких встречах идет на пользу посещаемости.

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

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

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

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

• Менеджеры должны нести ответственность и демонстрировать систематическую работу над предложениями.

Глава 15 Начало перехода на канбан

Начало работы с Канбаном не похоже на те меры, которые вы, возможно, предпринимали в прошлом. Важно заложить основания для долгосрочного успеха. Для этого нужно сначала понять цели Канбан-подхода к изменениям. Главное при переходе на Канбан – это управление изменениями. Все остальное вторично.

Культурные изменения, а не инициатива сверху

В главе 5 описано, как Канбан оптимизирует существующий процесс после ряда пошаговых эволюционных изменений. Процесс оптимизации уже существующей модели ведет к повышению зрелости организации и позволяет впоследствии провести более крупные стратегические улучшения. Поэтому маловероятно, что перехода на Канбан удастся добиться при помощи инициативы сверху – например, назначив специальную программу обучения. Это существенно отличается от планирования и управления типичным переходом к agile-методологиям. На самом деле подход к управлению изменениями, используемый при переходе на agile-методы, мало отличается от предшествовавших подобных инициатив, например, основанных на модели CMMI или предполагающих введение Rational Unified Process. Инициатива по внедрению изменений в этом случае оказывается масштабным проектом, продуманным и распланированным заранее. Это особый вид управляемых изменений, при котором сначала определяется и оценивается текущий процесс, а затем выбирается один из agile-методов из учебника. После этого планируются меры по обучению и наставничеству, которые призваны помочь команде перейти от текущего метода к вводимому agile-процессу. Когда все заканчивается и внедряется новый процесс, проводится следующая оценка, которая должна продемонстрировать принятие новых методов. С Канбаном все происходит не так. В этом случае инициатива не планируется, не проводится никаких оценок и никто не говорит в конце: «Ну вот, мы перешли на agile!» Вообще конца как такового нет. Руководство управляет непрерывным процессом, проводя пошаговые изменения. В результате команда постепенно приходит к культуре кайдзен.