Что такое Kanban? Часть 2

Алексей Пименов, управляющий партнер ScrumTrek:

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

Но с точки зрения реального физического мира это правильное действие. Почему? Представим себе принтер. У принтера есть определенная производительность, и, если мы в принтер попытаемся натолкать побольше бумаги, принтер просто заклинит. То же самое происходит и с сотрудниками. У них есть реальная их натуральная производительность. Да, она может как-то меняться, если человек рефлексирует определенно над своей деятельностью. Но пока оставим это за скобками. И если мы в него будем наталкивать больше бумаги, то нам придется часто останавливаться, чтобы убирать замятие. То есть Kanban – это про что больше? Kanban на таком низшем уровне – это про то, что надо аккуратно наладить вынимание этих листов из принтера, нежели заталкивание туда большой стопки бумаги.

Николай Борисов, руководитель направления Дирекции по процессам Альфа-Банк:

- То есть выстроить этот процесс работы от начала до конца, такой поток задач, чтобы он шел регулярно?

- Взять, точнее, в начале то, что есть, визуализировать это на стене, допустим, или в каком-то кейс-средстве.

- Те самые Kanban-доски, да?

- Да. И наладить вытягивающую модель, чтобы задачи вытягивались.

- Что это физически означает – наладить вытягивающую модель? Если мы на стену что-то повесили, визуализировали там работу какой-то команды, как работает втягивающая модель? Что физически происходит?

- В какой-то момент времени на нашей доске должен возникать определенный сигнал о том, что какая-то задача может быть перенесена по статусам слева доски направо. Это pull-сигнал называется – сигнал, когда мы можем что-то тянуть. А когда мы можем что-то тянуть? Когда мы что-то закончили. То есть я как специалист…

- Одну задачу сделали, да?

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

- То есть, фактически, если я правильно вас слышу, введение эти ограничений означает, что отказываем менеджеру, то есть это постановка менеджера в очередь, получается, некоторая?

- Да.

- Которая, в принципе, для менеджера несколько непривычна в его текущей деятельности. И что происходит в этот момент с компанией? Что происходит в этот момент с командой?

- На самом деле, для начала еще надо с этим менеджером поговорить на тему, которая называется «взятие обязательств», то есть бывают иногда разночтения, которые в принципе визуальная доска должна устранить. Разночтения какого плана? Допустим, ты руководитель, я подчиненный. Ты ко мне прибежал с какой-то пачкой заданий. Ты меня спросил: «Алексей, сколько это времени займет?» Я сказал: «Каждое по два дня». В это время у тебя начинают тикать часы. То есть ты через два дня ко мне придешь и предъявишь мне вопрос: «Когда? Где готовое?».

- «Давай готовую задачу».

- С точки зрения меня, я могу их все начать одновременно, но мозг человека устроен таким образом, что я не могу всем одновременно заниматься. Там либо будут задачи такие, по которым активно надо что-то сделать и долго подождать, либо задачи, над которыми надо работать постоянно. Но, в любом случае, даже если над всеми стартовала работа, то в какой-то момент я занимаюсь одной задачей, а остальные стоят. Я могу этот процесс сдвинуть несколько левее по моей визуальной Kanban-доске и сказать так, что те задачи, которые ты принес, ложатся в некоторую очередь, откуда я буду брать. И по-хорошему вот эти двухдневные часы начинают тикать, когда я за задачу взялся.

Смотри, есть точка принятия решения, точка принятия обязательств на себя. Нам надо с тобой договориться о том, что для нас является точкой принятия обязательств. После этого мы начинаем уже определенным образом вести работу. То есть если у меня или у моего подразделения, или у моего отдела, есть какая-то емкость, то есть сколько в один момент времени мы можем обрабатывать задач или проектов, то эта система становится для меня более или менее предсказуемой, я ей могу управлять. Если я ей могу управлять, я могу давать тебе обоснованные, можно так сказать, обязательства по выполнению этих задач. Я могу сделать для тебя процесс более предсказуемым, то есть на все, что ты мне приносишь, я могу тебе сказать: «Давай классифицируем это по каким-то вещам». И в зависимости от того, как мы классифицировали, это будет сделано для тебя, допустим за 5 дней, за 6 дней, за 2 дня. То есть сделать так для тебя процесс прозрачным.

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

- Да. На первом этапе это именно так, то есть сделать процесс предсказуемым для заказчика.

- Что дальше?

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

