Marat @ Predictable.Team

💎WIP Aging — самая важная метрика потока 🪦 Посмотрите реальный пример на скриншоте выше - там состарилась целая свора задач, какие-то явно протухли. WIP (work in progress) Aging — это количество времени, которое задача уже провела в работе, но еще не завершена. Помогает понять, где работа "застревает" в процессе и сигнализирует о рисках для потока. Мы считаем начало "в работе" как точку, когда вы втягиваете в свою систему работу (у разных команд она может разная). 📈 Где посмотреть: - Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда) - Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging 👆 Почему это важно? - Чем дольше задача "стареет" в потоке, тем выше риск, что она устареет для бизнеса, попадёт в зависимости, или просто потеряется ценность работы. - Следить за Aging надо до завершения задачи - ваш шанс оперативно реагировать на проблемы в процессе, а не ждать, когда цикл завершится и станет "слишком поздно" для улучшений. - Всё в Kanban — визуализация, блокировки, Pull-политики — заточено на то, чтобы не позволять задачам стареть без необходимости. 🕸 Какие основные паттерны Aging встречаются в практике? - Стабильный рост: WIP Aging растёт равномерно — признак стабильного процесса и правильных WIP-лимитов. - Плато или затор: Aging резко увеличивается на каком-то этапе — вероятен bottleneck или проблемы формата слишком крупных задач. - Волнообразные скачки: Aging периодически ускоряется — возможны внешние зависимости/нестабильность команды. - Разделение на мелкие задачи: Когда Aging сигнализирует о "застрявшей" задаче, best practice — разделить её на более мелкие части. - Экспоненциальный рост: Очевидная перегрузка WIP — новые задачи начинают быстрее, чем завершаются старые. Tips & Tricks: - WIP Aging — один из лучших ранних индикаторов проблем (если выбирать одну метрику, то Aging — самая полезная для начала). - Комбинируйте её с Lead Time и Throughput, чтобы видеть общую картину. Lead Time = ваш исторический SLA, а Aging - возможность увидеть в realtime что сейчас пробьёт SLA. - При превышении допустимого возраста задачи — обсуждайте и разбивайте крупные работы. Например, начинайте разбирать все, что выше 85-перцентили. - Правильно используйте WIP-лимиты: лимит не спасёт, если не анализировать aging, а просто "сжимать поток". 📝 Хотите большую большущую детальную статью про Aging? - На VC недавно вышла статья про опережающий индикатор: WIP Aging от Васи Савунова. 📈 Где посмотреть: - Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда) - Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging #aging #flowmetrics

Вот вам мемчик в тему 👆

Если на прошлой неделе я ресерчил - какие китайские альтернативы Nvidia скоро появятся. То на этой - а сколько ведущие страны-производители полупроводников вкладывают (государственных и частных денег) в ИИ-железки. И сравнил с Россией. При сохранении текущей ситуации мы доберемся до стран-лидеров никогда (но может и не надо и будем пользоваться китайским железом). Сейчас у нас все железки по старым техпроцессам и в основном для военки. https://habr.com/ru/articles/948144/

Как правильно прогнозировать, когда команда закончит следующие X задач и причем тут прогнозирование через симуляцию Монте-Карло? ❌ Точную дату говорить не надо "Эпик будет готов ровно через 42 дня" — это неправда. ✅ Правильный прогноз: 10 задач за 35-45 календарных дней, где: - 35 дней = 50% вероятности - 45 дней = 85% вероятности У любого прогноза есть - Разброс, - Вероятность, - Мы предполагаем что работа в будущем будет похожа на работу в прошлом. Работает следующим образом: - 1️⃣ Собираем историю throughput команды - 2️⃣ Запускаем 1000+ симуляций со случайной выборкой - 3️⃣ Получаем распределение вероятностей Главное условие: нужны WIP-лимиты! "Нет WIP-лимита = нет потока = нет предсказуемости" — Daniel Vacanti 👩‍🔬 Исследования и материалы: - 🖥 На прикрепленной картинке пример прогноза из приложения: Predictable.team (я когда-нибудь переведу его на русский) — загружаете CSV из Jira (или demo data) и тыкаете во вкладку Монте-Карло. - ActionableAgile доказали: простая случайная выборка работает лучше сложных алгоритмов. - Российские кейсы (Тинькофф, SportMaster) подтверждают точность 80-90%. - Daniel Vacanti "Actionable Agile Metrics". - Моя статья на Хабре - Материалы на Scrum.ru, Neogenda. Впрочем, это все неважно если продажники уже подписали контракт, обещая новую фичу клиенту. Но хотя б вы им покажете данные.

