Начнем с небольшого вступления для понимания контекста.

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

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

Контролировать поток входящих запросов помогает Канбан Метод. О производительности системы можно судить только оценочно, поэтому в Канбане есть несколько метрик. Две из них – Lead Time (время производства) и Cycle Time (время цикла). Отслеживание этих метрик позволяет спрогнозировать срок сдачи работ – эти данные можно передать заказчику, чтобы он также мог прогнозировать сроки выполнения запросов.

Если бы Канбан Метод внедрили в «Дэйли Бьюгл»

Далее расскажем все об этих метриках.

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

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

Cycle TIme (время цикла) – это время прохождения задачей каких-либо этапов на Канбан-доске: например, от этапа «В работе» до этапа «Готово». Здесь, как и в случае с Lead Time, учитывается все время, не только рабочее. Отслеживание Cycle Time позволяет выявить затруднения на каком-нибудь конкретном этапе Канбан-доски. Бывает, что какой-то этап длится слишком долго – имеет смысл его изучить, чтобы понять, почему так.

Примечание. Иногда Cycle TIme считают как время с фактического взятия запроса в работу до его сдачи заказчику, но это неправильная трактовка.

Схематичное отображение Lead Time, которое показал наш эксперт Алексей Пименов в своей видеолекции «Производственный процесс глазами Канбан-практика». Видно, что в Lead TIme включено как время фактической работы, так и время простоя запроса. Но здесь есть небольшой нюанс: на графике запрос сразу взят в работу, хотя в случае с Lead Time такое возможно только тогда, когда заказчик отправил запрос, а организация сразу согласилась его выполнить и начала по нему работать

У разных запросов Lead Time и Cycle Time будет разным. На показатель будут влиять как особенности самих запросов, так и количество одновременно реализуемых запросов. Поэтому метрики анализируются не по каждому запросу в отдельности, а по диапазону значений. Чтобы отследить диапазон значений, данные по Lead Time и Cycle Time можно собрать в диаграмму распределения времени цикла.

Простой пример диаграммы распределения времени цикла с данными, выраженными за определенный временной период: например, месяц. На оси X указано количество дней, которые потребовались для выполнения задачи, а на оси Y указано количество выполненных задач. То есть, мы можем увидеть, что 8 задач были выполнены за 2 дня, 9 задач – за 3 дня и так далее.

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

Первое, что дает узнать диаграмма распределения времени цикла – это прогнозируемое время выполнения задачи. Представим, что в нашем примере на скриншоте мы замеряем Lead Time одного из рабочих процессов компании.

На примере мы видим, что большинство запросов были выполнены максимум за 7 рабочих дней. Но в графике есть аномалии – один запрос был выполнен за 11 дней, а другой – за 12.

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

Но можно дать прогноз и с вероятностью в 75 %, и в 50 %, отчего прогнозируемое время выполнения задач будет меньше. Ведь на диаграмме явно видно, что в 50 % случаев запрос точно будет выполнена раньше, чем за 7 дней. Такие вероятности, выраженные в процентах, называют перцентилями. Например, если мы строим прогноз срока выполнения запроса в 50 % случаев, мы вычисляем 50-й перцентиль.

Чаще всего для прогнозирования срока выполнения запроса используют 85-й перцентиль. Он достаточно большой, чтобы выдать прогноз с хорошей достоверностью. Но он не учитывает аномалии, когда что-то пошло не так и выполнение запроса задержалось. В нашем примере 85-й перцентиль будет где-то в районе 6 дней. Для более точного прогнозирования чаще всего вычисляют 98-й перцентиль.

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

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

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

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

На этой диаграмме видно, что время выполнения запросов распределено примерно равномерно

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

Здесь видно, что большинство запросов выполняется в первые пару дней – но хорошо ли это?

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

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

Тут видно 2 пика на распределении: в самом начале и ближе к концу

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

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

Примерно так могут различаться данные по Lead Time и Cycle Time у разных производственных процессов

Сначала следует проанализировать Lead Time, а уже следом – начать смотреть Cycle Time у разных этапов производственного процесса. Часто бывает, что Lead TIme растягивается из-за какого-то одного долгого этапа: например, согласования руководителем. Выходит, чтобы это заметить, нужно сравнить между собой Cycle Time у разных этапов производственного процесса и обратить внимание, что запросы долго висят именно на согласовании.

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

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