Знакома ситуация: вы крутитесь как белка в колесе, помогаете всем и всюду, а на вопрос «Чем ты занят?» отвечаете: «Да всем понемногу…». К сожалению, в 2026 году такой подход уже не работает.

Меня зовут Дианова Анастасия, я — Lead Delivery Manager в Lenta Tech («Группа Лента»). Я отвечаю за скорость поставки новых фич в приложение для заказа продуктов онлайн. В статье расскажу, как мы переосмыслили роль Delivery Manager’а, когда столкнулись с жесткими ограничениями.

2026 год принес нам новые вызовы:

• Охлаждение экономики и, как следствие, найма. Расширить штат очень сложно — ни Delivery Manager’ов, ни специалистов в команды.

• Рост контроля за списанием затрат и расходами. IT‑специалисты — дорогие кадры: каждый час работы стоит немало, поэтому теперь мы тщательно учитываем время.

• Высокие ожидания от внедрения ИИ. Все мы видели статьи про «оптимизацию с помощью ИИ»: один человек с ИИ сделает работу за пятерых. На практике с легаси кодом и контекстом ИИ помогает, но не творит чудес. Тем не менее, общий информационный фон давит, и нам приходится искать способы повысить продуктивность без расширения штата.

• Конкуренция. Наши прямые конкуренты наращивают функциональность, выпускают новые версии приложений. Мы не можем отставать: нужно поддерживать привычный пользователям функционал и искать точки роста. 

• Давление налоговых служб. С начала 2026 года налоговые органы стали строже проверять IT‑компании. Нужно обосновывать и доказывать право на льготы и преференции для сотрудников. Любая неточность в документах — и мы рискуем их потерять.

Проблема: почему Delivery Manager становится уязвим

У нас 9 продуктовых команд и всего 4 Delivery Manager’а. Вместе со мной, тимлидом, нас пятеро, но распределить команды всё равно непросто: почти на каждого приходится по две.

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

Теперь Delivery Manager должен:

• быть держателем процессов — следить, чтобы все проекты двигались по единому флоу;

• расставлять приоритеты — понимать, что важно сейчас, а что может подождать, причем критерии должны быть едиными и прозрачными;

• использовать инструменты для оптимизации — искать способы автоматизировать рутинные операции;

• уметь отказываться от лишнего — не браться за всё подряд, а фокусироваться на главном;

• обрести чёткую ценность — чтобы любой сотрудник, от разработчика до гендиректора, понимал: вот зачем нужен Delivery Manager, какую конкретную пользу он приносит компании.

Поворотный момент: когда стало ясно, что по‑старому уже не получится

Поворотный момент наступил, когда к нам пошли масштабные проекты. Руководство решило присоединить к компании ещё несколько сетей — самые известные из тех, что вы наверняка знаете: «Монетка» и «ОБИ» (теперь — «Дом Лента»). 

Мы с коллегами‑менеджерами сразу поняли: таких проектов будет ещё много. И кому, как не нам, Delivery Manager’ам, включиться в их реализацию? Нужно выстроить процессы так, чтобы масштабирование стало реально возможным.

Объём работ по масштабированию наших цифровых продуктов на новые сети был не просто амбициозным — поначалу он казался почти нереальным. Представьте, что нужно:

Раньше мы могли решать задачи «по мере поступления»: помочь команде, подстраховать, оперативно перебросить ресурсы. Но теперь такой подход — как попытка потушить пожар стаканом воды. Мы поняли, что такая нагрузка — это не временное явление, которое можно перетерпеть. По‑старому работать больше не получится.

Инсайт: ценность нужно измерять, а не чувствовать

Мы взялись за переосмысление роли Delivery Manager’а. Ключевой инсайт был таким: наша ценность для компании должна выйти из категории «всем понятно, что это классные и полезные ребята» в чёткую, измеримую структуру. Что это значит на практике? 

