🔧 Инструмент недели: Unidraw - бесплатная онлайн‑доска
Всем успешной доставки!
Помню, как в самом начале канала делился постом про онлайн-доски: вот он. Тогда Miro объявило об уходе с российского рынка и пообещало блокировать аккаунты. (Кстати, работает ли у вас Miro сейчас, или уже заблокировали?)
Хочу вернуться к этой теме и рассказать про ещё одну онлайн-доску, которую точно стоит попробовать. Альтернатива надёжная, бесплатная и доступная без VPN.
🧩 Что это?
Unidraw - это удобная онлайн‑доска для совместной визуализации. Отлично подойдёт для командной работы, исследований, проектирования и просто наведения порядка в голове. Имеет большое количество встроенных шаблонов:
📌 CJM,
🧠 Майнд-карты,
🧩 Бизнес-модели,
🎯 OKR,
🧪 Lean Canvas и др.
⚙️ Возможности:
-Неограниченное количество досок и проектов;
-Совместная работа в реальном времени;
-Визуальные элементы: стикеры, фигуры, стрелки, текст;
-Импорт из Excel и CSV, экспорт в PNG и SVG;
-История версий и откат;
-Импорт досок из Miro (если вдруг вы переезжаете);
🎯 Кому подойдёт:
Аналитикам и дизайнерам - для схем и пользовательских путей;
Тимлидам - для визуализации процессов, проведения ретро
Руководителям - для планов и стратегических досок.
Delivery/Project/Product менеджерам
Это не реклама, просто делюсь тем, что оказалось полезным 😎
Канал в телеграм у ребят тут
Всем успешной доставки!
Помню, как в самом начале канала делился постом про онлайн-доски: вот он. Тогда Miro объявило об уходе с российского рынка и пообещало блокировать аккаунты. (Кстати, работает ли у вас Miro сейчас, или уже заблокировали?)
Хочу вернуться к этой теме и рассказать про ещё одну онлайн-доску, которую точно стоит попробовать. Альтернатива надёжная, бесплатная и доступная без VPN.
🧩 Что это?
Unidraw - это удобная онлайн‑доска для совместной визуализации. Отлично подойдёт для командной работы, исследований, проектирования и просто наведения порядка в голове. Имеет большое количество встроенных шаблонов:
📌 CJM,
🧠 Майнд-карты,
🧩 Бизнес-модели,
🎯 OKR,
🧪 Lean Canvas и др.
⚙️ Возможности:
-Неограниченное количество досок и проектов;
-Совместная работа в реальном времени;
-Визуальные элементы: стикеры, фигуры, стрелки, текст;
-Импорт из Excel и CSV, экспорт в PNG и SVG;
-История версий и откат;
-Импорт досок из Miro (если вдруг вы переезжаете);
🎯 Кому подойдёт:
Аналитикам и дизайнерам - для схем и пользовательских путей;
Тимлидам - для визуализации процессов, проведения ретро
Руководителям - для планов и стратегических досок.
Delivery/Project/Product менеджерам
Это не реклама, просто делюсь тем, что оказалось полезным 😎
Канал в телеграм у ребят тут
👍3❤2
Всем успешной доставки! В Перми скоро (1 августа) снова пройдёт одна из моих любимых конференций - Ural Digital Weekend.
За последние годы успел побывать там и на сцене, и "по ту сторону" - в программном комитете.
В этом году в программе десятки сильных докладов, крутые секции про команды, технологии, процессы, продуктовый подход. И что особенно приятно большинство спикеров не «теоретики», а настоящие практики.
Если раздумываете, стоит ли идти, точно стоит.
А промокод KANBANFOREVER 😁 будет бонусом для окончательного «да».
За последние годы успел побывать там и на сцене, и "по ту сторону" - в программном комитете.
В этом году в программе десятки сильных докладов, крутые секции про команды, технологии, процессы, продуктовый подход. И что особенно приятно большинство спикеров не «теоретики», а настоящие практики.
Если раздумываете, стоит ли идти, точно стоит.
А промокод KANBANFOREVER 😁 будет бонусом для окончательного «да».
❤4🔥4👍2
🔍 Фичи ради фич в 2025 - это роскошь. Поговорим про Double Diamond
Если в прошлом можно было позволить себе "экспериментировать на проде", сейчас это бьёт по самому больному, по деньгам.
💡 Вспоминаем, что такое e2e-процесс?
Это не просто «от идеи до продакшена». Это полный цикл создания продукта, где каждый этап от формулировки проблемы до оценки влияния на бизнес работает как единая система.
Важнейшие этапы:
Discovery - понять, что именно нужно делать;
Delivery - сделать это эффективно и с минимальными потерями;
Постанализ - проверить, дало ли это результат.
🧠 Почему без discovery никак?
💸 Потому что "сделать и выбросить" стало слишком дорого.
Ошибки на уровне идеи обходятся не в тысячи рублей, а в часы дорогой разработки, потерянные конверсии, репутационные издержки и упущенные возможности.
Время "фич ради фич" ушло. Сейчас продуктовые команды должны быть помешаны на валидации. И тут на сцену выходит:
✨ Метод Double Diamond
Если коротко, это способ не наломать дров и не выкинуть деньги на фичи, которые никому не нужны. Он помогает разобраться, что действительно стоит делать, а не просто «что мы можем запилить».
🔷 Первый ромб - расширяем взгляд и постепенно фокусируемся:
→ цель - понять настоящую проблему пользователя, а не ту, которую кажется важной.
🔶 Второй ромб - снова расширяемся и сужаемся, но теперь уже в поиске решения проблемы.
🗺 Этапы Double Diamond:
Discover - исследуем, где на самом деле болит: проводим интервью, смотрим аналитику, наблюдаем.
Define - формулируем настоящую проблему, которую стоит решать. Не симптомы, а суть.
Develop - придумываем возможные решения, генерим гипотезы, не ограничиваем себя.
Deliver - выбираем самое ценное из идей и реализуем. Проверяем на результат.
📌 Это подход не про скорость. Это подход про разумную экономию, осознанные действия и снижение рисков сжигания бюджета в пустоту. Особенно актуально в 2025, когда стоимость любой ошибки выросла в разы.
📊 Что получает бизнес?
-Делается только то, что действительно влияет на бизнес-метрики (выручка, удержание, NPS и др).
-Команда тратит меньше времени на бесполезную реализацию.
-Растёт доверие к продукту внутри компании: меньше хаоса, больше результата.
Поделитесь, как это устроено у вас. Или, наоборот, почему пока не дошли до этого. Обсудим 👇
#DD #discovery #e2e
Если в прошлом можно было позволить себе "экспериментировать на проде", сейчас это бьёт по самому больному, по деньгам.
💡 Вспоминаем, что такое e2e-процесс?
Это не просто «от идеи до продакшена». Это полный цикл создания продукта, где каждый этап от формулировки проблемы до оценки влияния на бизнес работает как единая система.
Важнейшие этапы:
Discovery - понять, что именно нужно делать;
Delivery - сделать это эффективно и с минимальными потерями;
Постанализ - проверить, дало ли это результат.
🧠 Почему без discovery никак?
💸 Потому что "сделать и выбросить" стало слишком дорого.
Ошибки на уровне идеи обходятся не в тысячи рублей, а в часы дорогой разработки, потерянные конверсии, репутационные издержки и упущенные возможности.
Время "фич ради фич" ушло. Сейчас продуктовые команды должны быть помешаны на валидации. И тут на сцену выходит:
✨ Метод Double Diamond
Если коротко, это способ не наломать дров и не выкинуть деньги на фичи, которые никому не нужны. Он помогает разобраться, что действительно стоит делать, а не просто «что мы можем запилить».
🔷 Первый ромб - расширяем взгляд и постепенно фокусируемся:
→ цель - понять настоящую проблему пользователя, а не ту, которую кажется важной.
🔶 Второй ромб - снова расширяемся и сужаемся, но теперь уже в поиске решения проблемы.
🗺 Этапы Double Diamond:
Discover - исследуем, где на самом деле болит: проводим интервью, смотрим аналитику, наблюдаем.
Define - формулируем настоящую проблему, которую стоит решать. Не симптомы, а суть.
Develop - придумываем возможные решения, генерим гипотезы, не ограничиваем себя.
Deliver - выбираем самое ценное из идей и реализуем. Проверяем на результат.
📌 Это подход не про скорость. Это подход про разумную экономию, осознанные действия и снижение рисков сжигания бюджета в пустоту. Особенно актуально в 2025, когда стоимость любой ошибки выросла в разы.
📊 Что получает бизнес?
-Делается только то, что действительно влияет на бизнес-метрики (выручка, удержание, NPS и др).
-Команда тратит меньше времени на бесполезную реализацию.
-Растёт доверие к продукту внутри компании: меньше хаоса, больше результата.
Поделитесь, как это устроено у вас. Или, наоборот, почему пока не дошли до этого. Обсудим 👇
#DD #discovery #e2e
👍3🔥2❤1
🔁 Дейли-митинги: привычка, необходимость или ритуал ради галочки?
Всем успешной доставки 🚀
Когда-то дейли были придуманы как быстрый способ синхронизации команды.
15 минут, три вопроса: что сделал, что планируешь, где затык.
Просто, понятно, эффективно.
Но что-то пошло не так.
Сегодня в разных командах мы видим вот что:
-Дейли длятся по 30-60 минут
-Говорит только тимлид
-Никто не слушает, все ждут своей очереди
-Говорят только статусными ответами: взял в работу, тестирую.
Вопросы задаются «в стол», без последующих действий.
🎯 Слышал, что в одной из команд попробовали отменить дейли и перешли на:
-еженедельные синки по темам
-живые апдейты в тасктрекере
-прозрачную доску с понятным статусом задач
Результат? Больше фокуса, меньше шума, всё стало спокойнее.
Но не всем такой подход заходит. Есть команды, где дейли - это точка опоры: без них люди не синхронизируются, не чувствуют ритм, теряют нить.
🤔 А теперь внимание к сути:
Нужны ли дейли всем командам? Или это просто «наследие скрама»(хотя в Канбане есть такая же каденция), которое тащат даже туда, где оно не работает?
📣 Делитесь опытом:
-Есть ли у вас дейли?
-Как часто на них рождаются реальные решения?
-Кто их фасилитирует?
-Пробовали отменить? Что вышло?
Всем успешной доставки 🚀
Когда-то дейли были придуманы как быстрый способ синхронизации команды.
15 минут, три вопроса: что сделал, что планируешь, где затык.
Просто, понятно, эффективно.
Но что-то пошло не так.
Сегодня в разных командах мы видим вот что:
-Дейли длятся по 30-60 минут
-Говорит только тимлид
-Никто не слушает, все ждут своей очереди
-Говорят только статусными ответами: взял в работу, тестирую.
Вопросы задаются «в стол», без последующих действий.
🎯 Слышал, что в одной из команд попробовали отменить дейли и перешли на:
-еженедельные синки по темам
-живые апдейты в тасктрекере
-прозрачную доску с понятным статусом задач
Результат? Больше фокуса, меньше шума, всё стало спокойнее.
Но не всем такой подход заходит. Есть команды, где дейли - это точка опоры: без них люди не синхронизируются, не чувствуют ритм, теряют нить.
🤔 А теперь внимание к сути:
Нужны ли дейли всем командам? Или это просто «наследие скрама»(хотя в Канбане есть такая же каденция), которое тащат даже туда, где оно не работает?
📣 Делитесь опытом:
-Есть ли у вас дейли?
-Как часто на них рождаются реальные решения?
-Кто их фасилитирует?
-Пробовали отменить? Что вышло?
❤4👍2🔥1🤔1
📊 Метрика недели Discard Rate или «сколько задач мы выкидываем на помойку»
🧯 В условиях 2025-го, когда каждая неделя работы стоит как самолет, важно не только делать правильно, но и перестать делать лишнее.
И вот тут появляется полезная, но недооцененная метрика Discard Rate.
❓Что это такое?
Discard Rate - это доля задач, которые были запланированы, но так и не дошли до продакшена.
Например:
-Начали делать, но отменили
-Завели задачу, но забросили
-Потратили ресурсы, но поняли, что не нужно
🔎 Зачем её считать?
Понимать, сколько усилий ушло впустую, если часто отменяете задачи после старта, где-то сбоит приоритезация.
Обнаруживать "горячие головы", инициатива хорошо, но если постоянно отбрасываются начатые задачи, это тревожный симптом.
Оптимизировать процесс Discovery, высокий Discard Rate может говорить, что фичи начинают пилить без нормальной проработки.
Снижать риски сжигания бюджета, особенно критично, если деньги «дорогие» на проекте каждый день имеет ценник.
Улучшать прозрачность потока работы, команде и менеджерам проще видеть, куда утекают усилия.
Ценить ранний отказ, чем раньше задача была отменена, тем меньше времени и денег потрачено. Ранний “нет” это экономия.
🛠 Как внедрить?
Отметьте “выкинутые” задачи в Jira, создайте статус Discarded или метку cancelled, won’t do, abandoned.
Следите за трендом, Discard Rate >15%(может отдельно для себя определить этот процент) регулярно? Уже стоит копать глубже.
Анализируйте причины, ретроспектива, работа с продуктовыми командами: почему задача не дожила до релиза?
Показывайте в дашборде, добавить в CFD/графики можно визуализировать как долю от всех заведенных задач.
💡 Нормально ли, что что-то выбрасываем?
Да, если осознанно. Главное не тратить на это недели работы. Чем раньше “завернули” тем лучше для всех.
Discard Rate не про обвинения, а про улучшение процесса принятия решений.
🧯 В условиях 2025-го, когда каждая неделя работы стоит как самолет, важно не только делать правильно, но и перестать делать лишнее.
И вот тут появляется полезная, но недооцененная метрика Discard Rate.
❓Что это такое?
Discard Rate - это доля задач, которые были запланированы, но так и не дошли до продакшена.
Например:
-Начали делать, но отменили
-Завели задачу, но забросили
-Потратили ресурсы, но поняли, что не нужно
🔎 Зачем её считать?
Понимать, сколько усилий ушло впустую, если часто отменяете задачи после старта, где-то сбоит приоритезация.
Обнаруживать "горячие головы", инициатива хорошо, но если постоянно отбрасываются начатые задачи, это тревожный симптом.
Оптимизировать процесс Discovery, высокий Discard Rate может говорить, что фичи начинают пилить без нормальной проработки.
Снижать риски сжигания бюджета, особенно критично, если деньги «дорогие» на проекте каждый день имеет ценник.
Улучшать прозрачность потока работы, команде и менеджерам проще видеть, куда утекают усилия.
Ценить ранний отказ, чем раньше задача была отменена, тем меньше времени и денег потрачено. Ранний “нет” это экономия.
🛠 Как внедрить?
Отметьте “выкинутые” задачи в Jira, создайте статус Discarded или метку cancelled, won’t do, abandoned.
Следите за трендом, Discard Rate >15%(может отдельно для себя определить этот процент) регулярно? Уже стоит копать глубже.
Анализируйте причины, ретроспектива, работа с продуктовыми командами: почему задача не дожила до релиза?
Показывайте в дашборде, добавить в CFD/графики можно визуализировать как долю от всех заведенных задач.
💡 Нормально ли, что что-то выбрасываем?
Да, если осознанно. Главное не тратить на это недели работы. Чем раньше “завернули” тем лучше для всех.
Discard Rate не про обвинения, а про улучшение процесса принятия решений.
❤7🔥3👍1
🧨 Скрама не существует 🆘
Кажется, этот пост должен был быть первым в моем канале 😅
Много команд гордо говорят: "Мы работаем по скраму". Но если открыть Scrum Guide и внимательно посмотреть,
что там написано, то выяснится: скрама нет.
Он как кот Шредингера , есть и одновременно нет. А точнее, он есть только на бумаге.
👇 Вот почему:
❌ 1. Нет цели спринта
“Цель спринта - это единственный объектив работы команды.”
На практике: цель никто не формулирует. Планирование - это просто раздача задач на две недели.
Если спросить у команды "а что мы хотим достичь?", в ответ тишина.
❌ 2. Нет скрам-мастера
Часто его роль исполняет проектный менеджер, тимлид или вообще никто.
А ведь по гайду это ключевая фигура, ответственная за фасилитацию, обучение и устранение препятствий.
❌ 3. Истории кочуют из спринта в спринт
“В скраме важно завершать инкременты. Done значит Done.”
На практике: "не успели ну ничего, возьмём в следующий спринт".
А если копнуть глубже, оказывается, что задачи невозможно завершить за один спринт. Потому что никто не думал об объёме, блокерах и зависимости.
❌ 4. Инкремента нет
В конце спринта нет демо. Или оно номинальное. Или то, что показали нельзя использовать. Или это "почти готово", но на самом деле требует ещё недели багфиксов и ручного тестирования.
❌ 5. Нет ретро. Или оно не работает
По скраму ретроспектива - важнейший элемент непрерывного улучшения.
На деле ритуал ради галочки. Без выводов, без планов на изменения, без замеров результатов. Просто “ну норм, давайте дальше”.
❌ 6. Нет Definition of Done
“Что означает ‘готово’?” простейший вопрос, на который 80% команд не могут ответить. Именно поэтому в прод попадают недоделки, “полуфичи” и баги.
❌ 7. Нет Product Owner
Или он перегружен, или работает в 5 командах одновременно.
А значит, нет ни управления бэклогом, ни связи с клиентом, ни приоритезации по бизнесу. Всё летит в бэклог по принципу "а давайте сделаем".
❌ 8. Velocity не замеряется
Спринты проходят, команда работает, но ритма и предсказуемости нет.
Поток задач непредсказуем, оценки неточные, планирование пальцем в небо.
❌ 9. Дейли превратились в “отчитайся”
Дейли это синхронизация команды.
На деле это отчет перед менеджером. По очереди. Монотонно. Без вовлечения.
После дейли никто ничего не понял, никто не перефокусировал работу, никто не нашёл блокеры.
❌ 10. Спринт ради спринта
Главный вопрос - не "доставили ли мы ценность", а "уложились ли мы в дедлайн".
Вывод: Скрама не существует.
То, что называют "скрамом" - это имитация.
Снаружи ритуалы, а внутри всё та же неуправляемая и непрозрачная разработка.
Я опираюсь на личный опыт. Если у вас всё по Скрам-гайду вы молодцы, это редкость!
#Scrum #Разаработка #Управление
Кажется, этот пост должен был быть первым в моем канале 😅
Много команд гордо говорят: "Мы работаем по скраму". Но если открыть Scrum Guide и внимательно посмотреть,
что там написано, то выяснится: скрама нет.
Он как кот Шредингера , есть и одновременно нет. А точнее, он есть только на бумаге.
👇 Вот почему:
❌ 1. Нет цели спринта
“Цель спринта - это единственный объектив работы команды.”
На практике: цель никто не формулирует. Планирование - это просто раздача задач на две недели.
Если спросить у команды "а что мы хотим достичь?", в ответ тишина.
❌ 2. Нет скрам-мастера
Часто его роль исполняет проектный менеджер, тимлид или вообще никто.
А ведь по гайду это ключевая фигура, ответственная за фасилитацию, обучение и устранение препятствий.
❌ 3. Истории кочуют из спринта в спринт
“В скраме важно завершать инкременты. Done значит Done.”
На практике: "не успели ну ничего, возьмём в следующий спринт".
А если копнуть глубже, оказывается, что задачи невозможно завершить за один спринт. Потому что никто не думал об объёме, блокерах и зависимости.
❌ 4. Инкремента нет
В конце спринта нет демо. Или оно номинальное. Или то, что показали нельзя использовать. Или это "почти готово", но на самом деле требует ещё недели багфиксов и ручного тестирования.
❌ 5. Нет ретро. Или оно не работает
По скраму ретроспектива - важнейший элемент непрерывного улучшения.
На деле ритуал ради галочки. Без выводов, без планов на изменения, без замеров результатов. Просто “ну норм, давайте дальше”.
❌ 6. Нет Definition of Done
“Что означает ‘готово’?” простейший вопрос, на который 80% команд не могут ответить. Именно поэтому в прод попадают недоделки, “полуфичи” и баги.
❌ 7. Нет Product Owner
Или он перегружен, или работает в 5 командах одновременно.
А значит, нет ни управления бэклогом, ни связи с клиентом, ни приоритезации по бизнесу. Всё летит в бэклог по принципу "а давайте сделаем".
❌ 8. Velocity не замеряется
Спринты проходят, команда работает, но ритма и предсказуемости нет.
Поток задач непредсказуем, оценки неточные, планирование пальцем в небо.
❌ 9. Дейли превратились в “отчитайся”
Дейли это синхронизация команды.
На деле это отчет перед менеджером. По очереди. Монотонно. Без вовлечения.
После дейли никто ничего не понял, никто не перефокусировал работу, никто не нашёл блокеры.
❌ 10. Спринт ради спринта
Главный вопрос - не "доставили ли мы ценность", а "уложились ли мы в дедлайн".
Вывод: Скрама не существует.
То, что называют "скрамом" - это имитация.
Снаружи ритуалы, а внутри всё та же неуправляемая и непрозрачная разработка.
Я опираюсь на личный опыт. Если у вас всё по Скрам-гайду вы молодцы, это редкость!
#Scrum #Разаработка #Управление
Please open Telegram to view this post
VIEW IN TELEGRAM
💯9🗿4❤2
Если ты не отменяешь фичи - ты не занимаешься Discovery
Я уже много постов написал про этап discovery и даже описывал DD, хочу подсветить проблему еще раз, но с другой стороны 🧐
Discovery - это не про "понять, как делать".
Discovery - это про понять, стоит ли делать вообще.
💸 В 2025 году фичи - это дорогие деньги
Разработка стоит дорого. Даже один спринт команды сеньоров может сжечь месячный бюджет небольшого стартапа. В условиях, когда каждый рубль должен приносить ROI, не отменять фичи значит быть безответственным.
🚧 Почему надо отменять фичи?
90% идей — плохие
Большинство гипотез не выживают столкновения с пользователем. Фичи, которые не решают реальные боли, не приносят метрик → это мусор.
Фича = инвестиция
Каждая задача - это как стартап: у неё должен быть потенциал окупаемости. Если её нельзя защитить цифрами она не стоит затрат.
Фокус дороже функционала
Чем меньше продукт делает, тем проще им пользоваться. Ценность создаёт не количество фичей, а решение боли.
🚫 Почему важно отменять рано?
Каждый шаг дальше дороже
📌 Идея → ✏️ исследование → 🖌 дизайн → 👨💻 разработка → 🚀 релиз
Если отменяешь на шаге идеи - теряешь час.
Если на этапе тестов - уже неделю.
Если после релиза - считай, выбросил в окно.
Ранние “стопы” = зрелый процесс
Компании с хорошим discovery-процессом отменяют больше фичей, чем делают 😁
🔁 А если не отменяете?
Поздравляю, у вас конвейер надежд:
-фичи берутся “по ощущениям”, "мы в нее верим"
-в беклоге сотни задач, потому что “всё важно”
-каждая фича доходит до релиза, но никто не считает, окупилась ли она
А главное - никто не отвечает за решение проблем, только за “поставить вовремя”.
📌 Вывод
Если ты хочешь заниматься настоящим Discovery, то список отменённых задач должен быть длиннее списка тех, что пошли в прод.
Сложно? Да. Зато дешевле.
Я уже много постов написал про этап discovery и даже описывал DD, хочу подсветить проблему еще раз, но с другой стороны 🧐
Discovery - это не про "понять, как делать".
Discovery - это про понять, стоит ли делать вообще.
💸 В 2025 году фичи - это дорогие деньги
Разработка стоит дорого. Даже один спринт команды сеньоров может сжечь месячный бюджет небольшого стартапа. В условиях, когда каждый рубль должен приносить ROI, не отменять фичи значит быть безответственным.
🚧 Почему надо отменять фичи?
90% идей — плохие
Большинство гипотез не выживают столкновения с пользователем. Фичи, которые не решают реальные боли, не приносят метрик → это мусор.
Фича = инвестиция
Каждая задача - это как стартап: у неё должен быть потенциал окупаемости. Если её нельзя защитить цифрами она не стоит затрат.
Фокус дороже функционала
Чем меньше продукт делает, тем проще им пользоваться. Ценность создаёт не количество фичей, а решение боли.
🚫 Почему важно отменять рано?
Каждый шаг дальше дороже
📌 Идея → ✏️ исследование → 🖌 дизайн → 👨💻 разработка → 🚀 релиз
Если отменяешь на шаге идеи - теряешь час.
Если на этапе тестов - уже неделю.
Если после релиза - считай, выбросил в окно.
Ранние “стопы” = зрелый процесс
Компании с хорошим discovery-процессом отменяют больше фичей, чем делают 😁
🔁 А если не отменяете?
Поздравляю, у вас конвейер надежд:
-фичи берутся “по ощущениям”, "мы в нее верим"
-в беклоге сотни задач, потому что “всё важно”
-каждая фича доходит до релиза, но никто не считает, окупилась ли она
А главное - никто не отвечает за решение проблем, только за “поставить вовремя”.
📌 Вывод
Если ты хочешь заниматься настоящим Discovery, то список отменённых задач должен быть длиннее списка тех, что пошли в прод.
Сложно? Да. Зато дешевле.
👍3❤2🔥2🥰1💯1
🧨 Метрики команды ≠ Метрики людей
Иногда кто-то берёт диаграмму CFD или график Lead time и спрашивает:
"А можно ли по этим метрикам понять, кто из разработчиков/тестировщиков/аналитиков работает медленно?"
Ответ: нет. И даже не пытайтесь.
🔍 Процессные метрики - это не про людей.
-Они не измеряют эффективность конкретного участника.
-Они показывают, как работает система в целом.
Если растёт lead time - это может быть из-за:
-завала на тестировании,
-ожидания ревью,
-долгого согласования,
-отсутствия ясности по задаче,
а не потому, что «Вася снова всё тормозит».
❌ Использование этих метрик для оценки сотрудников:
-разрушает доверие,
-порождает защитное поведение,
-создаёт токсичную атмосферу,
-искажает сами метрики они перестают отражать реальность.
💡 Если уж очень хочется мерить людей, делайте это открыто, в формате Индивидуального Плана Развития (ИПР), с фокусом на рост, а не наказание. Это честно, конструктивно и не ломает командные процессы.
📈 Метрики типа:
-Lead Time
-WIP
-Blocker Time
-Discard Rate
-WIP Rate
это не про людей. Это инструменты улучшения командной работы.
🔄 Метрики должны помогать работать лучше, а не защищаться, манипулировать и выживать.
Иногда кто-то берёт диаграмму CFD или график Lead time и спрашивает:
"А можно ли по этим метрикам понять, кто из разработчиков/тестировщиков/аналитиков работает медленно?"
Ответ: нет. И даже не пытайтесь.
🔍 Процессные метрики - это не про людей.
-Они не измеряют эффективность конкретного участника.
-Они показывают, как работает система в целом.
Если растёт lead time - это может быть из-за:
-завала на тестировании,
-ожидания ревью,
-долгого согласования,
-отсутствия ясности по задаче,
а не потому, что «Вася снова всё тормозит».
❌ Использование этих метрик для оценки сотрудников:
-разрушает доверие,
-порождает защитное поведение,
-создаёт токсичную атмосферу,
-искажает сами метрики они перестают отражать реальность.
💡 Если уж очень хочется мерить людей, делайте это открыто, в формате Индивидуального Плана Развития (ИПР), с фокусом на рост, а не наказание. Это честно, конструктивно и не ломает командные процессы.
📈 Метрики типа:
-Lead Time
-WIP
-Blocker Time
-Discard Rate
-WIP Rate
это не про людей. Это инструменты улучшения командной работы.
🔄 Метрики должны помогать работать лучше, а не защищаться, манипулировать и выживать.
👍8💯4🔥3❤1
Всем успешной доставки!
Обычно я пишу про продуктовую разработку, но знаю, что в канале много ребят из заказной, давайте попробую помочь вам 😎
🎯 Нужно ли внедрять Канбан в аутсорс-команду?
Спойлер: да. Особенно если вы хотите меньше гореть и больше зарабатывать.
Работая в аутсорсе, вы всегда между двух огней:
– заказчик хочет «быстро, дешево и всё сразу»,
– команда хочет «внятные задачи, адекватные сроки и стабильность».
Во многих аутсорс-командах Scrum существует только номинально. Спринт просто двухнедельная коробка, чтобы что-то куда-то втиснуть.
Что даёт Канбан аутсорс-команде?
🟢 Прозрачность
Каждая задача проходит четкий путь: "взяли —> делаем —> проверили —> сдали".
Это видно как команде, так и заказчику. Меньше созвонов “а где вот эта штука?”, → больше доверия.
🟢 Прогнозируемость
C помощью метрик (Lead Time, Throughput, WIP) можно не гадать, а прогнозировать:
«эта задача будет готова через 3-4 дня, с вероятностью 85%».
🟢 Управление WIP (Work in Progress)
Меньше задач в работе = быстрее доодим до конца.
Это важно в аутсорсе, где «почти сделано» = не оплачено.
🟢 Гибкость под изменения
Канбан не требует фиксировать объем на 2 недели.
Пришел новый приоритет от заказчика — перестроились без боли и оправданий.
А заказчик это поймет?
Да. Даже если он про Канбан не слышал.
Ты показываешь:
✅ Статус всех задач
✅ Метрики прогресса
✅ Предсказуемость сроков
✅ Быструю реакцию на его новые хотелки
Выгода понятна без терминов.
Обычно я пишу про продуктовую разработку, но знаю, что в канале много ребят из заказной, давайте попробую помочь вам 😎
🎯 Нужно ли внедрять Канбан в аутсорс-команду?
Спойлер: да. Особенно если вы хотите меньше гореть и больше зарабатывать.
Работая в аутсорсе, вы всегда между двух огней:
– заказчик хочет «быстро, дешево и всё сразу»,
– команда хочет «внятные задачи, адекватные сроки и стабильность».
Во многих аутсорс-командах Scrum существует только номинально. Спринт просто двухнедельная коробка, чтобы что-то куда-то втиснуть.
Что даёт Канбан аутсорс-команде?
🟢 Прозрачность
Каждая задача проходит четкий путь: "взяли —> делаем —> проверили —> сдали".
Это видно как команде, так и заказчику. Меньше созвонов “а где вот эта штука?”, → больше доверия.
🟢 Прогнозируемость
C помощью метрик (Lead Time, Throughput, WIP) можно не гадать, а прогнозировать:
«эта задача будет готова через 3-4 дня, с вероятностью 85%».
🟢 Управление WIP (Work in Progress)
Меньше задач в работе = быстрее доодим до конца.
Это важно в аутсорсе, где «почти сделано» = не оплачено.
🟢 Гибкость под изменения
Канбан не требует фиксировать объем на 2 недели.
Пришел новый приоритет от заказчика — перестроились без боли и оправданий.
А заказчик это поймет?
Да. Даже если он про Канбан не слышал.
Ты показываешь:
✅ Статус всех задач
✅ Метрики прогресса
✅ Предсказуемость сроков
✅ Быструю реакцию на его новые хотелки
Выгода понятна без терминов.
1👍3🔥3❤1
Всем успешной доставки! 🚀
Не верится, но вчера исполнился ровно год с момента создания этого канала. Время летит невероятно быстро! Если честно, я даже не думал, что продержусь так долго, казалось, быстро заброшу это дело.
Но вот цифры за год: 102 поста и 71 история!
А еще 373 подписчика! Много это или мало за год? Пока не знаю, но для меня это крутой результат! 🤟
Спасибо огромное всем, кто читает канал! Дальше только интереснее! 😉
P.S. пересылайте канал знакомым и друзьям, чтобы нас стало еще больше 😎
Не верится, но вчера исполнился ровно год с момента создания этого канала. Время летит невероятно быстро! Если честно, я даже не думал, что продержусь так долго, казалось, быстро заброшу это дело.
Но вот цифры за год: 102 поста и 71 история!
А еще 373 подписчика! Много это или мало за год? Пока не знаю, но для меня это крутой результат! 🤟
Спасибо огромное всем, кто читает канал! Дальше только интереснее! 😉
P.S. пересылайте канал знакомым и друзьям, чтобы нас стало еще больше 😎
❤4👍4🔥3
📊 Метрика недели: время нахождения задач в бэклоге
Кажется, что все важные метрики уже известны - скорость, Lead Time, Cycle Time… Но есть одна неочевидная, которую редко используют - время нахождения задач в бэклоге.
🔍 Что это такое?
Это количество дней (или недель), которое задача проводит в статусе "Backlog" - от момента её попадания туда до момента, когда команда берёт её в работу.
💡 Зачем мерить
Признак приоритизации - если задача лежит в бэклоге месяцами, значит, её ценность или приоритет под вопросом.
Выявление "кладбища идей" - бэклог легко превращается в свалку, где теряются актуальные задачи.
Сигнал к пересмотру процессов - слишком длинное ожидание может говорить о неэффективной работе с входящими запросами.
Индикатор загрузки команды - если задачи быстро забираются в работу, но бэклог всё равно растёт, это сигнал к дополнительному найму или перераспределению ресурсов.
📈 Какие выводы можно сделать
Если задачи лежат в бэклоге более 6–12 месяцев, велика вероятность, что они "протухли", контекст изменился, а ценность снизилась до нуля.
Если старые задачи вдруг начали попадать в работу, проверь не изменились ли требования или бизнес-приоритеты.
Если большая часть задач живёт в бэклоге более N дней, то команда, скорее всего, набирает слишком много задач "на потом".
⚙️ Как использовать
Регулярно проводить grooming с удалением или переоценкой "долгожителей".
Отслеживать тренд: растёт ли среднее время нахождения задач или уменьшается.
#метриканедели #backlog #e2e
Кажется, что все важные метрики уже известны - скорость, Lead Time, Cycle Time… Но есть одна неочевидная, которую редко используют - время нахождения задач в бэклоге.
🔍 Что это такое?
Это количество дней (или недель), которое задача проводит в статусе "Backlog" - от момента её попадания туда до момента, когда команда берёт её в работу.
💡 Зачем мерить
Признак приоритизации - если задача лежит в бэклоге месяцами, значит, её ценность или приоритет под вопросом.
Выявление "кладбища идей" - бэклог легко превращается в свалку, где теряются актуальные задачи.
Сигнал к пересмотру процессов - слишком длинное ожидание может говорить о неэффективной работе с входящими запросами.
Индикатор загрузки команды - если задачи быстро забираются в работу, но бэклог всё равно растёт, это сигнал к дополнительному найму или перераспределению ресурсов.
📈 Какие выводы можно сделать
Если задачи лежат в бэклоге более 6–12 месяцев, велика вероятность, что они "протухли", контекст изменился, а ценность снизилась до нуля.
Если старые задачи вдруг начали попадать в работу, проверь не изменились ли требования или бизнес-приоритеты.
Если большая часть задач живёт в бэклоге более N дней, то команда, скорее всего, набирает слишком много задач "на потом".
⚙️ Как использовать
Регулярно проводить grooming с удалением или переоценкой "долгожителей".
Отслеживать тренд: растёт ли среднее время нахождения задач или уменьшается.
#метриканедели #backlog #e2e
❤5👍4🔥2
🕒 Почему заказчики не верят в сроки и что с этим делать
Наверняка у вас было так:
Ты озвучиваешь сроки, заказчик скептически хмыкает:
- «А вы точно успеете?»
Или хуже:
- «В прошлый раз тоже обещали за 2 недели…»
👉 Проблема в том, что большинство команд называет сроки “с потолка”. Это не прогноз, а обещание «на авось». Естественно, доверия тут нет.
🚫 Почему заказчики не верят срокам:
Ожидания ≠ реальность. В прошлых проектах обещали быстро, но сдавали позже.
Субъективность. «Петя сказал, что справится за день» - звучит как мнение, а не как прогноз.
Нет прозрачности. Заказчик не видит, на чём основаны сроки.
✅ Что делать вместо «обещаний»
Применять data-driven подход.
Это значит, что решения принимаются не по ощущениям («думаю, что успеем»), а на основе фактов и статистики.
Ключевые метрики:
Lead Time - сколько времени в среднем проходит от постановки задачи до её завершения.
Cycle Time - сколько времени реально уходит на выполнение после старта.
Throughput - сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Если у тебя есть данные за последние 3–6 месяцев, ты можешь сказать заказчику:
«85% задач подобного размера мы закрываем за 8–12 дней. С большой вероятностью эта задача будет в том же диапазоне».
Это уже не «авось», а прогноз, основанный на данных.
🎯 Как метрики и data-driven подход помогают строить доверие:
-Переводят разговор из «верьте нам на слово» → в «вот данные».
-Позволяют принимать решения осознанно: менять приоритеты, увеличивать команду, убирать узкие места.
-Дают заказчику ощущение контроля и прозрачности.
-Убирают пространство для манипуляций: цифры объективнее эмоций.
💡 Итог: заказчики не верят обещаниям, потому что слишком много раз обжигались. Но они верят цифрам, данным и статистике.
Data-driven подход и метрики Lead Time / Cycle Time — это твой способ перейти от хаоса к доверительной и предсказуемой работе.
👉 А у вас как в проектах: чаще дают обещания или работают на основе данных?
#leadtime #throughput #заказчики #сроки
Наверняка у вас было так:
Ты озвучиваешь сроки, заказчик скептически хмыкает:
- «А вы точно успеете?»
Или хуже:
- «В прошлый раз тоже обещали за 2 недели…»
👉 Проблема в том, что большинство команд называет сроки “с потолка”. Это не прогноз, а обещание «на авось». Естественно, доверия тут нет.
🚫 Почему заказчики не верят срокам:
Ожидания ≠ реальность. В прошлых проектах обещали быстро, но сдавали позже.
Субъективность. «Петя сказал, что справится за день» - звучит как мнение, а не как прогноз.
Нет прозрачности. Заказчик не видит, на чём основаны сроки.
✅ Что делать вместо «обещаний»
Применять data-driven подход.
Это значит, что решения принимаются не по ощущениям («думаю, что успеем»), а на основе фактов и статистики.
Ключевые метрики:
Lead Time - сколько времени в среднем проходит от постановки задачи до её завершения.
Cycle Time - сколько времени реально уходит на выполнение после старта.
Throughput - сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Если у тебя есть данные за последние 3–6 месяцев, ты можешь сказать заказчику:
«85% задач подобного размера мы закрываем за 8–12 дней. С большой вероятностью эта задача будет в том же диапазоне».
Это уже не «авось», а прогноз, основанный на данных.
🎯 Как метрики и data-driven подход помогают строить доверие:
-Переводят разговор из «верьте нам на слово» → в «вот данные».
-Позволяют принимать решения осознанно: менять приоритеты, увеличивать команду, убирать узкие места.
-Дают заказчику ощущение контроля и прозрачности.
-Убирают пространство для манипуляций: цифры объективнее эмоций.
💡 Итог: заказчики не верят обещаниям, потому что слишком много раз обжигались. Но они верят цифрам, данным и статистике.
Data-driven подход и метрики Lead Time / Cycle Time — это твой способ перейти от хаоса к доверительной и предсказуемой работе.
👉 А у вас как в проектах: чаще дают обещания или работают на основе данных?
#leadtime #throughput #заказчики #сроки
1🔥4❤3
«Ну как тут пройти мимо, если разыгрывают книгу про Канбан? 🚀»
❤1
Forwarded from I’m CTO, bitch
🏆 Это конкурс, bitch!
Подписчики и подписчицы, я тут решил устроить конкурс и разыграть несколько крутых призов.
Вы часто репостите посты из этого канала в разные чаты и каналы, а также выкладываете у себя в соцсетях, linkedin и сторис. Пришло время вас за это отблагодарить.
🎁 Призы за репосты: десять топовых книг, уникальная карта Камшотбанка и пост в канале о вас или вашем деле.
👉 Читай условия конкурса
🗓 Конкурс продлится до 12 сентября. Победителя объявим в день программиста — 13 сентября.
#конкурс
Подписчики и подписчицы, я тут решил устроить конкурс и разыграть несколько крутых призов.
Вы часто репостите посты из этого канала в разные чаты и каналы, а также выкладываете у себя в соцсетях, linkedin и сторис. Пришло время вас за это отблагодарить.
🎁 Призы за репосты: десять топовых книг, уникальная карта Камшотбанка и пост в канале о вас или вашем деле.
👉 Читай условия конкурса
🗓 Конкурс продлится до 12 сентября. Победителя объявим в день программиста — 13 сентября.
#конкурс
👍3🔥2❤🔥1
Рубрика "инструмент недели"
🛠 Личные инструменты менеджера: как выбрать таск-менеджер?
У любого менеджера (PM, тимлида, delivery) рано или поздно встаёт вопрос: как организовать личные задачи так, чтобы ничего не потерялось и не сгорело?
Инструментов сейчас море, но у каждого свои сильные и слабые стороны. Давайте разберёмся 👇
🌍 Международные решения
Todoist - «золотой стандарт» таск-менеджеров. Минимализм, теги, фильтры, интеграции. Но бесплатная версия ограничена.
TickTick - более «фичастый» брат Todoist. Есть календарь, Pomodoro, приоритизация. Для многих лучший баланс цены и функций.
Asana - мощная система для команд, но её можно использовать и для личных задач. Проблема в том, что в России сервис официально недоступен (обходные пути есть, но не всем удобно).
Any.do - очень простое и красивое решение. Фокус на «ежедневнике»: список дел + календарь. Подходит, если не хотите нагружать себя сложными функциями.
Microsoft To Do - наследник Wunderlist. Хорошо интегрирован с экосистемой Microsoft (Outlook, Teams), идеально для тех, кто живёт в Microsoft 365.
Notion (как таск-менеджер) - универсальный инструмент «всё в одном»: можно вести задачи, базы знаний, заметки. Но для простого списочка дел перегружен.
🇷🇺 Российские альтернативы
ЛидерТаск - один из самых известных отечественных таск-менеджеров. Канбан, напоминания, офлайн-доступ. Подходит тем, кто хочет «всё в одном» и без блокировок.
Weeek - современный и гибкий инструмент. Отлично дружит с Google, Miro, Figma. По ощущениям лёгкий аналог Notion/Trello, но с российским бэкграундом.
💬 Новые тренды
Даже Telegram не отстаёт: теперь там можно заводить простые задачи прямо в приложении. Удобно для быстрых заметок и мелких дел, которые должны быть «под рукой».
⚖️ Что выбрать?
-Хотите «чистый» инструмент для личных задач - берите Todoist, TickTick или Any.do.
-Если живёте в Microsoft-экосистеме идеально подойдёт Microsoft To Do.
-Если важна доступность в России и без VPN смело смотрите в сторону ЛидерТаска или Weeek.
-Нужен гибрид «таск-менеджер + база знаний» берите Notion.
-Для командных задач (особенно распределённых) Asana, если есть возможность её использовать.
👉 А какой таск-менеджер используете вы?
#taskменеджер #todoist #asana #ticktick #notion #лидертаск #week
🛠 Личные инструменты менеджера: как выбрать таск-менеджер?
У любого менеджера (PM, тимлида, delivery) рано или поздно встаёт вопрос: как организовать личные задачи так, чтобы ничего не потерялось и не сгорело?
Инструментов сейчас море, но у каждого свои сильные и слабые стороны. Давайте разберёмся 👇
🌍 Международные решения
Todoist - «золотой стандарт» таск-менеджеров. Минимализм, теги, фильтры, интеграции. Но бесплатная версия ограничена.
TickTick - более «фичастый» брат Todoist. Есть календарь, Pomodoro, приоритизация. Для многих лучший баланс цены и функций.
Asana - мощная система для команд, но её можно использовать и для личных задач. Проблема в том, что в России сервис официально недоступен (обходные пути есть, но не всем удобно).
Any.do - очень простое и красивое решение. Фокус на «ежедневнике»: список дел + календарь. Подходит, если не хотите нагружать себя сложными функциями.
Microsoft To Do - наследник Wunderlist. Хорошо интегрирован с экосистемой Microsoft (Outlook, Teams), идеально для тех, кто живёт в Microsoft 365.
Notion (как таск-менеджер) - универсальный инструмент «всё в одном»: можно вести задачи, базы знаний, заметки. Но для простого списочка дел перегружен.
🇷🇺 Российские альтернативы
ЛидерТаск - один из самых известных отечественных таск-менеджеров. Канбан, напоминания, офлайн-доступ. Подходит тем, кто хочет «всё в одном» и без блокировок.
Weeek - современный и гибкий инструмент. Отлично дружит с Google, Miro, Figma. По ощущениям лёгкий аналог Notion/Trello, но с российским бэкграундом.
💬 Новые тренды
Даже Telegram не отстаёт: теперь там можно заводить простые задачи прямо в приложении. Удобно для быстрых заметок и мелких дел, которые должны быть «под рукой».
⚖️ Что выбрать?
-Хотите «чистый» инструмент для личных задач - берите Todoist, TickTick или Any.do.
-Если живёте в Microsoft-экосистеме идеально подойдёт Microsoft To Do.
-Если важна доступность в России и без VPN смело смотрите в сторону ЛидерТаска или Weeek.
-Нужен гибрид «таск-менеджер + база знаний» берите Notion.
-Для командных задач (особенно распределённых) Asana, если есть возможность её использовать.
👉 А какой таск-менеджер используете вы?
#taskменеджер #todoist #asana #ticktick #notion #лидертаск #week
🔥4
Самая недооценённая метрика: "Blocked Time" ⏱️⛔️
Всем успешной доставки, на связи рубрика "Метрика недели"
Я уже писал про такие процессные метрики как:
👉Time to market
👉Lead time
👉Пропускная способность (throughput)
👉Discard rate
👉Время нахождения задач в бэклоге
Если ещё не видели, лучше прочитать 😉.
И помните: метрики - это инструмент улучшения процессов, а не контроля людей.
Сегодня пишу про "более зрелую" метрику Blocked time, почему "более зрелую"?
Почему ее называют «более зрелой метрикой»?
Команды, которые начинают её считать, уже вышли за рамки базовых показателей вроде Lead Time или WIP.
Blocked Time требует осознанного анализа: что именно мешает нам двигаться?
Она не только показывает факт задержки, но и помогает вскрывать системные проблемы взаимодействия.
Blocked time - это время, которое задача была «заблокирована» ⛔️.
То есть команда не могла продвигать её дальше из-за внешних или внутренних зависимостей:
-ждём ревью у другой команды,
-не пришли данные от заказчика,
-согласование у юристов.
-фриз на релиз
🔥 Какую проблему решает?
-Помогает отделить «мы работали долго» от «мы не могли работать, потому что ждали».
-Делает узкие места прозрачными: видно, что тестирование ждёт доступ к стенду по 5 дней, или заказчик согласовывает требования неделями.
-Даёт аргументы на встречах с заказчиком и внутри компании: «Сами мы сделали за 2 дня, но 10 дней ушло на ожидание согласования».
📈 Использование Blocked Time в динамике:
Если показатель системно высокий → проблема в процессе (надо оптимизировать взаимодействие).
Если блокеры случайные и редкие → нормальная рабочая ситуация, главное фиксировать и обсуждать.
📝 Чек-лист: стоит считать Blocked Time, если…
-у вас уже есть базовые метрики (Lead Time, WIP),
-ощущаете, что «задачи буксуют», но непонятно где,
-хотите объяснять сроки на языке данных, а не эмоций.
А у вас в команде считается Blocked Time? Делитесь опытом 👇
Подписаться
#метрики #blockedtime #блокировка
Всем успешной доставки, на связи рубрика "Метрика недели"
Я уже писал про такие процессные метрики как:
👉Time to market
👉Lead time
👉Пропускная способность (throughput)
👉Discard rate
👉Время нахождения задач в бэклоге
Если ещё не видели, лучше прочитать 😉.
И помните: метрики - это инструмент улучшения процессов, а не контроля людей.
Сегодня пишу про "более зрелую" метрику Blocked time, почему "более зрелую"?
Почему ее называют «более зрелой метрикой»?
Команды, которые начинают её считать, уже вышли за рамки базовых показателей вроде Lead Time или WIP.
Blocked Time требует осознанного анализа: что именно мешает нам двигаться?
Она не только показывает факт задержки, но и помогает вскрывать системные проблемы взаимодействия.
Blocked time - это время, которое задача была «заблокирована» ⛔️.
То есть команда не могла продвигать её дальше из-за внешних или внутренних зависимостей:
-ждём ревью у другой команды,
-не пришли данные от заказчика,
-согласование у юристов.
-фриз на релиз
🔥 Какую проблему решает?
-Помогает отделить «мы работали долго» от «мы не могли работать, потому что ждали».
-Делает узкие места прозрачными: видно, что тестирование ждёт доступ к стенду по 5 дней, или заказчик согласовывает требования неделями.
-Даёт аргументы на встречах с заказчиком и внутри компании: «Сами мы сделали за 2 дня, но 10 дней ушло на ожидание согласования».
📈 Использование Blocked Time в динамике:
Если показатель системно высокий → проблема в процессе (надо оптимизировать взаимодействие).
Если блокеры случайные и редкие → нормальная рабочая ситуация, главное фиксировать и обсуждать.
📝 Чек-лист: стоит считать Blocked Time, если…
-у вас уже есть базовые метрики (Lead Time, WIP),
-ощущаете, что «задачи буксуют», но непонятно где,
-хотите объяснять сроки на языке данных, а не эмоций.
А у вас в команде считается Blocked Time? Делитесь опытом 👇
Подписаться
#метрики #blockedtime #блокировка
1👍6🔥5❤1