🚚📦 Delivery Meme Friday 🎉
А вы знаете, что Скрама вообще не существует?😂

🔹 Что такое точка принятия обязательств?
Всем успешной доставки!
Здесь я много писал про практики и принципы и каденции в Канбан, но не раскрыл самое главное 🌚 что такое "точка принятия обязательств"
В Канбане есть ключевое понятие - Commitment Point или точка принятия обязательств.
Это момент, когда команда официально берёт на себя ответственность довести задачу до результата. Можно сказать задача переходит из "хотим сделать" в "решили делать".
До этой точки идеи и запросы могут свободно обсуждаться, приоритизироваться, отсеиваться. Но как только задача пересекает границу, то команда обязуется её сделать.

🔹 Как определить эту точку?
Визуально - это граница на доске, где заканчивается поток «идей» и начинается поток «обязательств».
На практике у разных команд это может быть разный статус: «Готов к работе», «Запланирован», «Принят в работу».

🔹 Зачем она нужна?
Чтобы управлять ожиданиями заказчиков: до этой точки можно менять приоритеты, после команда работает на выполнение своих обязательств.
Чтобы отделить мир пожеланий от мира обязательств.

🔹 Какие метрики считаются от этой точки?
Lead Time - сколько времени задача проходит от обязательства до «Done».
Throughput - сколько задач команда завершает за период (считается только то, что прошло через точку).
Flow Efficiency - доля реальной работы во времени задачи.

🔹 Что является «отдачей обязательств»?
Точка выхода из зоны обязательств - это момент, когда команда выполнила обещанное.
⚡️ Ключевой критерий: задача больше не требует усилий команды и приносит ценность заказчику.

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

📌 Вывод:
Точка принятия обязательств - это ключевой рубеж в потоке задач: от неё считаются основные метрики потока, а завершение задачи после этой точки - это выполнение обязательства перед заказчиком.

🚚📦 Delivery Meme Friday 🎉
Не надо так 😂, стори поинты не работают, используйте метрики

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

🚚📦 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 недели раньше → возврат инвестиций стал быстрее».
«Мы снизили количество блокировок → сократили простой → экономия времени команды = экономия денег».
«Мы повысили пропускную способность → теперь одна фича “стоит” меньше → стоимость развития снижается».
Теперь изменения не «кажется, стало лучше», а обоснованная инвестиция.

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

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

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