Начнем с небольшого вступления для понимания контекста.
Если ваша компания успешно выполняет какую-нибудь интеллектуальную работу, например, разработку сайтов, у вас нет отбоя от заказчиков. Они, то и дело, предлагают выполнить еще какой-нибудь проект. Но вы не можете взяться за все, поскольку ваш рабочий ресурс ограничен и из-за этого входящей работы поступает больше, чем ваша организация может выдавать.
Из-за этого, чтобы обезопаситься от срыва дедлайнов, нужно отклонять часть запросов от заказчика. Думаем, не нужно объяснять, почему нельзя срывать дедлайны: от этого страдает ваша репутация и вы лишаете заказчика пользы, на которую он рассчитывает.
Контролировать поток входящих запросов помогает Канбан Метод. О производительности системы можно судить только оценочно, поэтому в Канбане есть несколько метрик. Две из них – Lead Time и Cycle Time. Отслеживание этих метрик позволяет спрогнозировать срок сдачи работ – эти данные можно передать заказчику, чтобы он также мог прогнозировать сроки выполнения своих задач.
Если бы Канбан Метод внедрили в «Дэйли Бьюгл»
Далее расскажем все об этих метриках.
Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.
👉 Читайте также: «Что такое управление рисками и почему это важно»
Lead Time и Cycle Time: в чем разница
Lead Time (время производства) – это время от принятия обязательств до сдачи готового результата заказчику. То есть, Lead Time начинается, когда вы говорите заказчику «Берем в работу», а не от момента, когда вы реально взяли задачу в работу. Также это не фактическое время, которое потребовалось на выполнение запроса, а все время, прошедшее со старта работ до сдачи работы заказчику.
То есть, в это время входят все перекуры, кофе-брейки, разговоры у кулера, паузы на согласование и так далее.
Cycle TIme (время цикла) – это время прохождения задачей каких-либо этапов на Канбан-доске: например, от этапа «В работе» до этапа «Готово». Здесь, как и в случае с Lead Time, учитывается все время, не только рабочее. Отслеживание Cycle Time позволяет выявить затруднения на каком-нибудь конкретном этапе Канбан-доски. Бывает, что какой-то этап длится слишком долго – имеет смысл его изучить, чтобы понять, почему так.
Примечание. Иногда Cycle TIme считают как время с фактического взятия запроса в работу до его сдачи заказчику, но это неправильная трактовка.
Схематичное отображение Lead Time, которое показал наш эксперт Алексей Пименов в своей видеолекции «Производственный процесс глазами Канбан-практика». Видно, что в Lead TIme включено как время фактической работы, так и время простоя запроса. Но здесь есть небольшой нюанс: на графике запрос сразу взят в работу, хотя в случае с Lead Time такое возможно только тогда, когда заказчик отправил запрос, а организация сразу согласилась его выполнить и начала по нему работать
👉 Читайте также: «Диаграмма сгорания (Burndown Chart): как управлять ходом разработки»
Как спрогнозировать Lead Time и Cycle 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 пика: в самом начале и ближе к концу
Итак, мы разобрали популярные примеры данных гистограмм и рассказали о возможных трактовках данных. Теперь поделимся тонкостями эффективного анализа метрик.
👉 Читайте также: «5 самых важных Agile-метрик и 11 второстепенных»
Как анализировать Lead Time и Cycle Time
Самое главное – нужно анализировать не обобщенные показатели, а частные, по различным срезам. Это могут быть срезы по разным производственным процессам, разным типам задач, разным сотрудникам, разным заказчикам и так далее.
Примерно так могут различаться данные по Lead Time и Cycle Time у разных производственных процессов
Сначала следует проанализировать Lead Time, а уже следом – начать смотреть Cycle Time у разных этапов производственного процесса. Часто бывает, что Lead TIme растягивается из-за какого-то одного долгого этапа: например, согласования руководителем. Выходит, чтобы это заметить, нужно сравнить между собой Cycle Time у разных этапов производственного процесса и обратить внимание, что запросы долго висят именно на согласовании.
Как оптимизировать показатели Lead Time и Cycle Time
Первое правило Канбанского клуба – не брать сразу в работу поступающие запросы. Ведь вы не сможете просрочить выполнение запроса, если вы его не взяли в работу, верно? Синк эбаут ит.
Вместо этого нужно предупреждать стейкхолдера о том, что вы приняли к сведению, что нужно выполнить такой-то запрос. Если он не идет с запросом к кому-то другому, вы держите его у себя до лучших времен. Такой беклог запросов в Канбане называется Upstream Backlog.
Еще один скриншот из видео Алексея Пименова, на который мы уже ссылались выше. Здесь видно, что Upstream Kanban заканчивается на Commitment Point – точке соглашения принятия запроса в работу. А Downstream Kanban – это этапы процесса от взятия запроса в работу до его выполнения
Далее вы можете приоритизировать задачи из беклога, чтобы брать в работу самые важные или ценные из них.
После этого, чтобы не брать в работу слишком много запросов, неплохо бы отслеживать еще одну метрику – пропускную способность. Если коротко, то это количество выполненных запросов за определенный временной период. Например, максимально вы можете выполнять 20 запросов в месяц – это будет вашей месячной пропускной способностью. И вот: если вы сейчас работаете над 13 запросами, вы понимаете, что можете взять в работу еще 7 запросов.
Что ж, вот вы и начали брать в работу посильное количество запросов, за счет чего улучшили свои показатели Lead Time и Cycle Time. Далее можно дополнительно оптимизировать метрики, отслеживая в ваших процессах этапы, которые отнимают слишком много времени. Отыскав их и поняв причину задержек, вы сможете сделать рабочий процесс еще более эффективным. Для этого используют еще ряд Канбан-инструментов, о которых мы рассказываем в других статьях: например, WIP-лимиты.
Ну а если вы не хотите во все это погружаться, но вам нужно оптимизировать рабочие процессы, обратитесь за бесплатной консультацией в Neogenda. Мы успешно внедряем в бизнес современные управленческие практики и помогаем достигать компаниям лучших результатов.