• Метрики вместо интуиции. Раньше мы часто опирались на ощущение: «работа идёт хорошо, команда довольна, пользователи не жалуются». Теперь этого мало. 

• Фокус на эффекты для бизнеса. Наша работа должна влиять на ключевые показатели бизнеса. Мы выделили главные метрики, которые теперь держим в фокусе.

• Прозрачность вклада. Теперь мы не просто «решаем проблемы», а закладываем паттерн, который позволит решать аналогичные проблемы быстрее или не допускать их вовсе. 

В итоге этап масштабирования стал для нас точкой роста. Мы поняли: чтобы вести компанию вперед в новых условиях, Delivery Manager должен не просто «управлять релизами», а чётко понимать и демонстрировать свою ценность через цифры и результаты.

1. Стартовый замер

Чтобы определить точку отсчёта и понять текущую ситуацию, мы провели опрос среди деливери-менеджеров и всех участников продуктовых команд. Вот какие выводы мы сделали по результатам:

Сильные стороны:

• доверие к управлению задачами и коммуникацией;

• комфортность и эффективность взаимодействия; 

• вклад в достижение целей бизнеса; 

• делегирование задач. 

Точки роста:

• доверие к срокам;

• проактивность; 

• понимание роли Delivery Manager’а — некоторым до конца не ясно, чем занимаются DM;

• единый стиль / подход — заметен разнобой в манере работы;

• поддержка продуктивности — можно усилить эффект от взаимодействия.

2. Миссия и ценности 

Ключевым шагом стало определение ценностей и ролей: мы чётко сформулировали, кто мы, что делаем и зачем нужны.

Шаг 1. Выявление ценностей через диалог с командой

Мы не стали копировать готовые списки — они не подходили. Вместо этого опирались на сложившуюся корпоративную культуру и реальные ценности наших менеджеров.

Для этого разработали вопросы для глубинных интервью, провели серию встреч с действующими менеджерами, расшифровали ответы и обобщили данные с помощью нейросетей — это помогло выделить ключевые паттерны. Затем ранжировали ценности: приоритет получили те, что отозвались большинству. Их мы и взяли за основу. Результат оформили в презентацию и статью в Confluence.

Шаг 2. Формулировка миссии

Следующей задачей стала формулировка миссии — ёмкой фразы, которая бы собрала в себя всё, что мы считаем важным.Мы использовали подход, описанный в книге Саймона Синека «Start With Why» («Начинай с почему»). 

Успешные лидеры и компании сначала определяют своё «Почему» — глубинную цель или убеждение, ради которой они существуют. Затем формулируют «Как» — уникальные методы, ценности и принципы, которые позволяют реализовать это «Почему». И только потом — «Что»: конкретные продукты, услуги или действия, которые люди видят и с которыми взаимодействуют.

Вот так мы сформулировали первую версию миссии деливери-менеджеров в Lenta Tech: «Создание и развитие процессов с помощью современных методологий и инструментов для достижения бизнес-целей оптимальным способом». 

Зачем это было нужно? Практическая польза

Может показаться, что работа над ценностями и миссией — абстрактные упражнения, далекие от реальных задач. Но на практике мы сделали важную вещь: задокументировали наш образ мышления и приоритеты.

В долгосрочной перспективе эта работа упрощает найм и онбординг: кандидаты сразу видят нашу философию, а новички быстрее погружаются в контекст благодаря чётким ориентирам. Единое понимание миссии помогает командам принимать решения в духе общей стратегии даже при ограниченных ресурсах, а нам — ясно и эффективно доносить свои цели до стейкхолдеров и партнёров.

3. Работа с метриками: от интуиции к данным

Очевидно, что полагаться на интуицию при принятии решений нельзя. Для эффективного управления в условиях ограниченных ресурсов нам нужна была система метрик — доступная, удобная и наглядная для всех заинтересованных сторон.

Основа подхода: канбан-методология

Ключевой методологией, на которой мы выстраиваем процессы, является Kanban. Соответственно, и систему метрик мы спроектировали в соответствии с его принципами. Нам было важно отслеживать:

