Дорогой дневник читатель!

📊 Сегодня покроем базу по метрикам (на примере с едой). Она супер-короткая.
Но для начала договоримся: метрики это инструмент. На самом-то деле мы хотим предсказуемости и прогнозов на его основе!

🧑‍🍳 Ситуация: ты менеджер в пиццерии.
Клиент спрашивает: “Когда будет готова моя пицца?”
Что отвечаешь? “Скоро” или всё-таки можешь дать конкретику?

🔮 Любой прогноз = диапазон + вероятность
“С вероятностью 85% ваша пицца будет готова через 20 минут” (про вероятности поговорим в следующих постах). Дословно про 85% говорить не нужно :)

А вот индикаторы разберём прямо сейчас. Я за минимализм — достаточно трёх показателей:

🍽️ Throughput (Пропускная способность)

Сколько блюд кухня выпускает за час. Это пульс ресторана:
- 25 блюд в обычный день
- 40 в пятницу вечером

⏰ Cycle Time (Время цикла)

От заказа до подачи (упрощенный пример):
- Паста — 15-20 минут
- Стейк — 20-30 минут
Важно: считаем только завершённые заказы!

🥞Item Aging (Состаривание элемента)

Сколько времени текущие заказы уже готовятся (и еще недоготовились).
Если стейк готовится 25 минут, а средний Cycle Time — 20, это сигнал проверить кухню.
Это моя любимая метрика.


А теперь главный вопрос:

🤔 Ой, а разве это натягивается на айтишечку? - спросите вы.

💪Да, да, и еще раз - да! При этом учитывает и всю вашу размерную вариативность задач, и время простоя, и все потери, которые можно оптимизировать!

Что будет дальше?

- В следующих постах — детальный разбор каждой метрики. Но у Саши Торгашева (Delivery Manager в Т-Банке) уже есть подобное: Throughput, Lead Time - если не терпится почитать.

- Поиграться с данными и понять как работают метрики можно в моём инструменте: predictable.team

- ❓А у тебя в команде какие показатели отслеживаете?
Мини-срачик в @AgileUfa — уже тебя ждет!

- А еще у нас будет митап по этим метрикам в середине августа. 👍 Тык для регистрации

#metrics #throughput #cycletime #aging #predictability

🍣 😊 Лайк, если тоже любите суши!

📈 Сегодня детальнее про Throughput (пропускная способность) на примере суши-ресторана — главную метрику для всех, кто не любит угадывать и предпочитает честно считать, сколько реально «блюд» выдает кухня. Мы уже проходили по верхам базовые метрики для предсказуемости в посте выше.

👨‍🔬 На Throughput можно смотреть
- на масштабе за период (неделя-месяц-квартал),
- исследовать в микро- или макро-режимах чтобы найти паттерны,
- смотреть срезы по типам и источниками.
Сегодня рассмотрим как читать метрику, делая zoom in / zoom out.

🎭 Занавес, пятничный вечер, полный зал в здесь-могла-бы-быть-реклама-Тануки, суши-мастера не успевают нарезать рыбу, официанты спасают от голода фанатов темаки и сашими.

В 19:00 кухня выдаёт 50 порций в час — круто! Но уже к 22:00 throughput падает, сеты тянутся, а посетители начинают задумываться, не пора ли просто перебиться эдамаме и кимчи вместо полноценных блюд.

🗺 Zoom out:
В среднем по неделе throughput — 32 порции в час. Но этого мало! Если смотреть шире — видны пятничные пики, субботние провалы, идеальная среда. Это база для любого серьёзного планирования: хотите запускать happy hour или готовить новые акции — смотрите сюда!

🔍 Zoom in:
Приближаем: с 20:00 до 20:40 в пятницу часть заказов застревает в производстве (помните пресловутые Lead Time, Aging). Может, узкое место именно на сборке сложных сетов? Или повара устают от наплыва темпуры и роллов с лососем?

В следующих постах мы с вами разложим throughput по полочкам — покажем, как разные масштабы анализа меняют взгляд на цифры, и почему суши-ресторан — лучшая лаборатория для таких экспериментов!

❓🎁 А на вашу команду на каком масштабе (час/день/месяц/квартал) лучше смотреть, чтобы прогнозировать работу? (потом на Agile Ufa или СДЭКом наградим самых активных)

#metrics #throughput

Мы уже увидели, как throughput в суши-баре меняется на разных масштабах — теперь время докопаться до сути: какие именно заказы 🍜🍣🍥 идут по ленте, и почему это так важно использовать в прогнозах!

🌙🍸 Воображаем тот же вечер пятницы: В зал набилось народу, кто-то тыкает в меню на классический маки с тунцом 😊 , за соседним столиком ждут сашими 😨 ,а компания заказывает авторский сет аж из 12 позиций.

📝 Типы заказов важны для throughput (и типы задач если приземлять на наши реалии) для диагностики, ведь часто у них разные Lead Time (время реализации):

- 5 простых маки — приготовят за 7 минут.
- 2 темаки с креветкой — требуют аж 12 минут.
- 4 сашими-сета — рыбу нарезать делов на 5 минут.
- 2 больших сета — отнимут 20 минут минимум и займут на линии двух мастеров.

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

