Forwarded from Кринжайл | Скрам Мемы
This media is not supported in your browser
VIEW IN TELEGRAM
😁4💯3❤1🔥1
Всем привет, недавно я просил вас пройти 3 опроса, чтобы лучше понять, кто вы и что для вас максимально полезно на канале.
Давайте подведем итоги - получилось очень любопытно 👇
🧠 Кто вы по ролям?
Самые частые роли среди подписчиков:
Project Manager — 25%
Delivery Manager — 22%
Тимлиды и все, кто "на стыке" — ещё 15%
Есть и Скрам-мастера, разработчики, продуктовые менеджеры - аудитория точно разнообразная.
Это радует: значит, темы можно рассматривать с разных сторон.
🔍 Что вас интересует больше всего?
Вот топ 5 тем, которые вы выбрали:
📈 Метрики и дашборды (62%)
🔧 Настройка процессов внутри команды (62%)
🌐 End-to-end процесс (54%)
📦 Канбан практики и принципы (48%)
🔁 Внедрения изменений (43%)
Вы точно не про теорию — вас интересуют прикладные, измеримые и настраиваемые вещи.
Это и будет в фокусе следующих постов.
📦 Что вы хотите видеть дальше?
Наиболее ожидаемые форматы:
🛠 Обзор инструментов (68%)
📘 Примеры изменений (60%)
📑 Гайды и инструкции (56%)
🧩 Шаблоны для ретро и планирования (48%)
📊 Ответы на вопросы / разборы кейсов (48%)
Инфографика, схемы и даже мемы - в топе. Значит, будем продолжать миксовать полезное с визуальным и немного неформальным контентом.
Вывод:
Спасибо за ваши голоса! Канал теперь будет ещё точнее готовить под вас материал: меньше воды, больше практики, визуализации, процессов и инструментов.
А если у вас есть ещё идеи — пишите в комментах. Я читаю всё 👀
Давайте подведем итоги - получилось очень любопытно 👇
🧠 Кто вы по ролям?
Самые частые роли среди подписчиков:
Project Manager — 25%
Delivery Manager — 22%
Тимлиды и все, кто "на стыке" — ещё 15%
Есть и Скрам-мастера, разработчики, продуктовые менеджеры - аудитория точно разнообразная.
Это радует: значит, темы можно рассматривать с разных сторон.
🔍 Что вас интересует больше всего?
Вот топ 5 тем, которые вы выбрали:
📈 Метрики и дашборды (62%)
🔧 Настройка процессов внутри команды (62%)
🌐 End-to-end процесс (54%)
📦 Канбан практики и принципы (48%)
🔁 Внедрения изменений (43%)
Вы точно не про теорию — вас интересуют прикладные, измеримые и настраиваемые вещи.
Это и будет в фокусе следующих постов.
📦 Что вы хотите видеть дальше?
Наиболее ожидаемые форматы:
🛠 Обзор инструментов (68%)
📘 Примеры изменений (60%)
📑 Гайды и инструкции (56%)
🧩 Шаблоны для ретро и планирования (48%)
📊 Ответы на вопросы / разборы кейсов (48%)
Инфографика, схемы и даже мемы - в топе. Значит, будем продолжать миксовать полезное с визуальным и немного неформальным контентом.
Вывод:
Спасибо за ваши голоса! Канал теперь будет ещё точнее готовить под вас материал: меньше воды, больше практики, визуализации, процессов и инструментов.
А если у вас есть ещё идеи — пишите в комментах. Я читаю всё 👀
🔥6👍4❤1
🔥 Всем успешной доставки!
Сегодня хочу поделиться не рабочими практиками, а традицией, которая стала для нас настоящей отдушиной - летним сплавом.
Уже четвёртый год подряд мы с коллегами устраиваем сплав на катамаранах по рекам Пермского края. Что такое сплав? Это когда ты сажаешь себя и всё своё снаряжение на плавсредство на катамаран, берёшь весло, провизию, палатку - и уходишь в дикую природу на несколько дней.
🛶 3 дня без интернета, без суеты и дедлайнов. Только ты, река и команда.
📍 Мы стартовали с 30 человек. В этом году ожидается уже 75 участников - это почти 15 катамаранов на воде. Люди приезжают со всей России и даже ближнего зарубежья, чтобы просто быть - на берегу, в лесу, у костра. Никакого формализма, только настоящее общение и приключения.
Что входит в этот формат отдыха?
🏕 Ночёвки в палатках - на оборудованных стоянках или диких берегах.
🔥 Еда на костре - простая, вкусная, настоящая.
🛶 Катамараны - управляемые вручную, несложные даже для новичков.
🌲 Маршруты по живописным местам - леса, скалы, реки без шума цивилизации.
🧖♂️ И, конечно, походная баня на берегу - настоящий must-have.
📵 Самое ценное - это цифровой детокс. Телефоны молчат. Зато разговаривают люди.
Шутки, песни, кто-то играет на гитаре, кто-то просто смотрит на звёзды.
Этот формат давно вышел за рамки просто отдыха. Это стало нашим летним ритуалом.
P.S. Всё чаще слышу от знакомых: «А можно с вами?»
Приезжайте в Пермь, организуем вам классный сплав, есть контакты крутых организаторов 💪
Сегодня хочу поделиться не рабочими практиками, а традицией, которая стала для нас настоящей отдушиной - летним сплавом.
Уже четвёртый год подряд мы с коллегами устраиваем сплав на катамаранах по рекам Пермского края. Что такое сплав? Это когда ты сажаешь себя и всё своё снаряжение на плавсредство на катамаран, берёшь весло, провизию, палатку - и уходишь в дикую природу на несколько дней.
🛶 3 дня без интернета, без суеты и дедлайнов. Только ты, река и команда.
📍 Мы стартовали с 30 человек. В этом году ожидается уже 75 участников - это почти 15 катамаранов на воде. Люди приезжают со всей России и даже ближнего зарубежья, чтобы просто быть - на берегу, в лесу, у костра. Никакого формализма, только настоящее общение и приключения.
Что входит в этот формат отдыха?
🏕 Ночёвки в палатках - на оборудованных стоянках или диких берегах.
🔥 Еда на костре - простая, вкусная, настоящая.
🛶 Катамараны - управляемые вручную, несложные даже для новичков.
🌲 Маршруты по живописным местам - леса, скалы, реки без шума цивилизации.
🧖♂️ И, конечно, походная баня на берегу - настоящий must-have.
📵 Самое ценное - это цифровой детокс. Телефоны молчат. Зато разговаривают люди.
Шутки, песни, кто-то играет на гитаре, кто-то просто смотрит на звёзды.
Этот формат давно вышел за рамки просто отдыха. Это стало нашим летним ритуалом.
P.S. Всё чаще слышу от знакомых: «А можно с вами?»
Приезжайте в Пермь, организуем вам классный сплав, есть контакты крутых организаторов 💪
🔥7❤3
🎯 Метрика недели: Time to Market
Когда фича только появилась, кажется, что «всё сделаем быстро». А потом проходит неделя, вторая, месяц и фича всё ещё где-то в разработке.
Чтобы перестать гадать, пора смотреть на цифры. Сегодня говорим про Time to Market.
⏱️ Что это вообще?
Time to Market (TTM) - это время от старта до релиза.
Появилась идея → начали работу → фича вышла в прод.
Чем меньше это значение - тем быстрее вы доставляете ценность клиенту.
🤔 Зачем вообще это считать?
-Понимать, насколько быстро вы реагируете на запросы
-Если клиенту что-то нужно, а вы выпускаете это через 2 месяца - ну, такое.
-Находить узкие места
-TTM растёт? Значит, где-то затык. Ищите, где теряется время: анализ, ожидание, тесты, выкладка, всё влияет.
-Лучше прогнозировать сроки
-Проверять, помогают ли изменения
-Внедрили что-то новое? TTM стал меньше? Отлично, работает. Если нет - возможно, это просто новая боль.
🛠 Как начать считать?
Визуализируйте процесс: от идеи до продакшена. Канбан-доска, value stream map - подойдёт всё, где видно поток задач.
Определите чёткие точки старта и финиша. Например: «взяли в работу» → «выкатили».
Желательно, чтобы задачи вели в одной системе (Jira, Trello, Notion - неважно, главное, чтобы удобно было вытаскивать даты).
📌 Несколько советов:
-Разделяйте задачи по типам - фичи, баги, срочные правки. У них разный TTM, и это нормально.
-Смотрите на тренд - как меняется TTM по месяцам/кварталам.
-Показывайте метрику команде. Это фокусирует всех на главном - поставке ценности, а не просто «делании задач».
💬 Считаете TTM у себя? Или пока только приглядываетесь к метрике? Напишите в комментариях, интересно как это работает в разных командах.
Когда фича только появилась, кажется, что «всё сделаем быстро». А потом проходит неделя, вторая, месяц и фича всё ещё где-то в разработке.
Чтобы перестать гадать, пора смотреть на цифры. Сегодня говорим про Time to Market.
⏱️ Что это вообще?
Time to Market (TTM) - это время от старта до релиза.
Появилась идея → начали работу → фича вышла в прод.
Чем меньше это значение - тем быстрее вы доставляете ценность клиенту.
🤔 Зачем вообще это считать?
-Понимать, насколько быстро вы реагируете на запросы
-Если клиенту что-то нужно, а вы выпускаете это через 2 месяца - ну, такое.
-Находить узкие места
-TTM растёт? Значит, где-то затык. Ищите, где теряется время: анализ, ожидание, тесты, выкладка, всё влияет.
-Лучше прогнозировать сроки
-Проверять, помогают ли изменения
-Внедрили что-то новое? TTM стал меньше? Отлично, работает. Если нет - возможно, это просто новая боль.
🛠 Как начать считать?
Визуализируйте процесс: от идеи до продакшена. Канбан-доска, value stream map - подойдёт всё, где видно поток задач.
Определите чёткие точки старта и финиша. Например: «взяли в работу» → «выкатили».
Желательно, чтобы задачи вели в одной системе (Jira, Trello, Notion - неважно, главное, чтобы удобно было вытаскивать даты).
📌 Несколько советов:
-Разделяйте задачи по типам - фичи, баги, срочные правки. У них разный TTM, и это нормально.
-Смотрите на тренд - как меняется TTM по месяцам/кварталам.
-Показывайте метрику команде. Это фокусирует всех на главном - поставке ценности, а не просто «делании задач».
💬 Считаете TTM у себя? Или пока только приглядываетесь к метрике? Напишите в комментариях, интересно как это работает в разных командах.
👍4❤1
🔧 Инструмент недели: Jira Metrics Plugin - Analytics & Insights
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.
📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;
⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.
🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎
✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.
📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;
⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.
🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎
✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin
🔥5❤2
🎯 Метрика недели Lead Time
Когда мы обсуждаем метрики, хочется напомнить:
📌 метрики - это не инструмент давления на команду, а возможность улучшать процессы основываясь на фактах.
🕐 Что такое Lead Time?
Lead Time - это время от момента принятия обязательств до момента завершения задачи.
Говоря проще: задача перешла в колонку “In Progress” (или другой этап, где команда уже взялась за дело) - и пошёл отсчёт.
Завершили (например, “Done” или “Released”) - таймер остановился.
Это честное измерение: сколько времени заняло выполнение задачи после того, как вы сказали "мы это сделаем".
📊 Как считать Lead time ?
Хорошая практика - смотреть не только на среднее, а на перцентили.
Например:
50-й (медианный) перцентиль покажет, сколько занимает "типичная" задача;
85-й и 95-й — как обстоят дела с «хвостом» (долгими задачами);
Это помогает понять разброс и стабильность процесса, а не просто «в среднем по больнице».
📈 Зачем считать Lead Time?
-Чтобы понимать, насколько быстро команда доставляет ценность;
-Улучшать прогнозируемость и делать более реалистичные планы;
-Выявлять узкие места и неоптимальные этапы в процессе;
-Повышать надежность сроков: если вы знаете, как ведёт себя 85-й перцентиль, вы уверенно можете говорить о дедлайнах.
⚠️ Важное уточнение
Если вы хотите снизить Lead Time, не забывайте про пропускную способность (Throughput).Сократить время выполнения одной задачи можно, но если при этом падает общее количество завершённых задач - значит, мы просто «перераспределили» усилия, а не улучшили процесс.
Баланс важен: быстрее ≠ меньше.
🧩 Как внедрить Lead Time в практике?
-Визуализируйте процесс от момента, когда задача становится обязательством;
-Отмечайте даты входа и выхода задач;
-Собирайте данные, стройте графики, считайте перцентили;
-Обсуждайте это на ретро, а лучше заведите отдельную встречу по обзору метрик: где вы отвечаете себе на вопрос "почему зависают задачи, и что с этим делать?"
💬 А вы считаете Lead Time? Какой у вас 85-й перцентиль?
#метрики #leadtime
Когда мы обсуждаем метрики, хочется напомнить:
📌 метрики - это не инструмент давления на команду, а возможность улучшать процессы основываясь на фактах.
🕐 Что такое Lead Time?
Lead Time - это время от момента принятия обязательств до момента завершения задачи.
Говоря проще: задача перешла в колонку “In Progress” (или другой этап, где команда уже взялась за дело) - и пошёл отсчёт.
Завершили (например, “Done” или “Released”) - таймер остановился.
Это честное измерение: сколько времени заняло выполнение задачи после того, как вы сказали "мы это сделаем".
📊 Как считать Lead time ?
Хорошая практика - смотреть не только на среднее, а на перцентили.
Например:
50-й (медианный) перцентиль покажет, сколько занимает "типичная" задача;
85-й и 95-й — как обстоят дела с «хвостом» (долгими задачами);
Это помогает понять разброс и стабильность процесса, а не просто «в среднем по больнице».
📈 Зачем считать Lead Time?
-Чтобы понимать, насколько быстро команда доставляет ценность;
-Улучшать прогнозируемость и делать более реалистичные планы;
-Выявлять узкие места и неоптимальные этапы в процессе;
-Повышать надежность сроков: если вы знаете, как ведёт себя 85-й перцентиль, вы уверенно можете говорить о дедлайнах.
⚠️ Важное уточнение
Если вы хотите снизить Lead Time, не забывайте про пропускную способность (Throughput).Сократить время выполнения одной задачи можно, но если при этом падает общее количество завершённых задач - значит, мы просто «перераспределили» усилия, а не улучшили процесс.
Баланс важен: быстрее ≠ меньше.
🧩 Как внедрить Lead Time в практике?
-Визуализируйте процесс от момента, когда задача становится обязательством;
-Отмечайте даты входа и выхода задач;
-Собирайте данные, стройте графики, считайте перцентили;
-Обсуждайте это на ретро, а лучше заведите отдельную встречу по обзору метрик: где вы отвечаете себе на вопрос "почему зависают задачи, и что с этим делать?"
💬 А вы считаете Lead Time? Какой у вас 85-й перцентиль?
#метрики #leadtime
👍3🔥3❤2
🎯 Data-driven
Всем успешной доставки!
Часто в постах я упоминаю data-driven подход, давайте разберём, что это за зверь, зачем он нужен и как его применять на практике.
🧠 Что такое data-driven?
Data-driven - это способ принимать решения на основе данных, а не ощущений, догадок или личного опыта. Это не про "давайте замерим всё, что двигается", а про выбор тех данных, которые реально помогают видеть и улучшать систему.
🔍 Где применяется?
📌 В Discovery (на этапе исследований и принятия решений):
-Анализируем, какие гипотезы уже не работают (например, низкое использование фичей).
-Смотрим, какие сегменты пользователей реально нуждаются в решении.
-Используем опросы, интервью, метрики использования, чтобы понять, что действительно важно.
-Приоритизируем гипотезы по фактам, а не потому что "кому-то очень хочется".
🚀 В Delivery (на этапе реализации):
-Следим за скоростью и стабильностью поставки (lead time, cycle time).
-Отслеживаем качество и последствия изменений (баги, откаты, отзывы).
-Улучшаем процессы, опираясь на то, что реально тормозит работу, а не на догадки.
✅ Зачем считать?
Снижаем неопределённость - понятно, что происходит.
Улучшаем процессы - фокусируемся на узких местах.
Повышаем прозрачность - у всей команды единая картина.
Делаем точнее прогнозы - особенно важно для клиентов и стейкхолдеров.
Аргументируем решения - спорим меньше, действуем быстрее.
⚙️ Как начать?
-Определите, что важно для команды: скорость, качество, стабильность.
-Начните замерять простые вещи - даже ручной Excel подойдёт.
-Визуализируйте: графики, дашборды, помогают видеть картину.
-Включите метрики в регулярные обсуждения: ретро, планирование, демо.
-Помните: метрика - это не кнут, это фонарь в тумане.
💬 Data-driven - это не про контроль, а про осознанность.
Когда команда работает с данными, а не по наитию, она быстрее находит, что улучшить и делает это без микроменеджмента.
Всем успешной доставки!
Часто в постах я упоминаю data-driven подход, давайте разберём, что это за зверь, зачем он нужен и как его применять на практике.
🧠 Что такое data-driven?
Data-driven - это способ принимать решения на основе данных, а не ощущений, догадок или личного опыта. Это не про "давайте замерим всё, что двигается", а про выбор тех данных, которые реально помогают видеть и улучшать систему.
🔍 Где применяется?
📌 В Discovery (на этапе исследований и принятия решений):
-Анализируем, какие гипотезы уже не работают (например, низкое использование фичей).
-Смотрим, какие сегменты пользователей реально нуждаются в решении.
-Используем опросы, интервью, метрики использования, чтобы понять, что действительно важно.
-Приоритизируем гипотезы по фактам, а не потому что "кому-то очень хочется".
🚀 В Delivery (на этапе реализации):
-Следим за скоростью и стабильностью поставки (lead time, cycle time).
-Отслеживаем качество и последствия изменений (баги, откаты, отзывы).
-Улучшаем процессы, опираясь на то, что реально тормозит работу, а не на догадки.
✅ Зачем считать?
Снижаем неопределённость - понятно, что происходит.
Улучшаем процессы - фокусируемся на узких местах.
Повышаем прозрачность - у всей команды единая картина.
Делаем точнее прогнозы - особенно важно для клиентов и стейкхолдеров.
Аргументируем решения - спорим меньше, действуем быстрее.
⚙️ Как начать?
-Определите, что важно для команды: скорость, качество, стабильность.
-Начните замерять простые вещи - даже ручной Excel подойдёт.
-Визуализируйте: графики, дашборды, помогают видеть картину.
-Включите метрики в регулярные обсуждения: ретро, планирование, демо.
-Помните: метрика - это не кнут, это фонарь в тумане.
💬 Data-driven - это не про контроль, а про осознанность.
Когда команда работает с данными, а не по наитию, она быстрее находит, что улучшить и делает это без микроменеджмента.
🔥5❤2👍2👏1
🔍 А вы еще гуглите или уже спрашиваете у ИИ?
Наткнулся на интересный пост в Linkedin, если кратко:
Гугл теряет позиции.
🧵 Минус 20% трафика в туризме, -17% в медиа, -9% в e-commerce.
Люди всё чаще ищут ответы не в поисковике, а:
- у GPT/ИИ 🤖
- в Telegram-каналах 📲
- в TikTok 😁
Мы вошли в эпоху post-search.
Теперь важен не «топ по запросу», а голос, которому доверяют.
А вы как ищете ответы? гуглите? смотрите туториалы или задаете вопросы ИИ?
Наткнулся на интересный пост в Linkedin, если кратко:
Гугл теряет позиции.
🧵 Минус 20% трафика в туризме, -17% в медиа, -9% в e-commerce.
Люди всё чаще ищут ответы не в поисковике, а:
- у GPT/ИИ 🤖
- в Telegram-каналах 📲
- в TikTok 😁
Мы вошли в эпоху post-search.
Теперь важен не «топ по запросу», а голос, которому доверяют.
А вы как ищете ответы? гуглите? смотрите туториалы или задаете вопросы ИИ?
👍3❤2😁1
🎯 Метрика недели: Пропускная способность (Throughput)
Давайте разберёмся, что такое throughput и зачем его вообще считать.
Что это такое?
Throughput показывает, сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Например:
- 25 задач за месяц → throughput = 25
- 6 багфиксов и 4 фичи → throughput = 10 (или можно разделять по типам задач - это даёт дополнительную глубину анализа)
Зачем считать?
📈 Оценка скорости команды - понимаем, насколько стабильно двигаемся.
🔍 Анализ трендов - замечаем, когда темп падает или растёт.
📅 Прогнозирование сроков - throughput помогает понять, сколько времени займёт бэклог.
⚖️ Балансировка нагрузки - при падении throughput ищем причины: перегруз, блокеры, неоптимальные процессы.
📂 Глубокий анализ - можно смотреть throughput отдельно по типам задач, чтобы увидеть перекосы (например, много багов, мало фич).
🤝 Прозрачность - метрика легко объясняется и хорошо работает на демонстрациях.
Важно помнить
✅ Это не метрика продуктивности отдельного человека. Это командная метрика.
✅ Рост throughput - это не цель сама по себе. Главное стабильность и предсказуемость.
✅ Следите, чтобы при снижении Lead Time не пострадал throughput - важно сохранять баланс.
Как начать считать?
- Определите, какие задачи считаются «завершёнными» (например, в статусе Done).
- Считайте завершённые задачи за месяц (чтобы сгладить колебания).
- Смотрите динамику по неделям/месяцам.
- Разделите throughput по типам задач: баги, фичи, техдолг - это даст более точные инсайты.
- Используйте визуализацию (графики, диаграммы, трекеры).
📌 Через месяц можно увидеть первую динамику. А дальше уже строить прогнозы и находить точки для улучшений.
#метрики #throughput
Давайте разберёмся, что такое throughput и зачем его вообще считать.
Что это такое?
Throughput показывает, сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Например:
- 25 задач за месяц → throughput = 25
- 6 багфиксов и 4 фичи → throughput = 10 (или можно разделять по типам задач - это даёт дополнительную глубину анализа)
Зачем считать?
📈 Оценка скорости команды - понимаем, насколько стабильно двигаемся.
🔍 Анализ трендов - замечаем, когда темп падает или растёт.
📅 Прогнозирование сроков - throughput помогает понять, сколько времени займёт бэклог.
⚖️ Балансировка нагрузки - при падении throughput ищем причины: перегруз, блокеры, неоптимальные процессы.
📂 Глубокий анализ - можно смотреть throughput отдельно по типам задач, чтобы увидеть перекосы (например, много багов, мало фич).
🤝 Прозрачность - метрика легко объясняется и хорошо работает на демонстрациях.
Важно помнить
✅ Это не метрика продуктивности отдельного человека. Это командная метрика.
✅ Рост throughput - это не цель сама по себе. Главное стабильность и предсказуемость.
✅ Следите, чтобы при снижении Lead Time не пострадал throughput - важно сохранять баланс.
Как начать считать?
- Определите, какие задачи считаются «завершёнными» (например, в статусе Done).
- Считайте завершённые задачи за месяц (чтобы сгладить колебания).
- Смотрите динамику по неделям/месяцам.
- Разделите throughput по типам задач: баги, фичи, техдолг - это даст более точные инсайты.
- Используйте визуализацию (графики, диаграммы, трекеры).
📌 Через месяц можно увидеть первую динамику. А дальше уже строить прогнозы и находить точки для улучшений.
#метрики #throughput
✍3❤2🔥2
🔧 Инструмент недели: Unidraw - бесплатная онлайн‑доска
Всем успешной доставки!
Помню, как в самом начале канала делился постом про онлайн-доски: вот он. Тогда Miro объявило об уходе с российского рынка и пообещало блокировать аккаунты. (Кстати, работает ли у вас Miro сейчас, или уже заблокировали?)
Хочу вернуться к этой теме и рассказать про ещё одну онлайн-доску, которую точно стоит попробовать. Альтернатива надёжная, бесплатная и доступная без VPN.
🧩 Что это?
Unidraw - это удобная онлайн‑доска для совместной визуализации. Отлично подойдёт для командной работы, исследований, проектирования и просто наведения порядка в голове. Имеет большое количество встроенных шаблонов:
📌 CJM,
🧠 Майнд-карты,
🧩 Бизнес-модели,
🎯 OKR,
🧪 Lean Canvas и др.
⚙️ Возможности:
-Неограниченное количество досок и проектов;
-Совместная работа в реальном времени;
-Визуальные элементы: стикеры, фигуры, стрелки, текст;
-Импорт из Excel и CSV, экспорт в PNG и SVG;
-История версий и откат;
-Импорт досок из Miro (если вдруг вы переезжаете);
🎯 Кому подойдёт:
Аналитикам и дизайнерам - для схем и пользовательских путей;
Тимлидам - для визуализации процессов, проведения ретро
Руководителям - для планов и стратегических досок.
Delivery/Project/Product менеджерам
Это не реклама, просто делюсь тем, что оказалось полезным 😎
Канал в телеграм у ребят тут
Всем успешной доставки!
Помню, как в самом начале канала делился постом про онлайн-доски: вот он. Тогда Miro объявило об уходе с российского рынка и пообещало блокировать аккаунты. (Кстати, работает ли у вас Miro сейчас, или уже заблокировали?)
Хочу вернуться к этой теме и рассказать про ещё одну онлайн-доску, которую точно стоит попробовать. Альтернатива надёжная, бесплатная и доступная без VPN.
🧩 Что это?
Unidraw - это удобная онлайн‑доска для совместной визуализации. Отлично подойдёт для командной работы, исследований, проектирования и просто наведения порядка в голове. Имеет большое количество встроенных шаблонов:
📌 CJM,
🧠 Майнд-карты,
🧩 Бизнес-модели,
🎯 OKR,
🧪 Lean Canvas и др.
⚙️ Возможности:
-Неограниченное количество досок и проектов;
-Совместная работа в реальном времени;
-Визуальные элементы: стикеры, фигуры, стрелки, текст;
-Импорт из Excel и CSV, экспорт в PNG и SVG;
-История версий и откат;
-Импорт досок из Miro (если вдруг вы переезжаете);
🎯 Кому подойдёт:
Аналитикам и дизайнерам - для схем и пользовательских путей;
Тимлидам - для визуализации процессов, проведения ретро
Руководителям - для планов и стратегических досок.
Delivery/Project/Product менеджерам
Это не реклама, просто делюсь тем, что оказалось полезным 😎
Канал в телеграм у ребят тут
👍3❤2
Всем успешной доставки! В Перми скоро (1 августа) снова пройдёт одна из моих любимых конференций - Ural Digital Weekend.
За последние годы успел побывать там и на сцене, и "по ту сторону" - в программном комитете.
В этом году в программе десятки сильных докладов, крутые секции про команды, технологии, процессы, продуктовый подход. И что особенно приятно большинство спикеров не «теоретики», а настоящие практики.
Если раздумываете, стоит ли идти, точно стоит.
А промокод KANBANFOREVER 😁 будет бонусом для окончательного «да».
За последние годы успел побывать там и на сцене, и "по ту сторону" - в программном комитете.
В этом году в программе десятки сильных докладов, крутые секции про команды, технологии, процессы, продуктовый подход. И что особенно приятно большинство спикеров не «теоретики», а настоящие практики.
Если раздумываете, стоит ли идти, точно стоит.
А промокод KANBANFOREVER 😁 будет бонусом для окончательного «да».
❤4🔥4👍2
🔍 Фичи ради фич в 2025 - это роскошь. Поговорим про Double Diamond
Если в прошлом можно было позволить себе "экспериментировать на проде", сейчас это бьёт по самому больному, по деньгам.
💡 Вспоминаем, что такое e2e-процесс?
Это не просто «от идеи до продакшена». Это полный цикл создания продукта, где каждый этап от формулировки проблемы до оценки влияния на бизнес работает как единая система.
Важнейшие этапы:
Discovery - понять, что именно нужно делать;
Delivery - сделать это эффективно и с минимальными потерями;
Постанализ - проверить, дало ли это результат.
🧠 Почему без discovery никак?
💸 Потому что "сделать и выбросить" стало слишком дорого.
Ошибки на уровне идеи обходятся не в тысячи рублей, а в часы дорогой разработки, потерянные конверсии, репутационные издержки и упущенные возможности.
Время "фич ради фич" ушло. Сейчас продуктовые команды должны быть помешаны на валидации. И тут на сцену выходит:
✨ Метод Double Diamond
Если коротко, это способ не наломать дров и не выкинуть деньги на фичи, которые никому не нужны. Он помогает разобраться, что действительно стоит делать, а не просто «что мы можем запилить».
🔷 Первый ромб - расширяем взгляд и постепенно фокусируемся:
→ цель - понять настоящую проблему пользователя, а не ту, которую кажется важной.
🔶 Второй ромб - снова расширяемся и сужаемся, но теперь уже в поиске решения проблемы.
🗺 Этапы Double Diamond:
Discover - исследуем, где на самом деле болит: проводим интервью, смотрим аналитику, наблюдаем.
Define - формулируем настоящую проблему, которую стоит решать. Не симптомы, а суть.
Develop - придумываем возможные решения, генерим гипотезы, не ограничиваем себя.
Deliver - выбираем самое ценное из идей и реализуем. Проверяем на результат.
📌 Это подход не про скорость. Это подход про разумную экономию, осознанные действия и снижение рисков сжигания бюджета в пустоту. Особенно актуально в 2025, когда стоимость любой ошибки выросла в разы.
📊 Что получает бизнес?
-Делается только то, что действительно влияет на бизнес-метрики (выручка, удержание, NPS и др).
-Команда тратит меньше времени на бесполезную реализацию.
-Растёт доверие к продукту внутри компании: меньше хаоса, больше результата.
Поделитесь, как это устроено у вас. Или, наоборот, почему пока не дошли до этого. Обсудим 👇
#DD #discovery #e2e
Если в прошлом можно было позволить себе "экспериментировать на проде", сейчас это бьёт по самому больному, по деньгам.
💡 Вспоминаем, что такое e2e-процесс?
Это не просто «от идеи до продакшена». Это полный цикл создания продукта, где каждый этап от формулировки проблемы до оценки влияния на бизнес работает как единая система.
Важнейшие этапы:
Discovery - понять, что именно нужно делать;
Delivery - сделать это эффективно и с минимальными потерями;
Постанализ - проверить, дало ли это результат.
🧠 Почему без discovery никак?
💸 Потому что "сделать и выбросить" стало слишком дорого.
Ошибки на уровне идеи обходятся не в тысячи рублей, а в часы дорогой разработки, потерянные конверсии, репутационные издержки и упущенные возможности.
Время "фич ради фич" ушло. Сейчас продуктовые команды должны быть помешаны на валидации. И тут на сцену выходит:
✨ Метод Double Diamond
Если коротко, это способ не наломать дров и не выкинуть деньги на фичи, которые никому не нужны. Он помогает разобраться, что действительно стоит делать, а не просто «что мы можем запилить».
🔷 Первый ромб - расширяем взгляд и постепенно фокусируемся:
→ цель - понять настоящую проблему пользователя, а не ту, которую кажется важной.
🔶 Второй ромб - снова расширяемся и сужаемся, но теперь уже в поиске решения проблемы.
🗺 Этапы Double Diamond:
Discover - исследуем, где на самом деле болит: проводим интервью, смотрим аналитику, наблюдаем.
Define - формулируем настоящую проблему, которую стоит решать. Не симптомы, а суть.
Develop - придумываем возможные решения, генерим гипотезы, не ограничиваем себя.
Deliver - выбираем самое ценное из идей и реализуем. Проверяем на результат.
📌 Это подход не про скорость. Это подход про разумную экономию, осознанные действия и снижение рисков сжигания бюджета в пустоту. Особенно актуально в 2025, когда стоимость любой ошибки выросла в разы.
📊 Что получает бизнес?
-Делается только то, что действительно влияет на бизнес-метрики (выручка, удержание, NPS и др).
-Команда тратит меньше времени на бесполезную реализацию.
-Растёт доверие к продукту внутри компании: меньше хаоса, больше результата.
Поделитесь, как это устроено у вас. Или, наоборот, почему пока не дошли до этого. Обсудим 👇
#DD #discovery #e2e
👍3🔥2❤1
🔁 Дейли-митинги: привычка, необходимость или ритуал ради галочки?
Всем успешной доставки 🚀
Когда-то дейли были придуманы как быстрый способ синхронизации команды.
15 минут, три вопроса: что сделал, что планируешь, где затык.
Просто, понятно, эффективно.
Но что-то пошло не так.
Сегодня в разных командах мы видим вот что:
-Дейли длятся по 30-60 минут
-Говорит только тимлид
-Никто не слушает, все ждут своей очереди
-Говорят только статусными ответами: взял в работу, тестирую.
Вопросы задаются «в стол», без последующих действий.
🎯 Слышал, что в одной из команд попробовали отменить дейли и перешли на:
-еженедельные синки по темам
-живые апдейты в тасктрекере
-прозрачную доску с понятным статусом задач
Результат? Больше фокуса, меньше шума, всё стало спокойнее.
Но не всем такой подход заходит. Есть команды, где дейли - это точка опоры: без них люди не синхронизируются, не чувствуют ритм, теряют нить.
🤔 А теперь внимание к сути:
Нужны ли дейли всем командам? Или это просто «наследие скрама»(хотя в Канбане есть такая же каденция), которое тащат даже туда, где оно не работает?
📣 Делитесь опытом:
-Есть ли у вас дейли?
-Как часто на них рождаются реальные решения?
-Кто их фасилитирует?
-Пробовали отменить? Что вышло?
Всем успешной доставки 🚀
Когда-то дейли были придуманы как быстрый способ синхронизации команды.
15 минут, три вопроса: что сделал, что планируешь, где затык.
Просто, понятно, эффективно.
Но что-то пошло не так.
Сегодня в разных командах мы видим вот что:
-Дейли длятся по 30-60 минут
-Говорит только тимлид
-Никто не слушает, все ждут своей очереди
-Говорят только статусными ответами: взял в работу, тестирую.
Вопросы задаются «в стол», без последующих действий.
🎯 Слышал, что в одной из команд попробовали отменить дейли и перешли на:
-еженедельные синки по темам
-живые апдейты в тасктрекере
-прозрачную доску с понятным статусом задач
Результат? Больше фокуса, меньше шума, всё стало спокойнее.
Но не всем такой подход заходит. Есть команды, где дейли - это точка опоры: без них люди не синхронизируются, не чувствуют ритм, теряют нить.
🤔 А теперь внимание к сути:
Нужны ли дейли всем командам? Или это просто «наследие скрама»(хотя в Канбане есть такая же каденция), которое тащат даже туда, где оно не работает?
📣 Делитесь опытом:
-Есть ли у вас дейли?
-Как часто на них рождаются реальные решения?
-Кто их фасилитирует?
-Пробовали отменить? Что вышло?
❤4👍2🔥1🤔1
📊 Метрика недели Discard Rate или «сколько задач мы выкидываем на помойку»
🧯 В условиях 2025-го, когда каждая неделя работы стоит как самолет, важно не только делать правильно, но и перестать делать лишнее.
И вот тут появляется полезная, но недооцененная метрика Discard Rate.
❓Что это такое?
Discard Rate - это доля задач, которые были запланированы, но так и не дошли до продакшена.
Например:
-Начали делать, но отменили
-Завели задачу, но забросили
-Потратили ресурсы, но поняли, что не нужно
🔎 Зачем её считать?
Понимать, сколько усилий ушло впустую, если часто отменяете задачи после старта, где-то сбоит приоритезация.
Обнаруживать "горячие головы", инициатива хорошо, но если постоянно отбрасываются начатые задачи, это тревожный симптом.
Оптимизировать процесс Discovery, высокий Discard Rate может говорить, что фичи начинают пилить без нормальной проработки.
Снижать риски сжигания бюджета, особенно критично, если деньги «дорогие» на проекте каждый день имеет ценник.
Улучшать прозрачность потока работы, команде и менеджерам проще видеть, куда утекают усилия.
Ценить ранний отказ, чем раньше задача была отменена, тем меньше времени и денег потрачено. Ранний “нет” это экономия.
🛠 Как внедрить?
Отметьте “выкинутые” задачи в Jira, создайте статус Discarded или метку cancelled, won’t do, abandoned.
Следите за трендом, Discard Rate >15%(может отдельно для себя определить этот процент) регулярно? Уже стоит копать глубже.
Анализируйте причины, ретроспектива, работа с продуктовыми командами: почему задача не дожила до релиза?
Показывайте в дашборде, добавить в CFD/графики можно визуализировать как долю от всех заведенных задач.
💡 Нормально ли, что что-то выбрасываем?
Да, если осознанно. Главное не тратить на это недели работы. Чем раньше “завернули” тем лучше для всех.
Discard Rate не про обвинения, а про улучшение процесса принятия решений.
🧯 В условиях 2025-го, когда каждая неделя работы стоит как самолет, важно не только делать правильно, но и перестать делать лишнее.
И вот тут появляется полезная, но недооцененная метрика Discard Rate.
❓Что это такое?
Discard Rate - это доля задач, которые были запланированы, но так и не дошли до продакшена.
Например:
-Начали делать, но отменили
-Завели задачу, но забросили
-Потратили ресурсы, но поняли, что не нужно
🔎 Зачем её считать?
Понимать, сколько усилий ушло впустую, если часто отменяете задачи после старта, где-то сбоит приоритезация.
Обнаруживать "горячие головы", инициатива хорошо, но если постоянно отбрасываются начатые задачи, это тревожный симптом.
Оптимизировать процесс Discovery, высокий Discard Rate может говорить, что фичи начинают пилить без нормальной проработки.
Снижать риски сжигания бюджета, особенно критично, если деньги «дорогие» на проекте каждый день имеет ценник.
Улучшать прозрачность потока работы, команде и менеджерам проще видеть, куда утекают усилия.
Ценить ранний отказ, чем раньше задача была отменена, тем меньше времени и денег потрачено. Ранний “нет” это экономия.
🛠 Как внедрить?
Отметьте “выкинутые” задачи в Jira, создайте статус Discarded или метку cancelled, won’t do, abandoned.
Следите за трендом, Discard Rate >15%(может отдельно для себя определить этот процент) регулярно? Уже стоит копать глубже.
Анализируйте причины, ретроспектива, работа с продуктовыми командами: почему задача не дожила до релиза?
Показывайте в дашборде, добавить в CFD/графики можно визуализировать как долю от всех заведенных задач.
💡 Нормально ли, что что-то выбрасываем?
Да, если осознанно. Главное не тратить на это недели работы. Чем раньше “завернули” тем лучше для всех.
Discard Rate не про обвинения, а про улучшение процесса принятия решений.
❤7🔥3👍1
🧨 Скрама не существует 🆘
Кажется, этот пост должен был быть первым в моем канале 😅
Много команд гордо говорят: "Мы работаем по скраму". Но если открыть Scrum Guide и внимательно посмотреть,
что там написано, то выяснится: скрама нет.
Он как кот Шредингера , есть и одновременно нет. А точнее, он есть только на бумаге.
👇 Вот почему:
❌ 1. Нет цели спринта
“Цель спринта - это единственный объектив работы команды.”
На практике: цель никто не формулирует. Планирование - это просто раздача задач на две недели.
Если спросить у команды "а что мы хотим достичь?", в ответ тишина.
❌ 2. Нет скрам-мастера
Часто его роль исполняет проектный менеджер, тимлид или вообще никто.
А ведь по гайду это ключевая фигура, ответственная за фасилитацию, обучение и устранение препятствий.
❌ 3. Истории кочуют из спринта в спринт
“В скраме важно завершать инкременты. Done значит Done.”
На практике: "не успели ну ничего, возьмём в следующий спринт".
А если копнуть глубже, оказывается, что задачи невозможно завершить за один спринт. Потому что никто не думал об объёме, блокерах и зависимости.
❌ 4. Инкремента нет
В конце спринта нет демо. Или оно номинальное. Или то, что показали нельзя использовать. Или это "почти готово", но на самом деле требует ещё недели багфиксов и ручного тестирования.
❌ 5. Нет ретро. Или оно не работает
По скраму ретроспектива - важнейший элемент непрерывного улучшения.
На деле ритуал ради галочки. Без выводов, без планов на изменения, без замеров результатов. Просто “ну норм, давайте дальше”.
❌ 6. Нет Definition of Done
“Что означает ‘готово’?” простейший вопрос, на который 80% команд не могут ответить. Именно поэтому в прод попадают недоделки, “полуфичи” и баги.
❌ 7. Нет Product Owner
Или он перегружен, или работает в 5 командах одновременно.
А значит, нет ни управления бэклогом, ни связи с клиентом, ни приоритезации по бизнесу. Всё летит в бэклог по принципу "а давайте сделаем".
❌ 8. Velocity не замеряется
Спринты проходят, команда работает, но ритма и предсказуемости нет.
Поток задач непредсказуем, оценки неточные, планирование пальцем в небо.
❌ 9. Дейли превратились в “отчитайся”
Дейли это синхронизация команды.
На деле это отчет перед менеджером. По очереди. Монотонно. Без вовлечения.
После дейли никто ничего не понял, никто не перефокусировал работу, никто не нашёл блокеры.
❌ 10. Спринт ради спринта
Главный вопрос - не "доставили ли мы ценность", а "уложились ли мы в дедлайн".
Вывод: Скрама не существует.
То, что называют "скрамом" - это имитация.
Снаружи ритуалы, а внутри всё та же неуправляемая и непрозрачная разработка.
Я опираюсь на личный опыт. Если у вас всё по Скрам-гайду вы молодцы, это редкость!
#Scrum #Разаработка #Управление
Кажется, этот пост должен был быть первым в моем канале 😅
Много команд гордо говорят: "Мы работаем по скраму". Но если открыть Scrum Guide и внимательно посмотреть,
что там написано, то выяснится: скрама нет.
Он как кот Шредингера , есть и одновременно нет. А точнее, он есть только на бумаге.
👇 Вот почему:
❌ 1. Нет цели спринта
“Цель спринта - это единственный объектив работы команды.”
На практике: цель никто не формулирует. Планирование - это просто раздача задач на две недели.
Если спросить у команды "а что мы хотим достичь?", в ответ тишина.
❌ 2. Нет скрам-мастера
Часто его роль исполняет проектный менеджер, тимлид или вообще никто.
А ведь по гайду это ключевая фигура, ответственная за фасилитацию, обучение и устранение препятствий.
❌ 3. Истории кочуют из спринта в спринт
“В скраме важно завершать инкременты. Done значит Done.”
На практике: "не успели ну ничего, возьмём в следующий спринт".
А если копнуть глубже, оказывается, что задачи невозможно завершить за один спринт. Потому что никто не думал об объёме, блокерах и зависимости.
❌ 4. Инкремента нет
В конце спринта нет демо. Или оно номинальное. Или то, что показали нельзя использовать. Или это "почти готово", но на самом деле требует ещё недели багфиксов и ручного тестирования.
❌ 5. Нет ретро. Или оно не работает
По скраму ретроспектива - важнейший элемент непрерывного улучшения.
На деле ритуал ради галочки. Без выводов, без планов на изменения, без замеров результатов. Просто “ну норм, давайте дальше”.
❌ 6. Нет Definition of Done
“Что означает ‘готово’?” простейший вопрос, на который 80% команд не могут ответить. Именно поэтому в прод попадают недоделки, “полуфичи” и баги.
❌ 7. Нет Product Owner
Или он перегружен, или работает в 5 командах одновременно.
А значит, нет ни управления бэклогом, ни связи с клиентом, ни приоритезации по бизнесу. Всё летит в бэклог по принципу "а давайте сделаем".
❌ 8. Velocity не замеряется
Спринты проходят, команда работает, но ритма и предсказуемости нет.
Поток задач непредсказуем, оценки неточные, планирование пальцем в небо.
❌ 9. Дейли превратились в “отчитайся”
Дейли это синхронизация команды.
На деле это отчет перед менеджером. По очереди. Монотонно. Без вовлечения.
После дейли никто ничего не понял, никто не перефокусировал работу, никто не нашёл блокеры.
❌ 10. Спринт ради спринта
Главный вопрос - не "доставили ли мы ценность", а "уложились ли мы в дедлайн".
Вывод: Скрама не существует.
То, что называют "скрамом" - это имитация.
Снаружи ритуалы, а внутри всё та же неуправляемая и непрозрачная разработка.
Я опираюсь на личный опыт. Если у вас всё по Скрам-гайду вы молодцы, это редкость!
#Scrum #Разаработка #Управление
Please open Telegram to view this post
VIEW IN TELEGRAM
💯9🗿4❤2
Если ты не отменяешь фичи - ты не занимаешься Discovery
Я уже много постов написал про этап discovery и даже описывал DD, хочу подсветить проблему еще раз, но с другой стороны 🧐
Discovery - это не про "понять, как делать".
Discovery - это про понять, стоит ли делать вообще.
💸 В 2025 году фичи - это дорогие деньги
Разработка стоит дорого. Даже один спринт команды сеньоров может сжечь месячный бюджет небольшого стартапа. В условиях, когда каждый рубль должен приносить ROI, не отменять фичи значит быть безответственным.
🚧 Почему надо отменять фичи?
90% идей — плохие
Большинство гипотез не выживают столкновения с пользователем. Фичи, которые не решают реальные боли, не приносят метрик → это мусор.
Фича = инвестиция
Каждая задача - это как стартап: у неё должен быть потенциал окупаемости. Если её нельзя защитить цифрами она не стоит затрат.
Фокус дороже функционала
Чем меньше продукт делает, тем проще им пользоваться. Ценность создаёт не количество фичей, а решение боли.
🚫 Почему важно отменять рано?
Каждый шаг дальше дороже
📌 Идея → ✏️ исследование → 🖌 дизайн → 👨💻 разработка → 🚀 релиз
Если отменяешь на шаге идеи - теряешь час.
Если на этапе тестов - уже неделю.
Если после релиза - считай, выбросил в окно.
Ранние “стопы” = зрелый процесс
Компании с хорошим discovery-процессом отменяют больше фичей, чем делают 😁
🔁 А если не отменяете?
Поздравляю, у вас конвейер надежд:
-фичи берутся “по ощущениям”, "мы в нее верим"
-в беклоге сотни задач, потому что “всё важно”
-каждая фича доходит до релиза, но никто не считает, окупилась ли она
А главное - никто не отвечает за решение проблем, только за “поставить вовремя”.
📌 Вывод
Если ты хочешь заниматься настоящим Discovery, то список отменённых задач должен быть длиннее списка тех, что пошли в прод.
Сложно? Да. Зато дешевле.
Я уже много постов написал про этап discovery и даже описывал DD, хочу подсветить проблему еще раз, но с другой стороны 🧐
Discovery - это не про "понять, как делать".
Discovery - это про понять, стоит ли делать вообще.
💸 В 2025 году фичи - это дорогие деньги
Разработка стоит дорого. Даже один спринт команды сеньоров может сжечь месячный бюджет небольшого стартапа. В условиях, когда каждый рубль должен приносить ROI, не отменять фичи значит быть безответственным.
🚧 Почему надо отменять фичи?
90% идей — плохие
Большинство гипотез не выживают столкновения с пользователем. Фичи, которые не решают реальные боли, не приносят метрик → это мусор.
Фича = инвестиция
Каждая задача - это как стартап: у неё должен быть потенциал окупаемости. Если её нельзя защитить цифрами она не стоит затрат.
Фокус дороже функционала
Чем меньше продукт делает, тем проще им пользоваться. Ценность создаёт не количество фичей, а решение боли.
🚫 Почему важно отменять рано?
Каждый шаг дальше дороже
📌 Идея → ✏️ исследование → 🖌 дизайн → 👨💻 разработка → 🚀 релиз
Если отменяешь на шаге идеи - теряешь час.
Если на этапе тестов - уже неделю.
Если после релиза - считай, выбросил в окно.
Ранние “стопы” = зрелый процесс
Компании с хорошим discovery-процессом отменяют больше фичей, чем делают 😁
🔁 А если не отменяете?
Поздравляю, у вас конвейер надежд:
-фичи берутся “по ощущениям”, "мы в нее верим"
-в беклоге сотни задач, потому что “всё важно”
-каждая фича доходит до релиза, но никто не считает, окупилась ли она
А главное - никто не отвечает за решение проблем, только за “поставить вовремя”.
📌 Вывод
Если ты хочешь заниматься настоящим Discovery, то список отменённых задач должен быть длиннее списка тех, что пошли в прод.
Сложно? Да. Зато дешевле.
👍3❤2🔥2🥰1💯1
🧨 Метрики команды ≠ Метрики людей
Иногда кто-то берёт диаграмму CFD или график Lead time и спрашивает:
"А можно ли по этим метрикам понять, кто из разработчиков/тестировщиков/аналитиков работает медленно?"
Ответ: нет. И даже не пытайтесь.
🔍 Процессные метрики - это не про людей.
-Они не измеряют эффективность конкретного участника.
-Они показывают, как работает система в целом.
Если растёт lead time - это может быть из-за:
-завала на тестировании,
-ожидания ревью,
-долгого согласования,
-отсутствия ясности по задаче,
а не потому, что «Вася снова всё тормозит».
❌ Использование этих метрик для оценки сотрудников:
-разрушает доверие,
-порождает защитное поведение,
-создаёт токсичную атмосферу,
-искажает сами метрики они перестают отражать реальность.
💡 Если уж очень хочется мерить людей, делайте это открыто, в формате Индивидуального Плана Развития (ИПР), с фокусом на рост, а не наказание. Это честно, конструктивно и не ломает командные процессы.
📈 Метрики типа:
-Lead Time
-WIP
-Blocker Time
-Discard Rate
-WIP Rate
это не про людей. Это инструменты улучшения командной работы.
🔄 Метрики должны помогать работать лучше, а не защищаться, манипулировать и выживать.
Иногда кто-то берёт диаграмму CFD или график Lead time и спрашивает:
"А можно ли по этим метрикам понять, кто из разработчиков/тестировщиков/аналитиков работает медленно?"
Ответ: нет. И даже не пытайтесь.
🔍 Процессные метрики - это не про людей.
-Они не измеряют эффективность конкретного участника.
-Они показывают, как работает система в целом.
Если растёт lead time - это может быть из-за:
-завала на тестировании,
-ожидания ревью,
-долгого согласования,
-отсутствия ясности по задаче,
а не потому, что «Вася снова всё тормозит».
❌ Использование этих метрик для оценки сотрудников:
-разрушает доверие,
-порождает защитное поведение,
-создаёт токсичную атмосферу,
-искажает сами метрики они перестают отражать реальность.
💡 Если уж очень хочется мерить людей, делайте это открыто, в формате Индивидуального Плана Развития (ИПР), с фокусом на рост, а не наказание. Это честно, конструктивно и не ломает командные процессы.
📈 Метрики типа:
-Lead Time
-WIP
-Blocker Time
-Discard Rate
-WIP Rate
это не про людей. Это инструменты улучшения командной работы.
🔄 Метрики должны помогать работать лучше, а не защищаться, манипулировать и выживать.
👍8💯4🔥3❤1