Серия «Без названия»

Самая недооценённая метрика: "Blocked Time" ⏱️⛔️
Всем успешной доставки, на связи рубрика "Метрика недели"

Сегодня пишу про "более зрелую" метрику Blocked time, почему "более зрелую"?
Почему ее называют «более зрелой метрикой»?
Команды, которые начинают её считать, уже вышли за рамки базовых показателей вроде Lead Time или WIP.
Blocked Time требует осознанного анализа: что именно мешает нам двигаться?
Она не только показывает факт задержки, но и помогает вскрывать системные проблемы взаимодействия.

Blocked time - это время, которое задача была «заблокирована» ⛔️.
То есть команда не могла продвигать её дальше из-за внешних или внутренних зависимостей:
-ждём ревью у другой команды,
-не пришли данные от заказчика,
-согласование у юристов.
-фриз на релиз

🔥 Какую проблему решает?
-Помогает отделить «мы работали долго» от «мы не могли работать, потому что ждали».
-Делает узкие места прозрачными: видно, что тестирование ждёт доступ к стенду по 5 дней, или заказчик согласовывает требования неделями.
-Даёт аргументы на встречах с заказчиком и внутри компании: «Сами мы сделали за 2 дня, но 10 дней ушло на ожидание согласования».

📈 Использование Blocked Time в динамике:
Если показатель системно высокий → проблема в процессе (надо оптимизировать взаимодействие).
Если блокеры случайные и редкие → нормальная рабочая ситуация, главное фиксировать и обсуждать.

📝 Чек-лист: стоит считать Blocked Time, если…
-у вас уже есть базовые метрики (Lead Time, WIP),
-ощущаете, что «задачи буксуют», но непонятно где,
-хотите объяснять сроки на языке данных, а не эмоций.

А у вас в команде считается Blocked Time? Делитесь опытом 👇

📊 Метрика недели Discard Rate или «сколько задач мы выкидываем на помойку»
🧯 В условиях 2025-го, когда каждая неделя работы стоит как самолет, важно не только делать правильно, но и перестать делать лишнее.
И вот тут появляется полезная, но недооцененная метрика Discard Rate.

❓Что это такое?
Discard Rate - это доля задач, которые были запланированы, но так и не дошли до продакшена.
Например:
-Начали делать, но отменили
-Завели задачу, но забросили
-Потратили ресурсы, но поняли, что не нужно

🔎 Зачем её считать?
Понимать, сколько усилий ушло впустую, если часто отменяете задачи после старта, где-то сбоит приоритезация.
Обнаруживать "горячие головы", инициатива хорошо, но если постоянно отбрасываются начатые задачи, это тревожный симптом.
Оптимизировать процесс Discovery, высокий Discard Rate может говорить, что фичи начинают пилить без нормальной проработки.
Снижать риски сжигания бюджета, особенно критично, если деньги «дорогие» на проекте каждый день имеет ценник.
Улучшать прозрачность потока работы, команде и менеджерам проще видеть, куда утекают усилия.
Ценить ранний отказ, чем раньше задача была отменена, тем меньше времени и денег потрачено. Ранний “нет” это экономия.

🛠 Как внедрить?
Отметьте “выкинутые” задачи в Jira, создайте статус Discarded или метку cancelled, won’t do, abandoned.
Следите за трендом, Discard Rate >15%(может отдельно для себя определить этот процент) регулярно? Уже стоит копать глубже.
Анализируйте причины, ретроспектива, работа с продуктовыми командами: почему задача не дожила до релиза?
Показывайте в дашборде, добавить в CFD/графики можно визуализировать как долю от всех заведенных задач.

💡 Нормально ли, что что-то выбрасываем?
Да, если осознанно. Главное не тратить на это недели работы. Чем раньше “завернули” тем лучше для всех.
Discard Rate не про обвинения, а про улучшение процесса принятия решений.

📊 Метрика недели: время нахождения задач в бэклоге
Кажется, что все важные метрики уже известны - скорость, Lead Time, Cycle Time… Но есть одна неочевидная, которую редко используют - время нахождения задач в бэклоге.

🔍 Что это такое?
Это количество дней (или недель), которое задача проводит в статусе "Backlog" - от момента её попадания туда до момента, когда команда берёт её в работу.

💡 Зачем мерить
Признак приоритизации - если задача лежит в бэклоге месяцами, значит, её ценность или приоритет под вопросом.
Выявление "кладбища идей" - бэклог легко превращается в свалку, где теряются актуальные задачи.
Сигнал к пересмотру процессов - слишком длинное ожидание может говорить о неэффективной работе с входящими запросами.
Индикатор загрузки команды - если задачи быстро забираются в работу, но бэклог всё равно растёт, это сигнал к дополнительному найму или перераспределению ресурсов.

📈 Какие выводы можно сделать
Если задачи лежат в бэклоге более 6–12 месяцев, велика вероятность, что они "протухли", контекст изменился, а ценность снизилась до нуля.
Если старые задачи вдруг начали попадать в работу, проверь не изменились ли требования или бизнес-приоритеты.
Если большая часть задач живёт в бэклоге более N дней, то команда, скорее всего, набирает слишком много задач "на потом".

⚙️ Как использовать
Регулярно проводить grooming с удалением или переоценкой "долгожителей".
Отслеживать тренд: растёт ли среднее время нахождения задач или уменьшается.
#метриканедели #backlog #e2e

🎯 Метрика недели Lead Time
Когда мы обсуждаем метрики, хочется напомнить:
📌 метрики - это не инструмент давления на команду, а возможность улучшать процессы основываясь на фактах.

