Вы думаете, что Канбан – это просто доска с карточками? Ошибаетесь!

Сегодня мы работаем головой больше, чем руками. Современный бизнес – это управление задачами, информацией, креативными процессами. Но вот беда: старые методы управления, пришедшие из заводов и фабрик, в мире интеллектуального труда часто не работают.

И тут на сцену выходит Канбан Метод – инструмент, который помогает навести порядок в работе, улучшить процессы и сделать их прозрачными. Не путайте его с обычной доской задач – Канбан Метод гораздо глубже. Это не жёсткая методология и не пошаговая инструкция, а гибкий подход к организации труда, который адаптируется под ваши задачи.

Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 10 лет помогает компаниям разного уровня с построением адаптивных процессов. Организатор, продюсер, постоянный спикер и кейноут крупнейших профессиональных конференций FlowDays, Kanban Eurasia, AgileDays, TeamLead Conf, Merge, IT Nights, SECON, SECR, CodeFest, Стачка и пр. Специально для комьюнити Skillbox Code Experts рассказал про мифы о Канбан Метода. Публикую статью по мотивам этого эфира.

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

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

Хотите узнать, какие мифы окружают Канбан Метод и почему многие его неправильно понимают? Давайте разберёмся.

Миф №1: Канбан – это просто доска и стикеры

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

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

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

1. Понять текущее время выполнения – без данных нельзя сказать, насколько быстро или медленно работает система.

2. Разобрать процесс на части – сколько времени запрос реально обрабатывается, а сколько просто ждёт своей очереди? Какие этапы есть? Кто за что отвечает?

3. Снять данные – информация обычно хранится в учётных системах: таск-трекерах, CRM, внутренних базах. Их нужно проанализировать.

4. Определить точки для улучшения – где именно возникают задержки? Какие изменения могут ускорить процесс?

И вот тут на сцену выходят визуальные инструменты. Они помогают сделать процесс наглядным: где работа идёт, а где простаивает. Это может быть Канбан-доска, цифровая система или просто схема на бумаге.

Но главное – не доски и схемы, а анализ и осмысленное управление процессами. Канбан Метод – это способ выявить проблемы, найти решения и внедрить их так, чтобы процесс работал лучше. Доски – это лишь инструмент. Настоящий Канбан – в мышлении и подходе.

Миф №2: Канбан Метод пришёл из Toyota и бережливого производства

Готовы заглянуть в портал в ад? Если вы считаете, что современный Канбан Метод – это продолжение подходов Toyota, то пришло время разрушить этот миф. IT-шный Канбан, который используют разработчики, маркетологи и менеджеры, не имеет ничего общего с Канбаном из Toyota Production System. Совпадает только название.

Всё просто: современный Канбан Метод родился в XXI веке в Microsoft и развивался как способ управления интеллектуальными процессами. Канбан-доски, стикеры, WIP-лимиты – всё это придумано для работы с нематериальным трудом. В оригинальной системе Toyota таких инструментов не существовало.

Да, в Toyota была система карточек – хейдзунка, но она использовалась только в управлении запасами, а не в управлении процессами. В производственной системе Toyota не было ни визуальных досок, ни WIP-лимитов, ни того, что сегодня считается основой Канбан Метода.

В производстве управлять процессами просто: начальник цеха видит, как детали движутся по конвейеру, и может сразу заметить проблемы. В офисе – другая история. Откройте дверь в open space: там сидят люди за компьютерами, но что они делают, на каком этапе работа – непонятно. В этом и проблема: умственный труд невидим.

Чтобы его «материализовать», придумали:

• Стикеры – визуальное представление задач;

• Доски – способ показать, на каком этапе находится работа;

• WIP-лимиты – инструмент управления загрузкой команд.

Эти элементы – просто способ сделать интеллектуальный труд понятным и управляемым. Они не взяты из Toyota, а разработаны специально для управления знаниями, а не материальными объектами.

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

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

В IT управление работает иначе. Там сигнал к началу работы — не карточка, а свободное место в колонке. Вытягивающий процесс в интеллектуальном труде устроен по-другому, и пытаться «натянуть» принципы Toyota на современные офисные процессы – всё равно что управлять разработкой софта с помощью инструментов для сборки автомобилей.

