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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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