Age of Work: как найти задачи, которые начали тухнуть
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 показывает, какая работа уже слишком долго не доезжает до финиша.
Вместе они помогают увидеть классическую проблему: команда вроде постоянно занята, но результат выходит медленно.
Много начатого.
Мало завершённого.
Старые задачи копятся.
Новые всё равно берутся.
Поток начинает вязнуть.
Что можно попробовать без сложной аналитики:
Раз в день или пару раз в неделю смотреть на задачи в работе и выделять самые старые.
Не для наказания.
Для разговора.
Например:
«У нас есть несколько задач, которые давно в работе. Давайте поймём, что им нужно, чтобы завершиться: помощь, решение, декомпозиция или остановка».
Это маленькая смена фокуса, но она сильно меняет разговор.
Команда перестаёт обсуждать занятость.
И начинает обсуждать движение.
А это и есть смысл метрик без насилия: не давить на людей цифрами, а подсвечивать места, где системе нужна помощь.