Канбан для менеджера. Почему базовые практики не дают результат и как это исправить

- -
- 100%
- +

Об авторе и книге
С Игорем мы несколько лет работали плечом к плечу в S7 TechLab. Я хорошо помню, как выглядел Канбан «до» и «после»: от простой доски для контроля поручений — до полноценной системы управления с Flight Levels, воронкой инновационных гипотез и дашбордом метрик, на основе которого я, как руководитель, мог принимать решения и управлять эффективностью команд. Поэтому читал эту книгу не как теорию, а как хронику того пути, который мы во многом прошли вместе.
Главная ценность книги — в ее честности. Игорь не продает Канбан как волшебную таблетку, а прямо говорит: доска — не Канбан, WIP-лимиты никто не любит, а система первым делом покажет вам всю ту реальность, которую хочется не замечать. Это ровно то, через что мы проходили в TechLab: пока не появились явные метрики производства и предсказуемость поставки, разговор бизнеса с командами шел на языке ощущений, а не фактов.
Книга подробно и без прикрас разбирает, как выстроить этот путь от «доски на коленке» до системы, которая масштабируется на уровень целой компании — и кейс S7 TechLab, который вошел в книгу отдельной главой, для меня лично особенно ценен, потому что там узнается наша с Игорем совместная работа.
Отдельно хочу отметить структуру книги: теория подана компактно, а дальше — пять живых кейсов из разных индустрий, где видно, как один и тот же метод дает разный, но всегда измеримый результат. Для менеджера, который уже пробовал Канбан и разочаровался, это отличная перезагрузка: книга не учит «делать правильно», а учит задавать правильные вопросы и смотреть на поток как на экономику бизнеса, а не набор ритуалов.
Отдельное спасибо автору за то, что не ограничился классическими практиками и затронул новые вызовы, включая применение ИИ в Канбане — поделился своим опытом, видением и собрал вокруг темы экспертную дискуссию.
Игорь — один из немногих практиков, кто прошел путь от стикеров на ватмане до Аккредитованного Канбан-консультанта и умеет объяснить сложные вещи простым языком, подкрепляя их реальными цифрами и успешными кейсами. Рекомендую эту книгу всем менеджерам и руководителям, которые хотят не «внедрить Канбан для галочки», а получить управляемый, предсказуемый и честный процесс. Уверен, что для многих она станет настольной книгой и ориентиром — как в свое время наша совместная работа стала фундаментом для этой книги.
Шопник Герберт Иосифович, CEO «Ант-Цифровые Сервисы»Вступление. Зачем вам эта книга
Дорогой читатель!
Я очень рад, что вам в руки попала моя книга «Канбан для менеджера. Почему практики Канбан не дают результата и как это исправить». Это моя попытка открыть вам новые грани Канбана и ответить на ваши вопросы о нем. Итак, зачем вам эта книга?
Новички приходят в Канбан с ожиданием простоты: доску сделал, колонки поставил, задачи двигаются. Но правда в том, что Канбан — зеркало системы. Он показывает то, что хочется скрыть. Эта книга написана для менеджеров, которые уже что-то знают о Канбане и хотят понять, как делать и вообще можно ли делать правильно, но устали от противоречивых советов.
«Канбан для менеджера» — это честность: иногда неприятная, но абсолютно необходимая. После прочтения данной книги вы поймете: Канбан — это не ритуал, а мышление.
Я впервые узнал о Канбане, когда в 2015 году прошел тренинг Certified Agile Professional в компании Скрамтрек[1]. На нем давались основы Agile, Скрам-фреймворка и Канбан-метода.
Когда после тренинга я вернулся на работу, то понял, что теперь я смогу начать применять Канбан, а не Скрам. Контекст был такой, что Канбан помог бы мне лучше.
Я купил ватман, маркеры, стикеры и сделал первую Канбан-доску. Про СТАТИК[2] я на тот момент не знал, поэтому ориентировался на то, что нашел в Гугле и в раздаточном материале с тренинга.
Сделав первую доску, я перенес на нее все проекты, которые вел, и стал погружаться в мир Канбана.
В первые годы работы с Канбаном я считал, что проблемы возникают из-за того, что я неправильно применяю практики. Но по мере работы в разных командах я стал замечать повторяемость одних и тех же ситуаций: у всех были одинаковые вопросы, ошибки и ожидания от Канбана.
За десять лет практики я встретил много разных менеджеров, Agile-коучей, Скрам-мастеров и агентов изменений, которые применяли этот метод и, как и я, задавались вопросом: как использовать Канбан правильно?
Со временем стало понятно, что причина общих проблем была в том, что мы использовали Канбан как набор практик, а не как способ управления мышлением.
Особенно стоит отметить такой феномен: в Канбан-сообществе обсуждение пользы часто подменяется обсуждением терминов. Например, если вы скажете «Канбан — это фреймворк», или «Канбан нужно внедрять», или «Канбан эффективнее Скрама», вы почти гарантированно вызовете осуждение и споры. Признаюсь, вначале я и сам был участником этой полемики, но со временем заметил интересную закономерность: чем опытнее становится менеджер, тем меньше он спорит о терминах и тем больше думает о пользе для бизнеса. Поэтому цель данной книги — развеять мифы о Канбане и дать понимание того, что в Канбане нет понятия «правильно» или «неправильно».
Как Аккредитованному Канбан-консультанту мне очень хочется донести эту мысль до тех менеджеров, которые недавно стали применять Канбан для своей работы и задаются вопросом: «Правильно ли я применяю Канбан?». Ответ здесь один: не цепляйтесь за слова «правильно» или «неправильно» и лучше подумайте, какую пользу вы хотите или уже получаете от Канбана для себя или вашей компании. В следующих главах я покажу на реальных примерах разные способы применения Канбана и результаты, которые они дают.
Я искренне надеюсь, что после прочтения данной книги у вас уйдет стыд, страх, сомнения или волнение из-за того, что вы делаете что-то не так. Даже если что-то сейчас не получается, это лишний повод дочитать до конца и найти решение.
Несколько дисклеймеров: в этой книге я буду осознанно использовать словосочетание «внедрение Канбана», потому что оно очень хорошо отражает процесс применения Канбана в компании. И еще некоторые мысли будут повторяться в разных главах. Я верю в силу повторений: так информация точно отложится у вас в голове.
Часть I. Почему Канбан не работает?
Чтобы разобраться в том, почему Канбан «не работает», нужно рассмотреть наши установки в отношении Канбана и ожидания от него. В частности, что мы о нем думаем, что считаем в нем «правильным» и как по нашим представлениям он должен решать проблемы.
Глава 1. Канбан — это не то, что вы думаете
Часто к консультантам и бизнес-тренерам приходят с запросом «У нас хаос. Помогите нам выстроить прозрачные процессы, чтобы работа ИТ-отдела наладилась, и все подразделения получили результат». И начинается работа в этом направлении. Консультанты приходят, визуализируют процесс, оборачивают его в виде какой-то Канбан-доски или Канбан-системы и настраивают поток.
Казалось бы, все сделано по инструкции и должно работать. Но не работает. Почему? Из-за неправильного понимания Канбана.
Канбан — не доска
Большинство людей знакомятся с Канбаном через доску в Jira[3] или Кайтен[4] — отсюда иллюзия, будто Канбан равно доска. Но Канбан — это не только доски и стикеры. Канбан — это система управления потоком работы, а доска — лишь инструмент визуализации. Поэтому, когда мы начинаем внедрение Канбана с нарисованной доски, мы рискуем оказаться в ситуации, когда доска есть, а ее смысл и польза до команды или людей не донесены.
В моей практике был следующий случай. Ко мне обратилась сотрудница одного университета. У них был хаос в проектах. Они решили внедрить Кайтен, сделали по образцу Канбан-доску, но это не помогло: хаос как был, так и остался. Ко мне она пришла с таким запросом: «У нас есть доска, но никто возле нее не собирается и ничего не обсуждает. Мы не знаем, что делать». Проблема заключалась в том, что команда сделала доску без понимания, как использовать Канбан-метод и что нужно для того, чтобы он заработал. Получился карго-культ без результата для бизнеса.
В данном случае проблему можно было решить, введя роль Деливери-менеджера и объяснив, зачем он нужен. У доски появился бы ответственный, который собирал команду, следил за статусом проектов, движением работы и превратил бы Канбан в систему управления потоком.
Канбан — не инструмент мгновенного ускорения
Очень важно помнить и держать в уме еще одну вещь. Чего Канбан точно не делает — он не ускоряет работу магическим способом.
Канбан — это метод улучшения работы на основе данных. Поэтому если вы решили применять Канбан с целью повышения скорости работы, вас ждут большие препятствия и много работы на пути к этой цели. Само по себе это не произойдет. Вам сначала нужно будет собрать данные о скорости работы вашей команды, потом проанализировать источники задержек, внутренние и внешние, потом разработать гипотезы по их устранению, реализовать их, и только после этого скорость команды увеличится. По моему опыту самое быстрое ускорение происходит минимум через три месяца от начала работы. Помните об этом.
Канбан раскрывает реальность
Ну и последняя мысль этой главы: Канбан раскрывает реальность — и это пугает.
Когда я только начинал заниматься Канбаном, мне попался интересный случай. Одна международная компания решила внедрить Канбан, чтобы наладить работу IT-отдела — за его ресурсы бились все остальные подразделения и к производительности были вопросы. Консультанты сделали для них Канбан-доску, настроили систему, и тут всем стали видны скрытые проблемы: кто дольше всех задерживает работу и кто играет не по правилам.
Между топ-менеджерами началась ожесточенная борьба за ресурсы и дело кончилось тем, что Канбан поставил под угрозу выполнение годовых целей. Генеральный директор испугался и отменил введенные правила, а консультанты получили жалобу, что их работа чуть не стоила компании выполнения KPI.
В результате использования Канбана в этой компании стало видно, кто и как себя ведет, и эта реальность испугала CEO, поэтому он свернул все инициативы по использованию Канбана. К сожалению, таких примеров в Канбане очень много, потому что часто руководители просто не готовы узнать правду о своем бизнесе.
Выводы:• Чаще всего с Канбаном знакомятся через доску в Jira или Кайтен — отсюда иллюзия, будто Канбан = доска.
• Канбан — это система управления потоками работы, а доска — всего лишь инструмент визуализации.
• Что Канбан точно не делает: не ускоряет работу магическим образом.
• Канбан раскрывает реальность — и это пугает. Спокойно! Дальше я расскажу, как победить этот страх.
Глава 2. Что такое «правильно» в Канбане?
Вообще, что такое «правильно» в Канбане — довольно сложный вопрос и тема для холиваров. Я немного раскрыл эту мысль во вступлении. Разберемся с этим подробнее и начнем с истоков.
Когда я только познакомился с Канбаном, я искал любую информацию о нем. И все, что мне попадалось, я считал правильным.
Начнем с Канбан-доски, которую я подсмотрел в раздаточных материалах после тренинга «Certified Agile Professional» и которую я сделал, работая в Альпари. Там были стандартные этапы разработки: бэклог[5], очередь, анализ, разработка, тестирование, деплой[6] и приемка (Рис. 1).