🕐 Что такое Lead Time?
Lead Time - это время от момента принятия обязательств до момента завершения задачи.
Говоря проще: задача перешла в колонку “In Progress” (или другой этап, где команда уже взялась за дело) - и пошёл отсчёт.
Завершили (например, “Done” или “Released”) - таймер остановился.
Это честное измерение: сколько времени заняло выполнение задачи после того, как вы сказали "мы это сделаем".

📊 Как считать Lead time ?
Хорошая практика - смотреть не только на среднее, а на перцентили.
Например:
50-й (медианный) перцентиль покажет, сколько занимает "типичная" задача;
85-й и 95-й — как обстоят дела с «хвостом» (долгими задачами);
Это помогает понять разброс и стабильность процесса, а не просто «в среднем по больнице».

📈 Зачем считать Lead Time?
-Чтобы понимать, насколько быстро команда доставляет ценность;
-Улучшать прогнозируемость и делать более реалистичные планы;
-Выявлять узкие места и неоптимальные этапы в процессе;
-Повышать надежность сроков: если вы знаете, как ведёт себя 85-й перцентиль, вы уверенно можете говорить о дедлайнах.

⚠️ Важное уточнение
Если вы хотите снизить Lead Time, не забывайте про пропускную способность (Throughput).Сократить время выполнения одной задачи можно, но если при этом падает общее количество завершённых задач - значит, мы просто «перераспределили» усилия, а не улучшили процесс.
Баланс важен: быстрее ≠ меньше.

🧩 Как внедрить Lead Time в практике?
-Визуализируйте процесс от момента, когда задача становится обязательством;
-Отмечайте даты входа и выхода задач;
-Собирайте данные, стройте графики, считайте перцентили;
-Обсуждайте это на ретро, а лучше заведите отдельную встречу по обзору метрик: где вы отвечаете себе на вопрос "почему зависают задачи, и что с этим делать?"

💬 А вы считаете Lead Time? Какой у вас 85-й перцентиль?
#метрики #leadtime

🎯 Метрика недели: Пропускная способность (Throughput)
Давайте разберёмся, что такое throughput и зачем его вообще считать.

Что это такое?
Throughput показывает, сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Например:
- 25 задач за месяц → throughput = 25
- 6 багфиксов и 4 фичи → throughput = 10 (или можно разделять по типам задач - это даёт дополнительную глубину анализа)

Зачем считать?
📈 Оценка скорости команды - понимаем, насколько стабильно двигаемся.
🔍 Анализ трендов - замечаем, когда темп падает или растёт.
📅 Прогнозирование сроков - throughput помогает понять, сколько времени займёт бэклог.
⚖️ Балансировка нагрузки - при падении throughput ищем причины: перегруз, блокеры, неоптимальные процессы.
📂 Глубокий анализ - можно смотреть throughput отдельно по типам задач, чтобы увидеть перекосы (например, много багов, мало фич).
🤝 Прозрачность - метрика легко объясняется и хорошо работает на демонстрациях.

Важно помнить
✅ Это не метрика продуктивности отдельного человека. Это командная метрика.
✅ Рост throughput - это не цель сама по себе. Главное стабильность и предсказуемость.
✅ Следите, чтобы при снижении Lead Time не пострадал throughput - важно сохранять баланс.

Как начать считать?
- Определите, какие задачи считаются «завершёнными» (например, в статусе Done).
- Считайте завершённые задачи за месяц (чтобы сгладить колебания).
- Смотрите динамику по неделям/месяцам.
- Разделите throughput по типам задач: баги, фичи, техдолг - это даст более точные инсайты.
- Используйте визуализацию (графики, диаграммы, трекеры).

📌 Через месяц можно увидеть первую динамику. А дальше уже строить прогнозы и находить точки для улучшений.
#метрики #throughput

🎯 Метрика недели: Time to Market
Когда фича только появилась, кажется, что «всё сделаем быстро». А потом проходит неделя, вторая, месяц и фича всё ещё где-то в разработке.
Чтобы перестать гадать, пора смотреть на цифры. Сегодня говорим про Time to Market.

⏱️ Что это вообще?
Time to Market (TTM) - это время от старта до релиза.
Появилась идея → начали работу → фича вышла в прод.
Чем меньше это значение - тем быстрее вы доставляете ценность клиенту.

🤔 Зачем вообще это считать?
-Понимать, насколько быстро вы реагируете на запросы
-Если клиенту что-то нужно, а вы выпускаете это через 2 месяца - ну, такое.
-Находить узкие места
-TTM растёт? Значит, где-то затык. Ищите, где теряется время: анализ, ожидание, тесты, выкладка, всё влияет.
-Лучше прогнозировать сроки
-Проверять, помогают ли изменения
-Внедрили что-то новое? TTM стал меньше? Отлично, работает. Если нет - возможно, это просто новая боль.

🛠 Как начать считать?
Визуализируйте процесс: от идеи до продакшена. Канбан-доска, value stream map - подойдёт всё, где видно поток задач.
Определите чёткие точки старта и финиша. Например: «взяли в работу» → «выкатили».
Желательно, чтобы задачи вели в одной системе (Jira, Trello, Notion - неважно, главное, чтобы удобно было вытаскивать даты).

📌 Несколько советов:
-Разделяйте задачи по типам - фичи, баги, срочные правки. У них разный TTM, и это нормально.
-Смотрите на тренд - как меняется TTM по месяцам/кварталам.
-Показывайте метрику команде. Это фокусирует всех на главном - поставке ценности, а не просто «делании задач».

💬 Считаете TTM у себя? Или пока только приглядываетесь к метрике? Напишите в комментариях, интересно как это работает в разных командах.