Представьте, что я, как заказчик, должен прийти к админам, попросить сделать фичу. Админы должны поставить задачу тестировщикам, тестировщики — разработчикам, разработчики — системным аналитикам, те — бизнесовым аналитикам, бизнесовые аналитики — продактам. Звучит как бред!

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

В начале 2000-х одно из подразделений Microsoft столкнулась с проблемой слишком долгого цикла разработки – порядка 155 дней даже на мелкие изменения. Чтобы исправить процесс, Дэвид Андерсон и Драгош Димитриу нашли несколько интересных управленческих решения, позволивших сократить срок до 14 дней. Так появились первые идеи современного Канбан Метода.

В 2006 году Андерсон впервые рассказал о новом подходе на конференции. Сообщество заинтересовалось, и метод начал развиваться. Вначале его даже называли Lean-Kanban, но позже от слова «Lean» отказались совсем, чтобы не путать его с бережливым производством.

Со временем Канбан Метод наполнился инструментами анализа, управления процессами и гибкими подходами. Но от Toyota он унаследовал только одно – название.

Миф №3: Канбан Метод – это один из гибких (Agile) подходов

Когда говорят про Канбан Метод, его часто автоматически причисляют к Agile-подходам. Но это ошибка. Канбан — не Agile-методология, не один из фреймворков гибкой разработки, и даже не альтернатива Scrum.

Да, Канбан тоже используют в IT. Но это не делает его частью Agile. Agile, как термин, появился в 2001 году, когда был написан Agile-манифест с его четырьмя ценностями и 12 принципами. Если смотреть на Канбан через эту призму, то он вообще не зависит от Agile-принципов и не требует их для работы.

Канбан Метод может применяться:

• В гибких командах, которые хотят оптимизировать процесс и внедрить принципы Agile.

•  В компаниях, далёких от Agile, с бюрократией, жёсткой иерархией и сложными процессами.

• В организациях, где вообще никто не слышал про Scrum и Agile.

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

Дэвид Андерсон, создатель Канбан Метода, знаком с Agile-практиками и успешно использовал их в своей работе. В LinkedIn у него до сих пор никнейм @agilemanager.

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

Миф №4: Канбан Метод работает только для одинаковых задач

Канбан Метод изначально разрабатывался для среды, где каждая задача уникальна. В отличие от Канбана в бережливом производстве, оптимизированного для потоков однотипных задач, Канбан Метод позволяет работать с процессами, где разброс во времени выполнения задач огромный и предсказуемость сложна.

Допустим, в IT-компанию приходит консультант по бережливому производству. Он начинает анализировать процесс разработки, строит карту создания ценности, делает замеры всех этапов. Видит, что одна задача занимает 4 часа, другая – 2 недели. Разработчик объясняет это тем, что слишком разные задачи.

В Lean существует три «страшных» понятия:

1. Муда – потери (неэффективность).

2. Мура – вариативность, разный срок выполнения одной и той же операции.

3. Мури – перегрузка (чрезмерная нагрузка на ресурсы).

Консультант решит, что надо убрать вариативность – сделать задачи одинаковыми, стандартизировать процессы. Но в IT и других интеллектуальных сферах это невозможно! Ведь программисты, маркетологи и аналитики не «клепают» однотипные детали, их задачи уникальны по природе.

Канбан Метод не пытается устранить вариативность, а помогает научиться с ней работать, т.к. высокая вариативность — это суть умственного труда:

Канбан Метод использует статистическое прогнозирование. Время производства – это не конкретное число, а распределение плотности вероятности. Это позволяет строить прогнозы, учитывая, что задачи разные.

Миф №5: Канбан противоположен Scrum

Часто можно услышать: «Выбирайте – либо Scrum, либо Канбан». Но это неправильный подход. Эти инструменты не конкурируют, а решают разные задачи и могут прекрасно работать вместе.

Scrum – это организационный фреймворк. У него есть чётко заданные элементы: роли, артефакты, и чёткая цель – создание инновационного продукта в условиях неопределённости.