• всплески нагрузки;

• задачи, которые пришлось отменить или отложить;

• время выполнения задач на разных этапах;

• общую пропускную способность (throughput).

Для реализации этой задачи выбрали Grafana в качестве основного инструмента визуализации. Она идеально подошла для наших целей, поскольку подключается к реплике Jira без нагрузки на прод, строит гибкие дашборды и даёт любые аналитические срезы через фильтры.

В процессе работы мы не стали изобретать велосипед там, где это не нужно, а провели аудит уже интегрированных инструментов и приняли следующие решения:

• Использование встроенных графиков Jira. Некоторые стандартные отчёты, например, Cumulative Flow Diagram (CFD), оказались достаточно точными и полезными. Мы решили не дублировать их в Grafana, а использовать напрямую из Jira.

• Исследовали готовые плагины и выявили те, что дают ценные выгрузки данных. Их результаты также были включены в общую систему отчётности.

Собрав исчерпывающий набор метрик и диаграмм, мы получили возможность:

• видеть картину в цифрах, не погружаясь глубоко в работу каждой команды;

• сравнивать команды между собой: выявлять сильные стороны, которые можно масштабировать, и слабые места, требующие внимания;

• фокусироваться на проблемных зонах, требующих нашего непосредственного участия.

Героем метрик в «Группе Лента» является Алиса — она составила ТЗ, контролировала работу и проверяла каждый график, а после создала методичку по использованию дашборда. 

Документирование и обучение

Просто построить дашборд недостаточно. Чтобы система работала, мы подробно описали каждую метрику, её значение и способ расчёта.

Создали инструкцию по использованию метрик. Стандартные руководства из интернета нам не подошли, поэтому написали собственное, адаптированное под наши процессы и рабочий поток (workflow). В инструкции указали:

• как интерпретировать те или иные показатели;

• какие паттерны сигнализируют о проблемах, например, резкий рост количества задач в статусе «ожидание» или длительное нахождение задачи в «ревью»;

• какие управленческие решения следует принимать на основе данных.

Следующий шаг — обучить не только деливери‑менеджеров, но и всех заинтересованных лиц: продакт‑менеджеров, тимлидов и членов команд. Это позволит всем понимать, как движется работа, как устроен процесс и как их действия влияют на общие показатели.

4. Упростили и автоматизировали

Оптимизация работы delivery manager’а в условиях ограниченных ресурсов невозможна без выделения типовых задач и их автоматизации. Мы сделали на этом ключевую ставку и пошли несколькими путями.

Первым шагом стал аудит ежедневных рутинных операций на уровне отдельных команд и межкомандных взаимодействий. Мы проанализировали, какие процессы можно формализовать и переложить на алгоритмы.

Основным инструментом автоматизации выступила Jira. В результате:

• в каждом проекте внедрено до 50 автоматизаций;

• автоматизированы типовые переходы статусов, назначения исполнителей, уведомления;

• снижена нагрузка на деливери‑менеджеров по ручному контролю процессов.

5. Создание новых инструментов на базе ИИ‑ассистентов

Мы активно интегрировали ИИ в рабочие процессы. Подходы варьировались: от точечных решений отдельных менеджеров до полноценных новых систем.

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

Одна из проблем — логирование времени. 

Нам нужно было усилить контроль, но и упростить эту процедуру. Разработали внутреннюю ИИ-систему, которая отслеживает корректность учёта, отправляет персональные напоминания, подсказывает, по каким задачам вероятнее всего было затрачено время, и адресно работает с нарушителями, не отвлекая остальных.

Контроль дополнили поддержкой сотрудников: создали модуль, который анализирует активность в Jira, репозитории и мессенджере, на основе этих данных предполагает, над какими задачами шла работа, и при обнаружении пробелов создаёт черновик записи. Сотруднику остаётся проверить предложенные задачи, скорректировать время и подтвердить — в несколько кликов.

