Наверняка тебе знакома ситуация: начинается утренний синк, и ты задаёшься вопросом: «А что вообще сейчас происходит с задачами?». Кто‑то что‑то делал, кто‑то ждал ревью, у кого‑то что‑то зависло, а кто‑то вообще сидит без работы. На расспросы команды уходит много времени, а картина всё равно остаётся неполной. И самое важное: не про все вспомнишь в момент синка.

Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.

Зачем нужен LiveBoard?

• Быстро понять состояние задач перед синком, чтобы задавать конкретные вопросы.

• Сразу увидеть проблемные места, такие как застрявшие на ревью или в статусе Waiting задачи.

• Контролировать распределение работы между членами команды.

• Избежать неприятных сюрпризов вроде забытых или зависших задач.

LiveBoard помогает экономить время и силы: вместо долгих расспросов ты получаешь ясную картину прямо перед глазами. А значит, синки становятся эффективнее, а твои решения — точнее.

Как пользоваться LiveBoard?

Лучше всего просматривать этот дашборд прямо перед ежедневным синком и/или на синке, а также в течение дня. Тебе понадобится буквально несколько минут, чтобы пробежаться по всем пунктам и определить, на что именно обратить внимание.

Важно: цель не в том, чтобы контролировать каждый шаг разработчиков, а в том, чтобы вовремя увидеть проблемы и помочь команде двигаться быстрее и легче.

Я еще использую цветовую маркировку каждого дашборда

• красный — плохо

• желтый — обрати внимание

• зеленый — хорошо

• синий — ничего не значит, может быть как хорошо так и плохо

Короткое отступление: в этой статье мы не будем спорить, какие именно методы планирования или оценки задач правильные. Часы или сторипойнты? Планировать спринт на команду или на человека? Логировать ли фактические часы и пересчитывать остаток сторипоинтов при завершении спринта? Это оставим за рамками. Также я использую плагин для джиры от Oldstreetsolutions, но стандартные дашборды тоже все эти базовые графики выводят, в джире и яндекс трекере такое точно можно

Что включить в свой LiveBoard?

Ниже представлены примеры конкретных дашбордов, которые помогут тебе быть в курсе текущих задач и быстро реагировать на проблемы:

1. Задачи в спринте, требующие информации (Waiting/Need Info)

Это фильтр для задач из текущего активного спринта, которые находятся в статусе «Waiting»/«Need Info». Проще говоря, задачи, которые застряли из‑за ожидания: нужна уточняющая информация, ответ от другого отдела, доступы — что угодно, что блокирует работу. В этом даше вы можете собирать таски с разных статусов, досок, проектов, например аппрув выполненной задачи от инфры и тд, в зависимости от вашего ворк флоу. Это то, что нужно пушнуть.

Почему это важно? Потому что такие зависшие задачи тормозят весь спринт. Разработчик, уткнувшийся в «Waiting», часто переключается на что‑то ещё, и таска начинает пылиться. Твоя задача как лида — не дать про неё забыть. На каждом синке имеет смысл пробежаться по этому списку: спросить, что по этим задачам, не появилось ли нужной инфы, чем можно помочь, кого подтолкнуть. Не стесняйся подтолкнуть ответственных: если задача ждёт ответа от условного Васи — напомнить Васе. Идеально, если к следующему синку список таких задач окажется пустым. Тут может быть более чем один статус, и ничего страшного что в каких‑то моментах даш дублирует доску, главное не потерять фокус на важном.

2. Задачи на ревью дольше 24 часов

Время порога можно настроить под твою команду (24 часа — условный ориентир). Идеальный сценарий — таких задач нет вообще: это значит, что код‑ревью проходит быстро и ничего не застаивается.

Если же видим задачу, которая больше дня ждёт ревью, стоит задать вопрос: почему так долго? Возможно, ответственный за ревью перегружен или забыл, или изменения слишком объёмные и стоит их разбить. Для команды важно, чтобы ревью не превращалось в бутылочное горлышко. Данный дашборд помогает прозрачно увидеть, есть ли проблемы с оперативностью код‑ревью и вовремя напомнить ревьюерам о зависших задачах.

3. Задачи в спринте без исполнителя

