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

Мы находимся на одном из верхних этажей нашего сверкающего нового офиса, выходящего на вокзал Ньюгати в Будапеште. На часах 9:30, и традиционный стендап митинг в полном разгаре. Все оживлены больше обычного в предвкушении похода через дорогу за кофе и пирожными, чтобы отпраздновать наш последний этап «обучения». Я угощаю – накануне я оставил текущую сборку программы на несколько часов без внимания, а ИТ-директор не должен так поступать.

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

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

Любой может видеть наш рабочий процесс на большой доске. К ней прикреплены карточки, каждая из которых представляет рабочий элемент. Карточки располагаются в столбцах, которые обозначают этапы выполнения работы («Выполнено» – это один из этапов) или стадию нашего глобального производственного процесса.

Мы понимаем важность регулярной обратной связи и проводим стендап митинги.

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

Описанные события происходили в 2009–2010 гг., когда Дэвид Андерсон собирал отзывы о только что сформулированных им фундаментальных принципах и основных практиках Канбан Метода. Мы – это люди вроде меня, которые уже применяли эти идеи, – обсуждали и уточняли их в нашем групповом мейл-листе. Через несколько недель наши отклики вошли в «синюю книгу» Дэвида[2]. У нас появился документально зафиксированный метод!

Прозрачность – главная ценность канбана. С нею связаны три из шести основных практик:

ОП1: визуализируйте;

ОП4: сделайте правила работы явными;

ОП5: используйте циклы обратной связи.

Рассмотрим их по порядку.

Основная практика 1: визуализируйте

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

Если бы мы использовали электронную доску, то она, возможно, выглядела бы, как показано на рис. 1.1.

Вместо стикеров на доске используются иконки, которые можно перемещать по экрану. Независимо от вида доски (электронная или физическая) стикеры или иконки называются японским словом «канбан», что можно перевести как «визуальный символ». Мы предпочитаем оперировать более привычными терминами карточка (или тикет – я использую эти два термина взаимозаменяемо) и рабочий элемент, причем под первым понимается визуальное представление, а под вторым – содержание.

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

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

Если размер доски достаточен, а сами карточки яркие, то можно видеть ситуацию даже из противоположного конца комнаты:

● какая работа блокирована (в ожидании чего-либо);

● кто над чем работает;

● какие виды работ выполняются и в каком соотношении;

● какой объем работы имеется на каждом этапе выполнения.

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

Визуализация и изменения

В канбане цель визуализации и других форм прозрачности двояка – показать необходимость действия и помочь сделать правильный выбор. Это работает на двух уровнях:

● действие в форме работы, которую необходимо выполнить; правильный выбор рабочего элемента, которому нужно внимание;

● действие в форме изменений в системе; правильный выбор при обосновании изменения, определении его масштабов и внедрении.

Как вы будете реагировать, когда доска показывает, что не все идет как надо? Ниже перечислены несколько вариантов ответов, типичных для руководителя или наставника:

1. Не стоит волноваться, все обойдется, как обычно.

2. Я, как руководитель, приму меры и буду следить за ситуацией, пока все не уладится.

3. Я внесу изменения в систему.

4. Они понимают, что привело к такому развитию ситуации? Они хотят внести изменения в систему? Как мне им помочь?

5. Я уважаю их способности вносить необходимые изменения в такой ситуации.

Каждый из этих ответов может быть верным в конкретной ситуации, но некоторые кажутся более зрелыми по сравнению с остальными. Подталкивая к действию и поддерживая правильный выбор, канбан побуждает к более зрелой реакции (ответы 4 и 5). Любая организация, сознательно следующая этим установкам и использующая стиль лидерства, стимулирующий их применение, уверенно движется к совершенству.

Ответ 5 (и, в меньшей степени, ответ 4) ориентирован на еще один очень интересный аспект – на самоорганизацию.

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

Изменения системы при визуальном управлении осуществляются быстро и недорого. Сотрите на доске одну-две линии, проведите другую и передвиньте несколько карточек (или несколько раз кликните мышкой). С учетом того, что влияние изменений может быть огромно по сравнению с затраченными усилиями, такая работа с системой открывает большие возможности.

Здесь включается механизм самоусиления:

● канбан-система организует работу;

● люди организуются вокруг работы;

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

Основная практика 4: сделайте правила работы явными

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

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

Многие правила описывают качества, которыми должны обладать рабочие элементы, входящие или покидающие столбец, например:

● Рабочие элементы в колонке «Готово» не должны задерживаться более пяти дней. В Будапеште мы называли это «правилом пяти дней», которое позже превратилось в «правило двух дней».

● Рабочие элементы не могут перемещаться в столбец «Тест» до тех пор, пока они не пройдут ревью и не будут продемонстрированы всей команде.

Наклейки на доске или рядом с ней типа «<5 дней на разработку», «Разбор программы» или «Демо!» превосходно напоминают о том, чего ждет команда в ближайшем будущем.

Правила могут иметь и более общий характер:

● Стабильность продукта имеет больший приоритет, чем устранение ошибок при тестировании; при этом и первое, и второе имеют более высокий приоритет перед новой разработкой.

● Принимаясь за новый проект, проинформируйте заинтересованных лиц, если они могут повлиять на выполнение имеющихся работ.

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

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

● Более крупные рабочие элементы обычно вызывают больше трудностей по сравнению с мелкими. (Это может быть больше, чем предположение – у нас, возможно, есть факты, подтверждающие данную гипотезу.)