Рис. 1. Моя первая Канбан-доска
Мне эта доска казалась идеальной и, конечно же, правильной. Потом я перешел в Альфа-Банк, в команду Интернет-банка Альфа-Клик. И там Канбан-доска была уже покруче (Рис. 2).

Рис. 2. Канбан-доска Интернет-банка Альфа-Клик
На ней были дополнительные этапы: валидация, компонентное и интеграционное тестирование и свимлейны. Эту доску делали до меня консультанты из компании Скрамтрек. Конечно же, я тоже считал ее правильной.
Но самый яркий пример и тест на «правильно» в Канбане я прошел, когда готовил об этой Канбан-доске доклад «Эволюция Канбан-системы. Опыт Альфа Лаборатории» на конференцию Agiledays[7]. В докладе я последовательно перечислил все проделанное с этой доской: обновление явных правил, добавление WIP-лимитов, подсчет Lead Time[8], введение классов обслуживания и типов работ, обучение команды. Я делал упор на то, что с моим приходом и апгрейдом доски нам, во-первых, удалось подсчитать реальное время производства (Lead Time) для разных типов работ, а во-вторых, повлиять на его сокращение почти в два раза.
Считал ли я тогда это «правильным»? Конечно да. Но сейчас, с высоты своего десятилетнего опыта, я понимаю, что тогда действовал очень быстро, не давая команде привыкнуть к новым правилам. Поэтому сейчас я уверен в другом: вместо споров о том, что правильно, нужно задавать правильные вопросы. Вместо «Какая доска правильная?» спросите себя: «Помогает ли текущая система делать поток более предсказуемым?»
Таким образом можно сделать вывод, что «правильность» в Канбане измеряется не ритуалами или набором практик, а результатом: устойчивостью потока, прогнозированием поставки, улучшением Lead Time.
О чем важно помнить в поисках «правильного»
Если в вашей практике вопрос «Что такое правильно?» завел вас в тупик, то всегда можно апеллировать к теории — к основным принципам Канбана, потому что контекст может меняться, а принципы — нет.
Напомню три принципа управления изменениями в Канбане:
1. Начните с того, что есть. Поймите текущие процессы, уважайте текущие роли и обязанности.
2. Получите согласие на улучшения через эволюционные изменения.
3. Поощряйте проявление лидерства на всех уровнях.
Используйте эти принципы как основные ориентиры, потому что они работают всегда.
Ну и еще я бы добавил сюда такое измерение, как время привыкания к новым правилам. Выше я уже писал, что слишком торопился с внедрением новых практик. Сейчас, на опыте страховой компании, где я работал с 2024 по 2026 год, я научился действовать медленно и добавлять улучшения последовательно, как решения текущих проблем потока.
Еще один важный момент, о котором стоит сказать: нет такого понятия, как универсальная доска для всех. Вы можете начать с чего-то стандартного, что есть везде (как в примере с моей первой Канбан-доской), но впоследствии вам захочется ее обновлять. Это нормально. Ваша доска — это отражение вашей реальности и потока, того, как это работает именно у вас. Так что, если в процессе работы увидите, что первоначальная доска существенно изменилась, значит вы все сделали правильно.
Поэтому хочется пожелать вам — не заморачивайтесь на тему правильности. Начинайте с того, что есть, эволюционируйте вместе с вашей Канбан-доской, и она обязательно трансформируется в Канбан-систему. Дайте себе время и не торопитесь.
Выводы:• Правильность в Канбане измеряется не ритуалами, а результатами: устойчивостью потока, прогнозированием поставки, улучшением Lead Time.
• Вместо поисков «правильного» научитесь задавать правильные вопросы.
• Практики могут меняться, принципы — нет.
• Не заморачивайтесь на тему правильности. Начинайте с того, что есть, и эволюционируйте вместе с вашей Канбан-доской.
Глава 3. Канбан не решает ваши проблемы — он их показывает
Наверно, самое большое заблуждение в Канбане — это ожидание того, что он решит ваши проблемы. На практике все обстоит немного иначе. Ваша Канбан-система — это зеркало ваших процессов.
Вспоминая пример из Альфа-Банка, скажу, что мои ожидания как раз касались того, что Канбан решит все проблемы, поэтому я постоянно тюнил нашу Канбан-систему. В процессе я заметил, что у нас очень долгий цикл тестирования, около трех-четырех дней.
Взяв курс на сокращение Lead Time, я ввел WIP-лимиты. Это помогло, но не так, как я ожидал. За счет лимитов мы стали брать меньше новых задач в работу и сфокусировались на завершении того, что уже в процессе. Этапы анализа и разработки пролетали довольно быстро, а дальше работа переходила на этап тестирования.
И тут выяснилось, что в тестировании время не сократилось, потому что ребятам приходилось каждый раз делать регрессионное тестирование[9]. Это похоже на строительство многоэтажного дома, когда после каждого нового этажа нужно проходить по всему зданию и перепроверять каждый угол. Тестировщики по такому же принципу проводили полный регресс каждые две недели. Из десяти рабочих дней четыре по-прежнему уходили на тестирование.
В какой-то момент ко мне пришел лид команды тестировщиков и сказал, что его ребята (их было всего четверо) упоролись в хлам и нужно что-то менять в работе, чтобы они не выгорели.
Обсудив проблему, мы пришли к выводу, что время команды лучше инвестировать в автотесты. Если представить автотестирование на том же примере с домом — теперь тестировщикам не нужно было каждый раз заново проходить по всем этажам, это за них делал робот.
У нас ушло на это примерно полтора месяца, и результат превзошел все ожидания. Благодаря автотестам мы сократили время на регресс до одного-полутора дней. Вот так Канбан подсветил нам проблему, устранив которую, мы получили ощутимый профит.
Еще один хороший пример был в компании Альпари, я упоминал об этом проекте во второй главе. Спустя два месяца использования Канбана команда переделала всю работу, которая была на доске, и мы столкнулись с проблемой: на этапе приемки скопилось много задач, потому что наши заказчики не успевали принимать готовый результат. Снова Канбан подсветил узкое место.
В какой-то момент я пришел к бизнес-заказчикам и сказал: «Парни, мы переделали всю работу, которую вы нам дали. Поэтому, во-первых, нам нужны новые задачи и, во-вторых, примите, пожалуйста, то, что мы для вас уже сделали». Это был фурор!
Результат нашей работы настолько понравился стейкхолдерам, что спустя несколько месяцев, когда я уже не работал в Альпари, они пришли ко мне с просьбой провести обучение и сделать для них Канбан-доску (Рис. 3).