На первый взгляд, ситуация абсурдная: как это в активном спринте могут быть задачи без исполнителя? Чаще всего причина в том, что в спринт скинули задачи. Либо задача заведена, но ответственного назначили формально на лида/менеджера (placeholder, так сказать).

Зачем он нужен? Чтобы ты как лид мог быстро раздать сиротские таски конкретным людям. Если задача уже в спринте, но исполнителя нет — значит, высок риск, что о ней забыли. Если же спринт ведётся «на команду» без предварительной разбивки по людям, этот дашборд не нужен.

4. Задачи в спринте без оценки

Ещё один тип проблемных задач — те, у которых нет оценки. Если вы начинаете спринт только с оценёнными задачами (а это хорошая практика планирования), то внезапно появившиеся неоценённые таски могут подпортить планы. Чаще всего опять же причина — незапланированные вбрасывания: баги, «пожары» или срочные доработки, которые появились на ходу.

Этот фильтр найдёт задачи без указанных часов или сторипойнтов (в зависимости от того, что вы используете для оценки). Зачем это лиду? Во‑первых, чтобы при первой возможности оценить эти задачи — хотя бы приблизительно, чтобы понять их влияние на спринт. Во‑вторых, как сигнал: если много задач валится без оценки, возможно, хромает процесс планирования или требования прилетают в обход обычного порядка. Это повод обсудить на ретро, как уменьшить такие сюрпризы.

5. Остаток часов/Story Points по людям в спринте

Этот дашборд строится не просто списком задач, а графиком или таблицей, показывающей сколько работы осталось у каждого разработчика до конца текущего спринта. Проще говоря, берём все задачи спринта и группируем по Assignee, суммируя оставшиеся часы или Story Points.

Что это даёт? Ты видишь, у кого какая загрузка на оставшееся время. Например, если у Пети по задачам выходит, что осталось 2 часа работы, а у Васи — 40, это явный дисбаланс. Возможно, Петя будет сидеть без дела, а Вася не успеет к дедлайну. Благодаря этому дашборду лид может вовремя перераспределять нагрузки: передать задачу Васи кому‑то ещё, докинуть Пете задач или помочь тем, кто не укладывается. Фактически, это индивидуальный «берндаун» по каждому члену команды. Конечно, если у вас сплошь огромные задачи на весь спринт, эта метрика может быть не столь показательна. Но в большинстве случаев она позволяет избежать ситуации, когда кто‑то «перегружен», а кто‑то «недогружен».

6. Количество задач «в работе» по каждому разработчику

Здесь мы отслеживаем количество параллельно начатых задач у каждого члена команды. Под «в работе» я объединили статусы: In Progress (в процессе разработки), Reopen (повторно открыта), Waiting (ожидание, но ответственность ещё на разработчике) и Review (код на ревью, разработчик должен проконтролировать прохождение). Почему именно они? Потому что всё это стадии, за которые отвечает разработчик, и которые находятся между «взял в работу» и «готово».

Если у кого‑то скапливается слишком много задач в этих статусах, это тревожный сигнал. Например, видим: у Димы 5 задач висят на разных стадиях. Значит, Дима распыляется, берёт новые задачи, не доведя до конца предыдущие. А это плохо сказывается на Lead Time (времени выполнения задачи от начала до релиза) — незаконченные таски копятся, релизы откладываются. Хорошая практика: сначала довести до ума задачу, которая ближе к финишу (например, вывести из Waiting или добиться аппрува в Review), а уже потом хвататься за новую из «To Do». Данный дашборд позволит тебе быстро увидеть, кто нарушает этот принцип. Обсуди с такими разработчиками на 1-на-1, в чём причина: может быть, задача застряла и им нужна помощь, или нужно напомнить про ценность фокусировки на одном деле.

7. Задачи в In Progress без движения 48+ часов

Метрика для выявления застрявших задач. Она показывает все задачи, которые находятся в статусе «In Progress» (в работе) и при этом не меняли своего статуса уже два дня или более. (Порог 48 часов условный — в зависимости от темпа твоей команды можно поставить и 24 часа, и 72, суть в том, чтобы вылавливать зависания).

