Представьте, что вы отвечаете за организацию цепочки поставок и продаж в продуктовом магазине. Давайте для определенности считать, что речь идет об вкусных йогуртах. У вас есть производитель, поставляющий определенный объем продукции, есть склад (ну очень бОООльшой) и обычная магазинная витрина, откуда покупатели разбирают упаковки к себе в сумки. Она имеет конечный размер и может разместить сравнительно небольшое число упаковок продуктов. Как бы вы договорились с поставщиком об объемах регулярных поставок?

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

Конечно можно попытаться компенсировать рост поставок, выкладывая в торговый зал больше упаковок (например на пол, соседнюю витрину). Однако поднимать таким образом продажи это тоже самое, как добавлять в принтер больше бумаги, в надежде на увеличение скорости печати. У системы есть свойственная ей скорость (потребления, печати и др. ), которую нельзя бесконечно стимулировать «впихивая невпихуемое». Этот подход называется проталкиванием (PUSH) когда в систему сначала «закачивают» элементы работы, а потом думают, что с этим делать.

Альтернативным вариантом является «вытягивающася» система, которая в 50е годы была подсмотрена начальником механического цеха компании Тойота Тайити Оно во время его поездки в США. По его воспоминаниям идея вытягивания (PULL) в магазине как раз в момент осмотра подобной витрины. Этот человек (к слову создатель Toyota Production System) обратил внимание, что система работает в обратную сторону: вначале покупатели разбирают продукты на полке, а уже потом сотрудники магазина пополняют со склада ровно столько, сколько было куплено за день и на основании этих данных делают заказ на склад. По его возвращении на родину этот принцип лег в основу работы с Канбан доской: вначале проверяются те элементы работы, которые расположены как можно ближе к концу процесса и только после освобождения соответствующего WIP лимита переходим к предшествующим этапам (прямо как в игре в «пятнашки»). Другими словами перед тем как начать делать что-нибудь нужное, сначала завершить то, что вам казалось нужным нужным до этого.

Принцип вытягивания нашел свое отражение не только в Канбан. Его следы также видны и в SCRUM. Так в Планировании Спринта Команда разработки сама прогнозирует задачи, которые могут быть сделаны в предстоящем спринте (вытягивание), а не автоматически получает их от Владельца продукт согласно заранее предопределенному «нормативу» или текущей необходимости (проталкивание).

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

Работа в канбан должна быть построена по принципу PULL (вытягивай), а не по принципу PUSH (вталкивай). Это значит, что каждый раз, как у нас освобождается место в системе мы начинаем задумываться, а что мы втянем из предыдущего этапа.

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

Для этого нам поможет прием Конкурс красоты. Давайте рассмотрим на примерах из жизни, как это работает.

Первый пример — Очередь на регистрацию в Аэропорту.

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

Элементы работы (WIT Working ITem) в данном случае, это сами туристы. Первоначально они для нас все одинаковые, т. е. у нас один класс-обслуживания. Здесь стоит заметить, что есть разделение виды билетов Бизнес и Эконом, но так как они не конкурируют друг с другом мы можем допустить, что это разные канбан системы (потоки создания ценности).

Еще у нас есть кто-то, кто управляет системой (желтый человечек), он может менять классы обслуживания у каких-то элементов работы на основе легкодоступной информации.

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

Теперь, нам нужно разделить очередь на два класса обслуживания: обычные пассажиры и пассажиры у которых заканчивается регистрация на рейс. Что делает наш желтый человечек? О начинает спрашивать: «Есть ли кто-то, кто летит, например, в Санкт-Петербург?» (это внешняя легкодоступная информация и является внешним признаком). Туристы, кто идентифицировал себя подходящими данному критерию поднимают руку и проходят без очереди. Желтый человечек при этом убеждается, что туристы действительно летят нужным рейсом.

Второй пример, это ресторан

У нас опять есть желтый человечек на входе, который определяет, кого следующим втянуть с систему. На основании чего он может принимать, кого впустить в ресторан следующим? Вполне логично, чтобы максимум столов и стульев было занято (т. е. максимальная утилизация места в ресторане). Столы бывают следующих типов: на двух человек и четырех.

У нас опять же есть очередь с людьми, те кто пришел один, парами или семьей/компанией (для наглядности выделены разными цветами).

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

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

А теперь, давайте посмотрим, как это может выглядеть на канбан-доске

Между какими-то этапами есть колонки «очередь» и «в работе». У нас есть явные различия между ожидающими выполнения задачи (кружки, треугольник и квадрат). В представленном примере у нас свободен слот для синего квадрата, то его-то мы и втянем следующим, вне зависимости, что кружки и треугольник по времени пришли раньше.

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