Я Delivery Manager🚀

Всем успешной доставки! 🚚📦

Признаюсь честно: последний пост был 6 мая, пауза вышла куда длиннее, чем планировал. Возвращаюсь! 🔄

Пока молчал, успел понаблюдать за историей с Telegram в России: мессенджер с февраля живёт под замедлением, к апрелю сбои доходили почти до 100%, а официальной полной блокировки до сих пор нет - при этом миллионы пользователей просто ушли жить с VPN. А в июне из App Store неожиданно пропал MAX, тот самый сервис, который прочили в качестве замены. 📱🚫

С точки зрения доставки это отличный кейс на тему рисков единой точки отказа: когда весь процесс (или вся коммуникация) держится на одном канале без запасного плана, устойчивость системы становится вопросом времени, а не вероятности. ⏳⚠️

Что было бы дальше в постах:
🔹 как оценивать риски единой точки отказа в процессах 📉
🔹 как строить план Б, не усложняя систему 🛠

Пишите в комментариях, что из этого интереснее разобрать подробнее 👇💬

Привет, для тех кто в Москве 😎https://t.me/neogenda/1327

🔥 Унификация и стандартизация работы IT-команд это благо или ограничение?
Чем больше становятся IT-организации, тем чаще появляется один и тот же разговор:
“Нам нужна унификация и стандартизация работы команд”
И почти сразу возникает второй лагерь:
“Это убьёт автономность и скорость”

И дальше начинается классический конфликт:
-порядок vs гибкость
-контроль vs автономность
-масштаб vs уникальность команд

📍 Почему этот вопрос вообще появился
Пока команд мало вопроса нет.
Каждая команда:
-сама выбирает процесс
-сама определяет flow
-сама договаривается о правилах работы
Но на масштабе 100-500+ команд ситуация меняется.Появляется система, которую уже нельзя “почувствовать” через отдельные команды.
И начинают всплывать проблемы:
-разные определения одних и тех же вещей
-невозможность сравнивать команды
-отсутствие прозрачности end-to-end потока
-локальная оптимизация вместо системной

📍 Что обычно предлагают как решение.Идея появляется почти всегда одна:давайте стандартизируем и унифицируем работу команд
И под этим часто понимается:
-единые процессы
-единые стадии flow
-единые метрики
-единые правила работы с задачами
-единые определения “готово”

📍 И тут возникает конфликт
Потому что для разных участников системы это выглядит по-разному:
Для команд:
“нам навязывают процесс”
“нас ограничивают в способе работы”
“теряется гибкость под домен”

Для руководителей:
“наконец появляется управляемость”
“можно видеть систему целиком”
“можно сравнивать и принимать управленческие решения”

📍 Поэтому дискуссия всегда уходит в “хорошо или плохо”Но, возможно, правильный вопрос другой:
-где унификация помогает системе работать лучше, а где начинает её ограничивать? И на этом моменте обычно нет единого ответа
Именно поэтому вокруг темы всегда столько споров и в командах, и на уровне менеджмента, и на уровне бизнеса.

💬 Интересно, как у вас в компаниях это воспринимается:
унификация - это больше про порядок или про ограничение?

Антипаттерны discovery
Всем успешной доставки! 🚚
Я много уже писал про discovery и даже если discovery внедрили, то он может не работать.
Почему? Потому что вместо инструмента принятия решений он превращается в формальность.

Вот несколько антипаттернов, которые встречаются чаще всего:
1️⃣ Discovery ради галочки
«Ну у нас есть этап discovery»
А что там происходит никто не знает. Результат: фича всё равно берётся «на веру».

2️⃣ Нет ответа на вопрос “зачем?”
Обсуждают решение, но не проблему.
- «Сделаем новый экран»
- «Добавим фильтр»
Зачем? Какую проблему решаем?Тишина.

3️⃣ Нет критериев успеха
Фичу сделали → выкатили → забыли
-Как поймём, что она успешна?
-Какие метрики смотрим?
Если ответов нет - это не discovery.

4️⃣ Решение уже принято заранее
Discovery превращается в театр:
Решение уже есть, а обсуждение просто чтобы «всех послушать».

5️⃣ Нет связи с деньгами / ценностью
Фичи обсуждаются в отрыве от бизнеса:
- «Будет удобнее»
- «Так делают конкуренты»
А где ценность? Где impact?

