Предисловие переводчика

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

Статья автора Канбан метода Дэвида Андерсона раскрывает особенности того, как полноценные, клиенто-ориентированные канбан-системы работают с принятием обязательств и в чём их отличие от распространенных практик работы с бэклогом задач.

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

Встреча по пополнению – встреча, во время которой рабочие элементы перемещаются за точку принятия обязательств.

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

Подробнее с основами Канбан метода можно ознакомиться в книге Канбан: краткое руководство и на сайте kanbanguide.ru

Прото-пополнение

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


Работа по пополнению такой канбан системы довольно тривиальна. Она обычно происходит внутри системы и основывается на зависимостях технических, ресурсных, квалификационных либо координации поставки для облегчения потока.  Другими словами, пополнение в большей степени связано с «критериями готовности» (Definition of Ready, DoR) и отбором на основе готовности, а не с обязательствами, планированием и выстраиванием последовательности работы с точки зрения бизнес-рисков. Пул, из которого мы выбираем задачи называется бэклог и обязательства по выполнению задач из него уже зафиксированы. Уже достигнута договорённость с заказчиком, что элементы бэклога включены в границы проекта и должны быть выполнены.

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


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


Таким образом, эти встречи отличаются от описанных выше. Очевидно, что они представляют собой менее зрелую и более поверхностную реализацию Канбана. Вопрос в том, следует ли их обозначить как «прото-пополнение» или нам нужно другое, альтернативное, название? Прото-канбан – устоявшийся термин, обычно используемый для обозначения Канбан досок без ограничений объёма текущей работы (work in progress, WIP), хотя существуют и другие варианты. Этот термин был придуман Ричардом Тернером (Richard Turner) из Института Стивенса (Stevens Institute), потому что изучение конкретных примеров показало, что эти прото-канбан реализации часто созревают в полноценные Kanban системы. Следовательно, эти доски без ограничений WIP были эволюционными предшественниками Kanban, и префикс «прото» указывает на ожидание, что они являются семенем, из которого может развиваться нечто более зрелое.

Вопрос в том, целесообразно ли прото-пополнение или нет? Я считаю, что да. Обычно прото-канбан реализации сосредоточены на внутренних проблемах, и часто они находятся на I и II «полётном эшелоне» (flight levels), в терминологии, введённой  Клаусом Леопольдом. Что происходит когда канбан система спроектирована таким образом, чтобы смотреть вовне, задаваясь вопросом «кто наши клиенты» и «что они от нас просят»? Тогда мы обычно видим гораздо более глубокие реализации, включая ограничения WIP, вытягивание и классы обслуживания. Однако, переход от прото-пополнения к полноценному пополнению не произойдет без лидерства. Этот переход подчеркивает истинную суть реализации Канбан. Если вы смогли выйти за рамки прото-пополнения, то вы реализовали вытягивающую систему. Это нетривиальный шаг. И это тот нетривиальный шаг, который специалисты Kanban Coaching Professional (KCP) призваны помочь вам сделать.

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

За участие в переводе большая благодарность artnek