Когда задача висит «в прогрессе» несколько дней без изменений, есть повод насторожиться. Что могло случиться? Возможные варианты: разработчик не может решить проблему и буксует, или забыл обновить статус (что тоже плохо, значит, метрики врут!), или отвлёкся на что‑то ещё и бросил задачу. В любом случае, ты как тимлид должен заметить такие случаи. Можно прямо на дейли спросить: «Петя, у тебя задача #XYZ уже третьи сутки в In Progress, есть трудности? Давай обсудим, нужна помощь?». Иногда одного этого вопроса достаточно, чтобы дело сдвинулось (или хотя бы статус обновился честно).

8. Изменения статусов задач за последние сутки

Этот дашборд — как хроника событий с прошлого синка. Он показывает все задачи, у которых статус менялся за последний день (условно 23 часа, чтобы точно захватить период между ежедневными митингами). По сути, это срез активности команды: какие таски за сутки сдвинулись с места, ушли в тестирование, в релиз, закрылись или, может, вернулись обратно.

Чем полезна такая сводка? Тем, что на утреннем созвоне можно быстро пробежать: вот, вчера доделали задачу Х, молодцы; задачу Y перевели в «Review» — ок, ждём код‑ревью; задача Z откатилась из «Test» обратно в «Reopen» — ой, баг нашли, надо разобраться. То есть, ни одна движуха не проходит незамеченной. Если команда распределённая или просто большая, кто‑то мог не уследить за обновлениями в Jira — этот список гарантирует, что все в курсе последних обновлений. Плюс, он дисциплинирует самих разработчиков: когда они знают, что каждое изменение статуса видно, они ответственно обновляют задачи.

9. Задачи более 48 часов в статусе “Ready To Release”

В некоторых процессах есть стадия, когда задача полностью готова и протестирована, но ждёт релиза (деплоя на прод). Обычно такие задачи не должны долго задерживаться: если фича готова — её выпускают в ближайшем релизе. Поэтому, если мы видим задачи, которые уже двое суток как готовы к релизу, но так и не выпущены, это звоночек.

Что могло случиться? Либо про них забыли, либо релиз откладывается (и стоит понимать почему), либо задача застряла на какой‑то финальной процедуре (например, требует чьего‑то особого аппрува). В любом случае, хорошо бы периодически просматривать подобные «зависшие перед выпуском» таски. Аналогично можно мониторить и другие промежуточные статусы на финишной прямой — например, «Tested», «Staging», «QA Complete» и т. д., в зависимости от твоего воркфлоу. Цель одна: ничего не потерять перед релизом. Если уж задача сделана, грех держать её вне продакшена слишком долго.

10. Задачи без активности более 3 дней

Последний на сегодня фильтр — универсальный ловец висяков. Он находит любые задачи (кроме ещё не начатых «To Do» и уже завершённых «Done»), которые не менялись три дня и более. Если какая‑то активная задача не обновляется в Jira столько времени, значит, что‑то не так. Либо про неё забыли, либо работа идёт, а статусы ленятся менять (что опять же искажает реальность).

Эта метрика частично пересекается с предыдущими (например, попадут и задачи из In Progress, и из Waiting, и др., если стояли без движения). Зачем она нужна тогда? Как резервная сетка: вдруг где‑то что‑то проползло мимо наших предыдущих фильтров. Иногда процесс у команды нестандартный, и задача может застрять в необычном статусе. Этот дашборд поднимает наверх всё, что подозрительно долго лежит без прогресса, чтобы ты точно ничего не упустил. Конечно, здорово, если и он всегда пустой — но практика показывает, что в жизни регулярно находятся такие таски.

Выводы

Дашборды — отличные помощники тимлида. Они дают прозрачность, экономят время и нервы, позволяя сразу видеть отклонения от нормы. В этой статье мы рассмотрели лишь десяток примеров: от задач, застрявших в ожидании, до индивидуального берндауна по людям. Конечно, метрик может быть и больше — под каждый процесс можно придумать свои. Главное — не перегружать команду сотней графиков, а выбрать несколько ключевых и регулярно их отслеживать.

Помни, что метрики — это инструмент, а не панацея. Они работают в комплексе с человеческим вниманием и здоровым смыслом. Правильно интерпретируй данные, говори с командой, копай вглубь причин, а не только любуйся цифрами.

Удачи в управлении командой и пусть твои метрики всегда отражают реальный прогресс!