Майк Барроуз - Канбан Метод. Улучшение системы управления

• Название: Канбан Метод. Улучшение системы управления
• Автор: Майк Барроуз
• Жанр: Самосовершенствование
• Год: 2020
• ISBN: 978-5-9614-3833-8

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

---

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

Другие способы ограничить WIP

Я бы не хотел создавать впечатление, что WIP-лимиты на уровне столбцов – это единственный способ ограничения объема незавершенной работы. Он достаточно действенный, но иногда работает лучше в сочетании с другими механизмами. Их можно условно разделить на две основные категории:

1. Уменьшение размера пакетных транзакций – сокращение размера (в плане бюджета и продолжительности) проектов, интервалов между релизами, а также размеров спринтов, размера пакета разрабатываемого функционала и т. д.

2. Уменьшение количества событий, развивающихся параллельно, – сокращение количества бизнес-инициатив (к которым привязаны проекты), сокращение количества сопутствующих проектов в расчете на группу или отдел, сокращение количества рабочих элементов в расчете на группу или на человека и т. д.

Здесь в нашем распоряжении множество рычагов! Выберите правильный, и вы увидите, что другие поддаются легче как в техническом, так и в психологическом смысле. Ограничение объема незавершенной работы разными способами позволяет довести его до такого уровня, который когда-то мог казаться недостижимым.

Ситуация в Будапеште, с которой начинается глава 1, сложилась не сразу. Я пришел работать в организацию, которая просто «подсела» на WIP. Как это часто случается в молодых компаниях, им было просто очень трудно сказать «нет». Это относилось не только к взаимодействию с внешними заказчиками – не говорить «нет» превратилось в привычку и в отношениях между подразделениями компании. От одного совещания к другому списки необходимых дел (а таких списков было очень много) становились все длиннее и длиннее.

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

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

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

Баланс срочной работы и работы с привязкой к дате

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

Давайте подробно рассмотрим небольшую часть нашей доски, показанной на рис. 2.3.

Пусть вас не смущают непонятные названия трех рабочих элементов, сконцентрируйте внимание на различиях в их визуализации. Для начала возьмем две верхние задачи Tokyo gateway upgrade и Swap curve.

Рабочий элемент Tokyo gateway upgrade помечен карточкой с иконкой в виде календаря, т. е. это рабочий элемент с привязкой к дате. В данном примере речь идет о том, что интерфейс Токийской фондовой биржи должен измениться в определенный день, поэтому нам нужно к этому моменту обновить системы соответствующим образом. Если мы осуществим эти изменения слишком поздно, то не сможем торговать на данной площадке, и это может обойтись организации слишком дорого. Однако слишком ранняя поставка не принесет выгоды – более того, она может быть даже вредной.

Рабочий элемент Swap curve совсем другой. Он представляет совершенно независимую функциональность. Чем скорее он будет выполнен, тем раньше начнет приносить пользу. В отличие от предыдущего примера, этот рабочий элемент не привязан к дате, он является срочным.

Если мы сможем завершить выполнение срочного рабочего элемента раньше рабочего элемента, привязанного к определенной дате, то это прекрасно. Однако приоритет переходит к рабочему элементу с привязкой к дате, как только возникнет опасение, что он оказывается под угрозой. И в том и в другом случае мы получаем хорошие результаты[8].

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

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

Классификация на основе рисков и классы обслуживания

Рабочий элемент Try MongoDB (оставшийся в столбце) не кажется ни привязанным к дате, ни срочным. Но разве из-за этого он становится неважным? По этому рабочему элементу судить трудно, но где мы окажемся через год или два, если не будем экспериментировать и делать неафишируемую работу, ориентированную на перспективу и расширение наших возможностей в плане платформ, продуктов, процессов или людей?

Если смотреть только на график выполнения работы (без учета характера результатов или базовых рабочих процессов), то наши примеры укладываются в три качественно разные категории. Канбан Метод обычно определяет следующие четыре категории.

● Ускоренные (Expedite): рабочие элементы настолько срочные, что приходится откладывать выполнение других работ и немедленно переключаться на них.

● Привязанные к дате (с фиксированной датой) (Date-driven или Fixed Date): рабочие элементы, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки. Такие риски срыва графика тщательно контролируются.

● Стандартные (Standard), или регулярные[9] (Regular): срочные рабочие элементы, выполняемые в соответствии с порядком, согласованным с заказчиками, или в последовательности, соответствующей выбранным вами правилам. В зависимости от ситуации правила выполнения могут быть такими простыми, как «первым пришел – первым ушел» (first in, first out – FIFO), базироваться на такой экономической модели, как «стоимость задержки» (cost of delay) (глава 15), или просто на личном выборе.

● Нематериальные (Intangible): расширение возможностей, эксперименты в области технологий или на рынке, инвестиции в человеческие ресурсы – работа, результаты которой проявляются в среднесрочной или долгосрочной перспективе, но непосредственный бизнес-эффект трудно оценить количественно.

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