Хороший discovery - это не про встречи. Это про снижение неопределённости перед разработкой. Если после него вы всё ещё «верите», а не знаете, значит, что-то пошло не так.
#delivery #discovery #менеджмент #антипаттерны

Всем привет, проводим офлайн митап в Перми 😎

Команда Т-Технологий проведет митап в Перми ⚡️
Встречу соберем 7 апреля в БЦ Green Plaza, на базе собственного офиса. Обсудим, какие ИИ-инструменты могут помочь оптимизировать работу системного аналитика, в каких случаях и что стоит автоматизировать. А также, вместе с опытным ментором, разберем как работать со стажерами: ---на что обратить внимание при найме, как онбордить и какую пользу можно извлечь.
После докладов останемся на поболтать и познакомиться поближе с участниками.

📆 Встречаемся 7 апреля в Перми. Начало в 19:00.
Регистрируйтесь и зовите с собой коллег.

Привет, подводим итоги:
1.Было 3 заявки
2.Метрики не посмотрели ни по одной 😂
3.Зато обсудили: процессы в команде, приоритизацию и выстраивание E2E
Видимо в следующий раз надо делать рубрику не "покажи метрики", а "покажи процессы" 😎

Какие еще варианты? 🔥

Всем успешной доставки! 🚚
Любое внедрение изменений почти всегда встречает сопротивление.
Если команде не объяснить, зачем это нужно и какую проблему решает, изменения либо не взлетят, либо будут работать «для галочки».
Обычно изменения «продают»:
-рассказывают
-презентуют
-обучают
-выдают инструкции
Это важный этап и его не надо пропускать.
Но есть способ проще/сильнее. Можно не продавать изменения самому, а задавать вопросы, отвечая на которые команда сама приходит к выводу, что по-старому работать уже нельзя. Это навык, который стоит постоянно прокачивать.

Например, вы хотите внедрить этап discovery.
Можно сделать презентацию:
- зачем нужен discovery
- какие проблемы он решает
- как теперь будем работать
А можно прийти к команде с вопросами:
- Как вы определили, что именно эту фичу нужно делать?
- Сколько денег или новых клиентов она принесёт?
- Как мы поймём, что фича на проде успешна?
Если ответов нет или они в стиле «мы просто верим» ничего продавать уже не нужно.Проблема стала очевидной самой команде.
Тогда discovery - не навязанная практика,а логичное решение их же боли.

Простая формула внедрения изменений:
1️⃣ Подсветить проблему (лучше в цифрах)
2️⃣ Задать вопросы, которые создают конструктивное напряжение
3️⃣ Предложить решение, которое это напряжение снимает
И всё, вы не тот кто опять принес какое-то странное изменение, вы тот кто решил их боль 😎

Всем успешной доставки! Эта неделя без поста, занимаюсь заявками которые пришли в рубрику "Покажи метрики", но без мемчиков вас не оставлю 😃
P.S. как у вас телеграм? работает? или надо канал куда-то в другое место переносить?

🚚📦 Delivery Meme Friday 🎉
Думаете дело в документации? 😎

Привет, еще есть время оставить заявку 😎

Всем успешной доставки!
Что важнее: скорость или предсказуемость доставки?
Наверное многие задавались вопросом: что на самом деле важнее для команды скорость или предсказуемость?
Интуитивный ответ обычно такой: конечно скорость. Все хотят быстрее.
Но если посмотреть на систему чуть глубже, то ответ не такой очевидный.

Представьте две команды.
Команда А
Иногда делает задачу за 2 дня, иногда за 20.
Команда Б
Стабильно делает задачи за 7–8 дней.
Вопрос: какой команде легче планировать продукт? Почти всегда второй.
Потому что предсказуемость снижает управленческую неопределённость.

Когда система предсказуема:
- можно обещать сроки
- можно планировать релизы
- можно управлять ожиданиями бизнеса
И тут появляется важный инструмент percentile.
Например, если смотреть на 85-й перцентиль lead time, это означает: 85% задач проходят систему быстрее этого времени.
Если у команды 85-й перцентиль 9 дней, то можно довольно уверенно говорить: большинство задач будет готово до 9 дней.
Это намного полезнее для планирования, чем:
- среднее значение
- самая быстрая задача
- «обычно делаем за неделю»

