Друзья, привет!

С вами Денис Бартоломе, руководитель направления развития проектной деятельности Росбанка. Сегодня я расскажу об эволюции восприятия Канбан-метода.

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



Если интересно — добро пожаловать под кат.

Альтернативный путь в Agile

Большинство людей на постсоветском пространстве, которые начинают свое знакомство с Kanban-методом, воспринимает его исключительно в контексте Agile-практик. Хорошо это или плохо – вопрос дискуссионный, оставим это как факт.

Во многом такое восприятие можно объяснить работой маркетологов, которые перевели книгу Дэвида Андерсона (автора метода), которая в оригинале называется «Successful Evolutionary Change for Your Technology Business», как «Канбан. Альтернативный путь в Agile».

Хотя, масла в огонь подлили и консультанты-универсалы, которые предлагают «Agile под ключ», где Канбан представляют как «фреймворк, альтернативный Скраму».

Фреймворк из LEAN с WIP-лимитами

Да, да. Консультанты-универсалы часто останавливаются на этом восприятии метода – Канбан как фреймворк: набор определенных правил, который выстраивает поток задач. Такое восприятие возникает и от запроса заказчиков, которые тоже, не погрузившись в тему, хотят «фреймворк». Тем более, что в контексте Agile-практик перед глазами применение Скрама.

А потом все удивляются большому количеству неудач таких «внедрений».

Toolbox менеджера

Тот, кто все еще не бросил тему на одном из предыдущих двух этапов и решил в неё еще немного погрузиться, начинает осознавать, что Канбан-метод — это огромный ящик с инструментами, которыми можно решать проблемы в процессе доставки ценности.

В этот инструментарий входят:

• Набор ценностей
• Набор принципов
• Набор практик
• S.T.A.T.I.K. – структурированный воркшоп для поэтапной визуализации текущего процесса
• Канбан-модель зрелости – модель, помогающая адаптировать ценности, практики и принципы для конкретной ситуации, чтобы запустить управляемую эволюцию сервиса

Сustomer recognizable work item

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

В итоге в процессе появляются задачки, с которыми на самом деле работают люди, а не куски декомпозированных элементов, которые сами по себе и ценности-то не несут.

Инструмент командообразования

Канбан-профессионалы не любят слово «команда». Они живут в сервисной парадигме – любая деятельность может быть представлена в виде сервисов, а команда — это лишь один из способов организации. Однако, работая с людьми, я заметил, что работа с доской визуализации – проведение Канбан-митингов, фокус на общей задаче, а не на своём кусочке, выработка правил – всё это помогает людям изменить свое поведение.

Люди начинают вести себя как нечто целое – как команда. Естественно, это происходит не сразу, команды штормит в начале пути, но, вырабатывая собственные правила работы, визуализируя их, Канбан-метод плавно нормализует производительность сервиса.

Система раннего предупреждения

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

Трехмерная модель приоритезации

Отдельного упоминания стоит момент, когда люди смогли понять красоту приоритезации, которую предлагает Канбан-метод – симбиоз трех составляющих, влияющих на приоритет задачи:

• Приоритет заказчика
• Классы обслуживания
• Фокус на завершении задач, в противовес начинанию новых

Совокупное восприятие этих трех измерений превращает Канбан-доску в систему приоритезации, где место карточки с задачей на доске определяет её приоритет для сервиса.



3D-приоритеты — не самая простая вещь в принятии, но и не самая сложная. Когда люди осознают, как это работает, у них возникает вау-эффект «а что, так можно было?». Самое сложное – перед этим осознать, что колонки у доски — это не этапы процесса, а этапы накопления знаний. И то, что если ты двигаешь задачу по доске назад – ты снижаешь её приоритет, а не возвращаешь на предыдущий этап.

Что дальше?

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

Таким образом, Канбан – это далеко не просто альтернативный путь в Agile, а мощнейший метод управления процессами, который зачастую недооценивают или оценивают неправильно.

Если при чтении вы обнаружили себя на каком-то из промежуточных этапов – не отказывайтесь от Канбана, дайте ему себя показать.