⌛Что еще влияет на ваш поток?

Выше я приложил картинку с источниками заказов, будь то Яндекс Еда, Bolt, Uber Eats, заказ на поесть внутри ресторана. Ведь заказы на месте и на доставку грузят разные этапы: упаковка задерживает даже быстрые блюда.

Иногда на кухне притормаживает один мастер — потому что только он умеет делать особо хитрые нигири.

Бывают внезапные всплески новых позиций в меню — и никто не знает, как их быстро собирать! (ого, да это ж работа с новой технологией!)

⚡ Почему throughput - грут крут:

Он автоматически учитывает реальный микс заказов: простых, сложных, эксклюзивных. Не надо гадать и “калибровать” — просто честно считать фактический выход.
В этом его выигрыш перед разными баллами и оценками «на глаз» — наши суши уже рассказывают достаточно информации о потоке.

🖥 А как в айтишечке видна динамика Throughput в этих срезах?

- Начали больше выпускать работы, но в составе задач резко увеличились дефекты.
- Часто дефектов больше перед первым релизом продукта, а количество задач (в абсолютных значениях) увеличивается.
- Задачи с фиксированным дедлайном часто выполняются за другое количество времени, нежели стандартные задачи.
- Разброс времени выполнения спайков (исследовательских задач) может быть существенно больше, чем у стандартной работы.

❤️ А что нам важно-то?

- Стабильный Throughput - признак предсказуемости. На больших периодах не должен прыгать на +- 30% (можно использовать скользящее отклонение от среднего значения за последние 4-6 периодов)
- Рост / снижение это не плохо, а входная точка для диагностики вместе с другими метриками.
- Стабильность Throughput будет всегда скакать, если команда активно растет или продукт/сервис потихоньку декомиссится.


❕Есть ли разрезы информации в Throughput (кроме типов работы (блюда), источников заказов с особенностью выполнения (на вынос или в рестике), временных периодов (zoom in / out)) - которые мы не учли?

#metrics #throughput

🛠️ Инструменты мониторинга метрик команды и что почитать по теме.

Начал смотреть второй сезон Wednesday (который пока так себе).
- 🔥если тоже смотрите сериал
- 🤔если не смотрите

🕵️‍♂️ Где смотреть на метрики вашей команды

- Jira: без плагинов посмотреть на Throughput в задачах не получится и гаджетов для дешборда. Но есть решение ⬇️

- Jira Metrics Plugin (автор @akhakimov, hh.ru) - такой ультимативный плагин для хрома, читает данные с вашей Jira, причем безопасно (на сайте есть целый блок про секурность и его разрешают в этих ваших энтерпрайзах). Я даже у себя на его основе провожу обучение. Скоро будет AI-агент внутри с анализом и рекомендациями 🚀

- Predictable.team (это уже моё приложение): умеет кушать CSV / XLS выгрузки с Jira, Youtrack, кастомные форматы и визуализировать все flow-метрики. В дополнение - есть раздел с выводами по динамике команд и рекомендациям - что делать чтоб стало лучше. 🔮

- ActionableAgile: сильная визуализация флоу‑метрик (scatterplot cycle time, aging WIP, Монте‑Карло). Но для россиян доступ только через VPN. 📈

- Scope360: плагин для хрома и сайт, встраивается в Jira, но если есть Jira Metrics Plugin - будто б и не нужен. 🔭


📚 Список литературы

- Daniel Vacanti — Actionable Agile Metrics for Predictability [EN] — базовая книга по метрикам потока, aging и вероятностным прогнозам.

- Troy Magennis (классный дядька, автор блога observable hq) — вот тут инструменты и калькуляторы, вот тут статьи (что точнее) по прогнозированию и Монте‑Карло (Observable/Focused Objective)

- Bye Bye Velocity. Hello Throughput (статья на Scrum.org). Коротко о причинах сдвига от velocity/SP к потоку.

- Обзорные и критические материалы по SP (иллюзии измерения и сравнения между командами).

- Mike Cohn — Agile Estimating and Planning (полезно как набор практик).

#metrics

Всем привет! Сегодня продолжим покрывать основные метрики потока.

⏰ Lead Time (1/2): погружающий в базу пост.

Опять возьмем суши-бар в качестве примера. Опять приходим в пятницу и заказываем хенд-ролл с тунцом. Точкой отсчета мы считаем Commitment Point (когда ресторан берет на себя обязательство сделать нам хендролл - то есть время приёма заказа).

🍣 Так вот, Lead Time — в классическом понимании это время с момента заказа до момента, когда тебе подали заслуженную пищу богов после лютой рабочей недели. Всё, что тебе важно как клиенту, — когда эта еда окажется во рту и ты закроешь глаза от удовольствия.

👨‍💻В разработке то же самое: коммитмент сделан (пообещали что возьмете в работу) → взята в работу → разработана → протестирована → выкачена в продакшен → пользователь получает ценность. Иногда можно упростить до времени создания тикета, но тут надо быть осторожным и понимать где действительно начинаются ваши обязательства, и где вы ведете Discovery backlog.

