DeliveryMan

📏 Метрика недели WIP Rate

Всем успешной доставки!
Возвращаю рубрику «Метрика недели». Сегодня говорим про WIP rate.

Если коротко, WIP rate - это доля времени, сколько задачи разных типов находились в работе.
Метрика отвечает на вопрос: куда реально уходит время команды, пока задачи живут в процессе.

🔹 Зачем использовать
Чтобы видеть, на что уходит фокус команды - фичи, поддержку, техдолг, эксперименты.
Чтобы понять, достаточно ли мы инвестируем в разные типы работ.
Чтобы проверить, соблюдаются ли договорённости по квотам (например, 20% времени на улучшения, 10% на поддержку).
Чтобы иметь факты в разговоре «куда уходит время», а не ощущения.

🔹 Как посчитать
1️⃣ Определи период анализа - обычно месяц.
2️⃣ Выбери статусы, которые считаются активными (In Progress, Review, Testing) после точки комитмента.
3️⃣ Для каждой задачи вычисли, сколько времени она провела в активных статусах - это touch time.
4️⃣ Раздели задачи по типам работ (фичи, поддержка, техдолг, исследования).
5️⃣ Для каждого типа суммируй всё активное время задач.
6️⃣ Рассчитай долю каждого типа:
WIP Rate (тип работы) = (Сумма touch time задач этого типа) / (Сумма touch time всех задач) × 100%

🔹 Как читать метрику
📊 Для команды определите какой % должен быть по фичам, если процент падает, можно задать вопросы бизнесу: где фичи?
⚖️ Если поддержка стабильно отъедает треть, то стоит посмотреть, не стало ли это нормой.
🎯 Ценность WIP rate в динамике, в том, как меняется фокус команды со временем.

#метрики #wiprate

💸 Почему изменение процесса без метрик - это не улучшение, а вера в чудо
Во многих командах изменение процесса выглядит так:
«Давайте сделаем Daily короче / добавим колонку / перейдём на WIP-лимиты - должно стать лучше».
Никто не формулирует, что значит «лучше» и как это вообще измерить.
В итоге команда меняет процесс, искренне верит, что что-то улучшила… но бизнес не чувствует ни ускорения, ни снижения риска, ни экономии.

🧪 Output ≠ Outcome
Важно понимать: само внедрение изменений не является улучшением.
✅ Output - мы что-то сделали: внедрили практику, добавили артефакт, изменили правила приоритезации.
✅ Outcome - мы реально ускорились, снизили издержки, уменьшили хаос, стали предсказуемыми.
❗️Когда нет метрик - команда видит только Output и считает, что «изменилась → улучшилась». Но был ли Outcome, остаётся загадкой. А значит, никто не может доказать ценность изменений.

📏 Метрики - это способ увидеть Outcome
С метриками изменение процесса перестаёт быть актом веры и превращается в управляемый эксперимент:
Например:
Ввели WIP-лимиты->Снижение среднего времени доставки (смотрим на Lead time)
Добавили Kanban Replenishment->Стабилизация потока (смотрим на Throughput)
Ввели блокировку по причинам->Снижение внешних задержек (смотрим на количество блокировок)
Если изменений нет, то это не «плохая команда». Это просто гипотеза не сработала. Мы ищем следующую.

📉 Метрики переводят изменения в экономику
Когда у вас есть Lead Time, Throughput и данные по ФОТ команды —> вы можете показать бизнесу:
«Мы уменьшили Lead Time на 20% → бизнес начал получать фичи на 2 недели раньше → возврат инвестиций стал быстрее».
«Мы снизили количество блокировок → сократили простой → экономия времени команды = экономия денег».
«Мы повысили пропускную способность → теперь одна фича “стоит” меньше → стоимость развития снижается».
Теперь изменения не «кажется, стало лучше», а обоснованная инвестиция.

