Почему code review тормозит delivery сильнее, чем кажется
Разработчик говорит:
"Я задачу сделал".
В Jira задача почти готова.
Код написан.
PR открыт.
Осталось только ревью.
И вот это "только" иногда длится три дня.
Формально работа почти завершена.
Фактически ценность ещё не доставлена.
Потому что написанный код сам по себе ничего не меняет для пользователя. Он начинает иметь значение только после ревью, тестов, merge и релиза.
До этого момента это всё ещё незавершённая работа. Просто она лежит не в статусе "In Progress", а в более социально приемлемом месте: в pull request.
И вот тут у многих команд начинается болото.
PR висят по несколько дней.
Ревьюеры перегружены.
Непонятно, кто должен смотреть.
Комментарии превращаются в длинные философские ветки.
Автор ждёт. Контекст остывает. Задача вроде бы "почти готова", но delivery не двигается.
Причин обычно несколько:
- PR слишком большие;
- нет договорённости по SLA на ревью;
- ревьюеры заняты своей работой;
- ревьюеры назначаются неявно;
- в комментариях смешиваются must-fix и nice-to-have;
- автор PR плохо описывает контекст;
- нет общего чеклиста ревью;
- команда открывает больше PR, чем способна обработать.
Отдельно это становится заметно с AI.
AI помогает быстрее писать код.
Разработчик быстрее открывает PR.
PR может стать больше.
Количество изменений растёт.
Но ревьюеры не стали в два раза быстрее.
Архитектурный контекст не появился сам.
Ответственность за качество никуда не делась.
В итоге команда ускоряет производство изменений, но не ускоряет их принятие.
Скорость просто превращается в очередь.
И это важный момент для тимлида: смотреть надо не только на то, как быстро задачи переходят в "Review", а на то, сколько они там живут.
Я бы смотрел хотя бы на такие сигналы:
- сколько PR открыто прямо сейчас;
- сколько PR старше 1–2 дней;
- среднее время до первого комментария;
- среднее время до merge;
- размер PR;
- сколько раз PR возвращается на доработку;
- есть ли "вечные ревьюеры", через которых проходит почти всё.
Если всё упирается в ревью, ускорять написание кода почти бессмысленно.
Что можно сделать практически:
1. Договориться о SLA на первый взгляд ревью
Не "когда-нибудь посмотрю", а, например, первый ответ в течение рабочего дня.
2. Уменьшать размер PR
Большой PR почти всегда ревьюится хуже и дольше.
3. Назначать ревьюеров явно
Если никто конкретно не отвечает, PR легко становится ничьим.
4. Добавить нормальное описание контекста в шаблон PR
Что меняется, зачем, как проверено, где риск.
5. Разделять must-fix и nice-to-have
Не каждое замечание должно блокировать merge.
6. Спорные обсуждения выносить в голос
Если в PR уже 40 комментариев, это часто не ревью, а плохо организованная встреча.
7. Считать review time частью delivery
Не "задача почти готова", а "задача всё ещё в системе и не доставлена".
Code review нужен. Он защищает качество, знания и архитектуру.
Но если ревью стало бутылочным горлышком, команда начинает путать активность с поставкой. Код пишется, PR открываются, статусы двигаются, а ценность до пользователя доходит медленно.
Написанный код — это ещё не delivery.
Delivery начинается там, где изменение прошло через всю систему и оказалось в руках пользователя.
А у вас PR чаще зависают из-за нехватки ревьюеров, больших изменений или бесконечных обсуждений в комментариях?
Разработчик говорит:
"Я задачу сделал".
В Jira задача почти готова.
Код написан.
PR открыт.
Осталось только ревью.
И вот это "только" иногда длится три дня.
Формально работа почти завершена.
Фактически ценность ещё не доставлена.
Потому что написанный код сам по себе ничего не меняет для пользователя. Он начинает иметь значение только после ревью, тестов, merge и релиза.
До этого момента это всё ещё незавершённая работа. Просто она лежит не в статусе "In Progress", а в более социально приемлемом месте: в pull request.
И вот тут у многих команд начинается болото.
PR висят по несколько дней.
Ревьюеры перегружены.
Непонятно, кто должен смотреть.
Комментарии превращаются в длинные философские ветки.
Автор ждёт. Контекст остывает. Задача вроде бы "почти готова", но delivery не двигается.
Причин обычно несколько:
- PR слишком большие;
- нет договорённости по SLA на ревью;
- ревьюеры заняты своей работой;
- ревьюеры назначаются неявно;
- в комментариях смешиваются must-fix и nice-to-have;
- автор PR плохо описывает контекст;
- нет общего чеклиста ревью;
- команда открывает больше PR, чем способна обработать.
Отдельно это становится заметно с AI.
AI помогает быстрее писать код.
Разработчик быстрее открывает PR.
PR может стать больше.
Количество изменений растёт.
Но ревьюеры не стали в два раза быстрее.
Архитектурный контекст не появился сам.
Ответственность за качество никуда не делась.
В итоге команда ускоряет производство изменений, но не ускоряет их принятие.
Скорость просто превращается в очередь.
И это важный момент для тимлида: смотреть надо не только на то, как быстро задачи переходят в "Review", а на то, сколько они там живут.
Я бы смотрел хотя бы на такие сигналы:
- сколько PR открыто прямо сейчас;
- сколько PR старше 1–2 дней;
- среднее время до первого комментария;
- среднее время до merge;
- размер PR;
- сколько раз PR возвращается на доработку;
- есть ли "вечные ревьюеры", через которых проходит почти всё.
Если всё упирается в ревью, ускорять написание кода почти бессмысленно.
Что можно сделать практически:
1. Договориться о SLA на первый взгляд ревью
Не "когда-нибудь посмотрю", а, например, первый ответ в течение рабочего дня.
2. Уменьшать размер PR
Большой PR почти всегда ревьюится хуже и дольше.
3. Назначать ревьюеров явно
Если никто конкретно не отвечает, PR легко становится ничьим.
4. Добавить нормальное описание контекста в шаблон PR
Что меняется, зачем, как проверено, где риск.
5. Разделять must-fix и nice-to-have
Не каждое замечание должно блокировать merge.
6. Спорные обсуждения выносить в голос
Если в PR уже 40 комментариев, это часто не ревью, а плохо организованная встреча.
7. Считать review time частью delivery
Не "задача почти готова", а "задача всё ещё в системе и не доставлена".
Code review нужен. Он защищает качество, знания и архитектуру.
Но если ревью стало бутылочным горлышком, команда начинает путать активность с поставкой. Код пишется, PR открываются, статусы двигаются, а ценность до пользователя доходит медленно.
Написанный код — это ещё не delivery.
Delivery начинается там, где изменение прошло через всю систему и оказалось в руках пользователя.
А у вас PR чаще зависают из-за нехватки ревьюеров, больших изменений или бесконечных обсуждений в комментариях?
❤2
DACI: как перестать ходить по кругу и наконец принять решение
Есть задачи, которые не блокируются технически.
Их не стопорит код, инфраструктура или отсутствие людей.
Их стопорит отсутствие решения.
Например:
— выбрать вариант реализации;
— согласовать MVP-объём;
— решить: переносим релиз или режем scope;
— выбрать владельца спорной зоны;
— договориться, что важнее: быстро или красиво.
Вроде бы все участвуют.
Все хотят как лучше.
Все “за качество”.
Но решения нет.
Встречи повторяются.
Обсуждения возвращаются к тем же аргументам.
Каждый ждёт, что кто-то другой поставит точку.
В итоге задача стоит не потому, что команда не умеет работать.
А потому что непонятно, кто принимает решение.
Вот здесь полезен DACI.
Не как бюрократия, а как простой способ заранее разложить роли в решении.
D — Driver
Кто двигает процесс: собирает вводные, организует обсуждение, доводит до решения.
A — Approver
Кто принимает финальное решение.
C — Contributors
Кто даёт экспертизу, аргументы и ограничения.
I — Informed
Кого нужно держать в курсе, но не вовлекать в согласование.
Главная польза DACI — он отделяет обсуждение от принятия решения.
Потому что часто проблема не в том, что мало мнений.
Проблема в том, что слишком много людей пытаются быть Approver.
Если финальное решение принимают “все”, обычно его не принимает никто.
Например, команда спорит, как реализовать фичу.
Разработчики предлагают варианты.
QA говорит о рисках.
Аналитик уточняет требования.
Продакт держит в голове ценность для бизнеса.
Тимлид думает о сроках и техдолге.
Все важны.
Но не все должны ставить финальную точку.
DACI помогает заранее спросить:
Кто ведёт процесс?
Кто принимает решение?
Кто даёт вводные?
Кого просто информируем?
Это особенно полезно, когда:
— решение спорное;
— есть несколько сильных мнений;
— участвуют разные роли или команды;
— решение влияет на сроки, scope или архитектуру;
— обсуждение уже пошло по третьему кругу.
Частая ошибка — путать Driver и Approver.
Driver не обязан быть самым главным.
Он отвечает за движение процесса.
Approver не обязан собирать все детали сам.
Он отвечает за финальное “да/нет”.
Ещё одна ошибка — превращать Contributors в согласующих.
Contributor помогает принять решение, но не должен блокировать его бесконечно.
DACI не нужен для каждой мелкой задачи.
Но если обсуждение буксует, достаточно 10 минут, чтобы разложить роли:
Кто Driver?
Кто Approver?
Кто Contributors?
Кто Informed?
И часто сразу становится понятно, почему решение не принимается.
Не потому что люди плохо думают.
А потому что команда не договорилась, кто ставит точку.
А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?
Есть задачи, которые не блокируются технически.
Их не стопорит код, инфраструктура или отсутствие людей.
Их стопорит отсутствие решения.
Например:
— выбрать вариант реализации;
— согласовать MVP-объём;
— решить: переносим релиз или режем scope;
— выбрать владельца спорной зоны;
— договориться, что важнее: быстро или красиво.
Вроде бы все участвуют.
Все хотят как лучше.
Все “за качество”.
Но решения нет.
Встречи повторяются.
Обсуждения возвращаются к тем же аргументам.
Каждый ждёт, что кто-то другой поставит точку.
В итоге задача стоит не потому, что команда не умеет работать.
А потому что непонятно, кто принимает решение.
Вот здесь полезен DACI.
Не как бюрократия, а как простой способ заранее разложить роли в решении.
D — Driver
Кто двигает процесс: собирает вводные, организует обсуждение, доводит до решения.
A — Approver
Кто принимает финальное решение.
C — Contributors
Кто даёт экспертизу, аргументы и ограничения.
I — Informed
Кого нужно держать в курсе, но не вовлекать в согласование.
Главная польза DACI — он отделяет обсуждение от принятия решения.
Потому что часто проблема не в том, что мало мнений.
Проблема в том, что слишком много людей пытаются быть Approver.
Если финальное решение принимают “все”, обычно его не принимает никто.
Например, команда спорит, как реализовать фичу.
Разработчики предлагают варианты.
QA говорит о рисках.
Аналитик уточняет требования.
Продакт держит в голове ценность для бизнеса.
Тимлид думает о сроках и техдолге.
Все важны.
Но не все должны ставить финальную точку.
DACI помогает заранее спросить:
Кто ведёт процесс?
Кто принимает решение?
Кто даёт вводные?
Кого просто информируем?
Это особенно полезно, когда:
— решение спорное;
— есть несколько сильных мнений;
— участвуют разные роли или команды;
— решение влияет на сроки, scope или архитектуру;
— обсуждение уже пошло по третьему кругу.
Частая ошибка — путать Driver и Approver.
Driver не обязан быть самым главным.
Он отвечает за движение процесса.
Approver не обязан собирать все детали сам.
Он отвечает за финальное “да/нет”.
Ещё одна ошибка — превращать Contributors в согласующих.
Contributor помогает принять решение, но не должен блокировать его бесконечно.
DACI не нужен для каждой мелкой задачи.
Но если обсуждение буксует, достаточно 10 минут, чтобы разложить роли:
Кто Driver?
Кто Approver?
Кто Contributors?
Кто Informed?
И часто сразу становится понятно, почему решение не принимается.
Не потому что люди плохо думают.
А потому что команда не договорилась, кто ставит точку.
А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?
❤2👍1
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 часто означает не то, что люди медленно работают.
Она означает, что система плохо пропускает задачи через себя.
Люди могут быть заняты весь день. Календарь может быть забит. Чаты могут кипеть. Но если задачи при этом лежат в очередях, поток всё равно медленный.
А если разложить ваши задачи по времени, где будет больше ожидания: требования, ревью, тесты, согласования или релиз?
❤2