Почему code review тормозит delivery сильнее, чем кажется
Почему 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 чаще зависают из-за нехватки ревьюеров, больших изменений или бесконечных обсуждений в комментариях?