📚 Книжка "Неслучайная случайность: как управлять удачей и что такое серендипность." (en: The Serendipity Mindset: The Art and Science of Creating) 🦋 Долго и нудно, на протяжении 300 страниц автор предлагает видеть необычное в обычном, быть “открытым к неожиданностям” и прокачивать тот самый serendipity – “искусство счастливых случайностей”. Не рекомендую. 🔍 Короткий обзор и духота от меня В 2020 году профессор Кристиан Буш решил легализовать удачу (мол, это не просто "удача", это целый процесс) и описал новый “майндсет” поиска возможностей в хаосе. 🎱 Основа - принципы “серендипного” мышления: - Будь внимательнее: замечай детали, на которые обычно бы не обратил взор (развивай внимание, периферийное зрение и вот это всё). Тут про насмотренность и осознанность. - Мысли с разных сторон: рассматривай привычные ситуации с других сторон (в идеале — не только своих). Тут как бы просто про критическое/латеральное/ дивергентное мышление. - Расширяй связи: общайся шире, спрашивай про “что-то еще” в Small Talk — вдруг подвернется “касание удачи”. Я переведу - просто будь экстравертом и делай нетворкинг. - Порождай триггеры: вместо “Я маркетолог” во время знакомста удиви (вау) всех словами — “Я изучаю поведение людей, делаю подкасты, люблю сканди-детективы” — и смотри, к чему это приведет. Именно так люди запоминают тебя лучше и образовываются связи. - Не жди чуда, а сам создавай предпосылки: чем больше действий, тем выше шанс “случайного” открытия (но это не точно). Ну чем не проактивность. ☦️ К чему скепсис (мой) Неплохо, что тут есть практики self-reflection и упражнений в конце каждой главы. Но если коротко — почти всё, о чем пишет Буш можно найти в любой self-help литературе. Много историй уровня “один парень что-то сделал -> случайно повезло -> теперь миллионер”. Сама идея, что “сознательно можно тренировать удачу”, не нова. Но в этой книге глубокое знание и эрудиция как фундамент серендипности — отодвинули на второй план. Зато техник, сторителлинга который бесконечно повторяется — с лихвой. "Видеть возможности в случайностях”, как говорит автор, всегда полезно — особенно если крутишься в стартапах или креативных продуктах. Но никакой “серендипный майндсет” без системного подхода, осознанности, привычки критично смотреть на вещи и работы с культурой не жизнеспособен Ozon / Альпина / Амазон PS: Лучше прочитайте эту "Неслучайную случайность"

Воскресное чтиво: Какое есть ии-железо в Китае на замену Nvidia (и насколько они мощные). https://habr.com/ru/articles/944548/ Я на работе занимаюсь внедрением AI в разработку. И интересуюсь ИИ-темой во всех ее проявлениях. И ROI, и adoption, и в целом насколько это реально помогает командам разработки. На выхожных читал статью, на которую наткнулся в канале The Edinorog - какие в Китае есть производители ИИ чипов. Перевел статью и добавил мяса (ато как-то неинтересно без деталей) - какие по техническим характеристикам есть чипы в сравнении с Nvidia A100/H100 , AMD Ryzen.