Чтобы понять это проще, представьте очередь в кофейне.
В среднем кофе делают за 2 минуты.
Но иногда ломается кофемашина, кто-то заказывает 5 напитков, или бариста готовит сложный заказ.
В итоге получается примерно так:
- среднее время: 2 минуты
- 85-й перцентиль: 4 минуты

Если сказать человеку:
«кофе будет через 2 минуты», он будет разочарован довольно часто.
А если сказать: «примерно до 4 минут», ожидания почти всегда совпадут с реальностью.
Поэтому вопрос «насколько быстро работает команда» часто менее полезен, чем вопрос:
«насколько предсказуем её 85-й перцентиль?»

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

🚚 Если пост был полезен отправь коллеге, у которого процессы всё ещё «на ощущениях».
Подписывайся на канал «Я Delivery Manager» - про delivery, метрики 📊 и системное управление процессами.

🚚📦 Delivery Meme Friday 🎉
А сколько у вас длится дейлик?🙂

👋 Всем успешной доставки!

Продолжаем нашу регулярную рубрику "Покажи метрики😂"

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

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

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

🚚📦 Delivery Meme Friday 🎉

Всем успешной доставки!
Сегодня будет необычный формат: недавно закончил читать первую книгу «Задача трёх тел» из цикла книг "Воспоминания о прошлом Земли" и словил себя на мысли:

Осторожно, дальше будут спойлеры

Если бы одна из главных героинь использовала data-driven подход корректно, сюжет книги мог бы пойти совсем по другому пути.
Ключевое решение в книге принимается не на данных, а на боли.
-Личная трагедия.
-Один яркий пример жестокости системы.
И дальше экстраполяция этого опыта на всё человечество.
По сути:
-выборка из одного кейса,
-нулевая репрезентативность,
-максимальные ставки,
-и решение без возможности отката.

Это не data-driven. Это эмоция, возведённая в стратегию.
В data-driven подходе важно не просто «иметь данные».
Важно понимать, когда данных недостаточно, и честно признавать неопределённость.

Проблемы начинаются там, где:
-личный опыт принимают за статистику,
-эмоцию за инсайт,
-единичный кейс за системный паттерн.

В работе это выглядит так:
«В прошлый раз команда сорвала сроки, а значит, она всегда так работает».

Самые опасные решения принимаются не тогда, когда нет данных.
А тогда, когда кажется, что данных достаточно.

Если у вас нет метрик, то вы рискуете.
Если метрики есть, но вы их неправильно интерпретируете, то вы рискуете ещё сильнее.
У кого был кейс "эмоции vs данные"? Делитесь в комментариях!

🚚 Если пост был полезен отправь коллеге, у которого процессы всё ещё «на ощущениях».
Подписывайся на канал «Я Delivery Manager» - про delivery, метрики 📊 и системное управление процессами.

🚚📦 Delivery Meme Friday 🎉
А вы всегда успеваете в дедлайн? 😂

Всем успешной доставки!
Наверное многим все еще не понятно кто такой Delivery Manager?
Я этот канал завел только потому, что устал отвечать чем же я занимаюсь 😎
Давайте попробую еще раз раскрыть, что из себя представляет Delivery Manager (конечно только по моему мнению)

Если мы откроем hh и возьмем случайную вакансию которая будет называться Delivery Manager, мы увидим, что в каждой компании свои требования, вот вам пару примеров:

Вакансия 1
Требования:
-планирование ресурсов совместно с PO и СТО для достижения целей в установленные сроки
-поиск и устранение «узких мест» потока через анализ метрик (Cycle Time, Lead Time, Throughput и Flow Efficiency)
-упрощение рабочих процессов: удаление лишних процедур и препятствий, которые замедляют команду
-управление разногласиями по объёму работ и срокам: сведение позиций бизнеса и разработки к рабочему компромиссу, фиксация состава релиза и критериев готовности, управление изменения через формальный процесс согласований
-организация управления инцидентами: настройка процесса реагирования (on-call/роли, runbooks, SLA/эскалации), проведение разборов (postmortem) с командой, формирование плана улучшений и контроль выполнения корректирующих действий.
-управление поставкой: согласование релизного плана с PO и командой разработки, релизный календарь и синхронизация всех участников, организация поэтапной раскатки, подтверждение готовности к релизу.

