Всем успешной доставки!
Обычно я пишу про продуктовую разработку, но знаю, что в канале много ребят из заказной, давайте попробую помочь вам 😎

🎯 Нужно ли внедрять Канбан в аутсорс-команду?
Спойлер: да. Особенно если вы хотите меньше гореть и больше зарабатывать.

Работая в аутсорсе, вы всегда между двух огней:
– заказчик хочет «быстро, дешево и всё сразу»,
– команда хочет «внятные задачи, адекватные сроки и стабильность».

Во многих аутсорс-командах Scrum существует только номинально. Спринт просто двухнедельная коробка, чтобы что-то куда-то втиснуть.

Что даёт Канбан аутсорс-команде?
🟢 Прозрачность
Каждая задача проходит четкий путь: "взяли —> делаем —> проверили —> сдали".
Это видно как команде, так и заказчику. Меньше созвонов “а где вот эта штука?”, → больше доверия.

🟢 Прогнозируемость
C помощью метрик (Lead Time, Throughput, WIP) можно не гадать, а прогнозировать:
«эта задача будет готова через 3-4 дня, с вероятностью 85%».

🟢 Управление WIP (Work in Progress)
Меньше задач в работе = быстрее доодим до конца.
Это важно в аутсорсе, где «почти сделано» = не оплачено.

🟢 Гибкость под изменения
Канбан не требует фиксировать объем на 2 недели.
Пришел новый приоритет от заказчика — перестроились без боли и оправданий.

А заказчик это поймет?
Да. Даже если он про Канбан не слышал.
Ты показываешь:
✅ Статус всех задач
✅ Метрики прогресса
✅ Предсказуемость сроков
✅ Быструю реакцию на его новые хотелки
Выгода понятна без терминов.

📊 Метрика недели: время нахождения задач в бэклоге
Кажется, что все важные метрики уже известны - скорость, Lead Time, Cycle Time… Но есть одна неочевидная, которую редко используют - время нахождения задач в бэклоге.

🔍 Что это такое?
Это количество дней (или недель), которое задача проводит в статусе "Backlog" - от момента её попадания туда до момента, когда команда берёт её в работу.

💡 Зачем мерить
Признак приоритизации - если задача лежит в бэклоге месяцами, значит, её ценность или приоритет под вопросом.
Выявление "кладбища идей" - бэклог легко превращается в свалку, где теряются актуальные задачи.
Сигнал к пересмотру процессов - слишком длинное ожидание может говорить о неэффективной работе с входящими запросами.
Индикатор загрузки команды - если задачи быстро забираются в работу, но бэклог всё равно растёт, это сигнал к дополнительному найму или перераспределению ресурсов.

📈 Какие выводы можно сделать
Если задачи лежат в бэклоге более 6–12 месяцев, велика вероятность, что они "протухли", контекст изменился, а ценность снизилась до нуля.
Если старые задачи вдруг начали попадать в работу, проверь не изменились ли требования или бизнес-приоритеты.
Если большая часть задач живёт в бэклоге более N дней, то команда, скорее всего, набирает слишком много задач "на потом".

⚙️ Как использовать
Регулярно проводить grooming с удалением или переоценкой "долгожителей".
Отслеживать тренд: растёт ли среднее время нахождения задач или уменьшается.
#метриканедели #backlog #e2e

🕒 Почему заказчики не верят в сроки и что с этим делать
Наверняка у вас было так:
Ты озвучиваешь сроки, заказчик скептически хмыкает:
- «А вы точно успеете?»
Или хуже:
- «В прошлый раз тоже обещали за 2 недели…»
👉 Проблема в том, что большинство команд называет сроки “с потолка”. Это не прогноз, а обещание «на авось». Естественно, доверия тут нет.

🚫 Почему заказчики не верят срокам:
Ожидания ≠ реальность. В прошлых проектах обещали быстро, но сдавали позже.
Субъективность. «Петя сказал, что справится за день» - звучит как мнение, а не как прогноз.
Нет прозрачности. Заказчик не видит, на чём основаны сроки.

✅ Что делать вместо «обещаний»
Применять data-driven подход.
Это значит, что решения принимаются не по ощущениям («думаю, что успеем»), а на основе фактов и статистики.
Ключевые метрики:
Lead Time - сколько времени в среднем проходит от постановки задачи до её завершения.
Cycle Time - сколько времени реально уходит на выполнение после старта.
Throughput - сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.