💎Почему Lead Time одна из главных метрик потока?

- Это главный ориентир и для клиента ("когда будет готово?"), и для бизнеса (можно ли обещать релиз/фичу).
- По Lead Time видно, насколько реально наша команда быстрая (а не “про субъективную скорость”).

❓ А что и как считать-то?

Вот набралась у тебя статистика по времени завершения роллов / задач / чего угодно.
Когда задают вопрос про Lead Time, многие просто отвечают про “среднее время”.

❌Так вот, среднее в целом очень плохой показатель для анализа (например книжка Flaw of Averages). Среднее очень сильно подвержено выбросам данных, и не отражает реалий.

✅ Настоящие котаны и котанессы смотрят на перцентили вместо среднего. Нам для наглядности надо 50p, 85p, 95p.

- Для простоты - за какое время завершается 50% работы (50p или медиана), 85% работы (85p), 95% работы:
- 50p (медиана) показывает типичную работу. Например, мы можем стараться планировать на основе данных медианы.
- А вот 85p, 95p показывают не только “обычные” случаи, но и экстремальные ожидания.

💼 Примеры:

- "Среднее" время ожидания в суши-баре — 20 минут, но половина получает заказ за 10 минут, а часть ждёт по 40-50.
- Медиана (50p) покажет типичное время (10 минут), а 85p — насколько быстро обслуживают почти всех (40 минут). Это честнее и точнее — клиент меньше разочарован и команда видит, где реальные задержки.)

🏆 Самое главное для нас:

- Чем ближе 50p и 85p - тем вы предсказуемее.
- 85p не должен превышать 50p (медиану) в 3 раза. Но.. везде есть свои приколы и специфика домена.

🧩 Паттерны

- Если 85p намного больше медианы (пример во второй картинке присобаченной)— у вас есть “зависшие” задачи или бутылочные горлышки.
- Если 95p намного больше / выше чем 85p - есть какие-то супер специфические зависшие или зависимые от других команд задачи.

#leadtime #metrics

🚦Time to Market, Lead Time, Cycle Time и почему они про одно и то же?

Расставим точки над "i" после вчерашних дискуссий в @agileufa с Сережей (организатором @UfaJS)

🏗 Базовый термин времени производства: Cycle Time. Это супер-простая идея: выбери любую пару точек на процессе (начало и конец) и посчитай, сколько времени проходит между ними. Главное, после слов Cycle Time указать начало и конец цикла.

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

🧱 Как это работает на практике:

В IT и продуктовых командах часто под термином Cycle Time подразумевают время от момента, когда задача переходит в состояние “В работе”, до момента “Готово”. Это отражает длительность всех активных действий по задаче, исключая время, когда она находилась в бэклоге.

✅ Чтобы быть более точным, стоит обозначать этот показатель как Cycle Time (In Progress -> Closed), а не просто Cycle Time.

Какие еще циклы бывают?
- От “Идея!” до “Go Live” — Time to Market (общая скорость реакции компании на рыночные изменения).
- От “Будет сделано” до “В проде!” — Lead Time (качество планирования и уровень доверия клиентов).

❓ Зачем нам все это?

Если Time to Market, Lead Time не соответствуют нашим ожиданиям, то конкретные циклы внутри них (In Progress -> Closed, а может еще глубже: отдельно цикл Code Review / Ready for Testing / Testing) подсвечивают узкие места. Это наш базовый инструмент диагностики для понимания затыков в работе.

Что для нас по-настоящему важно: скорость вывода фичи на рынок, ведь это наша конкурентоспособность (будь мы внутренним продуктом/платформой или публичной компанией).

А еще большинство времени фича вообще ждет реализации в беклоге. Принимая решения на основе данных (время в беклоге или цикл Created -> Committed) мы можем существенно оптимизировать и балансировать наш поток работы.

🍰 TLDR

Cycle Time — универсальная линейка. Смотри на него под любым углом и всегда находишь способ точечно диагностировать, что реально происходит с вашей командой или продуктом.

⚠️ Очень важно, что Time to Market (а зачастую и Lead Time, и Cycle Time (In Progress -> Done) и мы все таки считаем у фичей (новый функционал приносящий ценность), а не у рядовых задач, которые делает кусочек нового функционала.

#timetomarket #cycletime #leadtime #metrics

👀️️️️️️ Друзья, делюсь планом контента с отпускными фото из Приэльбрусья ❤️🏔

- Посты про метрики были подготовкой к нашему митапу @agileufa в воскресенье. Уже 70 человек зарегистрировалось! Планирую завершить темы Lead Time, Aging и закон Литтла к концу недели.

- Хочу реже публиковать посты (раз в неделю) и больше обсуждать оргизменения, исследования и прогнозирования. Проголосуем?
- 👍 за посты реже
- 🔥 и так норм частота

- Метрики важны как база, в том числе чтоб делать разбор в моем инструменте прогнозирования: https://predictable.team

- Есть темы (кейсы / советы / обзоры), которые интересно было бы обсудить?