🚀 Вы только посмотрите до чего дошли технологии. Из статьи можно делать видео-презу с аудио и графиками, причем качественно и автоматически! Вчера, интереса ради закинул свою статью про Прогнозирование с помощью симуляции Монте-Карло с Хабра и попросил сделать NotebookLM видео-обзор (я уже писал для чего использую NotebookLM). 📹 Так он сделал целую презу с хорошим визуалом, нарративом (пусть и излишне оптимистичным). Такое можно хоть на youtube запихивать! Воистину, как пела SuperAlisa, "Безнен жирда жана технологиялар" (на нашей земле горят технологии) в своем шлягере "Су Анасы". 🙄 Если кому-то было лень читать и вы не в числе 2,4к прочитавших -> ролик-преза на английском (на русском он пока не могёт).

У меня тут вышел большой практический гайд на Хабре про Throughput (динамику и паттерны) и прогнозирование симуляцией 🎲 Монте-Карло. 🔍 Разбор Throughput со стороны - Значимых периодов и частоты замеров - Вариативности - Кластеризации по типам работ 🤖 Алгоритм составления прогнозов через симуляцию Monte-Carlo на основе Throughput - Когда будут готовы следующие 50 элементов + Обзор инструментов визуализации и прогнозирования + Почему Throughput уже учитывают вариативность в работе команде + Почему Story Points менее эффективны для прогнозирования https://habr.com/ru/articles/940882/ #mcs #montecarlo #throughput #forecasting

🎓 Про Notebook LM. Back to school (как в песне Deftones), так сказать. Общаемся с книжками, слушаем ИИ-подкасты, провоцируем шизофрению. Где-то год назад я открыл для себя NotebookLM*, это инструмент от гугла который достаточно сильно поменял мой подход к изучению информации. Фактически это, да простят меня технари, RAG-модель от Google. Она превращает ваши документы в умного собеседника. Теперь не надо листать книгу или PDF, в поисках цитаты. 🥸 Как это работает: 1. Загружаешь до 50 источников — Книги, статьи, видео YouTube, Google Docs. 2. Спрашиваешь что угодно — он отвечает ТОЛЬКО на основе загруженных документов. 3. Получаешь точные ответы со ссылками на источники! 💡Мои сценарии использования: - Изучаю как разные источники рассматривают одну и ту же проблему — закидываю, к примеру, книги по платформенным командам: Team Topologies, Platform Engineering, Scaling Teams (изучаю тему платформ). - Product research — собираю пользовательский фидбек на разные инструменты, нахожу паттерны - Academic Research - можно не грузить самому, а попросить инструмент походить по академическим источникам и составить список материалов, на которые он будет опираться. 🍰 В итоге: Экономия времени, никакого муторного поиска. И всегда супер-явно можно сослаться на данные из конкретных источников. 🎧 ИИ-подкасты А еще там есть генерация подкастов из ваших материалов! Это уже совсем космос и шизофрения, но я этим пользуюсь. Закинул три книги по теме, попросил сделать подкаст - и там два ИИ-хоста обсуждают твой материал * чтобы пользоваться из России, надо зайти "не-из-России"