Канбан Метод – это способ улучшения процесса. Он не требует конкретных ролей, командной структуры или фиксированных итераций. Его цель – находить проблемные места в процессе, устранять их и повышать эффективность работы.

Сравнивать Scrum и Канбан – всё равно что сравнивать вилку и пылесос. Они служат разным целям и в принципе могут использоваться вместе.

Есть компании, которые начинали со Scrum, но со временем столкнулись с проблемами:

• Итерационный ритм начинает «ломаться» под внешними изменениями.

• Спринты наполняются разнородными задачами, тяжело формулировать цель.

• Процесс требует гибкости, а не строгой структуры.

Тогда на помощь пришёл Канбан Метод, позволяющий сохранить знакомую структуру, но гибко адаптировать её под реальную работу. И появился Scrumban – термин, введённый Кори Ладасом в 2008 году. Он означает использование Канбан Метода в зрелом Scrum-процессе. В 2015 году Аджай Рэдди даже написал книгу «Scrumban (R)evolution», развив эту идею. Он показал, как компании, использующие Scrum, могут использовать Канбан-инструменты, не ломая привычную систему, но делая её гибче.

Миф №6: Канбан – это для поддержки, а Scrum – для разработки

Есть распространённое мнение, что Канбан Метод – это инструмент исключительно для процессов поддержки, а для разработки лучше подходит Scrum. Это неправда.

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

Канбан Метод отлично работает в разработке, потому что:

Не требует итераций, но поддерживает их. Если команда использует итерационный процесс (Scrum, Safe, Less), Канбан Метод может дополнять его инструментами прогнозирования и улучшения процесса. Если итерации не нужны, например, в постоянной разработке или работе с техническим долгом, Канбан помогает выстроить непрерывный поток задач.

Включает мощные инструменты анализа. В отличие от Scrum, где процесс ограничен временными рамками спринта, Канбан Метод ориентирован на оптимизацию потока работы. Его метрики и прогнозы помогают повысить предсказуемость работы и выявить точки улучшения.

Гибок и масштабируем. Канбан можно адаптировать под любой процесс разработки – от стартапа до крупного IT-энтерпрайза. Он не накладывает ограничений на команды – можно использовать роли Scrum, элементы SAFe или любую другую систему.

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

Но вот разработка, R&D, продуктовая работа – идеальная среда для Канбан Метода. Ведь он создавался именно для сложных интеллектуальных процессов с высокой неопределённостью.

Миф №7: Канбан Метод предназначен только для организации работы команд

Часто Канбан Метод воспринимают как инструмент для оптимизации работы команд, что неверно. Он работает на более высоком уровне – в среднем управленческом слое, обеспечивая оптимизацию всей организации, а не только отдельных команд.

Канбан – это не про команды, а про систему. Канбан Метод работает на уровне всей компании, проходя сквозь департаменты и процессы. Анализирует и оптимизирует движение клиентской ценности через всю организацию. Позволяет управлять не только командами, но и стратегическими инициативами.

В Scale Agile Framework (SAFe), например, упоминается, что команды могут использовать Scrum или Канбан, но это упрощение. Оно создаёт ложное представление, что Канбан – это лишь способ организации командной работы.

На уровне всей компании Канбан:

Оптимизирует поток работы через всю организацию. В компании множество команд, отделов, сервисов. Клиентский запрос проходит через сложную систему – Канбан Метод помогает понять, где есть узкие места и оптимизировать поток работы.

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

Позволяет покрыть всю компанию. В Канбане есть инструмент Enterprise Services Planning (ESP) – он помогает описать весь процесс работы компании с точки зрения потока клиентской ценности. ESP даёт возможность внедрить циклы обратной связи, обеспечивая постоянное улучшение процессов на всех уровнях.

Миф №8: В Канбане нельзя двигать стикеры назад

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

Что плохого в перемещении стикеров назад:

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

Проблема 2: Потеря приоритетов. Когда стикеры двигаются назад, нарушается очерёдность работы. Представьте, что каждая задача в Канбане – это инвестиция. Чем дальше задача в процессе, тем больше ресурсов на неё потрачено. Возвращая задачу назад, вы конкурируете с новыми задачами, и решение о том, что делать в первую очередь, становится сложнее.

