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

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

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

Эта теорема – часть теории массового обслуживания, названная в честь Джона Литтла, который впервые предложил ее в 1950-х годах и считается «отцом маркетинга». И хотя греческая буква L означает закон Литтла, не нужно быть математиком, чтобы использовать эту формулу:

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

Верно также и обратное:

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

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

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

Продолжительное время выполнения нового заказа – хороший индикатор качества проблем: Дэвид Андерсон в уже упоминавшейся книге «Канбан. Альтернативный путь в Agile» так говорит об этом:

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

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

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

Это может показаться немного абстрактным. Полезно представить, как применялась бы CFD в случае наиболее знакомой и простой системы – медицинского центра. Допустим, вам нужно несколько раз посетить врача, чтобы сдать ряд анализов и обсудить результаты. Вы заметили следующее: если встреча с доктором назначена на утро, когда прием только начинается, то вам не приходится долго ждать. Но если визит предполагается в более позднее время, то ожидание затягивается – и чем позднее время встречи, тем дольше вы ждете приема. Очевидно, что эта система нестабильна. Как использовать CFD для ее стабилизации?

Прежде всего нужно визуализировать рабочий процесс.

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

Рис. 9.11. Канбан-доска для медицинского центра. Первый столбец показывает пациентов, которые находятся в приемном покое, второй – пациентов в процедурных и третий столбец – тех, кто находится у врача. Есть пять процедурных и два врачебных кабинета – это естественный WIP-лимит, поэтому визуализируем его на доске

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

Давайте выясним. Начнем с построения CFD для типичного дня. Попросим персонал центра посчитать количество пациентов, входящих в медицинский центр каждые 15 минут. Это покажет скорость прибытия – в буквальном смысле количество прибывших в центр пациентов. И мы можем рассчитать список для каждого 15-минутного интервала путем подсчета общего количества пациентов в приемном покое и пяти процедурных кабинетах. Каждый раз, когда кто-то приходит, добавляется стикер в первую колонку на канбан-доске. Когда пациент переходит из приемного покоя в процедурную, стикер перемещают во вторую колонку. А если пациент уже зашел к врачу, то стикер сдвигается в третью колонку. После того как врач закончил работу с пациентом, стикер удаляют с доски. Сотрудники центра могут записать количество стикеров в колонках для каждого 15-минутного интервала.