Marat @ Predictable.Team

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

Товарищи, если вы в Уфе - мы проводим митап 24 августа - там будет база по метрикам и большой воркшоп по паттернам этих самых метрик! Приходите 😉

А вы ради крутанского продукта как бы поступили? - 🔥остаться работать по 80 часов в неделю? - ❤️ или уйти, согласившись на 9 окладов? Cognition в прошлом месяце купила Windsurf (делают ИИ-разработчика) и теперь делает вот такие ультиматумы сотрудникам. CEO говорит: "Вот такая у нас экстремальная культура продуктивности". На хабре люди однозначно голосуют, что уволятся с 9 окладами :) https://habr.com/ru/news/935160/ #opinion

Дорогой дневник читатель! 📊 Сегодня покроем базу по метрикам (на примере с едой). Она супер-короткая. Но для начала договоримся: метрики это инструмент. На самом-то деле мы хотим предсказуемости и прогнозов на его основе! 🧑‍🍳 Ситуация: ты менеджер в пиццерии. Клиент спрашивает: “Когда будет готова моя пицца?” Что отвечаешь? “Скоро” или всё-таки можешь дать конкретику? 🔮 Любой прогноз = диапазон + вероятность “С вероятностью 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

🎯 Radical Product Thinking: Видение важнее итераций Подробный разбор здесь: https://teletype.in/@kiniabulatov/radical-product-thinking Преамбула: A/B тесты идут, фидбек собираем, каждые 2 недели релизим — а продукт всё равно какой-то странный получается. Про авторку: В 2021 году Радика Датт (MIT, 4 больших M&A) выпустила книгу, которая объяснила, в чём проблема (с ее точки зрения). Мы научились быстро итерироваться, но разучились ставить правильные цели (вот все как просто!). Книга описывает диагностику этих "болезней" и как это лечить. 🦠 7 продуктовых болезней Узнаёте симптомы? - Hero Syndrome (Синдром героя) — незаменимый человек в команде - Strategic Swelling (Стратегическое распухание) — продукт решает всё и сразу - Hypermetricemia (Гипер-метрик-иемия) — одержимость метриками, не связанными с прогрессом - Pivotitis (Пивот - когда меняешь концепцию или бизнес-модель( — постоянная смена направления без видения - Narcissus Complex (Комплекс нарцисса) — строим для себя, а не для пользователей 💊 RPT Framework: 5 элементов которые помогут выстроить правильный вижон - Vision → Strategy (RDCL)* → Prioritization → Execution → Culture RDCL = Настоящие, реальные проблемы пользователей + Как мы их решаем + Какие функции несем этим решением + Как масштабируем 👊 Противостояние подходов Vision-driven (Радика любит его) vs Iteration-led (это статус-кво подход) Vision-driven (Tesla): Чёткое видение изменений → итерации уточняют КАК достичь Iteration-led (GM): Краткосрочный фидбек диктует направление → локальные максимумы ⏳ Актуально ли в 2025? 4 года прошло, ИИ ускорил итерации ещё больше, в итоге без четкого компаса еще сильнее упарываешься в локальные максимумы. Метафора: чем быстрее едет машина без навигатора, тем быстрее ты потеряешься. А у вас какой подход? 🔥 - Итеративный ♥️ - Радикальный #books

🏗️ Built to Last: 30-лет прошло, все еще актуальна 🔍 по ссылке большой разбор, ну а тут кратенько мысли 📚 Что за книга В 1994 году два товарища из Стэнфорда потратили 6 лет на изучение 18 компаний-долгожителей. В итоге получился такой альманах принципов и признаков долгоиграющих компаний. Главные принципы компаний-долгожителей - 🏭 При создании организации выстраивай систему (культура + принципы+дерзкие цели), а не решай конкретную проблему концентрируясь только на продукте - ➕ Не выбирай между стабильностью ИЛИ прогрессом. Принимай И то, И другое. - 🌳 Preserve Core / Stimulate Progress. Метафора - дерево: корни (это стержень внутренних принципов и ценностей компании) должны оставаться неизменными, а вот ветви (стратегии, продукты) адаптируются. - ☦️ Cult-like Culture. Сильная культура в которую люто и бешено верят — не для всех, но объединяет "своих". (там упоротые примеры американского ритейла с cult-like культурой - аж дрожь берет) 🧪 Try a Lot / Keep What Works. Эволюционный подход: постоянные эксперименты, естественный отбор идей. 🚀 Актуальность сегодня Сейчас итерации везде, продукты создаются за недели, а данные торчат из всех дашбордов и демократизированы. Agile - так это вообще мейнстрим. Но если хочешь enable-ить в своей организации возможность продуктивно работать удаленно, держать текучку на минимуме, иметь деньги на эксперименты и инновации - тут без выстраивания системы не обойтись. И культура, которая позволяет этой системе работать - стержень, без которого организация не будет работать десятилетиями (с другой стороны, а зачем работать десятилетиями? но это уже совсем другая история). Наш любимые FAANG: Apple, Amazon, Google — используют именно философию, схожую с Built to Last на уровне организаций. Выстраивают культуру и систему, которая поддерживает пайплайн продуктов и экспериментов. Такая организация и есть отдельный тип продукта (который можно попытаться создавать, если следовать принципам в книге). 🍺 Мысля: Подумал, что как Agile Coach ты так и так работаешь с культурой организации. чтобы люди, которые занимаются продуктами имели среду где можно продукты творить эффективно и фокусно. Так что нам как людям, работающим с e2e потоком ценности (не только одного продукта, а людей и организаций эти продукты создающих), в любом случае жить можно только в парадигме принципов, похожих на те, что описываются в Built to Last 🤝 МИФ | Amazon | Audible #books