● В целом лучше закончить что-либо, чем начинать дополнительную работу. (К этому можно отнестись как к житейской мудрости – «Перестаньте начинать, начните заканчивать!» – или как к проверенной временем теории.)

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

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

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

Основная практика 5: используйте циклы обратной связи

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

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

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

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

Стендап митинги могут иметь разные формы:

● неформальные, неструктурированные, без определенной повестки совещания (это трудно рекомендовать);

● опрос, который проводит руководитель (когда менеджер проекта заслушивает отчет подчиненных);

● совещания в офисе, возможно в скрам-формате, когда все по очереди отвечают на вопросы: Что я делал вчера? Что я планирую делать сегодня? Какие препятствия мешают мне работать?[3];

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

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

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

Конечно, регулярные стендап митинги являются важным фактором создания сплоченной команды. Члены команды получают огромную пользу от них, причем не только в результате информирования о том, как идут дела, но и потому, что регулярные отчеты помогают получить представление о работе коллег. По мере формирования атмосферы доверия и углубления понимания потребностей коллектива общение становится более откровенным и продуктивным. Одним словом, эти 15 минут тратятся не зря.

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

Вы тоже проводите похожие совещания? Тогда, следуя правилу делать неявное явным, задайте себе вопрос: почему вы проводите их в таком формате? Удается ли вам полностью реализовать свои намерения? Помогают ли совещания решать проблемы посредством самоорганизации коллектива или нет?

Совещания по пополнению – еще одна широко распространенная практика[4]. Это форум, на котором входная очередь рабочего процесса (или, если хотите, его бэклог) пополняется новой работой. Кроме того, это прекрасная возможность оценить удовлетворенность заказчика, изучить его потребности и сопоставить их с возможностями команды. Такое совещание является важным циклом обратной связи, потому что дает возможность получить оценку со стороны.

Я не буду сосредотачиваться на механике совещаний по пополнению по двум причинам:

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

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

Некоторые совещания являются внешними по отношению к рабочему процессу, поскольку их функция заключается в управлении изменениями. Популярная аджайл-практика, которая иногда используется совместно с Канбан Методом, предусматривает регулярные ретроспективные собрания на уровне команды. Есть варианты, когда для проведения изменений делают оперативные совещания «на месте». Мы же настоятельно рекомендуем проводить еженедельно или раз в две недели обзор сервиса (service delivery reviews) на уровне команды или подразделения (иногда такие совещания называют обзором возможностей системы – system capability reviews) и ежемесячные операционные обзоры (operations reviews) на уровне филиала. На таких совещаниях команды делятся друг с другом и (в идеале) с представителями заказчика и организации в целом информацией о своей производительности, инцидентах и произведенных усовершенствованиях.

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

График на рис. 1.2 – это моя накопительная диаграмма потока (cumulative flow diagram – CFD). Я сделал ее следующим образом:

1. Раз в несколько дней я подсчитывал, сколько карточек находится в каждом столбце доски.

2. Определял общее количество законченных рабочих элементов, чьи карточки были сняты с доски (по этой причине график называется накопительным).

3. Визуализировал эти значения с помощью диаграммы с областями и накоплением в Excel, выстраивая их таким образом, чтобы завершенная работа оказывалась внизу.

В наши дни вы можете получить такую диаграмму бесплатно в онлайн-пространстве с помощью вашего любимого канбан-инструмента.

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

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

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

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

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

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

Основная практика 2: ограничивайте объем незавершенной работы

Баланс – это ценность, тесно связанная со второй основной практикой канбана:

ОП2: ограничивайте объем незавершенной работы (WIP – work-in-progress).

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

Вытягивающие системы для интеллектуальной работы

Рассмотрим столбец «Тест» на доске (рис. 2.1).

В правом верхнем углу столбца «Тест» стоит цифра 4. Она обозначает WIP-лимит, т. е. максимально допустимое в этой зоне количество рабочих элементов. В приведенном примере общее количество рабочих элементов в столбце «Тест» (включая два его подстолбца «В работе» (In Progress) и «Выполнено» (Done)) не должно превышать четырех. Наше приложение выделяет лимит, потому что эта часть доски в данный момент максимально загружена.

Теперь посмотрим, что происходит на рис. 2.2, когда карточки перемещаются вправо, причем как внутри, так и (что важно) за пределы выделенной зоны.

Зона «Тест» на доске теперь не заполнена целиком. Пространство в подстолбце «В работе», оставшееся пустым, играет очень важную роль – оно сигнализирует, что можно вытянуть туда карточку из соседнего (левого) столбца.

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

Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски).

Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика – времени выполнения заказа с точки зрения клиента[5].

Баланс Загрузки и Возможностей

Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей.

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

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

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

Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно – он даже может уменьшиться сам собой[6]. Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota[7].

Противоположностью этого механизма я считаю порочный круг, который возникает, когда главной заботой становится постоянная занятость людей. В этом случае первая реакция на застопорившуюся работу заключается не в решении проблемы, а в начале выполнения еще одной рабочей задачи, что приводит к увеличению объема 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): расширение возможностей, эксперименты в области технологий или на рынке, инвестиции в человеческие ресурсы – работа, результаты которой проявляются в среднесрочной или долгосрочной перспективе, но непосредственный бизнес-эффект трудно оценить количественно.

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

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

Баланс нагрузки и возможностей

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

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

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

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

Баланс среди Заинтересованных Лиц

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

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

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

Поиск баланса