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

Канбан помог решить основную проблему. Команда использовала метод пяти «почему», чтобы найти причину удлинения времени выполнения задач, и ввела WIP-лимиты для исправления ошибки.

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

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

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

Допустим, они договорились и ввели лимит на выполнение незавершенных работ. Менеджеры продолжат добавлять новые функции до тех пор, пока этот WIP-лимит не будет исчерпан. Но как только первый менеджер достигает лимита, он больше не может просто так добавить новый стикер на доску, для этого придется удалить какой-то другой. Если он не хочет удалять один из своих стикеров, нужно будет договариваться с другими менеджерами.

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

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

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

Ключевые моменты

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

Канбан-практика измерения и управления потоком подразумевает измерение потока и корректировку процесса для его максимизации.

Кумулятивная диаграмма потока (CFD) показывает лимит на выполнение незавершенных работ (WIP-лимит), число рабочих элементов, добавляемых ежедневно (скорость поступления), общее количество рабочих элементов в рабочем процессе (список) и среднее время нахождения рабочих элементов в системе (время на выполнение заказа).

Когда скорость поступления и список со временем не меняются, система стабильна, канбан-команды устанавливают WIP-лимит для ее стабилизации.

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

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

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

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

Часто задаваемые вопросы

Вы говорите о WIP-лимитах и явной стратегии как об инструментах, способных изменить работу команды. Но этот аргумент кажется надуманным. Или это все-таки правда?

Удивительно, но это правда. Чтобы понять почему, вернемся к истокам Lean и Канбана.

WIP-лимиты – простой, но эффективный инструмент для сглаживания потока, и его эффективность известна уже давно. Канбан базируется на сигнальной системе для создания вытягивающей производственной системы, которая возникла в компании Toyota в 1950-е годы (как и многие идеи и инструменты Lean). Название «канбан» происходит от японского слова, которое означает «сигнальная карточка» (буквально «вывеска» или «рекламный щит»); для обозначения сигнальной карточки принято писать слово «канбан» с маленькой буквы. На станции сборочной линии завода-изготовителя использовалось определенное количество канбан-карточек, на которых печатался номер каждой детали или ее название, требующейся на сборочной линии.