ЛК
Меню

Паттерны зрелости Канбана

Перевод статьи Дэвида Андерсона, опубликованной на djaa.com.
Оригинал можно прочитать здесь.

Это 2-я часть моей серии статей, посвященной Канбану, организационной зрелости и эволюционным изменениям. Ознакомьтесь с частью 1: Организационная зрелость и эффект J-кривой для понимания контекста.

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

Вступление

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

Персональный канбан


Рисунок 1. Персональный Канбан

Персональная Канбан-доска служит для отдельного человека. Использование столбца «Next» необходимо для избавления человека от чрезмерной нагрузки, связанной с размером бэклога, который может быть очень большим. Число в верхней части столбца — это WIP-лимит. Когда человек что-то завершает, он берёт работу из столбца Next. Затем он может пополнить столбец «Next», вытянув элемент из бэклога. Дисциплина пополнения может осуществляться по требованию или с определённой частотой. Вероятно, что большой бэклог может потребовать некоторое время для выбора того, что будет следующим, и, следовательно, каденция более вероятна при большом бэклоге. Если объём бэклога небольшой, то пополнение столбца «Next» по запросу вероятно тогда, когда элемент переведён в статус In-progress.

Персональный Канбан обычно ориентирован на задачу, а тикеты имеют особое значение для человека. Владелец доски обычно является и владельцем, и поставщиком сервисов, хотя существуют некоторые варианты, такие как доска в стиле Honeydue. Это список дел, который супруги могут составлять друг для друга, обычно список включает в себя рутинные или неприятные задачи по дому (прикрутить полку, вымыть посуду и т. д.), или задачи по вызову сантехника или электрика, которые приходится делать через силу.

Агрегированный Персональный Канбан

Персональный Канбан зародился в офисе примерно в 2008 году и вошёл в домашний обиход. Однако, это типично, что люди применяют его дома, а затем приносят идею в свой офис, как это произошло с Марицой Ван Ден Хевел в Южной Африке. Данный факт случайно принес ей прозвище «мать Канбана в Южной Африке». Если Персональный Канбан становится популярным в офисе, то приходит понимание, что общая доска имеет ценность — каждый в команде или отделе может видеть, что делают другие. Имеется документальное подтверждение этого кейса от Роба Фергюсона, ранее работавшего в Banfield Pet Hospital, компании Mars. Роб выиграл национальную премию за обеспечение качества, за улучшения, которые внесла в их работу агрегированная персональная Канбан-доска. Он отвечал за повышение осведомлённости об этой технике как о ценном шаге вперёд и за её последующее включение в учебную программу по Lean Канбан в качестве формы прото-канбана.


Рисунок 2. Агрегированный Персональный Канбан

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

Командный Канбан

Командный Канбан — это просто Персональный Канбан для маленьких групп: обычно от 2 до 4 человек, редко более 6. Часто он сосредоточен на задаче, но может существовать форма для представления запросов клиентов на доске. Он движется к принципу Канбан Метода — «управление работой позволяет людям самоорганизовываться вокруг неё», и вполне возможно, что команда представляет собой единый сервис, и такая простая доска ориентирована на сервисы. Если заказчик по запросу получает поставку напрямую от этой команды, мы будем рассматривать его как сервис-ориентированный дизайн и простую, но полную Канбан-систему. Чаще всего команда фактически является частью более крупного рабочего процесса, и / или элементы на доске не являются рабочими элементами, ценными для клиентов, а являются локальными задачами рабочего процесса. В этом случае Командный Канбан определённо является реализацией прото-канбана.


Рисунок 3. Командный Канбан

Командная Канбан-доска (Рис. 3) похожа на доску Персонального Канбана, но у каждого члена команды есть один или несколько аватаров, иллюстрирующих, какие рабочие задачи у них есть или над которыми они работают совместно. WIP-лимиты отображаются в верхней части столбцов и представляют собой лимит для всей команды. Наблюдается переход от управления отдельными лицами, к управлению работой как совместной деятельностью. Как и в случае с Персональным Канбаном, текущие элементы пополняются из стобца «Next». Пополнение столбца «Next» производится либо по требованию, либо в соответствии с каденцией, определённой для удобства команды.

Возникающие рабочие процессы

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


Рисунок 4. Доска зарождающихся рабочих процессов

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

WIP-лимит на человека

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