Маленький пост, важная и очень простая тема. 🦾 Закон Литтла - универсальная взаимосвязь метрик потока Мы с вами прошлись по Throughput, Lead Time - а как они взаимосвязаны, есть ли формула? Да, закон Джона Литтла! В следующий раз, когда ваш менеджмент/команда будет говорить "да давайте напихаем побольше в спринт" - покажете что это приведет к определенным последствиям. 📜 Чем больше у вас элементов в работе (Work In Progress, WIP) - тем дольше вы делаете каждый элемент (Lead Time) и тем меньше элементов выпускаете (Throughput). 🍣 Что такое WIP на примере суши‑ресторана WIP — это сколько заказов одновременно «висят» в работе на кухне: повара режут рыбу, варят рис, собирают роллы. Если взять в работу слишком много заказов сразу, очередь расползается, каждый заказ «готовится» дольше, клиенты ждут и нервничают. Если удерживать разумное число параллельных заказов, кухня идёт ровнее и предсказуемее: гости получают еду быстрее, а команда — меньше стресса. 💻 А в IT? В айти также. У команды куча недоделанных задач? Ну так а зачем размывать фокус и брать все подряд, контролируй количество параллельной работы! 👌 Простота и универсальность Логика закона Литтла тривиальна в использовании и не требует спецподготовки. В практике она превращается в один вывод: чтобы lead time был меньше, а throughput — выше, нужно не раздувать параллельную работу. Слишком много начатого — значит, мало законченного и долгое ожидание. 🛣 С чего начать с WIP‑лимитов - Базовая настройка: стартовать с WIP примерно «размер команды + 1». - Наблюдать пару итераций: если throughput растёт и lead time сокращается — можно пробовать аккуратно снижать WIP дальше. - Если при снижении WIP throughput падает — лимит задушили, верните на шаг назад. 👨‍🦰Так что наматываем на ус правило: ограничивая параллельную работу, мы управляем и временем поставки (lead time), и пропускной способностью (throughput).

Пятничный лайтовый-пост. Самые нестандартные (и местами трешовые) метрики. Из коллекции “2 Dozen Weird Agile Metrics Ideas” — это подборка странных и забавных способов замерять "эффективность" команд, которой поделились PM-ы, agile-практики и коучи на projecttimes.com. Всё серьёзно: авторы статьи честно пробовали внедрять эти метрики в реальной жизни — иногда для фана и командного духа, иногда чтобы взглянуть на процессы с необычного ракурса. Вот топ-10 из подборки “2 Dozen Weird Agile Metrics Ideas”: 🗑 Количество фич, удалённых (не отмененных) из бэклога (а может, и из прода) — иногда главное не сделать, а вовремя удалить ❌ Количество остановок продакшна (stop the line events)? ❓ Сколько пунктов из ретро реализуют реально? (Легенда гласит, что кто-то доводил до 3 из 10) 🤟 “Коэффициент user stories с нулём багов” — чем ближе к 100%, тем веселее обсуждение! 🤣 Время до первой шутки на дейли — автоматизация для души. ☕️ “Индекс кофеина” — сколько кофе на команду за спринт vs сколько багов в релизе? 🐞 Число багов, найденных после релиза vs до — здесь всегда есть над чем посмеяться и задуматься. ✍️ Дедлайны, на которые подписались абсолютно все… Если такое было — команда получает +10 к карме! А если еще и смежным командам было ок, это какие-то единороги. 🔥 Количество историй, переписанных после демо PO — "индекс выгорания продакта". ✋ Число креативных ICE-breakers подряд на ретро (иногда с этим очень перебарщивают). С одной стороны это забавные показатели на поржать (и про процессы в организации где такое вводят, и просто). С другой - можно посмотреть на команду под новым углом, и с шутками-прибаутками вовлечь команду в обсуждение реальных проблем. Они отлично подходят для ретро, помогают снять напряжение и поднять важные темы, но не должны становиться самоцелью или поводом для токсичности. Главное не вести по ним отчетность :) ❓ У вас был опыт с какой-нибудь упоротой метрикой?)