В последние три месяца добрался до своего списка литературы и прочел две давно лежавшие на полочке книги. 📚 Built to Last (EN, RU) и Radical Product Thinking (EN) - это два разных взгляда на создание продуктов. В одном случае организации как продукта. Вторая книга - именно про продукт в его классическом понимании. 🏗 В «Built to Last» - большое исследование того, как строить компанию, которая выдержит испытание временем. Там даже основная метафора - как не определять время (продукт), а уметь строить часы, которые переживут тебя самого. Больше внимания уделяется культуре, ценностям и постоянному улучшению, а вот резкие революционные прорывы поощряются в меньшей степени. 📈 С другой стороны, «Radical Product Thinking» больше про подчинение продукта строгим метрикам и ориентацию на быстрые, ощутимые результаты, суперфокус. То есть там подход более жёсткий, сфокусированный на эффективности и достижении конкретных целей. Там есть рабочая тетрадка и алгоритмы и таблица для работы с достижением целей продукта. 🤯 На контрасте читать очень интересно, потому что сначала соглашаешься и строишь в голове фрейм под одну книгу, а потом вторая его подвергает сильной критике. А потом понимаешь что это про два аспекта одного и того же. Так как прочел последовательно, сделаю небольшой разбор относительно друг-друга в постах ниже. 👇

Друзья, для следующих постов хотите: (реагируйте) - 🔥 Почитать про кейсы метрик и эффективности команд - 👍 Фасилитацию (как сделать встречи эффективными) - 👏 Обучение и тренинги - что-то еще (в комментариях)

⚛️ Броуновское движение + Бинго: как за 15 минут познакомить 90 человек Представьте: 90 человек в зале, все из разных отделов, которые работают над одним страт проектом. И нужно их быстро "растопить". "Представьтесь по кругу" — тут точно не подойдет (будет долго и нудно). Есть классный инструмент: Броуновское движение (к которому можно добавить бинго-карточки для геймификации). Как итог, за 15-20 минут люди 4 раза знакомятся с незнакомыми людьми, да еще и получают призы. Стоит это буквально 0 денег (ну или 3к рублей, если вы хотите купить красивые беджики и 🍯 баночку мёда в подарок). Короче говоря: энергия взлетает, люди смеются, а знакомств происходит много одновременно. Полный разбор с инструкцией, скриптом и шаблоном бинго — в статье: https://teletype.in/@kiniabulatov/brown-movement-technique

Минутка оффтопа про AI. Мы тут все думаем, что ИИ нас ускоряет (таким гуманитариям как я это точно сильно помогает создавать прототипы). Но на деле, если говорить про реализацию решений в продакшне все иначе: компания METR взяла небольшую выборку из 16 опытных разработчиков, использование ИИ снизило их скорость выполнения работы (наш любимый Lead Time) на 19%. Подробнее тут: https://habr.com/ru/news/927436/