Рисунок 5. WIP-лимит на человека, Неограниченный рабочий процесс

На рисунке 5 незавершённая работа системы не ограничена, и в результате время выполнения заказа будет непредсказуемым. Подобная система может улучшить качество, избавить людей от чрезмерной нагрузки, но система может и дальше оставаться перегруженной. Как следствие, не удаётся обеспечить более быструю доставку и большую предсказуемость. Подобная система может быть реализована как система выталкивания. Эта система считается прото-канбан-системой, потому что есть реальные свидетельства её превращения в полноценную Канбан-систему, такую как Posit Science в Сан-Франциско — тематическое исследование, которое мы используем в нашем обучении специалистов по Канбан-менеджменту (KMPII).

Развязанные каденции & Постоянный WIP

Грант Аммонс недавно выявил этот паттерн, опубликовав несколько спорный пост «Отказ от Скрама в пользу Канбана — лучшее решение, которое мы приняли как команда». Рисунок 6 показывает интерпретацию Командного Канбана с развязанными каденциями и WIP-лимитами, охватывающим столбцы «Committed «и «In-Progress». Это слабо похоже на Скрам-доску, но без спринтов. Использование одного WIP лимита на несколько колонок известно как CONWIP («постоянный WIP»). CONWIP — это форма вытягивающей системы. Такой дизайн был кратко освещён в моей книге по Канбан в 2010 году. Таким образом, с CONWIP у нас есть система вытягивания, и это граничит с тем, будем ли мы считать её полноценной системой вытягивания или мы всё равно будем рассматривать её как прото-канбан. Я считаю, что решение зависит от двух других факторов: 1) это реализация на уровне команды? В основном это Канбан-команды с CONWIP; 2) или CONWIP — это зарождающийся рабочий поток? Если это один из этих вариантов, то полагаю, что это слишком просто для прото-канбана. Если бы CONWIP охватывал определённый рабочий поток по поставке сервисов, мы бы рассматривали его как полноценную систему вытягивания. Чтобы это произошло, рисунок 6 должен был бы больше походить на рисунок 10, но с одним CONWIP, охватывающим столбцы рабочего потока.


Рисунок 6. CONWIP для Командного Канбана

Агрегированный Командный Канбан

В течение многих лет мы думали о досках с Рисунка 7, как о вырожденных интерпретациях реальных Канбан-систем и назвали их в честь их неограниченных буферов «Выполнено» (Done). Эти неограниченные состояния делят систему и подсвечивают, что это не Канбан-система, и работа в системе не ограничена. Система не защищена от перегрузки. Это происходило в организациях, где понимали ориентацию на сервис и могли моделировать определённые рабочие потоки поставки сервиса, но не были достаточно зрелыми, чтобы справиться с использованием WIP-лимитов и вытягивающей системы в качестве фактора стресса для ускорения улучшений. Это стало распространённой формой прото-канбана даже среди организаций, прошедших базовый курс обучения по проектированию Канбан-систем (KMPI) в Lean Kanban University.

Осенью 2013 года мы с Майком Берроузом осознали: то, что на самом деле эти доски представляли из себя агрегированные, но разделённые командные Канбаны. Это стало частью нашего прозрения о свободного от масштаба подхода к масштабированию Канбан, что цель всегда состоит в устранении неограниченных буферов или очередей. Устраняя неограниченные буферы «Выполнено» на рисунке 7, вы масштабируете Командный Канбан до Канбана сервиса поставки. Это значительный шаг вперёд, так как он вызывает вытягивание со стороны клиента и изменяет фактор стресса для организации, поскольку первичная петля обратной связи переходит на собрание по пополнению. Эти концепции будут раскрыты в четвёртой статье этой серии.


Рисунок 7. Доска Агрегированного Командного Канбана

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

Прото-Канбан

Термин «Прото-канбан» был введён академическим инженером-программистом Ричардом Тёрнером из Института Стивенса. Ранее мы использовали термин «поверхностный канбан»(shallow Kanban) для частичных реализаций, но Ричард отметил, что эти поверхностные реализации часто вызревали и эволюционировали в нечто более глубокое, и появлялись системы полного вытягивания. Таким образом, «прото» относится к эволюционному предшественнику, где есть намерение продолжать использовать Канбан-системы и эволюционные изменения. Случайная доска на стене с несколькими стикерами на ней, визуализирующая какую-то работу или рабочий поток, не будет считаться прото-канбаном, если только нет намерения использовать визуализацию в качестве стрессора в преднамеренном стремлении к эволюционным изменениям. Без намерения — это просто доска на стене, визуализирующая что-то.