✅ Вывод
Если вы меняете процесс без метрик:
→ вы не знаете, улучшили вы что-то или просто стали работать «по-другому».
→ любая практика воспринимается как «мистическое спасение».
→ через полгода всё откатывается обратно.

Если вы меняете процесс с метриками:
→ у вас есть гипотеза → эксперимент → результат → выгода.
→ вы формируете цикл непрерывного улучшения.
→ вы можете переводить изменения в деньги.

🔍 Улучшение без метрик - это вера. Улучшение с метриками - это управление.

Всем успешной доставки 🚀
💰 Как превратить метрики в деньги (и показать бизнесу ценность процесса)
Многие команды внедряют Lead Time, пропускную способность и на этом останавливаются. Но как только вы переводите метрики в деньги, разговор с бизнесом меняется.

📍 Допустим:
ФОТ команды (разработчики, тестировщики, аналитики) = 2 000 000 ₽ в месяц
Команда завершает 20 задач в месяц
Пропускная способность распределяется так:
✅ Фичи -10 задач
🐞 Баги - 6 задач
🧱 Техдолг - 4 задачи
📊 Считаем стоимость одной задачи
1️⃣ Берём ФОТ: 2 000 000 ₽
2️⃣ Делим на количество завершённых задач:
👉 2 000 000 ₽ / 20 = 100 000 ₽ за одну задачу

И это не теория - это ответ на вопросы бизнеса:
📍 «Сколько стоит одна фича?»
📍 «Почему при падении производительности мы теряем деньги?»
📍 «Что даст нам ускорение на 20%?»

Теперь понятно, что "просто взять ещё одну задачу сверху" - это не бесплатно.
В таком случаи даже можно посчитать сколько будет стоить 1 фича (среди багов и техдолга), но для этого надо понимать трудозатраты по каждому типу задач.

🚀 Дальше можно показать влияние изменений:

📉 Сократили Lead Time → быстрее получаем ценность.
📈 Увеличили Throughput до 25 задач → стоимость задачи падает до 80 000 ₽.
📦 Убрали простаивания → выросла эффективность инвестиций.

Получается не просто «мы стали быстрее», а:
👉 «Мы снизили себестоимость задачи на 20% и ускорили возврат инвестиций».

🎯 Что это даёт команде:
✔️ Легче обосновывать инициативы по улучшению
✔️ Проще защищать capacity на техдолг
✔️ Можно оценивать экономический эффект от изменений
✔️ Команда начинает понимать, как её работа влияет на деньги

Метрики решают 😎
#метрики #leadtime #throughput

Всем успешной доставки, недавно на круглом столе мы обсуждали ситуацию, когда метрики ставят в KPI команды/человека. Это очень плохо и я попробую раскрыть почему.

🎯 Почему метрика в KPI перестаёт быть метрикой
Есть такой закон Гудхарта:
«Когда мера становится целью, она перестаёт быть хорошей мерой».
И это ровно то, что происходит, когда метрику ставят в KPI.
Пока метрики инструмент обратной связи, они помогают понять, где узкие места и как улучшить процесс.
Но как только метрики превращают в цель, то начинается искажение.

📉 Примеры:
Сокращаем Lead Time - команда перестаёт брать сложные задачи, лишь бы не портить среднее значение.
Повышаем Throughput - задачи дробятся до абсурда, чтобы график красиво рос.
Считаем % выполнения планов - задачи начинают «переоценивать» на старте, чтобы наверняка попасть в 100%.

В итоге команда не улучшает процесс, она играет с цифрами.
Метрики нужны не для контроля, а для понимания. Они должны помогать находить точки роста, а не становиться способом давления.

🚦Как сделать правильно:
-Отделяйте KPI бизнеса от метрик процесса.
-Метрики используйте как инструмент улучшения процессов.
-Смотрите не на цифры сами по себе, а на тренды и контекст.
-Определить себе north star метрику к которой хочется стремиться.

У вас стоят метрики в KPI?