Проблема 3: Разрыв командной работы. Если разработчики работают только с колонкой «Разработка», тестировщики – с «Тестирование», аналитики – с «Анализ», то возврат задач назад усиливает разрыв между этапами. Это мешает командному взаимодействию и вызывает «эффект человека-колонки»: каждый отвечает только за свой этап, но не за весь процесс.

Чтоб не двигать задачи назад:

Используйте блокеры вместо возврата карточек. Если тестировщик нашёл дефект, он не двигает задачу назад в «Разработку», а создаёт блокер. Разработчик видит этот блокер и исправляет проблему в текущем статусе, а не откатывает весь процесс.

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

Если кто-то утверждает, что «в Канбане нельзя двигать карточки назад», смело отвечайте: «Можно, но это не лучший путь».

Миф №9: Мы не можем использовать WIP-лимиты, потому что задачи разные

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

WIP-лимит – это не про ограничение количества задач, а про балансировку системы. Он помогает управлять потоком работы и балансировать три ключевые метрики:

• Время производства (cycle time) – сколько времени занимает выполнение одной задачи.

• Пропускная способность (throughput) – сколько задач выходит из системы за единицу времени.

• Объём незавершённой работы (WIP) – сколько задач в системе в данный момент.

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

Представьте трубу, через которую течёт вода. Если труба переполнена, молекулы воды сталкиваются, завихряются и выходят медленно. Если труба пустая, вода течёт быстро, но её слишком мало. Оптимальный поток – сбалансированное количество воды. Точно так же в рабочем процессе: слишком много задач в работе – перегруз, слишком мало – недозагрузка.

Один из аргументов против WIP-лимитов – «у нас задачи разные, значит, их нельзя ограничивать». На самом деле WIP-лимиты не привязаны к размеру задачи. Они регулируют общее количество задач, независимо от их сложности.

Допустим, у нас есть три типа задач: большие, средние и маленькие. Сценарий без WIP-лимита: начинаем кучу задач сразу. Большие задачи зависают в работе на долгое время. Маленькие задачи теряются в общем потоке. Всё выполняется хаотично. Сценарий с WIP-лимитом: мы ограничиваем количество задач, находящихся в работе одновременно. Если одна большая задача уже в процессе, новая большая не стартует, пока текущая не завершится. Это поддерживает баланс, а не приводит к перегрузу.

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

Миф №10: Канбан Метод – это бездушный подход, не про людей

На самом деле, Канбан Метод — один из самых человекоцентричных подходов к управлению.

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

Основной принцип — «Управляйте работой, а не людьми» (Manage work, don’t manage people). В отличие от других подходов, Канбан не заставляет людей «подстраиваться» под фиксированные роли и процессы. Он создаёт среду, в которой команда сама организуется вокруг работы, а не подчиняется жёстким правилам. Канбан Метод не требует революционных изменений, не ломает привычный уклад работы и не заставляет людей насильно менять поведение.

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

Миф №11: В Канбане нет итераций и дедлайнов, значит, нет фокуса на завершение

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

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

Возьмем два примера: когда нет фокуса на работе, и когда он есть. Зачастую статусные собрания в командах идут по принципу «что я делал вчера / что буду делать сегодня / какие есть проблемы». Такой способ проведения статусного собрания фокусирует вас на занятости людей. В Канбане мы проходим по доске справа налево – от конца к началу процесса и задаём следующие вопросы:

• Что это за задача?

• Кто ей занимается? 

• Что надо сделать, чтобы её можно было переместить вправо?

• Когда это будет сделано?

• Есть ли какие-то проблемы?

• Можем ли мы как-то помочь?

Такой формат собрания держит фокус на завершении работы, а не загрузке людей.

Популярность — на поверхности, сложность — в глубине

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

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

• Headhunter – одни из первых, кто использовал вероятностное прогнозирование и глубоко внедрил Канбан Метод.

• Банк «Санкт-Петербург» – периодически развивает и восстанавливает Канбан-подход в разных отделах.

• ТБанк и инфраструктура Тинькофф – Канбан применяется от базовой визуализации до продуктового управления и прогнозирования.

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