Полные Канбан-системы

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

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

Канбан-системы моделируются для рабочих процессов сервисов поставки В конструкции системы сервисная-ориентация есть по умолчанию. Рабочие элементы в системе имеют типы, запрошенные клиентами. Ориентация на клиента и на работу, значимую для клиента. Система соответствует принципу Канбан Метода: «управляйте работой, позвольте работникам самоорганизовываться вокруг неё».

Канбан в виде физических слотов

На рисунке 8 показан стиль Канбан-доски, который стал очень популярным в Бразилии, за который выступал Алиссон Вейл — один из первых последователей Канбана, лидер сообщества и лауреат премии Brickell Key Award за его достижения и вклад. Алиссон искал решение, которое помогло бы ускорить использование WIP-лимитов и обеспечить их принятие. Он искал что-то, что работало бы в условиях низкой дисциплины. Обратная сторона медали заключается в том, что этот стиль доски, как известно, тормозит инновации и эволюционные изменения. В физическом представлении доски слишком много инерции, и внесение изменений влечёт за собой слишком большие накладные расходы. Позже Алиссон признался, что сожалеет об этой инертности. Поэтому выбирайте этот стиль доски с осторожностью.


Рисунок 8. Канбан-доска, использующая физический слот для канбан-сигналов.

На доске с рисунка 8, пустой слот представляет собой Канбан-сигнал для вытягивания. Количество слотов представляет собой общий WIP-лимит для данного состояния или действия. Тикет I — это некая форма срочного запроса, которому разрешено отменять WIP-лимит. Маленький красный тикет, прикреплённый к A, означает, что A заблокирован, чтобы I мог работать. Тот, кто работал над A, будет обслуживать I. I ломает WIP-лимит. Временное превышение WIP-лимита разрешено до тех пор, пока вы знаете причины. Такой стиль доски не подходит для такого превышения. Это может быть хорошо, поскольку препятствует нарушению WIP-лимитов, но также может препятствовать тактическому использованию классов обслуживания, и это может создать сопротивление их принятию в неопределённых или сильно изменчивых средах.

Канбан-доска с подвижным токеном

На рисунке 9, Канбан — это физический токен, например магнит или скрепка. Этот стиль доски стал популярным в Европе, и впервые был замечен в таких местах, как ASR, голландская страховая компания, которую возглавляли Олав Маассен и Яспер Зонневельт. Очень хороший пример показан в тематическом исследовании Тупало. Здесь токены, такие как магниты, представляют собой WIP-лимиты. Можно делать интересные вещи, например использовать цвет для обозначения дополнительной информации, например, «вытягивается» или «заблокирован». Такой дизайн доски более гибкий и хорошо поддаётся инновациям, мутациям и эволюционным изменениям. Однако для этого требуется немного больше дисциплины и зрелости. Добавить новые токены несложно. Иногда нам это нужно, так как мы хотим временно нарушить WIP-лимит. Мы должны оставаться дисциплинированными, чтобы гарантировать, что это не станет постоянной практикой, а незавершённая работа не будет постепенно расти с течением времени.


Рисунок 9. Канбан-доска с подвижными токенами

Виртуальные Канбан-системы

На рисунке 10 показана доска, типичная для того типа, который использовался в Corbis в Сиэтле в 2007 году. Она служила вдохновением для создания Канбан Метода и стала основным стилем доски на Канбан-тренингах. Ещё с 2006 года я описывал такие системы как «виртуальные Канбан-системы», потому что в них нет физического сигнального токена. Сигнал вытягивания генерируется путём вычитания WIP-лимита, отображаемого в верхней части столбца, из количества рабочих элементов в этом столбце. Доска такого типа требует высочайшего уровня дисциплины для соблюдения WIP-лимитов и правильного использования вытягивающей системы. Кроме того, он наиболее гибок для изменения.


Рисунок 10. Виртуальная Канбан-доска

Добавление классов обслуживания

Любую из досок на рисунках 8, 9 и 10 мы можем начать приукрашивать дополнительными возможностями. Только в целях иллюстрации рисунки с 11 по 13 основаны на виртуальных Канбан-досках, подобно рисунку 10.

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