Такой подход не только повышает точность учёта, но и существенно снижает нагрузку на сотрудников.

Автоматизация релиз‑ноутсов

Еженедельные релизы (до 40 изменений в каждом) требуют понятных и структурированных релиз‑ноутсов для заказчика. Мы автоматизировали этот процесс с помощью ИИ‑ассистента:

• он преобразует сухие технические заголовки коммитов и задач в ясные формулировки, понятные бизнесу;

• группирует изменения по функциональным блокам и приоритету;

• формирует готовый черновик документа с логичной структурой.

В итоге команда тратит на подготовку статьи о релизе в разы меньше времени, а коммуникация с заказчиком стала прозрачнее и эффективнее.

Анализ корпоративного мессенджера

Ещё одно решение на базе ИИ анализирует переписку в корпоративном мессенджере. Это позволяет:

• собирать всю информацию по конкретной теме, например, проекту или фиче, даже если обсуждение ведётся в нескольких тредах;

• агрегировать ссылки, упоминания и ключевые решения в одном месте;

• экономить время на поиск информации и синхронизацию команды.

Предвижу возражение: а как же личные переписки и приватные чаты? Конечно же, они исключены из обработки, мы анализируем только данные по рабочим вопросам. 

Эти инструменты разработал Владимир — он у нас главный по ИИ и мощным автоматизациям.

Расширенная система аналитики

Параллельно дополнили систему аналитики с использованием ИИ‑инструментов. Её ключевые компоненты:

• Кастомные метрики. Помимо стандартных показателей (Lead Time, Cycle Time, throughput, CFD), мы отслеживаем: количество коммитов, 

• багов и саб-багов по конкретному функционалу (в т. ч. критических) и 

• число комментариев к MR (Merge Request). 

Результат: комплексный дашборд даёт ещё более объемную картину работы команды. 

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

6. Перестали быть «передаточным звеном»

Ранее деливери‑менеджер часто выступал в роли «передаточного звена»: через него проходило множество вопросов и решений, что отнимало время от стратегических задач. Мы сместили фокус — теперь главная цель: развивать зрелость команд и минимизировать количество запросов, требующих прямого участия деливери‑менеджера.

Ключевые шаги трансформации

Чёткое распределение зон ответственности

Прописали границы между тимлидом, деливери‑менеджером и продакт менеджером. В результате команда поняла, в каких ситуациях может принимать решения самостоятельно, а когда нужно привлекать менеджера.

Командам предоставили возможность выбрать формат и регулярность проведения ежедневных стендапов и ретроспективы. Некоторые команды с энтузиазмом взяли эти задачи на себя и успешно проводят встречи без участия деливери‑менеджера.

Передача ответственности за результаты

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

Сохранение и развитие проверенных инструментов

Мы не отказались от ранее внедрённых механизмов, а адаптировали их под новый подход. Например:

• система дежурств для оперативного устранения критических багов;

• автоматизированные оповещения о проблемах;

• шаблоны для быстрого описания типовых задач.

Может показаться, что мы просто «отдали задачи» и освободили своё время. На деле перераспределили фокус: вместо рутинного контроля сосредоточились на:

• оптимизации процессов в масштабах всех команд;

• выстраивании кросс‑командного взаимодействия;

• стратегическом планировании.

Это особенно важно, ведь ни одна фича больше не реализуется в рамках одной команды — требуется слаженная работа разных команд и отделов.

Что изменилось? Какой результат?

Измерили внутреннее ощущение команды и внешнюю оценку пользы работы деливери-менеджеров спустя год после начала изменений. 

Внутреннее ощущение команды изменилось в лучшую сторону почти по всем пунктам:

Но и замер внешней обратной связи принес просто фантастическую картину:

Мы выросли буквально по всем параметрам. Нас оценили выше чем год назад в среднем на 1 балл.

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

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

Что не получилось

