Приходите к нам на первый круглый стол, где будем говорить про внедрение изменений 😎

🚚📦 Delivery Meme Friday 🎉
Кажется уже из каждого утюга говорят про ИИ, а есть ли конкретные примеры как вам ИИ помог в работе? Кроме написания текста и поиска информации?
Мы у себя подключили внутреннюю LLM, которая по комментариям указанным при блокировки задач автоматически определяет категории блокировок.
Хотите, расскажу подробнее, как мы это сделали?

🚚📦 Delivery Meme Friday 🎉

Всем успешной доставки!
Внедрять изменения это не благородное дело😢 Потому, что всегда столкнешься с сопротивлением. Есть хороший пост из канала "Разумный менеджмент" «Почему изменения бесят команду?»

И я прям согласен почти с каждым пунктом.
Команды редко сопротивляются самим изменениям - они сопротивляются хаосу, который за ними идёт. Когда нет прозрачности, контекста и последовательности, любая инициатива воспринимается как «ещё одна странная идея сверху».

В итоге даже полезные улучшения начинают раздражать.
Особенно откликнулось про игнорирование текущего контекста.
Если команда уже горит в дедлайнах и не выстроены базовые процессы, любое «новое» только усиливает боль.

Тут важно не просто «внедрить», а помочь пройти изменения осознанно.
🧩 Один из подходов, который мне нравится ADKAR.

Он помогает смотреть на изменения через призму людей, а не только процессов:
Awareness - понять, зачем всё это нужно,
Desire - захотеть участвовать,
Knowledge - знать, как делать,
Ability - уметь применять,
Reinforcement - закрепить результат.
Иногда достаточно пройтись по этим шагам, чтобы увидеть, где именно буксует внедрение.

📌 Почитайте пост - хорошая основа для рефлексии.
А если добавить к нему призму ADKAR, то можно реально повысить шансы, что изменения приживутся, а не останутся на слайдах.
Ну и посмотрите другие посты в этом канале, там достаточно интересно рассказывает про управление командой и процессами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🚚📦 Delivery Meme Friday 🎉

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

🚚📦 Delivery Meme Friday 🎉
У вас есть кот? 😁