Самая недооценённая метрика: "Blocked Time" ⏱️⛔️
Всем успешной доставки, на связи рубрика "Метрика недели"
Я уже писал про такие процессные метрики как:
👉Time to market
👉Lead time
👉Пропускная способность (throughput)
👉Discard rate
👉Время нахождения задач в бэклоге

Если ещё не видели, лучше прочитать 😉.
И помните: метрики - это инструмент улучшения процессов, а не контроля людей.

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

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

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

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

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

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

Подписаться
#метрики #blockedtime #блокировка

👋 Всем привет!

Хочу предложить вам перейти от теории к практике (смотрите примеры 👉 пост , результаты).

📊 Суть проста:
У вас есть процессные метрики - Lead Time, пропускная способность или другие.
Вы их показываете, а я даю рекомендации, которые помогут улучшить процесс доставки. Будете ли вы это внедрять решайте сами 😉

🔧 Как это будет:
Оставляете заявку тут
Договариваемся на слот (1 час).
Созваниваемся в Google Meet, я готовлю для вас доску в Unidraw, с ней вы останетесь после встречи, со всеми записями и инсайтами.
🗓 Заявки принимаю до 23.09, после этого начну планировать созвоны.

💸 Всё бесплатно.

Всем успешной доставки! Хочу поделиться полезным форматом от ребят, которые делают конференцию Ural Digital Wekeend, а теперь ещё и проводят онлайн-митапы.
Ближайший митап 18 сентября: как держать пожары в разработке под контролем с помощью Observability и умных алертов.

Ссылка на митап: ЗАРЕГИСТРИРОВАТЬСЯ

Думаю, многим из вас зайдёт 👍

🚚📦 Delivery Meme Friday 🎉
Считайте метрики правильно и приносите мне на анализ 🧐

👥 Когда говорим про End-to-end процесс (от идеи до релиза), часто думаем только о разработке.
Но поток шире: это цикл от поиска проблем до поддержки решения.

🔹 Discovery:
-Стейкхолдеры формулируют потребность.
-Аналитики / исследователи проводят интервью и исследования, выявляют проблемы, формулируют гипотезы решений и готовят ТЗ. Писал тут про подход DD
-UX/UI превращают гипотезы в сценарии и прототипы.

🔹 Delivery:
-Разработчики создают решение.
-QA / тестировщики проверяют качество.
-DevOps / SRE обеспечивают инфраструктуру и доставку.

🔹 После релиза (support):
Поддержка фиксирует первые проблемы от пользователей.
Продуктовые / дата-аналитики измеряют эффект и метрики.
На основе данных рождаются новые гипотезы → цикл запускается снова.

🔹 Сквозная роль:
Delivery Manager обеспечивает поток, убирает блокеры, согласует зависимости, следит за метриками.
📊 Визуально это выглядит как замкнутая петля ценности: исследование → разработка → поддержка → новое исследование.

❗️Почему это важно?
Без discovery мы рискуем сделать «не то», без поддержки ценность быстро теряется. End-to-end - это умение видеть весь цикл, а не только свой участок.

📌 Попробуйте нарисовать свой e2e-поток и отметить, каких ролей у вас нет. Это отличный способ понять, где теряется скорость или качество.

Всем успешной доставки 🚀
📌 Если ищете, что почитать про AI, бизнес и технологии, то я нашёл хороший вариант.

Я сам периодически теряюсь в этом инфопотоке. Поэтому мы с ребятами из сообщества собрали подборку каналов, за которыми реально стоит следить.

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

📂 Кому интересно, вот папка, можно подписаться сразу на всех

🚚📦 Delivery Meme Friday 🎉
А вы знаете, что Скрама вообще не существует?😂

🔹 Что такое точка принятия обязательств?
Всем успешной доставки!
Здесь я много писал про практики и принципы и каденции в Канбан, но не раскрыл самое главное 🌚 что такое "точка принятия обязательств"
В Канбане есть ключевое понятие - Commitment Point или точка принятия обязательств.
Это момент, когда команда официально берёт на себя ответственность довести задачу до результата. Можно сказать задача переходит из "хотим сделать" в "решили делать".
До этой точки идеи и запросы могут свободно обсуждаться, приоритизироваться, отсеиваться. Но как только задача пересекает границу, то команда обязуется её сделать.

🔹 Как определить эту точку?
Визуально - это граница на доске, где заканчивается поток «идей» и начинается поток «обязательств».
На практике у разных команд это может быть разный статус: «Готов к работе», «Запланирован», «Принят в работу».

🔹 Зачем она нужна?
Чтобы управлять ожиданиями заказчиков: до этой точки можно менять приоритеты, после команда работает на выполнение своих обязательств.
Чтобы отделить мир пожеланий от мира обязательств.

🔹 Какие метрики считаются от этой точки?
Lead Time - сколько времени задача проходит от обязательства до «Done».
Throughput - сколько задач команда завершает за период (считается только то, что прошло через точку).
Flow Efficiency - доля реальной работы во времени задачи.

🔹 Что является «отдачей обязательств»?
Точка выхода из зоны обязательств - это момент, когда команда выполнила обещанное.
⚡️ Ключевой критерий: задача больше не требует усилий команды и приносит ценность заказчику.

🔹 С чем её путают?
С дедлайном - дедлайн связан со сроком, а не с фактом взятия в работу.
С приоритизацией - выбрать задачу «важной» ещё не значит взять её в обязательство.

📌 Вывод:
Точка принятия обязательств - это ключевой рубеж в потоке задач: от неё считаются основные метрики потока, а завершение задачи после этой точки - это выполнение обязательства перед заказчиком.

🚚📦 Delivery Meme Friday 🎉
Не надо так 😂, стори поинты не работают, используйте метрики

Приходите к нам на первый круглый стол, где будем говорить про внедрение изменений 😎

🚚📦 Delivery Meme Friday 🎉
Кажется уже из каждого утюга говорят про ИИ, а есть ли конкретные примеры как вам ИИ помог в работе? Кроме написания текста и поиска информации?
Мы у себя подключили внутреннюю LLM, которая по комментариям указанным при блокировки задач автоматически определяет категории блокировок.
Хотите, расскажу подробнее, как мы это сделали?

🚚📦 Delivery Meme Friday 🎉

Всем успешной доставки!
Внедрять изменения это не благородное дело😢 Потому, что всегда столкнешься с сопротивлением. Есть хороший пост из канала "Разумный менеджмент" «Почему изменения бесят команду?»

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

В итоге даже полезные улучшения начинают раздражать.
Особенно откликнулось про игнорирование текущего контекста.
Если команда уже горит в дедлайнах и не выстроены базовые процессы, любое «новое» только усиливает боль.

Тут важно не просто «внедрить», а помочь пройти изменения осознанно.
🧩 Один из подходов, который мне нравится ADKAR.

Он помогает смотреть на изменения через призму людей, а не только процессов:
Awareness - понять, зачем всё это нужно,
Desire - захотеть участвовать,
Knowledge - знать, как делать,
Ability - уметь применять,
Reinforcement - закрепить результат.
Иногда достаточно пройтись по этим шагам, чтобы увидеть, где именно буксует внедрение.

📌 Почитайте пост - хорошая основа для рефлексии.
А если добавить к нему призму ADKAR, то можно реально повысить шансы, что изменения приживутся, а не останутся на слайдах.
Ну и посмотрите другие посты в этом канале, там достаточно интересно рассказывает про управление командой и процессами.