RACI: как понять, кто за что отвечает, пока всё не развалилось
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?
🔥2
AI-трансформация — это не про “все начали пользоваться агентами”
Прочитал статью AI Transformation Journey: 3 Myths and Learnings по докладу Vinay Perneti из Augment Code.
Главная мысль простая:
если команда просто начала использовать AI-агентов, это ещё не значит, что она стала AI-native.
Потому что AI не встраивается в команду магическим образом.
Он не чинит процессы.
Он не убирает очереди.
Он не делает требования понятнее.
Он не ускоряет ревью, если ревью и так было бутылочным горлышком.
Он просто усиливает то, что уже есть.
Если в команде нормальная постановка задач, быстрые проверки, понятные границы ответственности и хорошая инженерная культура — AI может дать сильный эффект.
Если в команде хаос, мутные требования, вечные согласования и пять задач “почти готово” на каждого разработчика — AI поможет быстрее производить ещё больше незавершённой работы.
И это, конечно, прогресс. Просто в сторону более дорогого хаоса.
В статье хорошо разбираются три мифа.
Миф 1. AI-native — это когда все используют агентов
Нет. Использовать ChatGPT как более умный Stack Overflow и уметь оркестрировать несколько агентов вокруг задачи — это разные уровни зрелости.
Команде нужны новые рабочие привычки:
писать более качественные спеки, заранее думать о проверке результата, понимать, где человек должен принимать решение, а где можно отдать работу агенту.
Миф 2. AI-трансформацию можно спустить сверху
Можно сказать: “Теперь все используем AI”.
Можно даже добавить это в OKR, потому что иначе, видимо, цивилизация рухнет.
Но настоящая трансформация не случается приказом.
Команда должна сама найти, где AI реально помогает, где мешает, какие новые проблемы появляются и какие правила работы нужно менять.
Сверху можно дать пространство, инструменты и ожидания.
Но рабочие практики рождаются снизу, там, где люди каждый день сталкиваются с реальными задачами.
Миф 3. Это чисто техническая проблема
Нет. Это ещё и человеческая проблема.
Люди не просто “осваивают инструмент”.
Они пересобирают свою профессиональную идентичность.
Если разработчик 10 лет строил ощущение ценности вокруг умения писать код, а теперь слышит “код будет писать агент”, у него не всегда первая реакция:
“О, чудесно, наконец-то больше времени на архитектуру”.
Иногда первая реакция:
“А я тогда кто?”
И это нельзя игнорировать.
Для тимлида здесь важный вывод: AI-трансформация — это не закупка подписок и не рассылка “гайда по промптам”.
Это изменение системы:
— где теперь бутылочное горлышко;
— как мы ставим задачи;
— как проверяем результат;
— как ревьюим код;
— как не превращаем скорость генерации в склад незавершёнки;
— где человек создаёт максимальную ценность.
Мне особенно понравилась мысль из статьи: когда AI ускоряет написание кода, bottleneck просто переезжает в другое место.
Раньше команда могла упираться в реализацию.
Теперь она может упереться в постановку задач, ревью, тестирование, принятие решений или деплой.
И если не смотреть на систему целиком, можно радостно ускорить один участок и получить пробку на следующем.
AI не отменяет инженерный менеджмент.
Он делает его важнее.
Потому что чем быстрее команда может производить изменения, тем дороже становится плохой фокус, слабая постановка задач и медленная обратная связь.
Оригинальная статья:
https://newsletter.eng-leadership.com/p/ai-transformation-journey-3-myths
Прочитал статью AI Transformation Journey: 3 Myths and Learnings по докладу Vinay Perneti из Augment Code.
Главная мысль простая:
если команда просто начала использовать AI-агентов, это ещё не значит, что она стала AI-native.
Потому что AI не встраивается в команду магическим образом.
Он не чинит процессы.
Он не убирает очереди.
Он не делает требования понятнее.
Он не ускоряет ревью, если ревью и так было бутылочным горлышком.
Он просто усиливает то, что уже есть.
Если в команде нормальная постановка задач, быстрые проверки, понятные границы ответственности и хорошая инженерная культура — AI может дать сильный эффект.
Если в команде хаос, мутные требования, вечные согласования и пять задач “почти готово” на каждого разработчика — AI поможет быстрее производить ещё больше незавершённой работы.
И это, конечно, прогресс. Просто в сторону более дорогого хаоса.
В статье хорошо разбираются три мифа.
Миф 1. AI-native — это когда все используют агентов
Нет. Использовать ChatGPT как более умный Stack Overflow и уметь оркестрировать несколько агентов вокруг задачи — это разные уровни зрелости.
Команде нужны новые рабочие привычки:
писать более качественные спеки, заранее думать о проверке результата, понимать, где человек должен принимать решение, а где можно отдать работу агенту.
Миф 2. AI-трансформацию можно спустить сверху
Можно сказать: “Теперь все используем AI”.
Можно даже добавить это в OKR, потому что иначе, видимо, цивилизация рухнет.
Но настоящая трансформация не случается приказом.
Команда должна сама найти, где AI реально помогает, где мешает, какие новые проблемы появляются и какие правила работы нужно менять.
Сверху можно дать пространство, инструменты и ожидания.
Но рабочие практики рождаются снизу, там, где люди каждый день сталкиваются с реальными задачами.
Миф 3. Это чисто техническая проблема
Нет. Это ещё и человеческая проблема.
Люди не просто “осваивают инструмент”.
Они пересобирают свою профессиональную идентичность.
Если разработчик 10 лет строил ощущение ценности вокруг умения писать код, а теперь слышит “код будет писать агент”, у него не всегда первая реакция:
“О, чудесно, наконец-то больше времени на архитектуру”.
Иногда первая реакция:
“А я тогда кто?”
И это нельзя игнорировать.
Для тимлида здесь важный вывод: AI-трансформация — это не закупка подписок и не рассылка “гайда по промптам”.
Это изменение системы:
— где теперь бутылочное горлышко;
— как мы ставим задачи;
— как проверяем результат;
— как ревьюим код;
— как не превращаем скорость генерации в склад незавершёнки;
— где человек создаёт максимальную ценность.
Мне особенно понравилась мысль из статьи: когда AI ускоряет написание кода, bottleneck просто переезжает в другое место.
Раньше команда могла упираться в реализацию.
Теперь она может упереться в постановку задач, ревью, тестирование, принятие решений или деплой.
И если не смотреть на систему целиком, можно радостно ускорить один участок и получить пробку на следующем.
AI не отменяет инженерный менеджмент.
Он делает его важнее.
Потому что чем быстрее команда может производить изменения, тем дороже становится плохой фокус, слабая постановка задач и медленная обратная связь.
Оригинальная статья:
https://newsletter.eng-leadership.com/p/ai-transformation-journey-3-myths
👍2
Age of Work: как найти задачи, которые начали тухнуть
Есть неприятный тип задач: они вроде бы в работе, но на самом деле давно никуда не едут.
В Jira статус нормальный.
Исполнитель есть.
Blocked не стоит.
На daily человек говорит: «занимаюсь».
А потом внезапно выясняется, что задача висит уже вторую неделю, контекст потерян, ожидания разъехались, а завершение всё ещё где-то за горизонтом.
Вот для таких случаев полезна метрика Age of Work.
Если совсем просто, Age of Work показывает, сколько времени задача уже находится в активной работе.
Не сколько она лежала в бэклоге.
Не сколько прошло с момента создания.
А именно сколько она живёт в потоке delivery: взяли в работу — и с этого момента пошёл возраст.
Почему это важно?
Потому что старые задачи часто становятся невидимой проблемой команды.
Они занимают WIP.
Они держат контекст в голове.
Они создают ощущение занятости.
Они мешают брать новое.
Они увеличивают вероятность, что всё придётся переделывать.
И самое опасное: старая задача не всегда выглядит заблокированной.
Она может быть «почти готова».
«Осталось только проверить».
«Жду ответа, но не блокер».
«Надо чуть-чуть допилить».
«Там небольшой рефакторинг всплыл».
Классика жанра: задача не заблокирована, она просто медленно тухнет.
Age of Work помогает увидеть такие задачи раньше, чем они превратятся в археологический слой спринта.
Но здесь есть важный момент.
Эту метрику нельзя использовать как дубинку.
Если на daily тимлид открывает доску и говорит:
«Так, Петров, почему твоя задача уже 8 дней в работе?» —
это не управление потоком. Это публичный ритуал обвинения.
После такого люди быстро учатся не улучшать delivery, а защищаться:
- дробить задачи формально;
- двигать статусы туда-сюда;
- скрывать проблемы;
- объяснять, почему всё нормально.
Метрика становится токсичной не потому, что она плохая.
А потому что её используют для поиска виноватых.
Нормальный вопрос не «кто виноват?», а что мешает задаче закончиться?
По старым задачам полезно спрашивать:
- задача всё ещё актуальна?
- что должно случиться, чтобы она завершилась?
- есть ли там скрытый блокер?
- не слишком ли большой получился кусок работы?
- нужен ли созвон, ревью, решение, помощь другого человека?
- можно ли отрезать часть и довести хотя бы что-то до результата?
- стоит ли остановить задачу, если она больше не важна?
Это совсем другой тон.
Не «почему ты так долго делаешь?», а «давайте поможем работе пройти через систему».
Особенно хорошо Age of Work связывается с daily.
Daily вообще не должен быть отчётом по кругу в формате «вчера делал, сегодня буду». Иначе он быстро превращается в стендап ради стендапа.
Гораздо полезнее смотреть на поток:
- какие задачи давно в работе?
- какие не двигались со вчера?
- где вырос возраст задачи?
- что близко к завершению?
- что мешает закрыть старое перед тем, как брать новое?
То есть daily становится не проверкой занятости людей, а короткой синхронизацией вокруг движения задач.
И здесь Age of Work хорошо дополняет WIP.
WIP показывает, сколько работы мы одновременно тащим.
Age of Work показывает, какая работа уже слишком долго не доезжает до финиша.
Вместе они помогают увидеть классическую проблему: команда вроде постоянно занята, но результат выходит медленно.
Много начатого.
Мало завершённого.
Старые задачи копятся.
Новые всё равно берутся.
Поток начинает вязнуть.
Что можно попробовать без сложной аналитики:
Раз в день или пару раз в неделю смотреть на задачи в работе и выделять самые старые.
Не для наказания.
Для разговора.
Например:
«У нас есть несколько задач, которые давно в работе. Давайте поймём, что им нужно, чтобы завершиться: помощь, решение, декомпозиция или остановка».
Это маленькая смена фокуса, но она сильно меняет разговор.
Команда перестаёт обсуждать занятость.
И начинает обсуждать движение.
А это и есть смысл метрик без насилия: не давить на людей цифрами, а подсвечивать места, где системе нужна помощь.
Есть неприятный тип задач: они вроде бы в работе, но на самом деле давно никуда не едут.
В Jira статус нормальный.
Исполнитель есть.
Blocked не стоит.
На daily человек говорит: «занимаюсь».
А потом внезапно выясняется, что задача висит уже вторую неделю, контекст потерян, ожидания разъехались, а завершение всё ещё где-то за горизонтом.
Вот для таких случаев полезна метрика Age of Work.
Если совсем просто, Age of Work показывает, сколько времени задача уже находится в активной работе.
Не сколько она лежала в бэклоге.
Не сколько прошло с момента создания.
А именно сколько она живёт в потоке delivery: взяли в работу — и с этого момента пошёл возраст.
Почему это важно?
Потому что старые задачи часто становятся невидимой проблемой команды.
Они занимают WIP.
Они держат контекст в голове.
Они создают ощущение занятости.
Они мешают брать новое.
Они увеличивают вероятность, что всё придётся переделывать.
И самое опасное: старая задача не всегда выглядит заблокированной.
Она может быть «почти готова».
«Осталось только проверить».
«Жду ответа, но не блокер».
«Надо чуть-чуть допилить».
«Там небольшой рефакторинг всплыл».
Классика жанра: задача не заблокирована, она просто медленно тухнет.
Age of Work помогает увидеть такие задачи раньше, чем они превратятся в археологический слой спринта.
Но здесь есть важный момент.
Эту метрику нельзя использовать как дубинку.
Если на daily тимлид открывает доску и говорит:
«Так, Петров, почему твоя задача уже 8 дней в работе?» —
это не управление потоком. Это публичный ритуал обвинения.
После такого люди быстро учатся не улучшать delivery, а защищаться:
- дробить задачи формально;
- двигать статусы туда-сюда;
- скрывать проблемы;
- объяснять, почему всё нормально.
Метрика становится токсичной не потому, что она плохая.
А потому что её используют для поиска виноватых.
Нормальный вопрос не «кто виноват?», а что мешает задаче закончиться?
По старым задачам полезно спрашивать:
- задача всё ещё актуальна?
- что должно случиться, чтобы она завершилась?
- есть ли там скрытый блокер?
- не слишком ли большой получился кусок работы?
- нужен ли созвон, ревью, решение, помощь другого человека?
- можно ли отрезать часть и довести хотя бы что-то до результата?
- стоит ли остановить задачу, если она больше не важна?
Это совсем другой тон.
Не «почему ты так долго делаешь?», а «давайте поможем работе пройти через систему».
Особенно хорошо Age of Work связывается с daily.
Daily вообще не должен быть отчётом по кругу в формате «вчера делал, сегодня буду». Иначе он быстро превращается в стендап ради стендапа.
Гораздо полезнее смотреть на поток:
- какие задачи давно в работе?
- какие не двигались со вчера?
- где вырос возраст задачи?
- что близко к завершению?
- что мешает закрыть старое перед тем, как брать новое?
То есть daily становится не проверкой занятости людей, а короткой синхронизацией вокруг движения задач.
И здесь Age of Work хорошо дополняет WIP.
WIP показывает, сколько работы мы одновременно тащим.
Age of Work показывает, какая работа уже слишком долго не доезжает до финиша.
Вместе они помогают увидеть классическую проблему: команда вроде постоянно занята, но результат выходит медленно.
Много начатого.
Мало завершённого.
Старые задачи копятся.
Новые всё равно берутся.
Поток начинает вязнуть.
Что можно попробовать без сложной аналитики:
Раз в день или пару раз в неделю смотреть на задачи в работе и выделять самые старые.
Не для наказания.
Для разговора.
Например:
«У нас есть несколько задач, которые давно в работе. Давайте поймём, что им нужно, чтобы завершиться: помощь, решение, декомпозиция или остановка».
Это маленькая смена фокуса, но она сильно меняет разговор.
Команда перестаёт обсуждать занятость.
И начинает обсуждать движение.
А это и есть смысл метрик без насилия: не давить на людей цифрами, а подсвечивать места, где системе нужна помощь.
❤3👍1
Почему 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