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

Об авторе и книге

С Игорем мы несколько лет работали плечом к плечу в 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-лимиты, явные правила. Можно было бы сказать, что это идеальная Канбан-доска. Но! У нее был очень сильный минус — проводить дейлики и управлять потоком на этой доске мог только специально обученный человек. Поэтому когда он покинул компанию, произошло то же, что и в большинстве Канбан-инициатив. Никто не смог подхватить его работу, поэтому топы довольно скоро перестали собираться возле этой доски, и все сошло на нет.

Поэтому моя вторая главная рекомендация: не упарывайтесь по супер-детальной визуализации. Простота — путь к совершенству. Чем проще будет ваша визуализация Канбан-доски, тем выше шанс, что ей сможете пользоваться не только вы. А это значит, что она переживет вас и надолго останется в компании как рабочий инструмент.

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

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

У меня был такой случай в практике — одна фаундер стартапа обратилась ко мне, чтобы я помог ей наладить работу в команде с помощью Канбана. Я потратил кучу времени на СТАТИК, чтобы сделать Канбан-доску именно для ее кейса. Но когда мы все визуализировали и запустили инструмент в команде, доска оказалась слишком сложной. В итоге я сделал откат и внедрил готовую прото-Канбан доску. И поток работы сразу наладился. Все быстро сообразили, как пользоваться этим инструментом.

Выводы:

• Доска должна отражать вашу реальность.

• Не упарывайтесь сразу по супер-детальной Канбан-доске.

• Начиная визуализацию, идите небольшими итерациями. Пусть ваша доска эволюционирует.

• Визуализируя Канбан-доску, оценивайте ваш уровень владения Канбаном. Иногда проще использовать готовый вариант из прото-Канбан досок, а уже потом пробовать СТАТИК.

Глава 5. Ограничение WIP: самая нелюбимая практика

WIP-лимит (Work In Progress) переводится как ограничение незавершенного производства, или по-простому — сокращение количества задач, над которыми трудится команда. Это может быть как простая задача, так и проект или стратегическая инициатива.

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

Почему WIP вызывает сопротивление

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

Сопротивление WIP-лимитам неизбежно. Часто звучит аргумент: «У нас слишком много срочных задач, мы не можем ограничивать работу». Но именно в перегруженной системе лимиты нужны больше всего. Другой типичный страх — «клиенты не поймут». Однако клиенты обычно не страдают от того, что вы взяли в работу меньше задач. Они страдают от того, что вы не завершаете их вовремя. Ограничение WIP делает время выполнения задач более предсказуемым, не замедляя при этом бизнес.

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

Как WIP меняет систему

Парадокс в том, что чем больше мы работаем, тем медленнее заканчиваем. Это объясняется тем, что когда задач слишком много, работа начинает расползаться. Каждая из них продвигается медленно, потому что люди вынуждены постоянно переключаться. Многозадачность выглядит как высокая занятость, но фактически она пожирает производительность. Каждое переключение — это потеря контекста, времени и качества. В итоге ни одна задача не движется быстро, а общая длительность выполнения растет.

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

Ограничение WIP вместо «сделать больше» ставит цель «закончить быстрее». Это принципиальный сдвиг. Мы перестаем измерять эффективность количеством запущенных инициатив и начинаем смотреть на завершенные результаты. В этот момент система становится прозрачной: если мы не можем взять новую задачу из-за лимита, значит где-то есть узкое место. Лимит не создает проблему — он ее выявляет.

У себя в блоге я подробно описал кейс, когда данная практика помогла улучшить предсказуемость потока и сократить Lead Time в два раза. В результате применения лимитов время производства сократилось с 40 до 18 дней с вероятностью 95 %. Сам кейс вы найдете дальше в книге.

Как вводить WIP-лимиты

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

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

Что происходит после внедрения

Первые попытки ввести WIP-лимиты часто вызывают напряжение. Люди чувствуют, что их сдерживают. Руководители опасаются, что команда будет недогружена. Возникает тревога: «А вдруг мы не успеем?»

На практике происходит обратное. Сначала кажется, что скорость падает, потому что новых задач берется меньше. Затем начинает сокращаться цикл выполнения, работа перестает застревать в ожидании, команда начинает помогать друг другу, чтобы освободить место под новые задачи. Появляется коллективная ответственность за завершение.

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

Выводы:

• WIP-лимиты как антибиотик: неприятно, но спасает.

• Ограничение незавершенной работы — самый быстрый путь, чтобы повысить предсказуемость для клиентов.

• WIP-лимиты требуют управленческой смелости.

• Многозадачность пожирает производительность.

• Выбор правильных лимитов — это управленческий эксперимент.

• Канбан без WIP-лимитов — это просто визуализация перегруза.

Глава 6. Поток: сердце Канбана

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

Третья практика Канбана звучит так: «Manage the Flow» или в переводе на русский «Управляйте потоком». На старте я бы рекомендовал понимать это не буквально, а как метафору. Представьте, что поток в Канбане — это горная река. Она течет, сталкиваясь с препятствиями. Если препятствий много, то поток замедляется. Если препятствий нет, поток становится стремительным. Он в любом случае обойдет препятствия, но от их количества напрямую зависит его скорость. Поэтому ваша задача, как менеджера, следить за препятствиями, с которыми сталкивается поток, и устранять их, чтобы он становился равномерным и предсказуемым. И здесь мы переходим к следующей трактовке — поток как экономический эффект вашей системы. Именно в таком ключе он становится сердцем Канбана.

Главный инструмент управления потоком — это дэшборд[14]¹⁴ с производственными метриками. Когда я устроился в Лигу Ставок, мне очень повезло — в компании уже был внедрен дэшборд производственных метрик. Это действительно большое везение, потому что если такого дэшборда нет, а вы хотите управлять потоком, вам придется его сделать (я дважды проходил этот путь — в С7 ТехЛаб и в СберЗдоровье).

Дэшборд помогает менеджеру быстро оценить качество, уровень и стоимость ИТ-производства компании. Можно выделить две основные версии дэшборда: для топ-менеджмента и для линейных руководителей. Стандартный набор метрик дэшборда: время производства, пропускная способность, предсказуемость, время цикла[15]¹⁵, заблокированные задачи, баги[16]¹⁶ и инциденты[17]¹⁷.

Главные метрики для измерения потока — время производства, пропускная способность и количество заблокированных задач (задержки). Они отражают экономику производства. Если у вас высокий показатель времени производства, низкая пропускная способность и много заблокированных задач, вы начинаете тратить деньги впустую.

Если поток замедляется, появляется много незавершенных задач и фактически ваш капитал замораживается. А если еще посчитать стоимость задержек (Cost of Delay), то картина становится совсем пессимистичной. В компании растет операционный риск, появляется микроменеджмент, стоимость бизнеса снижается.

Но есть и хорошая новость: вы можете этим управлять и через метрики напрямую влиять на стоимость вашего производства и реализацию стратегии компании.

Например, в Лиге Ставок мы делаем регулярный обзор производственных метрик в каждой продуктовой команде и на уровне всего продуктового департамента. В начале нового спринта[18]¹⁸ мы вместе с командами смотрим, как текущие производственные метрики изменились за прошедшую итерацию и, если они деградировали, обсуждаем, что нужно сделать, чтобы их улучшить. Именно регулярный обзор производственных метрик помогает нам держать руку на пульсе и сразу же реагировать, если стоимость производства возрастает.