📏 Метрика недели 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

Всем успешной доставки 🚀
💰 Как превратить метрики в деньги (и показать бизнесу ценность процесса)
Многие команды внедряют 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

🚀 Всем успешной доставки!
Этап Delivery — это ключевая часть e2e процесса, где идея превращается в реальный результат. Но как сделать так, чтобы этот этап прошел гладко, а клиент получил именно то, что ему нужно? Давайте разберемся.

Что такое этап Delivery?
Delivery — это этап, на котором команда реализует продукт или фичу, основываясь на требованиях, определенных на этапе Discovery. Это не просто разработка, а целый комплекс процессов, включающий планирование, выполнение, тестирование и выпуск продукта.

Цель этапа Delivery — доставить ценность клиенту в рамках установленных ограничений: бюджета, сроков, ресурсов и качества.

Основные подэтапы Delivery
1.Планирование
На этом этапе команда определяет, как будет реализован продукт. Это включает:
Разработку дорожной карты.
Оценку ресурсов и сроков.
Распределение задач между участниками команды.

2.Разработка
Здесь команда приступает к созданию продукта. Важно, чтобы каждый участник понимал свои задачи и сроки их выполнения.
Разработчики пишут код.
Дизайнеры создают интерфейсы.
Тестировщики готовят тестовые сценарии.

3.Тестирование
Тестирование — это не просто проверка на баги, а гарантия того, что продукт соответствует требованиям клиента.
Функциональное тестирование: проверка, что все функции работают как задумано.
Регрессионное тестирование: проверка, что новые изменения не сломали старый функционал.
Юзабилити-тестирование: проверка удобства использования.
Совет: Автоматизируйте тестирование, чтобы сократить время на рутинные проверки.

4.Релиз
Релиз — это момент, когда продукт становится доступным для клиентов. Это может быть:
Полное развертывание (когда продукт выпускается для всех пользователей).
Поэтапное развертывание (когда продукт сначала выпускается для ограниченной группы пользователей).
Совет: Используйте feature toggles (флаги функций), чтобы включать или отключать функционал без необходимости повторного релиза.

5.Сбор обратной связи
После релиза важно собрать обратную связь от пользователей. Это поможет понять, насколько продукт соответствует их ожиданиям, и выявить возможные улучшения.
Опросы пользователей.
Аналитика продукта (например, метрики вовлеченности).
Интервью с клиентами.
Совет: Внедрите систему обратной связи прямо в продукт (например, кнопку «Сообщить о проблеме»).

Метрики для контроля этапа Delivery
Чтобы понять, насколько эффективно проходит этап Delivery, используйте следующие метрики:

1.Lead Time
Время от момента поступления задачи до ее завершения. Помогает оценить скорость выполнения задач.
2.Throughput
Количество задач, завершенных за единицу времени. Показывает, насколько продуктивна команда.
3.WIP (Work In Progress)
Количество задач, находящихся в работе одновременно. Высокий WIP может указывать на перегрузку команды.

Итог
Этап Delivery — это не просто технический процесс, а искусство доставки ценности клиенту. Чтобы он прошел успешно, важно:
-Планировать каждый шаг.
-Контролировать качество на всех этапах.
-Собирать и учитывать обратную связь.
-Использовать метрики для анализа и улучшения процессов.

А как вы организуете этап Delivery в своей команде? Делитесь опытом в комментариях! 😊
#delivery #метрики #e2e

Самая недооценённая метрика: "Blocked Time" ⏱️⛔️
Всем успешной доставки, на связи рубрика "Метрика недели"

Сегодня пишу про "более зрелую" метрику Blocked time, почему "более зрелую"?
Почему ее называют «более зрелой метрикой»?
Команды, которые начинают её считать, уже вышли за рамки базовых показателей вроде Lead Time или WIP.
Blocked Time требует осознанного анализа: что именно мешает нам двигаться?
Она не только показывает факт задержки, но и помогает вскрывать системные проблемы взаимодействия.

Blocked time - это время, которое задача была «заблокирована» ⛔️.
То есть команда не могла продвигать её дальше из-за внешних или внутренних зависимостей:
-ждём ревью у другой команды,
-не пришли данные от заказчика,
-согласование у юристов.
-фриз на релиз

🔥 Какую проблему решает?
-Помогает отделить «мы работали долго» от «мы не могли работать, потому что ждали».
-Делает узкие места прозрачными: видно, что тестирование ждёт доступ к стенду по 5 дней, или заказчик согласовывает требования неделями.
-Даёт аргументы на встречах с заказчиком и внутри компании: «Сами мы сделали за 2 дня, но 10 дней ушло на ожидание согласования».

📈 Использование Blocked Time в динамике:
Если показатель системно высокий → проблема в процессе (надо оптимизировать взаимодействие).
Если блокеры случайные и редкие → нормальная рабочая ситуация, главное фиксировать и обсуждать.

📝 Чек-лист: стоит считать Blocked Time, если…
-у вас уже есть базовые метрики (Lead Time, WIP),
-ощущаете, что «задачи буксуют», но непонятно где,
-хотите объяснять сроки на языке данных, а не эмоций.

А у вас в команде считается Blocked Time? Делитесь опытом 👇