🧵 Вдогонку про Pre-Mortem по страт проекту на 90 человек. Я недокрутил саму подготовку, потому что делал фасилитацию на коленке (на то были причины, но зато появился материал для поста ;) (тут подробный разбор где недокрутил). База: Подготовка это 80% работы. Для этого мы используем правила "5 П", прорабатывая который мы предвосхищаем 95% всех проблем во время фасилитации. 🎯 Поставленная цель • Какую проблему решаем и почему сейчас? • Спросить не только заказчика, но и других стейкхолдеров 📜 Продукт (результат) • Что конкретно получим на выходе? • Не «обсудили риски», а «топ-3 риска с вот такущими планами митигации и когда уже начинать будем» 🤼‍♂️ Приглашённые люди • Кто будет? Сколько человек? • Какой у них опыт, взаимоотношения и уровень доверия? ❓ Проблемы • Что может вызвать споры и конфликты? 📊 Процесс • Временные ресурсы, формат (очно/онлайн) • Флипчарты, стикеры, маркеры, права в фигме или миро — что нужно? 🔥 Preheat (бонус-пункт) Письмо участникам за неделю: «Подумайте заранее о 2-3 конкретных рисках». Без этого люди приходят «холодными» и начинают с нуля. Такая вот "лидогенерация" нормальных ответов. Главное правило: чем сложнее задача для группы, тем больше времени на подготовку. 🏥 По ссылке разбор, где я недоготовился по 5П 🙂

Как провести сессию на 90 человек и не получить на выходе список банальностей? Делюсь свежим кейсом: большая встреча, 4 отдела, стратегический проект. Задача: познакомить и собрать риски. Что сработало на ура, а где мы поймали антипаттерн «за всё хорошее, против всего плохого»? И главное — почему это произошло. Внутри статьи — честный рассказ о граблях фасилитатора и о том, как на них не наступать: https://teletype.in/@kiniabulatov/facilitate-90-ppl А вы себя на мысли ловили, что встреча вроде прошла успешно, но осталось ощущение, что «могли бы копнуть глубже»? Делитесь в комментах! 👇

⚠️ Холиварим про Story Points: инструмент планирования или источник проблем? Я вот уже 7 лет веду воркшопы по оценке задач в стори поинтах, и вот тут такие наблюдения: 🔍 Что показывает практика: - Только 20% команд эффективно используют Story Points после обучения (при замере через три месяца). - Чем крупнее компании (сейчас в моем отделе 400+ разработчиков) - тем меньше команд применяют SP. А те кто применяет, применяют их кто в лес, кто по-дрова. - В FAANG-компаниях Story Points используют редко (и вроде бы не умирают). Кроме того, в скраме нет никаких упоминаний о Story Points, это пришло от одного из авторов XP (Рона Джефриза, как поправил меня Андрей из enabling.team) и за это уже извинились. ⚡Основные проблемы для меня со Story Points: - Требуют постоянной поддержки — без слежки за командой скрам-мастером, команды быстро теряют навык, эталонные шкалы протухают. - Не всегда отражают реальность — задача в 3 SP может затянуться, а в 8 SP — решиться быстро. - Сложно масштабировать — каждая команда "калибрует" оценки по-своему. 🛞 Альтернативный нейтральный путь: Story Points + flow-метрики (Cycle Time, Пропускная Способность (Throughput), Состаривание (Aging)) могут давать сопоставимую точность прогнозов. 💣 Альтернативный радикальный путь: Только flow-метрики. 💡 Короче говоря: SP отлично работают для внутреннего планирования команды, но для долгосрочных прогнозов стоит рассмотреть метрики потока и прогнозирование через симуляцию Монте-Карло. 🤔 А как у вас в команде? Используете Story Points или пробовали другие подходы к планированию? Поделитесь опытом! Пост на хабре | в личном блоге

🤟️️ Всем хаумы ("привет" на башкирском) Меня зовут Марат. Я занимаюсь оптимизацией процессов и data-driven изменениями в АйТи и всех смежных с ним областях. Я работаю в крупном финтехе Agile-коучем (linkedin), отвечаю за эффективную работу и взаимодействие на периметре 45 команд. До этого я работал как Program Management Lead, Delivery Lead, COO в SaaS в разных индустрия. В этом блоге я делюсь кейсами и своей экспертизой по: ✅ Фасилитации - Как провести сессию на 90 человек и не получить на выходе список банальностей? - Правила подготовки к фасилитационной сессии через 5П - Броуновское движение + Бинго: как за 15 минут познакомить 90 человек - Фасилитация технически сложного воркшопа в душном простратстве: Context Engineering на 50 человек 🔮 Прогнозирование, метрики потока - Какие инструменты мониторинга и визуализации метрик есть, и где прочитать книжки по метрикам? - Холиварим про Story Points: инструмент планирования или источник проблем? - База по метрикам потока: Throughput, Cycle Time, Aging - Throughput: о чем метрика, какие временные промежутки использовать | как анализировать срезы по типам работы, почему Throughput универсальнее SP, паттерны метрики - Lead Time: база, 50 и 85 перцентили и их паттерны | анализ срезов Lead Time по типам задач - Кто такой этот ваш Time to Market, и как он соотносится с Lead Time, Cycle Time? - Friday-funday: Нестандартные и упоротые метрики 🏗 Product Operations - Уходим от заваливания пользователей фичами (feature factory) к оптимальной поставке - Как операционализировать Discovery, выстроить pipeline фичей, сбалансировать разработку с продажами и маркетингом и сократить time to market 🤖AI - Как AI потенциально замедляет разработчиков 📚Книжечки - Мой микро-обзор на Radical Product Thinking (Radica Dutt) и актуальность в 2025 - Built to Last (Jim Collins, Kerry Porras) - исследование компаний, которые успешно живут десятилетями и инновируют Context Engineering Зачем он нам | Техники работы с контекстом | шпаргалка: когда что применять / План фасилитации воркшопа по теме ➕ Еще у меня есть: - свой коворкинг (ufaitcoworking.ru) - я основатель сообщества (@AgileUfa) - мой инструмент для анализа метрик: predictable.team - мой блог на английском (kiniabulatov.com)

