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

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

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

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

Выводы:

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Скрамтрек (ScrumTrek) — ведущий провайдер тренингов в России по Agile, Scrum, Kanban и масштабируемым фреймворкам.

2

СТАТИК (англ. S.T.A.T.I.K. — System Thinking Approach to Introducing Kanban) — системный подход к внедрению Канбана.

3

Jira — американское ПО для управления задачами и проектами.

4

Кайтен — российский сервис для управления рабочими процессами.

5

Бэклог (от англ. backlog — «невыполненная работа») — место, где хранится список всех задач команды или будущий функционал продукта.

6

Деплой (от англ. deploy — «развертывать») — установка продукта в рабочую среду, например, в магазин приложений AppStore или Google Play.

7

Видео доклада https://youtu.be/X5cLDJtLpUA?si=aNZ7CoijbPbFcAnU.

8

Lead Time — время производства.

9

Регрессионное тестирование — тестирование функционала всей программы, а не только той части, которая дорабатывалась.

10

Свимлейн (от англ. swimlane — буквально «плавательная дорожка») — дорожка в Канбан-системе.

11

Таск-трекер — программа для управления задачами, например, Jira или Kaiten.

12

Алексей Жеглов — ведущий мировой эксперт по Канбан-методу, публицист, спикер, соавтор тренингов по Канбану и книги “Fit for Purpose”.

13

Канбан-система — Канбан-доска с WIP-лимитами.