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

Большинство команд переходят на канбан, потому что кто-то прочитал статью в блоге. Разумнее спросить другое: совпадают ли проблемы, которые решает канбан, с проблемами вашей команды.

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

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

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

Откуда на самом деле пришёл канбан

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

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

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

Что на самом деле показывает канбан-доска

В базовой канбан-доске три колонки: «К выполнению», «В работе» и «Готово». Для многих небольших команд этого достаточно, и это хорошая отправная точка. Но настоящая ценность появляется, когда вы начинаете подстраивать эти этапы под то, как работа течёт на самом деле, а не под то, как вам хотелось бы.

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

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

Правило, благодаря которому это работает: лимиты WIP

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

Это кажется нелогичным. Разве возможность взять в работу больше задач не означает, что будет сделано больше? Нет. На деле, когда люди одновременно занимаются слишком многим, всё занимает больше времени. Переключение контекста обходится дорого. Наполовину сделанная работа создаёт дополнительные издержки на координацию. А когда «в работе» десять задач, очень трудно понять, какие из них действительно движутся, а какие просто застряли без пометки.

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

Канбан и Scrum: вопрос, который команды задают всегда

Если вы хоть немного соприкасались с командами разработки ПО или современным операционным менеджментом, вы наверняка встречали Scrum — фреймворк, организующий работу в фиксированные двухнедельные спринты с сессиями планирования, ретроспективами и чётко определёнными ролями, такими как Scrum Master и Product Owner. Многие команды считают Scrum и канбан конкурирующими методологиями и думают, что нужно выбирать. На самом деле всё проще.

Многим командам, особенно не чисто программистским, церемонии Scrum кажутся громоздкими, а структура с фиксированными спринтами неудобна для текущей операционной работы. У команд маркетинга, клиентского сервиса (customer success), операционных команд и основателей, которые ведут всё сразу, редко бывает работа, аккуратно укладывающаяся в двухнедельные циклы. Модель непрерывного потока в канбане обычно подходит им лучше.

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

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

Канбан-доска полезнее всего тогда, когда, взглянув на неё и ни с кем не разговаривая, вы можете быстро ответить на три вопроса. Чем команда занята прямо сейчас? Где работа застревает? Есть ли что-то, что нужно сделать, но ещё не начато?

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

Чтобы поддерживать доску, нужна настоящая дисциплина. Задачи должны двигаться, когда движется работа. О блокировках нужно сообщать в момент остановки, а не две недели спустя. У карточек должны быть чёткие ответственные, а ответственные должны обновлять свои карточки. Всё это не требует много времени — при хорошо налаженной практике канбана хватает пяти–десяти минут в день на человека, — но требует постоянства. Больше всего от канбана выигрывают команды, которые считают доску единственным источником истины, а не вспомогательным учётом «для галочки».

Чего канбан не делает

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

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

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

Как начать — без трёхдневного воркшопа

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

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

Через две недели вместе посмотрите на доску. Где всё накапливалось? Что осталось в бэклоге из того, что все называли приоритетом? Что двигалось быстрее, чем ожидалось? Что застряло и почему? Используйте то, что вы увидели, чтобы уточнить колонки и добавить конкретики. Возможно, «В работе» нужно разделить на «В работе» и «Ожидание внешних сторон». Возможно, вам нужна колонка «На проверке», потому что этот шаг постоянно теряется. Пусть доска развивается в ответ на то, что показывает ваша реальная работа, а не на то, как она должна выглядеть по учебнику.

Взгляд на перспективу: метрики потока

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

Cycle time измеряет только время активной работы, не включая время, которое задача провела в бэклоге. Throughput (пропускная способность) показывает, сколько задач ваша команда завершает за неделю. Для этих метрик не нужно специальное ПО, если вы аккуратно фиксируете, когда карточки создаются и когда закрываются. А вместе они дают гораздо более честную картину возможностей вашей команды, чем любое планирование на основе оценок.

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