📊 Если у тебя есть данные за последние 3–6 месяцев, ты можешь сказать заказчику:
«85% задач подобного размера мы закрываем за 8–12 дней. С большой вероятностью эта задача будет в том же диапазоне».
Это уже не «авось», а прогноз, основанный на данных.

🎯 Как метрики и data-driven подход помогают строить доверие:
-Переводят разговор из «верьте нам на слово» → в «вот данные».
-Позволяют принимать решения осознанно: менять приоритеты, увеличивать команду, убирать узкие места.
-Дают заказчику ощущение контроля и прозрачности.
-Убирают пространство для манипуляций: цифры объективнее эмоций.

💡 Итог: заказчики не верят обещаниям, потому что слишком много раз обжигались. Но они верят цифрам, данным и статистике.
Data-driven подход и метрики Lead Time / Cycle Time — это твой способ перейти от хаоса к доверительной и предсказуемой работе.
👉 А у вас как в проектах: чаще дают обещания или работают на основе данных?
#leadtime #throughput #заказчики #сроки

«Ну как тут пройти мимо, если разыгрывают книгу про Канбан? 🚀»

Рубрика "инструмент недели"
🛠 Личные инструменты менеджера: как выбрать таск-менеджер?
У любого менеджера (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

Самая недооценённая метрика: "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 #блокировка

👋 Всем привет!

Хочу предложить вам перейти от теории к практике (смотрите примеры 👉 пост , результаты).

📊 Суть проста:
У вас есть процессные метрики - Lead Time, пропускная способность или другие.
Вы их показываете, а я даю рекомендации, которые помогут улучшить процесс доставки. Будете ли вы это внедрять решайте сами 😉

🔧 Как это будет:
Оставляете заявку тут
Договариваемся на слот (1 час).
Созваниваемся в Google Meet, я готовлю для вас доску в Unidraw, с ней вы останетесь после встречи, со всеми записями и инсайтами.
🗓 Заявки принимаю до 23.09, после этого начну планировать созвоны.

💸 Всё бесплатно.

Всем успешной доставки! Хочу поделиться полезным форматом от ребят, которые делают конференцию Ural Digital Wekeend, а теперь ещё и проводят онлайн-митапы.
Ближайший митап 18 сентября: как держать пожары в разработке под контролем с помощью Observability и умных алертов.

Ссылка на митап: ЗАРЕГИСТРИРОВАТЬСЯ

Думаю, многим из вас зайдёт 👍

🚚📦 Delivery Meme Friday 🎉
Считайте метрики правильно и приносите мне на анализ 🧐

👥 Когда говорим про End-to-end процесс (от идеи до релиза), часто думаем только о разработке.
Но поток шире: это цикл от поиска проблем до поддержки решения.

🔹 Discovery:
-Стейкхолдеры формулируют потребность.
-Аналитики / исследователи проводят интервью и исследования, выявляют проблемы, формулируют гипотезы решений и готовят ТЗ. Писал тут про подход DD
-UX/UI превращают гипотезы в сценарии и прототипы.

🔹 Delivery:
-Разработчики создают решение.
-QA / тестировщики проверяют качество.
-DevOps / SRE обеспечивают инфраструктуру и доставку.

🔹 После релиза (support):
Поддержка фиксирует первые проблемы от пользователей.
Продуктовые / дата-аналитики измеряют эффект и метрики.
На основе данных рождаются новые гипотезы → цикл запускается снова.

🔹 Сквозная роль:
Delivery Manager обеспечивает поток, убирает блокеры, согласует зависимости, следит за метриками.
📊 Визуально это выглядит как замкнутая петля ценности: исследование → разработка → поддержка → новое исследование.

❗️Почему это важно?
Без discovery мы рискуем сделать «не то», без поддержки ценность быстро теряется. End-to-end - это умение видеть весь цикл, а не только свой участок.

📌 Попробуйте нарисовать свой e2e-поток и отметить, каких ролей у вас нет. Это отличный способ понять, где теряется скорость или качество.

Всем успешной доставки 🚀
📌 Если ищете, что почитать про AI, бизнес и технологии, то я нашёл хороший вариант.

Я сам периодически теряюсь в этом инфопотоке. Поэтому мы с ребятами из сообщества собрали подборку каналов, за которыми реально стоит следить.

Это блоги разработчиков, аналитиков, продактов и маркетологов. Там делятся тем, что уже проверили на практике: что сработало, где обожглись и какие выводы сделали. Живой опыт вместо теории.

📂 Кому интересно, вот папка, можно подписаться сразу на всех

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

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

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

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

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

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

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

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

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