Не ждали? А вот оно, возвращение в тг-канал с громким заголовком: "Как Product Ops и метрики потока сократили время разработки фичей в 4 раза" Хочу поделиться интересным кейсом, как выстроенные процессы операционной работы над продуктовм (Product Ops) помогли нам в Metamap в 2022-2023 сократить время реализации фичей с 244 до 93 дней. В чем была проблема? Классическая ситуация: продажники обещают клиентам новые функции, инженеры не успевают их реализовать, приоритеты постоянно меняются, короче - все недовольные и злые. Если измерить время реализации большинства фичей - оно достигало 8 месяцев! Для стартапа с ограниченным финансированием это катастрофа (я пару лет назад писал что наступила венчурная зима). Чего мы сделали: выстроили процесс Product Ops через метрики потока: 1️⃣ Провели STATIK*-воркшоп STATIK-это стандартный инструмент внедрения Kanban. Это фактически несколько этапов, на которых мы рисуем наш e2e процесс, смотрим на бутылочные горлышки, обсуждаем текущую картину (и в идеале To Be картину). Я будучи Product Ops-лидом провел воркшоп, собрав вместе отделы продаж, продукта и разработки. Мы совместно составили карту реального рабочего процесса от рождения идеи до замера её эффективности на проде. Ну и выявили узкие места, разумеется. 2️⃣ Создание единого источника правды Для трекера / тикетной системы мы выбрали Jira Product Discovery - тогда еще сырой и в beta-версии, он уже умел интегрироваться с кучей инструментов и давал возможность сделать ICE/RICE. Так, все запросы на фичи оказались собраны в одном месте с интеграцией с Salesforce, Gong (система звонков и продаж), HubSpot. Это обеспечило полную прозрачность для всех отделов: тыкаешь в Idea / Feature Request в жире - видишь сколько денег принесет идея, какие клиенты её хотят, какой горизонт прогноза прибыли. 3️⃣ С боем и кровью договорились про правила приоритизации Правило "3×3": 1. функция продвигается только если её запросили 3+ активных клиента, 2. с ожидаемым ARR (Annual Recurring Revenue - ожидаемая прибыль, которая повторяется каждый год) выше порогового значения 3. Фича прямо связана с ключевыми метриками продукта (от которых у нас построены цели на год+). 4️⃣ Визуализировали ключевые метрики потока • Пропускная способность (Throughput): количество реализованных фичей в месяц • Время цикла (Cycle Time): с целью не более 90 дней • Ограничение WIP: не более 2 фичей на команду одновременно Почесали репу, посмотрели на данные исторически: Инженерная команда могла обработать только 1/4 поступающих запросов, и визуализация этого факта помогла обосновать необходимость жестких правил приоритизации. В итоге получилось вот что: ✅ Время выполнения сократилось в 2,6 раза (до 93 дней) ✅ 76% выпущенных фичей напрямую связаны с ключевыми метриками (было ниже 40%) ✅ Продажники перестали обещать нереализуемые сроки (ведь мы потом смотрели на данные и проверяли прогнозы) ✅ Выросло доверие между отделами (это, наверное, стало самым классным инструментом синергии внутри компании) Итого, вот вам рецептик: 1. Интегрируйте системы для создания единой картины (CRM + тикет-система) 2. Визуализируйте метрики потока для всех отделов — это устраняет эмоции и домыслы 3. Внедряйте строгую дисциплину приоритизации 4. Обязательно измеряйте результат после внедрения фичей Если ваша команда страдает от затянутых сроков разработки и конфликтов между отделами, внедрение Product Ops-подходов с фокусом на метрики потока может стать решением проблемы. Тут у Анвара есть целый пост про книжку про Product Operations.