Также в опросе были вопросы, на которые стоит ответить в свободной форме. Там нам от души «напихали в панамку». Но мы за это благодарны коллегам, именно благодаря обратной связи мы и растем, усиливаем сильные стороны и прикрываем слабые. 

Например, нам подсветили, что нужно:

• быстрее предлагать и внедрять изменения в процессах;

• активнее развивать самостоятельность лидов через делегирование;

• повысить качество описания задач.

Анализ цифровых ответов тоже дал пищу для размышлений. Я отметила очень много низких оценок в ответ на вопрос: «Насколько вам понятно, за что отвечает деливери‑менеджер?» Буквально половина опрошенных не представляют, кто это такой.

Эта ситуация, возможно, объясняется несколькими причинами:

• Недавно мы переименовались: раньше наша роль называлась «проджект‑менеджер», а теперь — «деливери‑менеджер». Это изменение могло сбить с толку.

• Для части сотрудников, вероятно, не так важно, какие конкретно задачи выполняет деливери‑менеджер. Им главное, чтобы работа была, а зарплата выплачивалась вовремя.

Шаги здесь очевидны: будем работать над узнаваемостью роли «деливери‑менеджер» в нашей компании. Возможно, создадим наглядные материалы, например, слайды или стикеры,  которые помогут объяснить роль и функции деливери‑менеджера, его цели и задачи, с какими вопросами стоит к нему обращаться.

Ещё один момент, который надо отметить. Мы спросили коллег: «Насколько у наших деливери-менеджеров единый стиль и подход?» — и получили почти классическое гауссово распределение: большинство ставит 3 из 5.

Получается, что все мы совпадаем по ценностям и целям, но вот с единым подходом не всё так гладко. Кто‑то делает так, кто‑то иначе, и общего шаблона нет.

И тут я, как тимлид, задумалась: а надо ли нам это единство? Превращать всех в «универсальных солдат» с одинаковым подходом или оставить как есть? Может, именно эта разница и есть наша сила? Вдруг благодаря разным стилям мы лучше закрываем разные задачи?

Честно говоря, сейчас я склоняюсь к тому, чтобы ничего специально не менять. Но очень хочу услышать ваше мнение! Коллеги, давайте обсудим в комментариях, как вы считаете, нужен ли единый стиль работы для деливери‑менеджеров?

Выводы и рекомендации

Если вы столкнулись с похожей ситуацией, начните с постановки цели: определите ваши ценности и поймите, зачем ваша роль нужна бизнесу — какую задачу вы решаете.

Часто этот этап игнорируют, полагая, что всё и так очевидно. Но проведите небольшой опрос: задайте за чашкой кофе двум‑трём коллегам вопрос: «В чём наша ценность?» — и вы, скорее всего, услышите разные ответы. Именно с унификации понимания и стоит начать: зафиксируйте ключевые положения и донесите их до всех.

Не стоит сразу бросаться в бой: решать конкретные задачи, стараться присутствовать на всех созвонах и включаться в каждый процесс. Наоборот, уделите время делегированию — это освободит время для осмысления процессов внедрения чего‑то нового, создания документов, описывающих процессы.

Оперативное решение каждой конкретной задачи и коммуникация по ней с разработчиками — как раз то, что можно делегировать тимлидам или самим разработчикам.

Конечно, это будет непросто — в первую очередь для тех, на кого вы передадите обязанности. Взращивая самостоятельность команды, вы неизбежно столкнётесь с сопротивлением. Но это нормальный процесс, он требует времени. Постепенно, шаг за шагом, эти сложности можно преодолеть.

А мы, в свою очередь, продолжим фокусироваться на осмыслении глобальных процессов, поиске «бутылочных горлышек», улучшении нашего рабочего потока — в текущих условиях, с имеющимся составом и ресурсами.

С верой в мою команду, с уверенностью, что у нас всё получится, и с желанием создавать суперское приложение для наших покупателей,

Анастасия Дианова,

Lead Delivery Manager «Группы»