Рисунок 11. Виртуальная Канбан-доска с классами обслуживания

На рисунке 11 показана доска, на которой тикеты рабочих элементов окрашены в соответствии с классом обслуживания, который они получают. Кроме того, элементы любого заданного класса обслуживания контролируются WIP-лимитом. Это означает, что теперь Канбан-сигналы имеют два измерения. «Входная очередь» на рисунке демонстрирует, что есть Канбан-сигналы для 4 элементов, один из которых должен быть оранжевым тикетом — по умолчанию это тикет с фиксированной датой поставки — а остальные три должны быть фиолетовыми тикетами — по умолчанию это нематериальный класс обслуживания, поскольку они имеют краткосрочные и среднесрочные стоимости задержки, которые не являются материальными или незначительными. Часто можно увидеть доску, где только самый низкий и самый высокий классы обслуживания имеют WIP-лимиты. Это «стратегия штанги», т. е. стратегия хеджирования рисков, при которой риск срочных элементов компенсируется ёмкостью, выделенной для несрочных элементов. В таких случаях другие классы обслуживания могут свободно занимать оставшуюся ёмкость независимо от конкретного типа.

Агрегированные сервисы

На рисунке 12 одна система рабочего потока и одна группа людей, работающих вместе, выполняют работу нескольких типов. Это можно рассматривать как предложение нескольких сервисов от одного поставщика. Каждый тип работы и, следовательно, каждый предлагаемый сервис моделируется с использованием разных строк на доске. В просторечии Agile-сообщества их часто называют свимлайнами («дорожками для плавания»). Также принято выделять пропускную способность для дорожки. Это ограничивает максимальную скорость поставки любого заданного типа и гарантирует, что все поддерживаемые типы получат обслуживание. Создавая WIP-лимиты для строк, мы также вводим двумерную Канбан-систему, в которой сигнал к вытягиванию может быть для элемента определённого типа. Если классы обслуживания также развёрнуты, то механизм вытягивающего сигнала может быть трёхмерным.


Рисунок 12. Виртуальная Канбан-доска с агрегированными сервисами

В этом примере показано, что общая незавершённая работа по столбцам равна пропускной способности Канбан-системы, как показано WIP-лимитами по столбцам. Однако, это может быть желательным дизайном, но не обязательным. Это возможно и часто необходимо, чтобы сумма WIP-лимитов для строк была больше, чем ёмкость всей системы. На рисунке 12 показаны карточки нескольких цветов, поэтому мы можем предположить, что классы обслуживания также развёрнуты, но не объясняются на этом рисунке.

Повышение ликвидности резерва рабочей силы

На рисунке 13 показана доска, которая иллюстрирует технику, появившуюся в компаниях Constant Contact и Ultimate Software примерно в 2010 году. За счёт объединения команд в более крупные отделы и обслуживания нескольких типов работы в единой системе, появилась возможность иметь небольшие выделенные группы для отдельных строк (или свимлайнов) на доске, сохраняя при этом около половины доступной рабочей силы в качестве гибких работников, которых можно было бы применить к любому сервису по мере необходимости. Это обеспечивало гибкость в реагировании на приливы и отливы спроса от одного типа рабочего элемента к другому.


Рисунок 13. Выделенные команды для каждой службы с гибким расширением штата

Как показано на рисунке 13, каждая строка предоставляет сервис для определённого типа рабочего элемента. В каждом сервисе есть специальная команда из 2 человек. В каждой команде есть старший участник — мастер, у которого есть ученик. Как правило, ученики будут сменяться каждые несколько месяцев. После прохождения срока работы над каждой строкой на доске под наблюдением руководителя группы, они могут быть переведены в гибкий пул работников. Гибким работникам предоставляется аватар. Аватар можно переместить в любое место на доске, чтобы увеличить доступную рабочую силу для этого сервиса по мере необходимости. Этот паттерн обеспечивает большую общую ликвидность системы, чем это было бы для отдельных частей, если бы у каждого была своя Канбан-доска и своя команда. Говорят, что гибкие работники являются универсалами или «T-образными» людьми, потому что они обладают глубокими знаниями по крайней мере в одной области и навыками во всех необходимых областях объединённого сервиса. На рисунке 13 не показаны классы обслуживания, но вполне возможно использовать все 3 стратегии с рисунков с 11 по 13 вместе.

Выводы

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