Почему Канбан работает — и как узнать готова ли ваша команда

Большинство команд принимают Канбан потому что кто-то прочитал статью в блоге. Более умный вопрос — решают ли проблемы, которые Канбан решает, действительно проблемы, которые есть у вашей команды.

Есть момент, который большинство команд признает, обычно около времени, когда у них больше восьми или девяти человек. Работа выполняется — письма отправляются, функции доставляются, клиенты управляются — но никто не имеет четкого представления о том, что делает каждый. Проекты накапливаются. Вещи обещаны и потом тихо забыты. Вы тратите двадцать минут перед каждой встречей, выясняя где кусок работы действительно находится. Ответ, обычно, — "где-то".

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

Это удивительно скромный инструмент для чего-то, что привлекло так много внимания. Канбан не претендует исправить вашу организацию. Он просто делает работу видимой. И получается что видимость, применяемая последовательно, меняет замечательное количество вещей downstream.

Откуда действительно пришел Канбан

Слово японское — это означает "доска объявлений" или "рекламный щит" — и система была разработана Toyota в конце 1940-х как способ управления инвентарем на их производственных предприятиях. Идея была простой: вместо производства деталей по фиксированному графику, фабрика производила бы их только когда downstream станция сигнализирует что им нужны. Физическая карта — канбан — путешествовала бы обратно вверх по линии как заказ. Ничего не производилось спекулятивно. Ничего не накапливалось необходимо.

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

Разработчики программного обеспечения, особенно в компаниях как Microsoft в начале 2000-х, начали адаптировать эти идеи для работы знаний. Карты стали задачами. Станции фабрики стали этапами в рабочем процессе. И доска объявлений стала доской — физически сначала, потом цифровой — где кто-то из команды мог видеть с одного взгляда, что в процессе, что ждет и что сделано.

Что доска Канбан действительно показывает

Базовая доска Канбан имеет три колонки: К Сделанию, В Процессе, Готово. Это достаточно для многих малых команд и хорошее место для начала. Но реальная ценность появляется когда вы начинаете настраивать эти этапы в соответствии с как ваша работа действительно течет — не как вы хотели чтобы она текла.

Команда контента может использовать: Идея, Бриф, В Черновике, В Обзоре, Запланировано, Опубликовано. Команда программного обеспечения может сломать "В Процессе" на отдельные колонки для разработки, обзора кода и QA. Команда консультации может отслеживать Открытие, Предложение, Активное, Ожидание Клиента, и Закрыто. Этапы должны отражать реальные передачи и реальные времена ожидания — места где работа меняет руки, или где она сидит пока что-то еще происходит.

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

Правило которое это делает работает: WIP ограничения

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

Это чувствует себя контруинтуитивно. Конечно, быть способным поставить больше задач в процесс означает больше получается сделано? Это не так. Что действительно происходит когда люди работают над слишком многими вещами одновременно — это все занимает дольше. Переключение контекста дорого. Полу-завершенная работа создает координационный overhead. И когда десять вещей "в процессе", это очень сложно говорить какие из них действительно движутся и какие просто застряли но не отмечены.

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

Канбан против Скрама: вопрос команды всегда спрашивают

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

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

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

Три вопроса ваша доска должна ответить в тридцать секунд

Доска Канбан — большинство полезная когда вы можете посмотреть на нее и, без разговора с кем-то, быстро ответить на эти три вопроса: На чем команда работает прямо сейчас? Где работа становится застрявшей? Есть ли что-то которое должно быть сделано что не было начато?

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

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

Что Канбан не делает

Канбан — не инструмент стратегии. Это не поможет вам выясниться что работать на — только помочь вам управлять что вы уже решили работать на. Если ваша организация имеет проблему приоритизации, или проблему неясного мандата, или проблему "мы начинаем слишком много проектов перед завершением старых" укоренено в поведении лидерства вместо процесса, доска Канбана раскроет эти проблемы но не решит их.

Это также не замена для хорошего управления. Доска не заменяет one-to-ones, или продумано делегирование, или четкую коммуникацию о почему определенная работа имеет значение. Команды иногда принимают инструменты процесса надеясь что процесс будет делать релационное и организационное работу которая на самом деле работа менеджера. Это не будет.

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

Как начать — без трехдневного мастер-класса

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

Начните с вашей командой как это действительно, с работой что вы действительно имеете. Создайте три колонки: Бэклог, В Процессе, Готово. Потратьте тридцать минут с вашей командой кладя каждый текущий рабочий предмет на карту. Согласитесь на одно правило: когда вы начинаете что-то, это идет на доску. Когда это движется, вы движете карту. Делайте ничего иного для две недели.

После две недели, посмотрите на доску вместе. Где вещи скопились? Что осталось в Бэклоге что каждый сказал была приоритет? Что движалось быстрее чем ожидалось? Что застряло и почему? Используйте что вы наблюдайте уточнить колонки и добавить специфичность. Может "В Процессе" нужно сломать на "В Процессе" и "Ожидание Внешнего." Может вам нужна колонка названная "В Обзоре" потому что этот шаг продолжает быть потеряна. Позвольте доске развиваться в ответ на что ваша действительная работа раскрывает, не в ответ на что методология книга говорит это должно выглядеть.

Более длинная игра: метрики потока

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

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

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