- Оставляем человека без работы в какой-то момент, ограничивая количество задач, и он вынужден помогать другому?

- Да. Он не вынужден помогать другому – он может помогать другому, а может простаивать. Вопрос заключается в чем: что они начнут делать? Как мы это будем все дело наблюдать? Ведь в простоях нет ничего плохого. Как нас учил Элияху Голдратт, у нас в такой цепочке создания ценности скорость этой всей цепочки диктуется одним узким звеном. Остальные могут в принципе работать не настолько загружено. Следовательно, мы можем определенным образом, зажимая или разжимая эти лимиты, делать вызов нашей команде. Если лимит мы очень сильно расширили, то у нас может возникать в системе очень много заблокированных задач. Психология работы сотрудника: «Я натолкнулся на препятствие, что я должен сделать?» Допустим, у меня не хватает каких-то данных. Я могу запросить…

- Позвонить коллегам.

- Могу их запросить по почте, а могу ногами сходить договориться. Здесь все зависит от некоторой такой осознанности сотрудника, от его желания справляться с проблемами. Это типичная эджайловая вещь, то есть насколько человек готов. Если люди не готовы, то мы таких, допустим, в Scrum скорее всего в команду не возьмем. Они этот Scrum-вызов не вытерпят. Kanban говорит: «Окей, у нас с ними не получается так работать. Давайте вернем WIP-лимиты в то состояние, в котором они были до нашего этого эксперимента». То есть Kanban – это про большое количество микроэкспериментов, которое позволяет у нас внутри какой-то маленькой системы попытаться работать с людьми, попытаться найти некоторый максимум их производительности.

- Можешь ли ты назвать какие-то основные проблемы, ошибки, с которыми люди встречаются при применении, использовании Kanban?

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

Так вот, люди чаще всего останавливаются на втором шаге. Им почему-то очень страшно вводить эти WIP-лимиты. То есть если Scrum нам изначально говорит: «Давайте мы переколбасим всю работу в нашей организации», то Kanban говорит: «Начните с того, что есть сейчас». Все говорят: «Окей, здорово, мы будем внедрять Kanban, потому что мы должны начать с того, что есть сейчас». Они начинают с того, что есть сейчас, делают визуализацию, а дальше попадают на первый самый вызов – ввести ограничения. И тут им становится грустно, скучно, и они не продолжают.

Но еще есть такая штука: бывает так, что визуализация в одном месте дает определенный профит и сокращение Time to Market. В моем опыте было сокращение Time to Market только за счет визуализации порядка 30%. Просто увидели реально, где затык. Людей, которые ответственны за этот затык, можно так сказать, стали к этой доске водить и показывать: «Коллеги, вот у нас поток стоит из-за вас». Затык разобрался, поток стал нормальным, Time to Market сократился на 30%. Как говорится, у больного голова прошла. Дальше он развиваться не захотел, хотя потенциал в принципе есть.

- То есть основная ошибка: есть набор принципов, люди их не доделывают до конца, не вводят то самое ограничение Work In Progress, на этом останавливаются.

- Да, это одна из самых первых типичных вещей.

- Алексей, смотри, ты говоришь, что мы визуализировали, начинаем каким-то образом работать с этой системой, вводим ограничения. Что заставляет людей и систему изменяться дальше? То есть как выстроен этот процесс улучшения дальнейшего внутри? Либо, если нет определенных каких-то правил, мы начинаем с того, что есть, как это все потом меняется?

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

- То есть юристы, налоговики, айтишники, HR какую-то функцию выполняют?

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

- Запутанной.

- Да. Это о том, как эти сервисы между собой взаимодействуют. И есть мероприятия, связанные с тем, как мы оцениваем риски – риски того, если что-то не будет сделано вовремя. То есть в Kanban под это предусмотрено отдельное мероприятие. Оно циклическое, оно оперирует реальными метриками и данными, которые мы собираем с нашего Kanban-процесса.

- То есть мы улучшаемся в рамках одной задачи, мы улучшаемся в рамках какого-то количества классов сервисов или выполняемых задач, мы, соответственно, еще работаем с рисками отдельно?

- Нет, мы улучшаемся в рамках одной системы, улучшаемся в рамках набора систем и анализируем… Вот эта идеология Fitness For Purpose – мы анализируем, насколько мы как система внутри организации попадаем в это свое предназначение.

При использовании материала гиперссылка на соответствующую страницу портала HR-tv.ru обязательна