• Проведение выездных совещаний, вероятно, помогает сосредоточить внимание присутствующих.
• Хорошая организация питания на таких встречах идет на пользу посещаемости.
• Участие высшего руководства сигнализирует о том, что организация серьезно рассматривает вопросы производительности и непрерывного совершенствования.
• Проявление серьезного интереса к производительности, непрерывному совершенствованию и управлению на основе количественных данных жизненно необходимо для развития культуры кайдзен среди сотрудников компании.
• Есть свидетельства того, что операционный обзор ведет к повышению уровня зрелости организации.
• Предложения по улучшению должны быть записаны как меры, которые предстоит принять руководству; реализация этих предложений рассмотрена в начале ближайшего и последующих совещаний.
• Менеджеры должны нести ответственность и демонстрировать систематическую работу над предложениями.
Глава 15
Начало перехода на канбан
Начало работы с Канбаном не похоже на те меры, которые вы, возможно, предпринимали в прошлом. Важно заложить основания для долгосрочного успеха. Для этого нужно сначала понять цели Канбан-подхода к изменениям. Главное при переходе на Канбан – это управление изменениями. Все остальное вторично.
Культурные изменения, а не инициатива сверху
В главе 5 описано, как Канбан оптимизирует существующий процесс после ряда пошаговых эволюционных изменений. Процесс оптимизации уже существующей модели ведет к повышению зрелости организации и позволяет впоследствии провести более крупные стратегические улучшения. Поэтому маловероятно, что перехода на Канбан удастся добиться при помощи инициативы сверху – например, назначив специальную программу обучения. Это существенно отличается от планирования и управления типичным переходом к agile-методологиям. На самом деле подход к управлению изменениями, используемый при переходе на agile-методы, мало отличается от предшествовавших подобных инициатив, например, основанных на модели CMMI или предполагающих введение Rational Unified Process. Инициатива по внедрению изменений в этом случае оказывается масштабным проектом, продуманным и распланированным заранее. Это особый вид управляемых изменений, при котором сначала определяется и оценивается текущий процесс, а затем выбирается один из agile-методов из учебника. После этого планируются меры по обучению и наставничеству, которые призваны помочь команде перейти от текущего метода к вводимому agile-процессу. Когда все заканчивается и внедряется новый процесс, проводится следующая оценка, которая должна продемонстрировать принятие новых методов. С Канбаном все происходит не так. В этом случае инициатива не планируется, не проводится никаких оценок и никто не говорит в конце: «Ну вот, мы перешли на agile!» Вообще конца как такового нет. Руководство управляет непрерывным процессом, проводя пошаговые изменения. В результате команда постепенно приходит к культуре кайдзен.
Действительно, обучение необходимо. Члены команды и другие заинтересованные лица должны понимать базовые принципы – например, взаимоотношения между WIP и временем выполнения, основанные на том, что строгие WIP-лимиты повысят предсказуемость времени выполнения. Возможно, понадобится провести краткий анализ вероятных путей совершенствования – устранения бутылочных горлышек, брака и вариативности. Когда потенциал для совершенствования выявлен, можно провести обучение новым навыкам и методам. Например, если основной источник брака – это программные ошибки, то стоит обучить команду разработчиков методам, которые существенно снижают количество ошибок и повышают качество кода: непрерывной интеграции, модульному тестированию и парному программированию.
Однако не нужно тратить слишком много времени на обучение. Прежде всего добейтесь консенсуса по поводу введения Канбана и начните пользоваться этим методом. Цель этой главы – попытаться заложить основы для успешного перехода на Канбан. В ней приводятся 12 простых шагов, необходимых для того, чтобы начать.
Хотя основная цель Канбана – вносить изменения при минимуме сопротивления, могут быть и иные задачи. Но изменения ради изменений бессмысленны: эти иные задачи должны отражать подлинные нужды бизнеса – например, предсказуемое создание высококачественного товара. Цели, перечисляемые здесь, – это примеры. Конкретные цели различаются для разных организаций. Первый шаг в процессе перехода – определить, для чего вы вводите Канбан в организации.
Основная цель для нашей канбан-системы
Мы переходим на Канбан, потому что считаем, что он дает возможность лучше производить изменения. Канбан изначально стремится изменить как можно меньше. Поэтому первая цель – это изменения с минимальным сопротивлением.
Цель 1. Оптимизация существующих процессов
Существующие процессы будут оптимизированы благодаря визуализации и ограничению числа незавершенных заданий, что стимулирует изменения. Поскольку существующие роли и степени ответственности не изменятся, сопротивление сотрудников будет минимальным.
Вторичные цели нашей канбан-системы
Мы знаем, что Канбан позволяет воплотить в жизнь все шесть элементов рецепта успеха (главу 3). Однако можно немного переформулировать цели и расширить некоторые пункты рецепта, чтобы каждый из них помогал добиться больше одной цели.
Цель 2. Высококачественные релизы
Канбан позволяет сосредоточиться на качестве, поскольку ограничивает число незавершенных заданий и дает возможность определить правила приемлемости, прежде чем единица работы будет переведена на следующий этап процесса. Эти правила могут включать критерии оценки качества. Если, например, мы строго-настрого запрещаем отправлять пользовательские истории на приемочный тест, пока не пройдут все остальные тесты и не будут устранены ошибки, мы тем самым заставляем конвейер простаивать, пока история не будет исправлена так, что можно продолжить работу. Если команда недостаточно знакома с Канбаном, то не стоит устанавливать такое жесткое правило, но какие-то критерии качества, привлекающие внимание команды к разработке хорошего кода, почти не содержащего ошибок, должны присутствовать.
Цель 3. Повышение предсказуемости времени выполнения
Нам известно, что количество WIP непосредственно связано с временем выполнения и есть корреляция между временем выполнения и нелинейным ростом количества ошибок
[9]. Поэтому имеет смысл задавать WIP-лимиты. Будет гораздо легче работать, если мы ограничим число незавершенных заданий фиксированной цифрой. Это позволит установить предсказуемое время выполнения, а число ошибок должно уменьшиться.