Часть третья про Lead Time (база тут, про связь cycle time+lead time+time to market тут). Обсудим кластеризацию типов работы, динамику, гистограммы и диаграммы рассеивания, end 2 end. Дорогой друг, давай прям на практике пройдёмся по показателям: - Открываем в хроме https://predictable.team, нажимаем на Try with Demo Data, и кликаем на вкладку Lead Time. На графике Scatteplot показывается, за какое время завершается 50% задач (median), а за какое 85%. 🏄‍♂️ В Lead Time динамика всегда важнее текущего состояния Один раз замерить lead/cycle time полезно. Но если хочешь реально улучшать показатели надо смотреть в динамике на типы работы (прямо как в throughput). 🎳 Кластеризуй Lead Time по типам работы (потому что они все разные) На практике, чаще показывают гистограмму Lead Time. Но мне субъективно кажется что в ней не хватает временной динамики, поэтому я люблю диаграмму рассеивания (scatterplot, control chart в Jira). - Баги — обычно устраняются быстрее (у них часто самые короткие lead time). - Полноценные end-2-end стори — куда длиннее, иногда с кучей согласований. - Инциденты — вообще особый поток, SLA, жёсткое реагирование. Посему смотрим на динамику в два шага: 1. Общая динамика (вкладка Lead Time) 2. Динамика по классам задач. Для этого в верхнем меню можно менять набор "Issue Types". Так мы поймем - на общую динамику повлияло просто то что у нас стало больше багов, которые мы решаем за короткий срок, или все таки стори стали меньше и эффективнее проходят через цикл разработки. 🧩 Цикл твоей команды ≠ end-to-end всего потока ценности. Оптимизировал поток своей команды вместе с ребятами, далаете свои задачи быстрее? Молодцы, но зачастую на всем end-2-end потоке работы ваша оптимизация будет локальной (то есть расширить самые медленные бутылочные горлышки и простои в сквозной системе всегда будет эффективнее, чем оптимизировать какую-то только подконтрольную вам часть). Мыслите системно: что надо сделать чтоб вся система быстрее работала, а не только ваш кусок, который потом упрется в соседний отдел. Обычно сэкономленное время (благодаря вашей оптимизации) меньше, чем время которое вы теряете из-за простоя задачи между смежными командами (делающими со-зависимый функционал). #leadtime #cycletime #timetomarket #метрики #metrics #flowmetrics

👀️️️️️️ Друзья, делюсь планом контента с отпускными фото из Приэльбрусья ❤️🏔 - Посты про метрики были подготовкой к нашему митапу @agileufa в воскресенье. Уже 70 человек зарегистрировалось! Планирую завершить темы Lead Time, Aging и закон Литтла к концу недели. - Хочу реже публиковать посты (раз в неделю) и больше обсуждать оргизменения, исследования и прогнозирования. Проголосуем? - 👍 за посты реже - 🔥 и так норм частота - Метрики важны как база, в том числе чтоб делать разбор в моем инструменте прогнозирования: https://predictable.team - Есть темы (кейсы / советы / обзоры), которые интересно было бы обсудить?

🚦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

Всем привет! Сегодня продолжим покрывать основные метрики потока. ⏰ 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

🛠️ Инструменты мониторинга метрик команды и что почитать по теме. Начал смотреть второй сезон 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

Мы уже увидели, как 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

🍣 😊 Лайк, если тоже любите суши! 📈 Сегодня детальнее про 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

🔥 Наконец-то определились с датой и местом! Agile Ufa - митап в августе: Командные метрики в agile/lean (какие бывают, как измерять, как действовать на их основе) 🗓 Дата и время: 24.08.2025, 11.00 — 14.00 🗺 Место проведения: Территория 3000, Малый Конференц-зал (Менделеева 134, корпус 7) 📌 Agenda: - 🎙 База по метрикам и какие инструменты есть чтобы их собирать из коробки. - 30 минут (Марат Киньябулатов, Райф) - 🏓 Воркшоп по паттернам метрик в группах, оптимизация показателей. - все остальное время (проводят эксперты Agile Ufa: Айгуль Камалтинова (Альфа-Банк), Костя Шибков (СДЭК), Саша Пальгова (Калуга-Астрал)). 🌟 Формат: доклад + панельная дискуссия + нетворкинг на местах. Разберём живые кейсы, пообсуждаем, что «работает у нас», и снова вернёмся с пользой к общению в офлайне. 🎟 Участие, как всегда, бесплатное — только зарегистрируйтесь заранее на Timepad! (если кому надо прямую ссылку - вот https://agile-ufa.timepad.ru/event/3450918/) Подвал: - 👥 Новости и апдейты в сообществе @agileufa - 💻 Финансовая поддержка - Ufa IT Coworking (приходите, у нас есть места и айтишники на поболтать) Забабахаем Data-driven завершение лета.☀️