Marat @ Predictable.Team

🤟️️ Всем хаумы ("привет" на башкирском) Меня зовут Марат. Я занимаюсь оптимизацией процессов и 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.