Flow Efficiency: почему задача больше ждёт, чем делается
Flow Efficiency: почему задача больше ждёт, чем делается
Задача попала в работу в понедельник.
На прод уехала в следующую пятницу.
На календаре — 10 дней.
Выглядит так, будто команда 10 дней делала задачу. Но если разложить путь по этапам, картина обычно менее героическая:
- разработка заняла 1 день;
- ревью — 2 часа;
- тесты — полдня;
- остальное время задача просто ждала.
Ждала уточнений.
Ждала ревью.
Ждала тестирования.
Ждала согласования.
Ждала релиза.
Ждала, пока кто-нибудь вспомнит, что она вообще существует.
Вот это и показывает Flow Efficiency.
Простыми словами:
Flow Efficiency — это доля времени, когда задача реально двигалась, по сравнению со всем временем её жизни в процессе.
Есть active time: над задачей пишут код, ревьюят, тестируют, выкатывают.
Есть waiting time: задача лежит в очереди и ничего полезного с ней не происходит.
Формула без страданий:
Flow Efficiency = время активной работы / общее время прохождения задачи
Если задача ехала 10 дней, а реально над ней работали 2 дня, то проблема, скорее всего, не в том, что разработчики медленно печатают.
Проблема в ожиданиях между этапами.
Для тимлида это полезная метрика, потому что она показывает не «кто виноват», а где поток ломается:
- задачи копятся перед ревью;
- требования долго уточняются;
- тестирование становится бутылочным горлышком;
- согласования съедают сроки;
- у людей слишком много параллельной работы;
- WIP раздут, поэтому всё начато и почти ничего не закончено.
И это очень хороший разговор с бизнесом.
Потому что иногда запрос звучит так:
«Давайте разработчики будут быстрее писать код».
А Flow Efficiency показывает:
«Даже если код писать в два раза быстрее, общий срок почти не изменится, потому что задача большую часть времени ждёт ревью, тестов и согласований».
Это неприятно, зато честно.
Теперь важная часть из рубрики «метрики без насилия».
Flow Efficiency не надо использовать как палку.
Не надо:
- мерить каждого разработчика отдельно;
- требовать 100% эффективности;
- делать выводы по одной задаче;
- сравнивать баг, исследование и большую фичу как одинаковые сущности;
- превращать метрику в повод для охоты на виноватых.
100% Flow Efficiency — это не цель. Это почти фантазия.
У нормальной команды задачи иногда ждут. Вопрос не в том, чтобы убрать ожидание полностью. Вопрос в том, чтобы увидеть, где ожидание стало системой.
Что делать, если Flow Efficiency низкая:
- уменьшить WIP;
- договориться о правилах ревью;
- быстрее уточнять требования;
- назначить владельцев согласований;
- резать крупные задачи;
- автоматизировать ручные проверки;
- явно подсвечивать задачи без движения;
- улучшать один участок за раз, а не «чинить весь процесс» разом.
Главный вывод такой:
Низкая Flow Efficiency часто означает не то, что люди медленно работают.
Она означает, что система плохо пропускает задачи через себя.
Люди могут быть заняты весь день. Календарь может быть забит. Чаты могут кипеть. Но если задачи при этом лежат в очередях, поток всё равно медленный.
А если разложить ваши задачи по времени, где будет больше ожидания: требования, ревью, тесты, согласования или релиз?
Задача попала в работу в понедельник.
На прод уехала в следующую пятницу.
На календаре — 10 дней.
Выглядит так, будто команда 10 дней делала задачу. Но если разложить путь по этапам, картина обычно менее героическая:
- разработка заняла 1 день;
- ревью — 2 часа;
- тесты — полдня;
- остальное время задача просто ждала.
Ждала уточнений.
Ждала ревью.
Ждала тестирования.
Ждала согласования.
Ждала релиза.
Ждала, пока кто-нибудь вспомнит, что она вообще существует.
Вот это и показывает Flow Efficiency.
Простыми словами:
Flow Efficiency — это доля времени, когда задача реально двигалась, по сравнению со всем временем её жизни в процессе.
Есть active time: над задачей пишут код, ревьюят, тестируют, выкатывают.
Есть waiting time: задача лежит в очереди и ничего полезного с ней не происходит.
Формула без страданий:
Flow Efficiency = время активной работы / общее время прохождения задачи
Если задача ехала 10 дней, а реально над ней работали 2 дня, то проблема, скорее всего, не в том, что разработчики медленно печатают.
Проблема в ожиданиях между этапами.
Для тимлида это полезная метрика, потому что она показывает не «кто виноват», а где поток ломается:
- задачи копятся перед ревью;
- требования долго уточняются;
- тестирование становится бутылочным горлышком;
- согласования съедают сроки;
- у людей слишком много параллельной работы;
- WIP раздут, поэтому всё начато и почти ничего не закончено.
И это очень хороший разговор с бизнесом.
Потому что иногда запрос звучит так:
«Давайте разработчики будут быстрее писать код».
А Flow Efficiency показывает:
«Даже если код писать в два раза быстрее, общий срок почти не изменится, потому что задача большую часть времени ждёт ревью, тестов и согласований».
Это неприятно, зато честно.
Теперь важная часть из рубрики «метрики без насилия».
Flow Efficiency не надо использовать как палку.
Не надо:
- мерить каждого разработчика отдельно;
- требовать 100% эффективности;
- делать выводы по одной задаче;
- сравнивать баг, исследование и большую фичу как одинаковые сущности;
- превращать метрику в повод для охоты на виноватых.
100% Flow Efficiency — это не цель. Это почти фантазия.
У нормальной команды задачи иногда ждут. Вопрос не в том, чтобы убрать ожидание полностью. Вопрос в том, чтобы увидеть, где ожидание стало системой.
Что делать, если Flow Efficiency низкая:
- уменьшить WIP;
- договориться о правилах ревью;
- быстрее уточнять требования;
- назначить владельцев согласований;
- резать крупные задачи;
- автоматизировать ручные проверки;
- явно подсвечивать задачи без движения;
- улучшать один участок за раз, а не «чинить весь процесс» разом.
Главный вывод такой:
Низкая Flow Efficiency часто означает не то, что люди медленно работают.
Она означает, что система плохо пропускает задачи через себя.
Люди могут быть заняты весь день. Календарь может быть забит. Чаты могут кипеть. Но если задачи при этом лежат в очередях, поток всё равно медленный.
А если разложить ваши задачи по времени, где будет больше ожидания: требования, ревью, тесты, согласования или релиз?