Рис. 3. Обучение Канбану для бизнес-команды Альпари
Как честность Канбана ощущается в реальных условиях
Представьте ситуацию, когда вы только начинаете использовать Канбан. Вы сделали доску, перенесли на нее все проекты и задачи и наконец впервые увидели, что у вас слишком много параллельной работы, хаос в приоритетах, узкие места и отсутствуют договоренности. В первый раз такая честность шокирует, но это нормально и через это проходят все менеджеры. Бонус в том, что прозрачность сразу дает кучу идей, как улучшить работу команды и выстроить предсказуемый поток.
Еще одна ситуация, с которой вы можете столкнуться после внедрения Канбана — это то, что у вас «все горит». Это абсолютно нормально для стадии взросления. Канбан всего лишь показал вашу реальность. Тут хорошо работает фраза с обложки главной книги о Канбане Девида Дж. Андерсона — «Давайте разбираться!». Вы получили бесценные сведения о том, где и с чем у вас проблемы. Вы осознали проблему, а значит, это можно исправить.
Стоит отметить еще один очень важный момент: вы можете запаниковать! На доске много задач, по ним горят дедлайны, нужно все успеть. А тут еще эти WIP-лимиты, будь они неладны. Вы вдруг понимаете, что у вас хаос на доске — проекты перемешаны с задачами. Хочется как-то выделить проекты, чтобы сфокусироваться на них. Может быть, стоит их выделить в свимлейны[10]? А может, перенести на отдельную доску? Столько вопросов и столько неочевидных ответов! Что делать? Видите, Канбан снова подсветил вам проблемы.
Эта паника — тоже нормальная ситуация! Не нужно ее бояться. Все решаемо. Вам могут помочь и свимлейны, и отдельная доска. Главное — не бойтесь экспериментировать.
Последний, очень яркий пример, с которым я столкнулся, показывает, как менеджеры зачастую сопротивляются такой честности Канбана. В проекте для страховой компании мы проводили анализ производственных метрик команды, в частности, Lead Time. Когда ко мне пришел Agile-коуч и мы вместе стали анализировать метрики, вдруг выяснилось, что в моем процессе есть проблемы, которые очень сильно влияют на данные. А я, вместо того, чтобы взять на себя ответственность, начал доказывать, что это проблема не моя, а процесса. Я даже апеллировал к первой ценности Agile-манифеста: «Люди и взаимодействие важнее процессов и инструментов». Мне не хватило мужества признать проблему, поэтому я стал возражать и сопротивляться. Но потом, немного порефлексировав, я согласился, что проблема есть, и стал ее устранять.
Поэтому запомните: честность — это всегда очень тяжело в Канбане. Постарайтесь найти в себе силы и смелость признать проблему. Канбан не решает проблему за вас, но он не позволяет делать вид, что ее нет.
Выводы:• Канбан не чинит процессы, а делает их видимыми.
• Проблемы, которые вскрываются в первые недели: слишком много параллельной работы, хаос в приоритетах, узкие места, отсутствие договоренностей.
• «Все горит» — нормальная стадия взросления.
• Через панику и сопротивление проходят все.
• Честность в Канбане — это всегда очень тяжело.
Теперь, когда система стала прозрачной, возникает следующий вопрос: какие механизмы Канбана позволяют работать с этими проблемами? Именно этому посвящена следующая часть книги.
Часть II. Основы, без которых невозможно двигаться дальше
Глава 4. Визуализация
Несмотря на то, что эта книга написана не для новичков, а для тех, кто уже попробовал Канбан и столкнулся с трудностями, я просто обязан начать с основ. И начнем мы с самой первой базовой практики — визуализации.
Помню, когда я только начинал изучать Канбан в 2015-м, таск-трекеры[11] были в зачаточном состоянии и визуализировать доску с лимитами, свимлейнами и разноцветными карточками с кучей информации было практически невозможно. Скажу даже больше — свою первую Канбан-доску я делал с помощью ватманов и стикеров.
Сейчас (в 2026-м) таск-трекеры настолько хороши, что вы можете ставить WIP-лимиты не то, что на колонки или дорожки, но даже на ячейки. Очень сильно развились графики с аналитикой: накопительная диаграмма потока, диаграмма распределения времени выполнения, контрольная диаграмма, график блокировок. Этот список можно продолжать долго.
Но, независимо от инструментов, визуализация как практика настолько универсальна, что вы можете сделать доску практически на коленке. Главное — и это моя первая рекомендация — чтобы она отражала вашу реальность. Помню, на мастер-классе «Аккредитованный Канбан-консультант» Алексей Жеглов[12] рассказывал нам про визуализацию доски с проектами одного CIO с бюджетом в сотни миллионов долларов. Там было всего четыре(!) колонки: «Очередь», «Следующее», «В работе» и «Готово». И этой доски топ-менеджеру хватало, чтобы держать руку на пульсе.
Был еще один интересный случай из практики, о котором я хочу рассказать. На самой топовой конференции в РФ Agile Days мой коллега по цеху рассказывал о Канбан-системе[13] для топ-менеджеров. Она была до невозможности перегружена деталями: сквозной поток (дискавери-часть и деливери-часть), куча свимлейнов и этапов, WIP-лимиты, явные правила. Можно было бы сказать, что это идеальная Канбан-доска. Но! У нее был очень сильный минус — проводить дейлики и управлять потоком на этой доске мог только специально обученный человек. Поэтому когда он покинул компанию, произошло то же, что и в большинстве Канбан-инициатив. Никто не смог подхватить его работу, поэтому топы довольно скоро перестали собираться возле этой доски, и все сошло на нет.
Поэтому моя вторая главная рекомендация: не упарывайтесь по супер-детальной визуализации. Простота — путь к совершенству. Чем проще будет ваша визуализация Канбан-доски, тем выше шанс, что ей сможете пользоваться не только вы. А это значит, что она переживет вас и надолго останется в компании как рабочий инструмент.



