📐💰 А как часто вы замеряете как перформят ваши фичи после релиза?
Очень многие компании грешат штампованием фичей, а на аналитику до и после никто не смотрит. Вот и получается, что потратили условные $10.000, а за год заработали около $3000. То есть инвестируете - инвестируете как организация в команды инженерки, а на выхлопе оно даже не окупается (и это только инженерка, маркетинг и продажи тоже кучу денег стоят).
И вот когда начинаются проблемы с деньгами, обычно только тогда организации начинают думать про оптимизации, про "эффективную" работу. Можно оптимизировать инжиниринг и бесконечно улучшать разные метрики, но если у вас от продактов приходит нечто, не очень-то и нужное клиентам, то и выхлоп после релиза будет никакой.
Последний год мы переходили в Metamap.com на рельсы продуктового подхода, уходя от паттерна feature factory. Где-то было плохо, где-то получше, но основная табличка и инструменты из этого поста родились благодаря этому опыту.
Самое забавное, что сейчас при консалтинге другой компании, мы идем по тем же шагам и сталкиваемся с теми же антипаттернами - вот, к примеру, фича которую выкатили клиентам несколько месяцев назад была тыкнута клиентами буквально пару раз, и так и не используется.
https://vc.ru/s/proddev/867747-hvatit-zavalivat-polzovateley-novymi-fichami-nachnite-uzhe-schitat-roi
Очень многие компании грешат штампованием фичей, а на аналитику до и после никто не смотрит. Вот и получается, что потратили условные $10.000, а за год заработали около $3000. То есть инвестируете - инвестируете как организация в команды инженерки, а на выхлопе оно даже не окупается (и это только инженерка, маркетинг и продажи тоже кучу денег стоят).
И вот когда начинаются проблемы с деньгами, обычно только тогда организации начинают думать про оптимизации, про "эффективную" работу. Можно оптимизировать инжиниринг и бесконечно улучшать разные метрики, но если у вас от продактов приходит нечто, не очень-то и нужное клиентам, то и выхлоп после релиза будет никакой.
Последний год мы переходили в Metamap.com на рельсы продуктового подхода, уходя от паттерна feature factory. Где-то было плохо, где-то получше, но основная табличка и инструменты из этого поста родились благодаря этому опыту.
Самое забавное, что сейчас при консалтинге другой компании, мы идем по тем же шагам и сталкиваемся с теми же антипаттернами - вот, к примеру, фича которую выкатили клиентам несколько месяцев назад была тыкнута клиентами буквально пару раз, и так и не используется.
https://vc.ru/s/proddev/867747-hvatit-zavalivat-polzovateley-novymi-fichami-nachnite-uzhe-schitat-roi
Please open Telegram to view this post
VIEW IN TELEGRAM
vc.ru
Как перестать заваливать пользователей новыми фичами и начать считать приблизительный ROI? — Marat Kiniabulatov на vc.ru
Стартап-индустрия в 2022–2023 годах, мягко говоря, оказалась между молотом и наковальней. С одной стороны, многие бизнесы начали сжиматься (а ставки центробанков расти), с другой — венчурные фонды почти перестали инвестировать. Начались сокращения, стартапы…
👍3🔥1
Не ждали? А вот оно, возвращение в тг-канал с громким заголовком:
"Как 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.
"Как 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.
🔥9❤1
🤟️️ Всем хаумы ("привет" на башкирском)
Меня зовут Марат. Я занимаюсь оптимизацией процессов и 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)
Меня зовут Марат. Я занимаюсь оптимизацией процессов и 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)
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Marat @ Predictable.Team
🛠️ Инструменты мониторинга метрик команды и что почитать по теме.
⠪⢑⣀⢨⠉ ⠸⠅⣂⡌⠡⠜⢔⠢ ⠪⠑⠸⠒⠦⠡ ⠊⠋⠓⡌⢌ ⢂⠰⡠⠲⠤⠇⡉⡑⡑ ⠖⠉⡘⣐⠱⡊⡉⡑ ⠲⠣⢆⠉ ⠃⢌⡉ ⣄⣁⡒⢐⢠⢆
⡅ ⠌⠙⢑⡆⡃ ⡌⡄⡡⢄ ⡊⡨⣄⠑⢁⠊⠨⢨ ⡆⠒⠨⠘⠒⣐
⡂ ⠉⠓⠇⢌⡢ ⡅⠕ ⢅⠃⡡⢒⠊⢊⠊⢃
🕵️♂️ Где смотреть на метрики вашей команды
- Jira: без плагинов посмотреть…
⠪⢑⣀⢨⠉ ⠸⠅⣂⡌⠡⠜⢔⠢ ⠪⠑⠸⠒⠦⠡ ⠊⠋⠓⡌⢌ ⢂⠰⡠⠲⠤⠇⡉⡑⡑ ⠖⠉⡘⣐⠱⡊⡉⡑ ⠲⠣⢆⠉ ⠃⢌⡉ ⣄⣁⡒⢐⢠⢆
⡅ ⠌⠙⢑⡆⡃ ⡌⡄⡡⢄ ⡊⡨⣄⠑⢁⠊⠨⢨ ⡆⠒⠨⠘⠒⣐
⡂ ⠉⠓⠇⢌⡢ ⡅⠕ ⢅⠃⡡⢒⠊⢊⠊⢃
🕵️♂️ Где смотреть на метрики вашей команды
- Jira: без плагинов посмотреть…
🔥5
Я вот уже 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 или пробовали другие подходы к планированию? Поделитесь опытом!
Пост на хабре | в личном блоге
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Как провести сессию на 90 человек и не получить на выходе список банальностей?
Делюсь свежим кейсом: большая встреча, 4 отдела, стратегический проект. Задача: познакомить и собрать риски.
Что сработало на ура, а где мы поймали антипаттерн «за всё хорошее, против всего плохого»? И главное — почему это произошло.
Внутри статьи — честный рассказ о граблях фасилитатора и о том, как на них не наступать: https://teletype.in/@kiniabulatov/facilitate-90-ppl
А вы себя на мысли ловили, что встреча вроде прошла успешно, но осталось ощущение, что «могли бы копнуть глубже»? Делитесь в комментах! 👇
Делюсь свежим кейсом: большая встреча, 4 отдела, стратегический проект. Задача: познакомить и собрать риски.
Что сработало на ура, а где мы поймали антипаттерн «за всё хорошее, против всего плохого»? И главное — почему это произошло.
Внутри статьи — честный рассказ о граблях фасилитатора и о том, как на них не наступать: https://teletype.in/@kiniabulatov/facilitate-90-ppl
А вы себя на мысли ловили, что встреча вроде прошла успешно, но осталось ощущение, что «могли бы копнуть глубже»? Делитесь в комментах! 👇
Teletype
🙃 Про фасилитацию (познакомить и выявить риски) на 90 человек и где я мог бы сделать (ощутимо) лучше.
Немного про фасилитацию (неотъемлемая часть моей работы).
👍4🔥1
🧵 Вдогонку про Pre-Mortem по страт проекту на 90 человек. Я недокрутил саму подготовку, потому что делал фасилитацию на коленке (на то были причины, но зато появился материал для поста ;) (тут подробный разбор где недокрутил).
База: Подготовка это 80% работы. Для этого мы используем правила "5 П", прорабатывая который мы предвосхищаем95% всех проблем во время фасилитации.
🎯 Поставленная цель
• Какую проблему решаем и почему сейчас?
• Спросить не только заказчика, но и других стейкхолдеров
📜 Продукт (результат)
• Что конкретно получим на выходе?
• Не «обсудили риски», а «топ-3 риска с вот такущими планами митигации и когда уже начинать будем»
🤼♂️ Приглашённые люди
• Кто будет? Сколько человек?
• Какой у них опыт, взаимоотношения и уровень доверия?
❓ Проблемы
• Что может вызвать споры и конфликты?
📊 Процесс
• Временные ресурсы, формат (очно/онлайн)
• Флипчарты, стикеры, маркеры, права в фигме или миро — что нужно?
🔥 Preheat (бонус-пункт)
Письмо участникам за неделю: «Подумайте заранее о 2-3 конкретных рисках». Без этого люди приходят «холодными» и начинают с нуля. Такая вот "лидогенерация" нормальных ответов.
Главное правило: чем сложнее задача для группы, тем больше времени на подготовку.
🏥 По ссылке разбор, где я недоготовился по 5П 🙂
База: Подготовка это 80% работы. Для этого мы используем правила "5 П", прорабатывая который мы предвосхищаем
🎯 Поставленная цель
• Какую проблему решаем и почему сейчас?
• Спросить не только заказчика, но и других стейкхолдеров
📜 Продукт (результат)
• Что конкретно получим на выходе?
• Не «обсудили риски», а «топ-3 риска с вот такущими планами митигации и когда уже начинать будем»
🤼♂️ Приглашённые люди
• Кто будет? Сколько человек?
• Какой у них опыт, взаимоотношения и уровень доверия?
• Что может вызвать споры и конфликты?
📊 Процесс
• Временные ресурсы, формат (очно/онлайн)
• Флипчарты, стикеры, маркеры, права в фигме или миро — что нужно?
🔥 Preheat (бонус-пункт)
Письмо участникам за неделю: «Подумайте заранее о 2-3 конкретных рисках». Без этого люди приходят «холодными» и начинают с нуля. Такая вот "лидогенерация" нормальных ответов.
Главное правило: чем сложнее задача для группы, тем больше времени на подготовку.
🏥 По ссылке разбор, где я недоготовился по 5П 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1🔥1
Минутка оффтопа про AI.
Мы тут все думаем, что ИИ нас ускоряет (таким гуманитариям как я это точно сильно помогает создавать прототипы).
Но на деле, если говорить про реализацию решений в продакшне все иначе: компания METR взяла небольшую выборку из 16 опытных разработчиков, использование ИИ снизило их скорость выполнения работы (наш любимый Lead Time) на19%.
Подробнее тут: https://habr.com/ru/news/927436/
Мы тут все думаем, что ИИ нас ускоряет (таким гуманитариям как я это точно сильно помогает создавать прототипы).
Но на деле, если говорить про реализацию решений в продакшне все иначе: компания METR взяла небольшую выборку из 16 опытных разработчиков, использование ИИ снизило их скорость выполнения работы (наш любимый Lead Time) на
Подробнее тут: https://habr.com/ru/news/927436/
Хабр
ИИ-инструменты замедляют опытных разработчиков: результаты исследования METR
Разработчики работали на 19% медленнее с ИИ, чем без него, хотя сами они считали, что ускорились на 20%. Ожидаемое ускорение против наблюдаемого замедления работы у опытных разработчиков при...
👍2🔥1
⚛️ Броуновское движение + Бинго: как за 15 минут познакомить 90 человек
Представьте: 90 человек в зале, все из разных отделов, которые работают над одним страт проектом. И нужно их быстро "растопить". "Представьтесь по кругу" — тут точно не подойдет (будет долго и нудно).
Есть классный инструмент: Броуновское движение (к которому можно добавить бинго-карточки для геймификации).
Как итог, за 15-20 минут люди 4 раза знакомятся с незнакомыми людьми, да еще и получают призы. Стоит это буквально 0 денег (ну или 3к рублей, если вы хотите купить красивые беджики и🍯 баночку мёда в подарок).
Короче говоря: энергия взлетает, люди смеются, а знакомств происходит много одновременно.
Полный разбор с инструкцией, скриптом и шаблоном бинго — в статье:
https://teletype.in/@kiniabulatov/brown-movement-technique
Представьте: 90 человек в зале, все из разных отделов, которые работают над одним страт проектом. И нужно их быстро "растопить". "Представьтесь по кругу" — тут точно не подойдет (будет долго и нудно).
Есть классный инструмент: Броуновское движение (к которому можно добавить бинго-карточки для геймификации).
Как итог, за 15-20 минут люди 4 раза знакомятся с незнакомыми людьми, да еще и получают призы. Стоит это буквально 0 денег (ну или 3к рублей, если вы хотите купить красивые беджики и
Короче говоря: энергия взлетает, люди смеются, а знакомств происходит много одновременно.
Полный разбор с инструкцией, скриптом и шаблоном бинго — в статье:
https://teletype.in/@kiniabulatov/brown-movement-technique
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Друзья, для следующих постов хотите: (реагируйте)
-🔥 Почитать про кейсы метрик и эффективности команд
-👍 Фасилитацию (как сделать встречи эффективными)
-👏 Обучение и тренинги
- что-то еще (в комментариях)
-
-
-
- что-то еще (в комментариях)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥6⚡1👏1🙏1🥱1
В последние три месяца добрался до своего списка литературы и прочел две давно лежавшие на полочке книги.
📚 Built to Last (EN, RU) и Radical Product Thinking (EN) - это два разных взгляда на создание продуктов. В одном случае организации как продукта. Вторая книга - именно про продукт в его классическом понимании.
🏗 В «Built to Last» - большое исследование того, как строить компанию, которая выдержит испытание временем. Там даже основная метафора - как не определять время (продукт), а уметь строить часы, которые переживут тебя самого. Больше внимания уделяется культуре, ценностям и постоянному улучшению, а вот резкие революционные прорывы поощряются в меньшей степени.
📈 С другой стороны, «Radical Product Thinking» больше про подчинение продукта строгим метрикам и ориентацию на быстрые, ощутимые результаты, суперфокус. То есть там подход более жёсткий, сфокусированный на эффективности и достижении конкретных целей. Там есть рабочая тетрадка и алгоритмы и таблица для работы с достижением целей продукта.
🤯 На контрасте читать очень интересно, потому что сначала соглашаешься и строишь в голове фрейм под одну книгу, а потом вторая его подвергает сильной критике. А потом понимаешь что это про два аспекта одного и того же.
Так как прочел последовательно, сделаю небольшой разбор относительно друг-друга в постах ниже. 👇
📚 Built to Last (EN, RU) и Radical Product Thinking (EN) - это два разных взгляда на создание продуктов. В одном случае организации как продукта. Вторая книга - именно про продукт в его классическом понимании.
🏗 В «Built to Last» - большое исследование того, как строить компанию, которая выдержит испытание временем. Там даже основная метафора - как не определять время (продукт), а уметь строить часы, которые переживут тебя самого. Больше внимания уделяется культуре, ценностям и постоянному улучшению, а вот резкие революционные прорывы поощряются в меньшей степени.
Так как прочел последовательно, сделаю небольшой разбор относительно друг-друга в постах ниже. 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1👎1🤬1
🏗️ 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
🔍 по ссылке большой разбор, ну а тут кратенько мысли
📚 Что за книга
В 1994 году два товарища из Стэнфорда потратили 6 лет на изучение 18 компаний-долгожителей. В итоге получился такой альманах принципов и признаков долгоиграющих компаний.
Главные принципы компаний-долгожителей
-
-
-
-
🧪 Try a Lot / Keep What Works. Эволюционный подход: постоянные эксперименты, естественный отбор идей.
🚀 Актуальность сегодня
Сейчас итерации везде, продукты создаются за недели, а данные торчат из всех дашбордов и демократизированы. Agile - так это вообще мейнстрим.
Но если хочешь enable-ить в своей организации возможность продуктивно работать удаленно, держать текучку на минимуме, иметь деньги на эксперименты и инновации - тут без выстраивания системы не обойтись. И культура, которая позволяет этой системе работать - стержень, без которого организация не будет работать десятилетиями (с другой стороны, а зачем работать десятилетиями? но это уже совсем другая история).
Наш любимые FAANG: Apple, Amazon, Google — используют именно философию, схожую с Built to Last на уровне организаций. Выстраивают культуру и систему, которая поддерживает пайплайн продуктов и экспериментов. Такая организация и есть отдельный тип продукта (который можно попытаться создавать, если следовать принципам в книге).
🍺 Мысля:
МИФ | Amazon | Audible
#books
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
🎯 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
Подробный разбор здесь: https://teletype.in/@kiniabulatov/radical-product-thinking
Преамбула: A/B тесты идут, фидбек собираем, каждые 2 недели релизим — а продукт всё равно какой-то странный получается.
Про авторку: В 2021 году Радика Датт (MIT, 4 больших M&A) выпустила книгу, которая объяснила, в чём проблема (с ее точки зрения). Мы научились быстро итерироваться, но разучились ставить правильные цели (вот все как просто!). Книга описывает диагностику этих "болезней" и как это лечить.
🦠 7 продуктовых болезней
Узнаёте симптомы?
- Hero Syndrome (Синдром героя) — незаменимый человек в команде
- Strategic Swelling (Стратегическое распухание) — продукт решает всё и сразу
- Hypermetricemia (Гипер-метрик-иемия) — одержимость метриками, не связанными с прогрессом
- Pivotitis (Пивот - когда меняешь концепцию или бизнес-модель( — постоянная смена направления без видения
- Narcissus Complex (Комплекс нарцисса) — строим для себя, а не для пользователей
- Vision → Strategy (RDCL)* → Prioritization → Execution → Culture
RDCL = Настоящие, реальные проблемы пользователей + Как мы их решаем + Какие функции несем этим решением + Как масштабируем
👊 Противостояние подходов Vision-driven (Радика любит его) vs Iteration-led (это статус-кво подход)
Vision-driven (Tesla): Чёткое видение изменений → итерации уточняют КАК достичь
Iteration-led (GM): Краткосрочный фидбек диктует направление → локальные максимумы
4 года прошло, ИИ ускорил итерации ещё больше, в итоге без четкого компаса еще сильнее упарываешься в локальные максимумы.
Метафора: чем быстрее едет машина без навигатора, тем быстрее ты потеряешься.
А у вас какой подход?
🔥 - Итеративный
♥️ - Радикальный
#books
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2❤🔥1🔥1🤩1
Дорогой дневник читатель!
📊 Сегодня покроем базу по метрикам (на примере с едой). Она супер-короткая.
Но для начала договоримся: метрики это инструмент. На самом-то деле мы хотим предсказуемости и прогнозов на его основе!
🧑🍳 Ситуация: ты менеджер в пиццерии.
Клиент спрашивает: “Когда будет готова моя пицца?”
Что отвечаешь?“Скоро” или всё-таки можешь дать конкретику?
🔮 Любой прогноз = диапазон + вероятность
“С вероятностью 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
📊 Сегодня покроем базу по метрикам (на примере с едой). Она супер-короткая.
Но для начала договоримся: метрики это инструмент. На самом-то деле мы хотим предсказуемости и прогнозов на его основе!
Клиент спрашивает: “Когда будет готова моя пицца?”
Что отвечаешь?
🔮 Любой прогноз = диапазон + вероятность
“С вероятностью 85% ваша пицца будет готова через 20 минут” (про вероятности поговорим в следующих постах). Дословно про 85% говорить не нужно :)
А вот индикаторы разберём прямо сейчас. Я за минимализм — достаточно трёх показателей:
🍽️ Throughput (Пропускная способность)
Сколько блюд кухня выпускает за час. Это пульс ресторана:
- 25 блюд в обычный день
- 40 в пятницу вечером
⏰ Cycle Time (Время цикла)
От заказа до подачи (упрощенный пример):
- Паста — 15-20 минут
- Стейк — 20-30 минут
Важно: считаем только завершённые заказы!
Сколько времени текущие заказы уже готовятся (и еще недоготовились).
Если стейк готовится 25 минут, а средний Cycle Time — 20, это сигнал проверить кухню.
Это моя любимая метрика.
А теперь главный вопрос:
Что будет дальше?
- В следующих постах — детальный разбор каждой метрики. Но у Саши Торгашева (Delivery Manager в Т-Банке) уже есть подобное: Throughput, Lead Time - если не терпится почитать.
- Поиграться с данными и понять как работают метрики можно в моём инструменте: predictable.team
-
Мини-срачик в @AgileUfa — уже тебя ждет!
- А еще у нас будет митап по этим метрикам в середине августа.
#metrics #throughput #cycletime #aging #predictability
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2💯2