Большинство команд, которые внедрили канбан, на самом деле просто создали доску с колонками. Перетащили стикеры слева направо — и решили, что на этом все. Но канбан — это не формат доски, а метод управления потоком работы. Мы тут решили дотошно разобраться и рассказать, из чего он состоит на практике: инструменты, принципы, WIP-лимиты и метрики.
Начнем с истории — она уходит корнями в послевоенную Японию, на заводы Toyota.
Статью подготовила команда Кайтена (Kaiten).
История одной карточки: как Toyota изобрела канбан
1940–1950-е
К 1945 году Toyota была небольшим провинциальным автопроизводителем, едва успевшим встать на ноги до войны. Заводы были частично разрушены бомбардировками, банки отказывали в кредитах. За первый послевоенный год компания выпустила около 300 грузовиков — против тысяч у американских конкурентов.
Но в 1958 году Toyota выиграла тендер на поставку крупной партии автомобилей в Австралию и впервые вышла на международный рынок. Вместе с масштабом выросло и количество задач. Их стало так много, что отследить прогресс на каждом этапе было практически невозможно.
При этом у компании не было ни огромных бюджетов, ни гигантских складов, ни стабильного спроса. Работать по западной Push-системе было не по силам: при таком подходе продукт производится заранее, исходя из прогнозов, — и остается только надеяться, что его раскупят. Toyota нужна была другая логика.
Тогда один из главных инженеров, Тайити Оно (Taiichi Ohno), предложил ввести правило:
Производить только то, на что уже есть реальный запрос, и ровно в том объеме, который нужен.
Этот подход получил название Pull-системы. Никаких складских запасов впрок — только работа под конкретную потребность. Но как сделать этот спрос видимым и управляемым? Здесь на помощь пришли карточки. Они заменили устные договоренности и стали работать как сигнал для сотрудников: нет карточки — нет задачи.
Так выглядело первое внедрение канбана на заводе Тойота — в виде физической доски
В переводе на русский «канбан» буквально значит «видимая карточка»:
看 (Kan) — видимый, сигнал, знак
板 (Ban) — карточка, табличка, доска
К 1963 году метод работал уже на уровне всей компании. Карточки постоянно дорабатывались, и узкие места на производстве были видны сразу. А Тайити Оно — человек, придумавший всю эту систему — в 1975 году стал вице-президентом Toyota. К началу XXI века компания вошла в число мировых лидеров по автопроизводству.
2000-е
Несколько десятилетий канбан оставался сугубо производственным инструментом — о нем знали инженеры и менеджеры заводов, но не разработчики программного обеспечения. Все изменилось в начале 2000-х.
А именно в 2004 году, когда Дэвид Дж. Андерсон, тогда работавший разработчиком и менеджером в Microsoft, помогал команде в Хайдарабаде (Индия) выбраться из операционного хаоса — и решил попробовать применить производственную логику канбана на ИТ-процессах.
Андерсон не просто скопировал систему Toyota один в один — он взял из нее главное: идею управления потоком. Остальное адаптировал под реалии разработки программного обеспечения: другой ритм, другие задачи, другие люди.
Результат быстро себя показал. Скорость завершения задач в команде выросла более, чем в 3 раза, время выполнения упало на 90%, а показатель своевременной доставки поднялся с 0% до 98% — все это за 15 месяцев и с минимальными затратами.
Через несколько лет Андерсон поделился своим опытом внедрения канбана на одной из Agile-конференций. Доклад вызвал огромный интерес — тогда же канбан-метод перестал быть лишь внутренним экспериментом одной команды и начал распространяться по индустрии.
Со временем карточки переехали в цифру — появились Trello, Jira, Кайтен (Kaiten) и десятки других инструментов, которые воспроизвели логику метода онлайн и позволили ему выйти за пределы физической доски.
«Канбан — метод управления нематериальной работой. За простой визуализацией стоит полноценная система со своими принципами, практиками и ценностями. И чтобы она заработала, ее нужно правильно спроектировать и объединиться вокруг нее — наладить движение карточек и регулярно собирать встречи вокруг досок»,
— Юрий Юрков, delivery manager в Кайтен.
Принципы канбана: философия, на которой строится метод
Главное отличие канбана от других подходов — в его гибкости. Но за этой гибкостью есть конкретная четкая система. Вот принципы, на которых она держится:
Эволюционные изменения, а не революция. Радикальные реформы почти всегда приводят к сопротивлению команды. Канбан не требует перестраивать все разом. Изменения должны быть осознанными, согласованными и идти небольшими шагами — ввели изменение, посмотрели на результат, скорректировали. Так проще понять, что сработало, и безболезненно откатить то, что не прижилось.
Лидерство поощряется на всех уровнях. Каждый сотрудник должен иметь возможность влиять на процесс. Если он видит проблему, то не ждет очередного синка, а сразу предлагает решение. Такая инициатива приносит больше пользы, чем строгие регламенты.
Вся работа визуализирована. Даже простая структура колонок — «В очереди», «В работе», «На проверке», «Готово» — дает команде общий язык и делает поток задач читаемым с первого взгляда.
Доска отражает реальность. Этапы должны быть понятны, задачи — зафиксированы, статусы — обновляются по факту. Иначе метрики не будут работать, а проблемы останутся невидимыми.
Скрытое — тоже часть процесса. Все, что живет в голове или в личной переписке, создает задержки в потоке, которых никто не видит. Блокер, зависимость, ожидание ответа — все это должно быть на доске.
Все эти принципы работают в связке — помогают видеть точки улучшений и принимать решения на основе фактов и цифр, а не ощущений.
Когда канбан работает лучше всего
Сегодня более 58% компаний из списка Fortune 500 используют те или иные формы канбана в своей ежедневной работе — и это не только ИТ. Канбан применяют в операционных процессах, HR, финансах и сервисных командах — иными словами, везде, где есть поток задач и необходимость делать работу предсказуемой.
Чаще всего метод закрывает одни и те же боли:
Никто не понимает, что происходит. Задачи теряются, ответственные не определены, дедлайны срываются без объяснений. Канбан-доска делает процесс видимым — буквально.
Приоритеты меняются каждый день. В отличие от скрама канбан не привязан к спринтам, поэтому команды могут гибко перестраивать поток задач.
Процесс работает в команде, но ломается при росте. Канбан одинаково применим для личных дел, команд и крупных организаций, потому что он фокусируется на движении задач по процессу, а не на жесткой структуре проекта.
Если собрать все это в одном месте, картина выглядит так:
В Кайтене мы работаем с канбан-методом давно. За это время видели самые разные команды, форматы и сценарии использования. Поэтому примеры будем разбирать на том, что сами знаем изнутри.
Из чего состоит канбан-метод: основные инструменты визуализации
А теперь — посмотрим, из чего канбан состоит на уровне конкретных инструментов и как они работают вместе.
Канбан-доска
Это главный инструмент для визуализации процесса. Канбан-доска представляет собой таблицу из колонок и дорожек, по которым слева направо движутся карточки. Колонки обозначают этапы процесса — от момента появления задачи до ее завершения, а дорожки помогают разделить задачи по категориям.
Доска может быть физической — маркерная доска на стене с бумажными стикерами — или цифровой. В обоих случаях принцип одинаковый: вся работа отображается в одном месте и доступна каждому участнику в любой момент.
Структура доски настраивается под конкретный процесс и задачи отдела. Так руководителю и команде легче ориентироваться в потоке — сразу видно текущее положение дел.
2. Карточки
Каждая задача, запрос или идея оформляется как отдельная карточка и помещается в самый первый столбец слева — туда, где собираются все входящие задачи.
Дальше карточка движется по доске: исполнитель берет ее в работу и перемещает в следующую колонку после выполнения своего этапа. Так задача проходит через все этапы процесса, пока не окажется в финальном столбце.
В карточке фиксируют ответственного, сроки/дедлайн, критерии готовности, вложения/ссылки, блокировки и комментарии по ходу выполнения задачи.
Но карточка не всегда движется равномерно. Она может задержаться на каком-то этапе — например, если задача ждет согласования, не хватает ресурсов или возникла зависимость от другой команды.
На доске это легко отразить при помощи визуальных блокеров.
Такие карточки сразу бросаются в глаза: они стоят на месте, пока остальные продвигаются вперед. Это и есть сигнал, что где-то в процессе существует проблема, которую нужно решить.
3. Колонки
Это вертикальные полосы на доске. Колонки соответствуют этапам работы (например: Очередь → В работе → На проверке → Готово).
Как только задача попадает в колонку «В работе», она считается начатой. Это точка принятия обязательств: исполнитель берет задачу и отвечает за то, чтобы довести ее до результата.
Дальше карточка проходит этапы процесса и в конце приходит в «Готово». Это точка поставки. Именно на этом этапе результат можно передать дальше — клиенту или смежной команде.
Колонки можно добавлять и убирать, менять этапы по мере роста команды. Даже с минимальным количеством колонок процесс быстро становится управляемым.
4. Дорожки (Swimlanes)
Горизонтальные полосы, которые делят канбан-доску на несколько уровней. Если колонки показывают этапы работы, то дорожки разделяют задачи по признаку — например, по типу, приоритету или исполнителю.
Например, можно создать отдельную дорожку для срочных задач, для плановых и для багов. Или дорожки по продуктам, если команда ведет несколько проектов одновременно. Это позволяет не плодить отдельные доски под каждый тип задач, а держать все в одном месте — но при этом не смешивать разные потоки работы в одну кучу.
Дорожки особенно полезны, когда команда растет и задач становится больше: без них доска быстро превращается в неуправляемый список. С дорожками каждый участник видит только свой поток и не теряется в чужих задачах.
5. WIP-лимиты (Work In Progress Limit)
Чем больше задач одновременно в работе, тем дольше выполняется каждая из них. Звучит парадоксально, но именно к такому выводу пришел профессор MIT Джон Литтл. На самом деле, перегруз не ускоряет процесс — он его замедляет. Когда команда распыляется на множество задач, фокус теряется, переключений становится больше, а сроки начинают «плыть».
Именно поэтому в канбане появился инструмент WIP-лимитов (Work In Progress Limit). WIP (Work in Progress) — это все, что находится в работе прямо сейчас, а WIP-лимит ограничивает количество таких задач, которое команда может взять одновременно.
Например, если для колонки «Тестирование» установлен лимит в 3 задачи, это значит, что новую работу туда можно взять только после того, как завершится одна из текущих.
Некоторые команды игнорируют WIP-лимиты и берут больше задач «на всякий случай». Однако ни к чему хорошему это обычно не приводит — со временем канбан-доска превращается в склад незавершенки.
Реальный пример из практики команды X5 Group:
У ребят была классическая «пробка»: куча задач висела в работе, и никто не понимал, когда они дойдут до финала. Анализ блокеров показал, что проблема была не в скорости выполнения, а в самом устройстве потока. Почти половина задержек возникала из-за перегрузки — задач было больше, чем команда могла одновременно взять, а значительная часть остального времени уходила на ожидание внешних действий. В сумме это приводило к сотням часов простоя и тому, что более 70% блокеров концентрировались именно на этапе исполнения.
Когда они ввели жесткие WIP-лимиты, команда перестала распыляться на новые задачи и сфокусировалась на завершении уже начатых. Поток выровнялся, зависания стали выявляться быстрее, а сроки выполнения — стабилизировались.
«Иногда возникают задачи, которые непредсказуемы по своей природе. Они требуют системного подхода, иначе издержки их реализации рискуют превысить создаваемую ценность. В этом случае важно выстраивать отдельную систему работы: сначала проверять, есть ли реальная проблема или возможность, затем оценивать варианты решения, и только потом переходить к реализации. Такая система работает с опциями и позволяет отказываться от задач до начала выполнения. При этом переходы между этапами должны быть четко определены»,
— Юрий Юрков, delivery manager в Кайтен.
Метрики Канбана
Как мы уже говорили выше, канбан — это путь непрерывных улучшений. Подход во многом опирается на философию кайдзен (kaizen). Это японская концепция, которая буквально переводится как «изменение к лучшему». Ее суть в том, что улучшения не обязательно должны быть радикальными: важнее делать маленькие шаги регулярно, чем раз в год проводить большую реорганизацию.
Но улучшать процессы только на ощущениях не получится — нужны объективные данные. Для этого в канбане используют метрики — измеримые показатели, которые отражают состояние рабочего процесса. К ним относятся:
Lead Time — время от момента появления задачи до ее завершения. Метрика показывает, насколько быстро работа проходит через весь процесс — от входа до выхода, — и отражает реальную скорость производства.
Cycle Time — длительность активной работы над задачей внутри процесса. Например, от начала разработки до готовности к тестированию. В отличие от Lead Time, эта метрика фокусируется не на всем пути задачи, а на конкретном участке — и именно поэтому помогает точнее находить узкие места и этапы, где задачи задерживаются.
Пропускная способность (Throughput) — количество задач, которые команда завершает за выбранный период, обычно за неделю или месяц. Метрика используется, чтобы понять фактическую скорость потока работы и прог��озировать сроки.
Без метрик канбан превращается в красивую визуализацию — но не дает понимания, что происходит на самом деле. Метрики переводят поток работы в цифры и позволяют принимать управленческие решения на основе реальных данных, а не ощущений.
Представьте типичную ситуацию: команда видит, что задачи идут по этапам, но сроки все равно срываются. Lead Time покажет общую картину — сколько времени в среднем проходит от появления задачи до ее завершения. Если цифра большая, Cycle Time объяснит почему: окажется, что 80% времени задача проводит не в активной работе, а в ожидании — ревью, согласования, ответа от руководителя. Это и есть узкое место, которое нужно устранять, а не ускорять разработку. Throughput, в свою очередь, добавляет предсказуемости: если команда стабильно закрывает 12–15 задач в неделю, можно обоснованно сказать, когда будет готов бэклог из 40 задач.
Канбан: за или против
Как и любой управленческий подход, канбан имеет свои ограничения. В таблице собрали то, с чем команды чаще всего сталкиваются на практике.
Почему канбан-метод иногда не работает
Канбан не требует сложного онбординга, дорогих инструментов или перестройки всей структуры. Именно поэтому метод внедряют часто — и именно поэтому нередко делают это поверхностно. Создают доску, заводят карточки, а дальше что-то идет не так. При этом проблемы почти всегда одни и те же:
не договорились о правилах перемещения между этапами;
WIP-лимиты поставили, но продолжают брать задачи «в обход»;
блокировки не зафиксировали, поэтому карточки долгое время висят без движения;
метрики не смотрят вовсе, игнорируют или не понимают;
часть работы остается в чатах и письмах.
В таких условиях доска — это, скорее, витрина задач, но никак не инструмент управления потоком.
«Иногда руководители спрашивают: как убедить команду обновлять доску в реальном времени? Но сам вопрос немного не в ту сторону. Убеждать не нужно — нужно выстраивать среду, в которой обновление доски становится естественной частью работы, а не дополнительной обязанностью. В такой системе сотрудники сами начинают видеть ценность: когда работа «выгружена» из головы в карточки, снижается когнитивная нагрузка и уровень стресса. А если система спроектирована правильно, она еще и ограничивает перегруз — не дает брать больше, чем можно реально выполнить. В итоге это выгодно и исполнителю, и бизнесу»,
— Юрий Юрков, delivery manager в Кайтен.
А как у вас?
Вы уже используете канбан-метод в своей работе? Какие изменения после внедрения оказались самыми заметными?
