Всем успешной доставки!
Внедрять изменения это не благородное дело😢 Потому, что всегда столкнешься с сопротивлением. Есть хороший пост из канала "Разумный менеджмент" «Почему изменения бесят команду?»
И я прям согласен почти с каждым пунктом.
Команды редко сопротивляются самим изменениям - они сопротивляются хаосу, который за ними идёт. Когда нет прозрачности, контекста и последовательности, любая инициатива воспринимается как «ещё одна странная идея сверху».
В итоге даже полезные улучшения начинают раздражать.
Особенно откликнулось про игнорирование текущего контекста.
Если команда уже горит в дедлайнах и не выстроены базовые процессы, любое «новое» только усиливает боль.
Тут важно не просто «внедрить», а помочь пройти изменения осознанно.
🧩 Один из подходов, который мне нравится ADKAR.
Он помогает смотреть на изменения через призму людей, а не только процессов:
Awareness - понять, зачем всё это нужно,
Desire - захотеть участвовать,
Knowledge - знать, как делать,
Ability - уметь применять,
Reinforcement - закрепить результат.
Иногда достаточно пройтись по этим шагам, чтобы увидеть, где именно буксует внедрение.
📌 Почитайте пост - хорошая основа для рефлексии.
А если добавить к нему призму ADKAR, то можно реально повысить шансы, что изменения приживутся, а не останутся на слайдах.
Ну и посмотрите другие посты в этом канале, там достаточно интересно рассказывает про управление командой и процессами.
Внедрять изменения это не благородное дело😢 Потому, что всегда столкнешься с сопротивлением. Есть хороший пост из канала "Разумный менеджмент" «Почему изменения бесят команду?»
И я прям согласен почти с каждым пунктом.
Команды редко сопротивляются самим изменениям - они сопротивляются хаосу, который за ними идёт. Когда нет прозрачности, контекста и последовательности, любая инициатива воспринимается как «ещё одна странная идея сверху».
В итоге даже полезные улучшения начинают раздражать.
Особенно откликнулось про игнорирование текущего контекста.
Если команда уже горит в дедлайнах и не выстроены базовые процессы, любое «новое» только усиливает боль.
Тут важно не просто «внедрить», а помочь пройти изменения осознанно.
🧩 Один из подходов, который мне нравится ADKAR.
Он помогает смотреть на изменения через призму людей, а не только процессов:
Awareness - понять, зачем всё это нужно,
Desire - захотеть участвовать,
Knowledge - знать, как делать,
Ability - уметь применять,
Reinforcement - закрепить результат.
Иногда достаточно пройтись по этим шагам, чтобы увидеть, где именно буксует внедрение.
📌 Почитайте пост - хорошая основа для рефлексии.
А если добавить к нему призму ADKAR, то можно реально повысить шансы, что изменения приживутся, а не останутся на слайдах.
Ну и посмотрите другие посты в этом канале, там достаточно интересно рассказывает про управление командой и процессами.
👍5
Всем успешной доставки, недавно на круглом столе мы обсуждали ситуацию, когда метрики ставят в KPI команды/человека. Это очень плохо и я попробую раскрыть почему.
🎯 Почему метрика в KPI перестаёт быть метрикой
Есть такой закон Гудхарта:
«Когда мера становится целью, она перестаёт быть хорошей мерой».
И это ровно то, что происходит, когда метрику ставят в KPI.
Пока метрики инструмент обратной связи, они помогают понять, где узкие места и как улучшить процесс.
Но как только метрики превращают в цель, то начинается искажение.
📉 Примеры:
Сокращаем Lead Time - команда перестаёт брать сложные задачи, лишь бы не портить среднее значение.
Повышаем Throughput - задачи дробятся до абсурда, чтобы график красиво рос.
Считаем % выполнения планов - задачи начинают «переоценивать» на старте, чтобы наверняка попасть в 100%.
В итоге команда не улучшает процесс, она играет с цифрами.
Метрики нужны не для контроля, а для понимания. Они должны помогать находить точки роста, а не становиться способом давления.
🚦Как сделать правильно:
-Отделяйте KPI бизнеса от метрик процесса.
-Метрики используйте как инструмент улучшения процессов.
-Смотрите не на цифры сами по себе, а на тренды и контекст.
-Определить себе north star метрику к которой хочется стремиться.
У вас стоят метрики в KPI?
🎯 Почему метрика в KPI перестаёт быть метрикой
Есть такой закон Гудхарта:
«Когда мера становится целью, она перестаёт быть хорошей мерой».
И это ровно то, что происходит, когда метрику ставят в KPI.
Пока метрики инструмент обратной связи, они помогают понять, где узкие места и как улучшить процесс.
Но как только метрики превращают в цель, то начинается искажение.
📉 Примеры:
Сокращаем Lead Time - команда перестаёт брать сложные задачи, лишь бы не портить среднее значение.
Повышаем Throughput - задачи дробятся до абсурда, чтобы график красиво рос.
Считаем % выполнения планов - задачи начинают «переоценивать» на старте, чтобы наверняка попасть в 100%.
В итоге команда не улучшает процесс, она играет с цифрами.
Метрики нужны не для контроля, а для понимания. Они должны помогать находить точки роста, а не становиться способом давления.
🚦Как сделать правильно:
-Отделяйте KPI бизнеса от метрик процесса.
-Метрики используйте как инструмент улучшения процессов.
-Смотрите не на цифры сами по себе, а на тренды и контекст.
-Определить себе north star метрику к которой хочется стремиться.
У вас стоят метрики в KPI?
🔥4❤2👍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
💰 Как превратить метрики в деньги (и показать бизнесу ценность процесса)
Многие команды внедряют 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
1🔥8❤5👍4
This media is not supported in your browser
VIEW IN TELEGRAM
🚚📦 Delivery Meme Friday 🎉
Не обижайте Скрам-мастера, переходите на Канбан 😂
Не обижайте Скрам-мастера, переходите на Канбан 😂
😁11🤣1
💸 Почему изменение процесса без метрик - это не улучшение, а вера в чудо
Во многих командах изменение процесса выглядит так:
«Давайте сделаем Daily короче / добавим колонку / перейдём на WIP-лимиты - должно стать лучше».
Никто не формулирует, что значит «лучше» и как это вообще измерить.
В итоге команда меняет процесс, искренне верит, что что-то улучшила… но бизнес не чувствует ни ускорения, ни снижения риска, ни экономии.
🧪 Output ≠ Outcome
Важно понимать: само внедрение изменений не является улучшением.
✅ Output - мы что-то сделали: внедрили практику, добавили артефакт, изменили правила приоритезации.
✅ Outcome - мы реально ускорились, снизили издержки, уменьшили хаос, стали предсказуемыми.
❗️Когда нет метрик - команда видит только Output и считает, что «изменилась → улучшилась». Но был ли Outcome, остаётся загадкой. А значит, никто не может доказать ценность изменений.
📏 Метрики - это способ увидеть Outcome
С метриками изменение процесса перестаёт быть актом веры и превращается в управляемый эксперимент:
Например:
Ввели WIP-лимиты->Снижение среднего времени доставки (смотрим на Lead time)
Добавили Kanban Replenishment->Стабилизация потока (смотрим на Throughput)
Ввели блокировку по причинам->Снижение внешних задержек (смотрим на количество блокировок)
Если изменений нет, то это не «плохая команда». Это просто гипотеза не сработала. Мы ищем следующую.
📉 Метрики переводят изменения в экономику
Когда у вас есть Lead Time, Throughput и данные по ФОТ команды —> вы можете показать бизнесу:
«Мы уменьшили Lead Time на 20% → бизнес начал получать фичи на 2 недели раньше → возврат инвестиций стал быстрее».
«Мы снизили количество блокировок → сократили простой → экономия времени команды = экономия денег».
«Мы повысили пропускную способность → теперь одна фича “стоит” меньше → стоимость развития снижается».
Теперь изменения не «кажется, стало лучше», а обоснованная инвестиция.
✅ Вывод
Если вы меняете процесс без метрик:
→ вы не знаете, улучшили вы что-то или просто стали работать «по-другому».
→ любая практика воспринимается как «мистическое спасение».
→ через полгода всё откатывается обратно.
Если вы меняете процесс с метриками:
→ у вас есть гипотеза → эксперимент → результат → выгода.
→ вы формируете цикл непрерывного улучшения.
→ вы можете переводить изменения в деньги.
🔍 Улучшение без метрик - это вера. Улучшение с метриками - это управление.
Во многих командах изменение процесса выглядит так:
«Давайте сделаем Daily короче / добавим колонку / перейдём на WIP-лимиты - должно стать лучше».
Никто не формулирует, что значит «лучше» и как это вообще измерить.
В итоге команда меняет процесс, искренне верит, что что-то улучшила… но бизнес не чувствует ни ускорения, ни снижения риска, ни экономии.
🧪 Output ≠ Outcome
Важно понимать: само внедрение изменений не является улучшением.
✅ Output - мы что-то сделали: внедрили практику, добавили артефакт, изменили правила приоритезации.
✅ Outcome - мы реально ускорились, снизили издержки, уменьшили хаос, стали предсказуемыми.
❗️Когда нет метрик - команда видит только Output и считает, что «изменилась → улучшилась». Но был ли Outcome, остаётся загадкой. А значит, никто не может доказать ценность изменений.
📏 Метрики - это способ увидеть Outcome
С метриками изменение процесса перестаёт быть актом веры и превращается в управляемый эксперимент:
Например:
Ввели WIP-лимиты->Снижение среднего времени доставки (смотрим на Lead time)
Добавили Kanban Replenishment->Стабилизация потока (смотрим на Throughput)
Ввели блокировку по причинам->Снижение внешних задержек (смотрим на количество блокировок)
Если изменений нет, то это не «плохая команда». Это просто гипотеза не сработала. Мы ищем следующую.
📉 Метрики переводят изменения в экономику
Когда у вас есть Lead Time, Throughput и данные по ФОТ команды —> вы можете показать бизнесу:
«Мы уменьшили Lead Time на 20% → бизнес начал получать фичи на 2 недели раньше → возврат инвестиций стал быстрее».
«Мы снизили количество блокировок → сократили простой → экономия времени команды = экономия денег».
«Мы повысили пропускную способность → теперь одна фича “стоит” меньше → стоимость развития снижается».
Теперь изменения не «кажется, стало лучше», а обоснованная инвестиция.
✅ Вывод
Если вы меняете процесс без метрик:
→ вы не знаете, улучшили вы что-то или просто стали работать «по-другому».
→ любая практика воспринимается как «мистическое спасение».
→ через полгода всё откатывается обратно.
Если вы меняете процесс с метриками:
→ у вас есть гипотеза → эксперимент → результат → выгода.
→ вы формируете цикл непрерывного улучшения.
→ вы можете переводить изменения в деньги.
🔍 Улучшение без метрик - это вера. Улучшение с метриками - это управление.
1👍6🔥5❤2
📚 Серия книг «Цель» Голдратта - зачем читать и что понять про Теорию ограничений.
Всем успешной доставки! Не знаю почему я раньше не написал про эти книги, но кажется это база базовая в управлении потоком.
Когда я впервые взял «Цель», думал, что это будет занудный учебник по производству. А оказалось роман про директора, которому дали пару месяцев, чтобы спасти завод.
И с каждой главой ты понимаешь - это не про завод, это про твою команду, твой процесс, твои «узкие места».
🔹 Теория ограничений (ТОС) - простая, но переворачивающая мышление идея: в любой системе есть одно ограничение, которое задаёт темп всему процессу. Можно оптимизировать всё подряд, но пока не найдёшь и не разгрузишь главное узкое место - всё остальное не сдвинется.
Книги:
🔹 «Цель» про то, как это осознать. Как перестать «чинить всё» и начать работать с тем, что реально ограничивает поток.
🔹 «Цель-2. Дело не в везении» про то, что ограничения бывают не только физическими, но и управленческими. Иногда тормозит не процесс, а политика.
🔹 «Цель-3. Необходимо, но недостаточно» уже про стратегию. Как принимать решения, когда идеальных вариантов нет, и почему «или–или» - это чаще всего ловушка мышления.
🔹 «Критическая цепь» тут Голдратт показывает, что сроки срываются не из-за времени, а из-за поведения людей и системы приоритетов.
ТОС - это не про завод. Это про то, как думать системно: искать, где реально застревает поток, и строить улучшения оттуда.
Если ты Delivery Manager, тимлид или просто хочешь перестать тушить пожары - начни с первой «Цели».
Еще есть классный канал про ТОС, всем рекомендую почитать (не реклама 😎)
Всем успешной доставки! Не знаю почему я раньше не написал про эти книги, но кажется это база базовая в управлении потоком.
Когда я впервые взял «Цель», думал, что это будет занудный учебник по производству. А оказалось роман про директора, которому дали пару месяцев, чтобы спасти завод.
И с каждой главой ты понимаешь - это не про завод, это про твою команду, твой процесс, твои «узкие места».
🔹 Теория ограничений (ТОС) - простая, но переворачивающая мышление идея: в любой системе есть одно ограничение, которое задаёт темп всему процессу. Можно оптимизировать всё подряд, но пока не найдёшь и не разгрузишь главное узкое место - всё остальное не сдвинется.
Книги:
🔹 «Цель» про то, как это осознать. Как перестать «чинить всё» и начать работать с тем, что реально ограничивает поток.
🔹 «Цель-2. Дело не в везении» про то, что ограничения бывают не только физическими, но и управленческими. Иногда тормозит не процесс, а политика.
🔹 «Цель-3. Необходимо, но недостаточно» уже про стратегию. Как принимать решения, когда идеальных вариантов нет, и почему «или–или» - это чаще всего ловушка мышления.
🔹 «Критическая цепь» тут Голдратт показывает, что сроки срываются не из-за времени, а из-за поведения людей и системы приоритетов.
ТОС - это не про завод. Это про то, как думать системно: искать, где реально застревает поток, и строить улучшения оттуда.
Если ты Delivery Manager, тимлид или просто хочешь перестать тушить пожары - начни с первой «Цели».
Еще есть классный канал про ТОС, всем рекомендую почитать (не реклама 😎)
2🔥8👍3🥰2
📏 Метрика недели 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
Всем успешной доставки!
Возвращаю рубрику «Метрика недели». Сегодня говорим про 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
1🔥4👍2
🎄 Годовое ретро: один пост, который закрывает весь вопрос
Всем успешной доставки!
Скоро конец года и вы наверное с командой начнете подводить итоги, лучше всего это делать на ретро команд, чтобы остановиться, посмотреть назад и не утащить старые паттерны в новый цикл. Годовое ретро здесь работает лучше любых планёрок: оно возвращает команде общую картину, показывает, что реально усиливало, что стабильно мешало, и помогает снова почувствовать влияние на процесс.
Чтобы упростить жизнь собрал единый гайд: форматы + вопросы, которые помогут вам провести ретро более плодотворно
7 рабочих сценариев годового ретро
1️⃣ Мемное ретро - каждый приносит мем про год. Убирает напряжение и открывает честность.
2️⃣ Таймлайн года - релизы, инциденты, найм, перестройки. Видно, что действительно происходило.
3️⃣ Награды года - несерьёзные номинации, которые приводят к серьёзным выводам
4️⃣ Data-driven ретро - Lead Time, WIP, дефекты, предсказуемость → что на это влияло?
5️⃣ Комикс-ретро - «как было», «как стало», «как хотим». Отлично визуализирует процесс.
6️⃣ Ретро через персонажей - обсуждение от имени образов помогает говорить о «сложном».
7️⃣ Ретро целей - что планировали, что получилось, что мешало, что оставляем в новом году.
🧩 Универсальный шаблон из 5 вопросов, подходит к любому из форматов выше:
-Что в этом году реально работало?
-Что стабильно нас замедляло?
-Какие решения мы приняли, но не довели и почему?
-Какие 1–2 принципа переносим в новый год?
-Что готовы сделать в первые 2 недели января?
Инструменты для ретро - это онлайн доски, во многих есть готовые шаблоны, например Unidraw
А вы проводите годовое ретро?
#ретро #итогигода
Всем успешной доставки!
Скоро конец года и вы наверное с командой начнете подводить итоги, лучше всего это делать на ретро команд, чтобы остановиться, посмотреть назад и не утащить старые паттерны в новый цикл. Годовое ретро здесь работает лучше любых планёрок: оно возвращает команде общую картину, показывает, что реально усиливало, что стабильно мешало, и помогает снова почувствовать влияние на процесс.
Чтобы упростить жизнь собрал единый гайд: форматы + вопросы, которые помогут вам провести ретро более плодотворно
7 рабочих сценариев годового ретро
1️⃣ Мемное ретро - каждый приносит мем про год. Убирает напряжение и открывает честность.
2️⃣ Таймлайн года - релизы, инциденты, найм, перестройки. Видно, что действительно происходило.
3️⃣ Награды года - несерьёзные номинации, которые приводят к серьёзным выводам
4️⃣ Data-driven ретро - Lead Time, WIP, дефекты, предсказуемость → что на это влияло?
5️⃣ Комикс-ретро - «как было», «как стало», «как хотим». Отлично визуализирует процесс.
6️⃣ Ретро через персонажей - обсуждение от имени образов помогает говорить о «сложном».
7️⃣ Ретро целей - что планировали, что получилось, что мешало, что оставляем в новом году.
🧩 Универсальный шаблон из 5 вопросов, подходит к любому из форматов выше:
-Что в этом году реально работало?
-Что стабильно нас замедляло?
-Какие решения мы приняли, но не довели и почему?
-Какие 1–2 принципа переносим в новый год?
-Что готовы сделать в первые 2 недели января?
Инструменты для ретро - это онлайн доски, во многих есть готовые шаблоны, например Unidraw
А вы проводите годовое ретро?
#ретро #итогигода
Unidraw
Unidraw — онлайн-доска для репетиторства и совместной работы бесплатно
Российская бесплатная интерактивная онлайн-доска для репетиторства, дистанционного обучения и совместной работы. Простая альтернатива Miro. Пишите, рисуйте, создавайте mind map, таблицы, CJM, workflow, сценарии и воронки
1🔥6❤2👍1
Всем успешной доставки! Давно не было постов, потому что я пытался разобраться, что происходит на российском рынке таск-трекеров. Хорошая новость, их стало много. Плохая, функционал пока местами хромает.
Для себя я выделил критерии оценки таск-трекеров:
- Есть бесплатный тариф - чтобы можно было спокойно посмотреть возможности.
- Есть встроенные отчёты для метрик (Lead Time, пропускная способность).
- Есть WIP-лимиты на доске.
- Есть какая-то автоматизация.
- Есть импорт из других трекеров.
Nice to have - встроенная база знаний, как wiki в Jira.
Пост решил разделить на две части, чтобы не перегружать.
Часть 1
Поехали:
Shtab
- Бесплатный тариф: есть, до 5 человек.
- Отчёты для метрик: есть, но не понял, можно ли корректно считать Lead Time.
- WIP-лимиты: нет.
- Автоматизация: нет в бесплатном тарифе, есть в платном.
- Импорт: есть.
Интерфейс мне показался не самым интуитивным, не смог настроить доску со своими статусами 😂. Зато Shtab единственные, кто лично написал мне письмо с предложением помощи. Это большой плюс.
TeamStorm
- Бесплатный тариф: Нет. Платный 500 ₽ за пользователя в месяц. Есть ещё отдельный тариф за поддержку по их же продукту 😄
- Отчёты: неизвестно, нет бесплатного тарифа.
- WIP-лимиты: неизвестно, нет бесплатного тарифа.
- Автоматизация: неизвестно, нет бесплатного тарифа.
- Импорт: неизвестно, нет бесплатного тарифа.
Directum Projects
- Бесплатный тариф: Нет. Платный 788 ₽ за пользователя в месяц.
- Отчёты: неизвестно, нет бесплатного тарифа
- WIP-лимиты: неизвестно, нет бесплатного тарифа
- Автоматизация: неизвестно, нет бесплатного тарифа
- Импорт: неизвестно, нет бесплатного тарифа
Можно запросить консультацию через сайт, возможно, дадут демо-доступ.
WEEEK
- Бесплатный тариф: есть, до 5 человек.
- Отчёты для метрик: не нашёл.
- WIP-лимиты: есть, но только в Pro.
- Автоматизация: не нашёл.
- Импорт: есть.
-Nice to have - есть база знаний для внутренней документации.
Интерфейс понятный, но потребуется немного времени, чтобы привыкнуть.
Вывод
В 2025 году хочется не просто «двигать карточки», а делать это осознанно, с опорой на метрики. Возможность считать Lead Time и пропускную способность - это уже базовый функционал.
И важный момент: отсутствие бесплатного тарифа сильно усложняет выбор. Всё-таки хочется сначала посмотреть продукт, прежде чем в него въезжать всей командой.
P.S.Если вы знаете людей которые создают этот продукт, покажите им пост, дайте мои контакты, дам им развернутую обратную связь 😎
Для себя я выделил критерии оценки таск-трекеров:
- Есть бесплатный тариф - чтобы можно было спокойно посмотреть возможности.
- Есть встроенные отчёты для метрик (Lead Time, пропускная способность).
- Есть WIP-лимиты на доске.
- Есть какая-то автоматизация.
- Есть импорт из других трекеров.
Nice to have - встроенная база знаний, как wiki в Jira.
Пост решил разделить на две части, чтобы не перегружать.
Часть 1
Поехали:
Shtab
- Бесплатный тариф: есть, до 5 человек.
- Отчёты для метрик: есть, но не понял, можно ли корректно считать Lead Time.
- WIP-лимиты: нет.
- Автоматизация: нет в бесплатном тарифе, есть в платном.
- Импорт: есть.
Интерфейс мне показался не самым интуитивным, не смог настроить доску со своими статусами 😂. Зато Shtab единственные, кто лично написал мне письмо с предложением помощи. Это большой плюс.
TeamStorm
- Бесплатный тариф: Нет. Платный 500 ₽ за пользователя в месяц. Есть ещё отдельный тариф за поддержку по их же продукту 😄
- Отчёты: неизвестно, нет бесплатного тарифа.
- WIP-лимиты: неизвестно, нет бесплатного тарифа.
- Автоматизация: неизвестно, нет бесплатного тарифа.
- Импорт: неизвестно, нет бесплатного тарифа.
Directum Projects
- Бесплатный тариф: Нет. Платный 788 ₽ за пользователя в месяц.
- Отчёты: неизвестно, нет бесплатного тарифа
- WIP-лимиты: неизвестно, нет бесплатного тарифа
- Автоматизация: неизвестно, нет бесплатного тарифа
- Импорт: неизвестно, нет бесплатного тарифа
Можно запросить консультацию через сайт, возможно, дадут демо-доступ.
WEEEK
- Бесплатный тариф: есть, до 5 человек.
- Отчёты для метрик: не нашёл.
- WIP-лимиты: есть, но только в Pro.
- Автоматизация: не нашёл.
- Импорт: есть.
-Nice to have - есть база знаний для внутренней документации.
Интерфейс понятный, но потребуется немного времени, чтобы привыкнуть.
Вывод
В 2025 году хочется не просто «двигать карточки», а делать это осознанно, с опорой на метрики. Возможность считать Lead Time и пропускную способность - это уже базовый функционал.
И важный момент: отсутствие бесплатного тарифа сильно усложняет выбор. Всё-таки хочется сначала посмотреть продукт, прежде чем в него въезжать всей командой.
P.S.Если вы знаете людей которые создают этот продукт, покажите им пост, дайте мои контакты, дам им развернутую обратную связь 😎
1👍7💘1
Всем успешной доставки!
Иногда кажется, что ИИ - это про «большие вещи»: стратегию, аналитику, сложные решения.
Но на самом деле его настоящий потенциал раскрывается там, где рутина давит сильнее всего.
Недавно наткнулся на классный разбор в канале Три монитора о том, как автоматизация спасает от бюрократического ада. Пост про генерацию сотен бюллетеней для МКД (Многоквартирного дома) типичная боль любого, кто хоть раз сталкивался с бумажной волокитой и меняющимися формулировками «прямо перед дедлайном».
ИИ прекрасно справился с реально узкой задачей:
- сгенерировал шаблоны Word,
- вставил нужные спец. поля для шаблонизатора,
- собрал данные в CSV,
По сути сделал всё то, что у людей обычно забирает вечность и силы.
Очень жизненная история, где ИИ помогает в повседневной жизни. И хороший пример того, как стоит относиться к ИИ в работе с командами и процессами: он снимает рутину, но не снимает ответственность за качество.
📌 Если интересно почитать подробнее - ловите пост там есть ссылка на репозиторий 😎
Иногда кажется, что ИИ - это про «большие вещи»: стратегию, аналитику, сложные решения.
Но на самом деле его настоящий потенциал раскрывается там, где рутина давит сильнее всего.
Недавно наткнулся на классный разбор в канале Три монитора о том, как автоматизация спасает от бюрократического ада. Пост про генерацию сотен бюллетеней для МКД (Многоквартирного дома) типичная боль любого, кто хоть раз сталкивался с бумажной волокитой и меняющимися формулировками «прямо перед дедлайном».
ИИ прекрасно справился с реально узкой задачей:
- сгенерировал шаблоны Word,
- вставил нужные спец. поля для шаблонизатора,
- собрал данные в CSV,
По сути сделал всё то, что у людей обычно забирает вечность и силы.
Очень жизненная история, где ИИ помогает в повседневной жизни. И хороший пример того, как стоит относиться к ИИ в работе с командами и процессами: он снимает рутину, но не снимает ответственность за качество.
📌 Если интересно почитать подробнее - ловите пост там есть ссылка на репозиторий 😎
Telegram
Три монитора
Привет! Меня зовут Константин Шибков aka @sendel и тут рассказываю и показываю что узнал новое, что попробовал и прочитал
🔥5
Что скрывается за статусом In Progress
Всем успешной доставки!
Если у вас в доске есть колонка In Progress, то вы еще не полностью визуализировал ваше производство😏 иногда задача заходит туда и исчезает, на дни или даже на недели 😳 И самое забавное, что никто ничего плохого не делает. Но Lead Time растёт, пропускная падает. Почему так происходит? Попробую сегодня ответить на этот вопрос.
Вот что чаще всего прячется внутри этого «волшебного» статуса:
🔹 1. Невидимые работы
Команда пишет код? Нет.
Она: чинит окружение, подбирает логи, спорит с аналитиком, застряла в PR, согласовывает макеты. Всё это работа, но никто её не видит.
А если работы не видно, вы не можете управлять потоком.
🔹 2. Очереди, которые никто не считает
Задача вроде «в работе», но реально она ждёт:
- ревью
- ответ заказчика
- данные от смежников
- тесты
Проблема: очередь маскируется как «работа». В итоге кажется, что все заняты, хотя поток стоит.
🔹 3. Многозадачность.
Один разработчик ведёт 3–5 задач параллельно. Кажется: «ну быстрее же выйдет».
По факту: LT растёт в геометрии, внимание падает, переключение контекста занимает много времени.
🔹 Как почистить «In Progress»
-Разбейте In Progress на реальные статусы: анализ → разработка → ревью → тест → готово.
-Ставь WIP-лимиты, чтобы не накапливать скрытую очередь.
-Заведи правило/DoD: «In Progress больше N дней —> идём смотреть, что там происходит».
Вывод
In Progress сам по себе не зло. Зло - это его непрозрачность.
Чем раньше вы разложите этот «чёрный ящик» на части, тем быстрее появится контроль над потоком и реальные улучшения.
Всем успешной доставки!
Если у вас в доске есть колонка In Progress, то вы еще не полностью визуализировал ваше производство😏 иногда задача заходит туда и исчезает, на дни или даже на недели 😳 И самое забавное, что никто ничего плохого не делает. Но Lead Time растёт, пропускная падает. Почему так происходит? Попробую сегодня ответить на этот вопрос.
Вот что чаще всего прячется внутри этого «волшебного» статуса:
🔹 1. Невидимые работы
Команда пишет код? Нет.
Она: чинит окружение, подбирает логи, спорит с аналитиком, застряла в PR, согласовывает макеты. Всё это работа, но никто её не видит.
А если работы не видно, вы не можете управлять потоком.
🔹 2. Очереди, которые никто не считает
Задача вроде «в работе», но реально она ждёт:
- ревью
- ответ заказчика
- данные от смежников
- тесты
Проблема: очередь маскируется как «работа». В итоге кажется, что все заняты, хотя поток стоит.
🔹 3. Многозадачность.
Один разработчик ведёт 3–5 задач параллельно. Кажется: «ну быстрее же выйдет».
По факту: LT растёт в геометрии, внимание падает, переключение контекста занимает много времени.
🔹 Как почистить «In Progress»
-Разбейте In Progress на реальные статусы: анализ → разработка → ревью → тест → готово.
-Ставь WIP-лимиты, чтобы не накапливать скрытую очередь.
-Заведи правило/DoD: «In Progress больше N дней —> идём смотреть, что там происходит».
Вывод
In Progress сам по себе не зло. Зло - это его непрозрачность.
Чем раньше вы разложите этот «чёрный ящик» на части, тем быстрее появится контроль над потоком и реальные улучшения.
1👍7❤1🔥1
Всем успешной доставки!
Есть один вопрос, который рано или поздно ловит каждого менеджера, разработчика и вообще любого, кто хоть раз брал задачу в работу:
👉 «Когда сделаете?»
И вот тут начинается самое интересное, потому что ответить хочется красиво, быстро и «чтобы отстали». Но как говорится, ваши ожидания - это ваши проблемы.
На днях читал отличный разбор этой темы в канале «Управление без паники» и прям рекомендую. Саша (тезка и бывший коллега) хорошо объясняет, почему «завтра» - это не ответ, «как пойдёт» - это испорченная репутация, а правильный ответ начинается с изменения самого вопроса.
Он предлагают классный приём:
не «Когда сделаете?», а «Успеете к конкретной дате?»
И всё, вместо бесконечного множества вариантов остаются два. Да или нет. И дальше решение уже на основе данных, а не ощущений.
Почему мне зашло:
🔹 объясняет по делу, без сложных терминов;
🔹 показывают, как использовать Lead Time и процентили для прогнозов;
🔹 напоминает, что ответ - это обязательство, а не просто звук.
Особенно классно раскрыто про то, как формируются ожидания стейкхолдеров и почему «сказать дату» = «взять ответственность».
Звучит очевидно, но вот интересно, что большинство промахов в сроках, именно от того, что ожидания были сформированы неправильно, а не потому что команда "тормозила".
Если вам тема тоже близка - загляните в канал «Управление без паники», там много полезной информации.
Есть один вопрос, который рано или поздно ловит каждого менеджера, разработчика и вообще любого, кто хоть раз брал задачу в работу:
👉 «Когда сделаете?»
И вот тут начинается самое интересное, потому что ответить хочется красиво, быстро и «чтобы отстали». Но как говорится, ваши ожидания - это ваши проблемы.
На днях читал отличный разбор этой темы в канале «Управление без паники» и прям рекомендую. Саша (тезка и бывший коллега) хорошо объясняет, почему «завтра» - это не ответ, «как пойдёт» - это испорченная репутация, а правильный ответ начинается с изменения самого вопроса.
Он предлагают классный приём:
не «Когда сделаете?», а «Успеете к конкретной дате?»
И всё, вместо бесконечного множества вариантов остаются два. Да или нет. И дальше решение уже на основе данных, а не ощущений.
Почему мне зашло:
🔹 объясняет по делу, без сложных терминов;
🔹 показывают, как использовать Lead Time и процентили для прогнозов;
🔹 напоминает, что ответ - это обязательство, а не просто звук.
Особенно классно раскрыто про то, как формируются ожидания стейкхолдеров и почему «сказать дату» = «взять ответственность».
Звучит очевидно, но вот интересно, что большинство промахов в сроках, именно от того, что ожидания были сформированы неправильно, а не потому что команда "тормозила".
Если вам тема тоже близка - загляните в канал «Управление без паники», там много полезной информации.
Telegram
Управление без паники
Как ответить на вопрос «Когда сделаете задачу?»
Это сложный и важный вопрос, ответ на который может повлиять на вашу карьеру.
Почему сложный? Потому что это открытый вопрос, и на него есть бесконечное количество ответов — от «завтра» до «через 5 лет» с…
Это сложный и важный вопрос, ответ на который может повлиять на вашу карьеру.
Почему сложный? Потому что это открытый вопрос, и на него есть бесконечное количество ответов — от «завтра» до «через 5 лет» с…
👍6
📋 Чеклист хорошей задачи: перестаём терять время на уточнения
Всем успешной доставки!
Хорошая задача - это не про аккуратно написанный текст. Это про экономию часов команды и меньше «а что ты имел в виду?» в комментариях. Ниже чеклист, который должен вам помочь избежать подводных камней после взятия в работу.
🔑 Обязательные поля (то, без чего задача мусор)
Заголовок - коротко и понятно (что + зачем).
Пример: «Добавить фильтр по статусу в список заявок, чтобы менеджеры видели только открытые».
Описание / Краткое ТЗ - не роман, а шаги/критерии приёма:
-Что сделать (функционал)
-Где изменить (страница/модуль)
-Ожидаемое поведение (конкретно)
Acceptance Criteria (Критерии приёма) - 3–5 пунктов «как проверить, что Done».
Пример: «1) Фильтр виден в правом верхнем углу; 2) При выборе “Открытые” выводятся только статусы A,B; 3) Работает на мобильной версии».
Ожидаемый результат / бизнес-ценность - зачем это нужно (кто выиграет и почему). Очень важный пункт, не хочется делать фичи, которые ничего не дают продукту/компании.
Пример: «Сокращает время обработки заявок на 20% у команды поддержки».
✅ Хорошая привычка - шаблон задачи
Вставьте в шаблон трекера:
Title: [Коротко] — [Ценность]
Denoscription: [Что сделать / где / как]
Acceptance: 1) … 2) … 3) …
Type: [feature/bug/etc]
Owner: @…
Dependencies: [список]
Design: [ссылка]
Estimate: [x pts]
🔍 Пример плохой vs хороший
Плохо:
«Сделать фильтр. Срочно. Нужно, чтобы менеджеры могли выбирать статус.»
Хорошо:
Title: Фильтр по статусу в списке заявок , чтобы отображать только открытые
Denoscription: Добавить выпадающий фильтр. По умолчанию — "Все".
Acceptance: 1) Фильтр показывает опции A/B/C; 2) При выборе "Открытые" видны статусы A,B; 3) Переход между страницами сохраняет фильтр.
Design: [link]
Dependencies: API /statuses готово.
Всем успешной доставки!
Хорошая задача - это не про аккуратно написанный текст. Это про экономию часов команды и меньше «а что ты имел в виду?» в комментариях. Ниже чеклист, который должен вам помочь избежать подводных камней после взятия в работу.
🔑 Обязательные поля (то, без чего задача мусор)
Заголовок - коротко и понятно (что + зачем).
Пример: «Добавить фильтр по статусу в список заявок, чтобы менеджеры видели только открытые».
Описание / Краткое ТЗ - не роман, а шаги/критерии приёма:
-Что сделать (функционал)
-Где изменить (страница/модуль)
-Ожидаемое поведение (конкретно)
Acceptance Criteria (Критерии приёма) - 3–5 пунктов «как проверить, что Done».
Пример: «1) Фильтр виден в правом верхнем углу; 2) При выборе “Открытые” выводятся только статусы A,B; 3) Работает на мобильной версии».
Ожидаемый результат / бизнес-ценность - зачем это нужно (кто выиграет и почему). Очень важный пункт, не хочется делать фичи, которые ничего не дают продукту/компании.
Пример: «Сокращает время обработки заявок на 20% у команды поддержки».
✅ Хорошая привычка - шаблон задачи
Вставьте в шаблон трекера:
Title: [Коротко] — [Ценность]
Denoscription: [Что сделать / где / как]
Acceptance: 1) … 2) … 3) …
Type: [feature/bug/etc]
Owner: @…
Dependencies: [список]
Design: [ссылка]
Estimate: [x pts]
🔍 Пример плохой vs хороший
Плохо:
«Сделать фильтр. Срочно. Нужно, чтобы менеджеры могли выбирать статус.»
Хорошо:
Title: Фильтр по статусу в списке заявок , чтобы отображать только открытые
Denoscription: Добавить выпадающий фильтр. По умолчанию — "Все".
Acceptance: 1) Фильтр показывает опции A/B/C; 2) При выборе "Открытые" видны статусы A,B; 3) Переход между страницами сохраняет фильтр.
Design: [link]
Dependencies: API /statuses готово.
👍10