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

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

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

А теперь давайте вернемся к нашему примеру из прошлой статьи, где мы столкнулись с ограничением. Объем пропускной способности на этапе тестирования — 2 задачи в неделю.

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

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

В статье Канбан-доска — это не то, что вы думаете мы уже говорили о том, что Канбан-доска — это крайне полезный инструмент. Она показывает нам весь процесс от момента, когда идея только появилась и стала частью пула задач «Хотим сделать», и до стадии «Готово», когда пройдя все необходимые этапы, эта идея была реализована и начала приносить нам определенную пользу, например, с точки зрения увеличения продаж, дополнительных инвестиций и т.д. Другими словами, Канбан-доска — это своеобразный поток, который показывает процесс перехода задач между двумя состояниями: «Хотим сделать» и «Готово».

А что же, собственно, происходит между этими двумя этапами? Как мы можем охарактеризовать эти задачи?

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

Давайте представим, что мы решили реализовать какую-то идею и передали ее в работу аналитикам. Они начали ее делать, а что это значит с точки зрения затрат? Они тратят на нее свое время, которое стоит определенных денег, и получается, что мы уже на первом этапе инвестировали деньги в эту задачу. Смотрим дальше: аналитики передали задачу разработчикам, далее ее забрали в работу тестировщики, и наконец она добралась до этапа приемки. И пока задача перемещалась из колонки «Хотим сделать» до «Готово» на каждом этапе мы инвестировали в нее деньги и только, когда она перешла в состояние «Готово», начался постепенный возврат инвестиций. Еще раз подчеркну очень важную мысль: любая незавершенная работа — это уже потраченные на более ранних этапах деньги на ее реализацию.

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

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

Вернемся к кейсу из начала статьи, когда на этапе тестирования мы обнаружили ограничение, максимальная производительность этого этапа — 2 задачи в неделю. Это означает, что все предыдущие этапы тоже вынуждены работать с аналогичной производительностью, так как протолкнуть большее количество задач дальше по процессу они просто не могут. В противном случае все дополнительные задачи, превышающие ограничение, скорее всего «сгорят»: сперва до них не доберется рука специалиста на следующем этапе, потом они будут долго висеть на доске, в ожидании когда о них вспомнит менеджер, и очень может быть, что о части из них, скорее всего, забудут, и где-то года через 3 бесцельного нахождения на доске их просто выбросят со словами «а это я вообще не помню, что такое».

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

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

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

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

А затем случается то, что мы видим на картинке ниже.

На этой картинке прекрасно всё. И грузовик с надписью «You can do it», как метафора веры заказчика в то, что никаких ограничений нет. И большая надпись на мосту «Low bridge», которую водитель проигнорировал.

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

Чтобы заказчик понял предельные возможности рабочей системы, нужно сделать их явными. Для этого на Канбан-доске в конкретной колонке с узким местом ставится явное ограничение, которое называется WIP-лимит. Work In Progress Limit — ограничение одновременно выполняемой работы на конкретном этапе.

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

Таким же образом WIP-лимиты можно расставить и на других этапах в соответствии с пропускной способностью.

А теперь самый интересный вопрос: к чему это приводит и какой результат мы в итоге получаем?

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

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

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek