Тема выпуска — пересечение ролей: может ли Delivery Manager быть полноценным владельцем продукта? И если да, то как именно?
Немного о спикере
Максим Фролов пришёл в IT не напрямую. Работал на сталелитейном заводе инженером, потом менеджером мероприятий, даже в мэрии Иннополиса успел поработать. В IT попал через веб-студию в Казани, где занимался проектами на Bittrex, а затем переехал в Петербург. Там впервые осознал: его задача — не «таскать тикеты», а выстраивать взаимодействие и обеспечивать эффективность командной работы.
Именно это понимание привело его к delivery-менеджменту.
Откуда растёт вопрос: «Кто ты такой?»
Максим вспоминает, что на ранних этапах карьеры часто сталкивался с вопросами вроде:
- Чем ты вообще занимаешься?
- Зачем ты нужен?
- Где зона твоей ответственности?
Эти вопросы казались почти провокационными. Тогда он их воспринимал болезненно. Сегодня — благодарен. Именно необходимость на них ответить и сформировала его подход к работе.
Delivery Manager ≠ Service Delivery Manager
В Тинькофф у роли Delivery Manager существенно более широкий охват, чем в классическом понимании, описанном, например, у Дэвида Андерсона.
Service Delivery Manager — это скорее про post-commit стадию: обеспечение потока, устранение «красных светофоров», контроль сроков. Delivery Manager в Тинькофф работает уже на Discovery-этапе, участвует в разработке практик, помогает в коммуникации, занимается коучингом, поддерживает сотрудников — и всё это выходит далеко за пределы только доставки.
Ключевое отличие — масштаб и вовлечённость в процессы вне классического delivery.
Delivery как продукт: метрики и подходы
В Тинькофф Delivery Manager отвечает за процесс — а процесс, в свою очередь, рассматривается как продукт. Что это значит на практике?
Используемые метрики:
- Lead time и его разброс
- Work in progress
- Потоковый долг
- Пропускная способность
- Удовлетворённость процессом
- Метрики ROI на изменения
- NPS и CSI по мероприятиям и процессам
То есть, применяются и классические канбан-метрики, и субъективные оценки вовлечённых сторон.
А как вы проводите STATIK?
STATIK в команде Максима не проводится в «академическом» формате. Чаще это точечные интервью или сессии, основанные на вопросах STATIK, при входе в новые команды или процессы. Это не обязательная регулярная практика, а инструмент, используемый по потребности. Главное — сохраняется системное мышление как основа для изменений.
Работа с гипотезами
Delivery Manager в Тинькофф работает не только с фактами, но и с гипотезами: что можно улучшить, изменить, оптимизировать. Тут важен «тулбокс» — набор инструментов, которыми он пользуется.
ТОП-3 инструмента Максима:
Метрики и статистика — самый частый выбор. Быстро, доступно, не требует вовлечения других людей.
Интервью — любимый инструмент. Именно в диалоге рождаются глубокие инсайты, когда задаёшь вопросы: «А зачем вам это?», «А что, если бы этой проблемы не было?».
Брейнштормы и воркшопы — для совместного генерации гипотез и идей.
Big Bang и эволюция: как запускали OKR в Тинькофф-кассе
Максим Фролов не строит из себя мягкого коуча — внутри его бизнес-подразделения есть те, кто считает его диктатором. «Каждый созвон — и снова какая-то кабала от Фролова», — с долей иронии описывает он собственный стиль изменений. Но суть не в авторитарности, а в масштабе трансформации: запуск OKR в подразделении из 450 человек — это не итерация, а взрыв. Настоящий Big Bang.
Революция по плану
Весной 2022 года команда договорилась внедрять OKR — и уже с июня началась активная фаза. Обучение, материалы, первые цели на всю бизнес-линию. «Мы собрали самолёт из картона и попытались взлететь», — так Фролов описывает старт. Да, отваливались крылья. Да, пришлось чинить на лету. Но с тех пор — только эволюция. Команда регулярно замеряет удовлетворенность, собирает обратную связь, корректирует процесс. OKR превратились в продукт — с 450 пользователями, внутренней поддержкой и движением вперёд.
Как работают с сопротивлением
Метод выбран осознанно: ProSci и его модель ADKAR. Это подход к управлению изменениями, где каждое «А» и «К» — это фаза прохождения трансформации:
- Awareness — осознание
- Desire — желание
- Knowledge — знание
- Ability — способность
- Reinforcement — закрепление
Раз в два месяца команда отправляет опрос на 25 вопросов, чтобы понять: на каком этапе застряли люди. Если нет осознания — не стоит лить знания. Если нет желания — нужно искать выгоды. 140 человек регулярно отвечают — показатель вовлеченности говорит сам за себя. На основе опросов даются рекомендации руководителям среднего звена: где поработать, с кем поговорить, как поддержать движение.
Почему выбрали именно ProSci? Просто. Потому что сам Фролов прошёл обучение — по рекомендации Алексея Пименова. А когда инструмент оказался в руках — начал использовать. Другие модели вроде Kotter остались «на картинке». Здесь — всё прикладное.
Метрики: от недоверия к решающим данным
Метрики собираются не ради красивых дашбордов. «Мы их собираем, чтобы принимать решения», — говорит Максим. Вдохновляясь подходом Дэна Вакканти, команда верит: если нельзя сделать метрику actionable — зачем она вообще?
Да, поначалу метрикам не радовались. Но провели обучение, объяснили, как принимать решения на их основе, подключили внутренний продукт Team Metra. И главное — был спонсорский вес: CPO и CTO поддерживают метрики как основу управления. Без этой поддержки всё было бы сложнее. Но с ней — это не 1х-изменение, а 10х, 50х, 100х.
Лидерство и фильтры принятия решений
Формальных фильтров в принятии решений пока нет. Есть культура: «работать нужно хорошо». Иногда — даже слишком. Чтобы не распыляться, используют OKR как фокусирующий инструмент. Надежда — именно через OKR придти к тому, что решения будут приниматься в соответствии с целями бизнес-подразделения.
Классы обслуживания, стоимость задержки, триаж
Пока классов обслуживания в бизнес-линии нет. Есть внимание к стоимости задержки, но без формализованных архетипов. Был интерес к Kanban-классификациям — сейчас к ним относятся с осторожностью. Избыточные или неправильно внедрённые классы могут привести к хаосу, а не к потоку.
Тем не менее, триаж — сортировка задач по важности — уже на подходе. Delivery-команда (четыре человека) начинает формализовывать бэклог гипотез. Как только бэклог оформится — начнётся триаж, доски, трекинг статусов.
Визуализация и WIP-лимиты
Сейчас команда не применяет классические практики Kanban — визуализацию, ограничения в работе. Пока всё держится на разумной загрузке и понимании приоритетов. Есть роадмап, есть общее понимание, кто чем занят. На ретроспективе признались: пока не доросли. Когда работа усложнится — доска и лимиты придут сами собой, как это уже было раньше.
Когда нужна визуализация?
Максим отвечает просто: когда становится больно. Когда работа прячется в головах, задачи теряются, коммуникации не работают — тогда нужна визуализация. Пока этого нет — можно обойтись.