Вакансия 2
Обязанности:
-Полноценное управление жизненным циклом разработки: руководство кросс-функциональной командой (аналитики, разработчики, тестировщики);
-Организация процесса доставки: полная ответственность за планирование, координацию и успешный выпуск релизов.
-Внедрение и отладка процессов: активное внедрение и адаптация лучших практик Agile/Scrum, SAFe в команде. Регулярная отчетность о статусе разработки, прогрессе задач, пропускной способности команды и соблюдении сроков.

Вакансия 3
Задачи
-Управлять портфелем изменений: приоритизация, масштабирование инициатив, перераспределение ресурсов между RUN и CHANGE
-Вести программу экономии на SMS: тарифные стратегии с операторами, маршрутизация, каскады каналов, контроль стоимости доставки без потери качества
-Оптимизировать бюджетирование и контроль затрат БЮ: драйверная модель, план–факт, меры экономии
-Обеспечивать формирование стратегии бизнес-юнита: миссия и видение, дорожная карта и приоритеты
-Выстроить активные коммуникации с другими бизнес-юнитами: SLA межблочных взаимодействий, регулярные синхронизации, единый журнал кросс-решений
-Курировать взаимодействие с операторами сотовой связи и участвовать в переговорах: условия, бонусы/штрафы, альтернативные маршруты, SLA-ревью
Вести метрики и отчётность: SLA, TTR, выполнение спринтов, NPS/CSAT партнёров, экономический эффект, вклад в EBITDA

И таких разных вакансий большое количество, есть совсем абсурдные требования.
Иногда кажется, что вакансию называют Delivery Manager ради какого-то хайпа или моды, а обязанности остаются руководителя проекта или project managerа.

В моем понимании Delivery Manager - это data-driven менеджер изменений, который отвечает за сквозной процесс (т.е. за весь E2E) доставки итогового продукта до пользователя: сокращает время от идеи до выхода продукта на рынок и увеличивает прогнозируемость. Если нет запроса на сквозной процесс - отвечает за всю доступную цепочку.
Если кратко то Delivery Manager это Produсt owner E2E процесса, для него продукт это процесс доставки ценности.

Зачем нужен:
-Пересобирать и улучшать процессы растущего или изменяющегося бизнеса, чтобы компании не теряли гибкость и эффективность при масштабировании
-Накапливать и делиться практиками и опытом с организацией, командами, сотрудниками, комьюнит
-Ускорять поставку продуктов на рынок в условиях растущей сложности ИТ систем, процессов и самих продуктови
Подробно все давно указано здесь

Надеюсь стало более понятней, если нет, то задавайте вопросы в комментариях.

🚚📦 Delivery Meme Friday 🎉
Мем из фоток с квартирника, Даня привет 😂 оригинал фото в комментариях

Всем успешной доставки!
🆘85-й процентиль: как объяснить бизнесу «вероятностные сроки»
Вопрос, который рано или поздно возникает в любой команде:
«Когда будет готово?» И бизнес почти всегда ждёт одну дату, а не «диапазон», «вероятность»
Проблема в том, что мы часто не умеем переводить статистику на человеческий язык. Почему “среднее” - плохая идея.
Если вы говорите:
«Средний lead time у нас 10 дней»
Бизнес слышит:
«Через 10 дней будет готово»😂
А потом случается реальность: зависимости, блокеры, срочные задачи и привет разочарование. Среднее не учитывает вариативность.

Что такое 85-й процентиль простыми словами👀
85-й процентиль - это ответ на вопрос: «В 85% случаев мы укладываемся в этот срок»
Пример:
85-й процентиль lead time = 14 дней. Перевод на бизнес-язык: «С вероятностью 85% задача будет готова не позднее чем через 14 дней»
Не обещание. Не гарантия. А управляемый риск, который можно обсудить.

Почему именно 85%, а не 100%. 100% это идеальный мир, где нет:
-внезапных блокеров
-смены приоритетов
-внешних зависимостей
85% хороший баланс:
-достаточно надёжно для планирования
-достаточно честно по отношению к реальности процесса

Как это продавать бизнесу. Рабочая формула выглядит так:
«Мы можем назвать дату с разной степенью уверенности. 85% - это срок, в который мы обычно укладываемся. Если нужна большая надёжность срок будет длиннее, если готовы рискнуть, то короче». И дальше выбор делает бизнес.
Что важно проговорить заранее:
-это работает только на исторических данных
-процентиль - не SLA и не KPI
-если процесс меняется → данные пересчитываются

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