Дэвид Андерсон - Канбан. Альтернативный путь в Agile

Необходимость в ускорении можно сократить. Увеличение резервной мощности благодаря усовершенствованию пропускной способности, автоматизации или увеличению ресурсов повысит способность к реагированию. Более короткое время выполнения, высокая прозрачность и организационная зрелость – все это снизит необходимость в ускорении. Хорошие команды, усвоившие Канбан-подход, обычно не злоупотребляют ускоренными запросами. Например, в Corbis за весь 2007 год их было всего пять.

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

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

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

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

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

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

Первый восстанавливает поток за счет времени выполнения и даже качества. Вы можете восстановить поток, увеличив общий WIP-лимит – либо установив буфер напрямую, либо задав менее жесткие правила ограничения незавершенных задач: например, 3, а не 1,2 элемента в среднем на человека. Больший WIP-лимит подразумевает, что, пока одна задача блокирована, члены команды могут работать над остальными. Такой подход рекомендуется недостаточно зрелым организациям. Эффект от него прост и лишен драматизма. Время выполнения будет больше, но во многих отраслях это не составляет проблемы. Сильнее может оказаться и разброс вариативности, так что время выполнения окажется менее предсказуемым. Однако благодаря использованию канбан-системы оно все равно будет более предсказуемым, чем раньше. Главный недостаток использования б о льших WIP-лимитов в том, что так почти (или совсем) не создается внутренней напряженности, которая вызвала бы обсуждения и внедрение улучшений. Нет стимула к совершенствованию, эффект канбана как катализатора утрачивается.

Второй подход связан с неукоснительным проведением политики управления проблемами и их разрешения и, по достижении зрелости команды, с переходом к анализу и устранению первопричин, а также внесению улучшений, направленных на предотвращение вариаций с выявляемыми причинами в будущем. При таком подходе WIP-лимиты, размеры буфера и действующие правила остаются достаточно жесткими, и если задача блокируется, то это останавливает всю работу. Простой сотрудников, назначенных на блокированную задачу, повышает ответственность за блокирующую проблему. После этого может начаться массовая атака на проблему, что, как было установлено, стимулирует простаивающих членов команды думать о первопричинах и возможных изменениях в процессе, которые смогут сократить или исключить возможность новой подобной проблемы. Как показывает практика, сохранение жестких WIP-лимитов и проведение мероприятий по управлению проблемами и их разрешению позволяет создать культуру непрерывного совершенствования. Впервые я столкнулся с этим в Corbis в 2007 году, но есть и другие данные, полученные в 2009 году в таких компаниях, как Software Engineering Professionals (Индианаполис), IPC Media и BBC Worldwide (обе из Лондона). Сейчас уже достаточно информации, позволяющей предположить, что Канбан действительно способствует появлению культуры, сосредоточенной на непрерывном совершенствовании. Среди постоянно появляющихся элементов процесса, которые можно привести в пример, – готовность устанавливать жесткие правила WIP, маркировать работу как заблокированную, позволять потоку останавливаться, вызывая простой, и заниматься управлением проблемами и их решением в качестве устоявшейся организационной практики. Результат – сосредоточение на анализе и устранении первопричин и постепенное внедрение усовершенствований, которые снижают вариации с выявляемыми причинами и помогают распространению культуры непрерывного совершенствования.