×

Delivery Manager: кто он, что делает и как им стать

Я начинал с позиции инженера, но достаточно скоро мне пришлось руководить командой. Заказчик был своего рода стартапом: распределения ролей почти не было, но надо было совмещать управление, архитектуру и разработку. Со временем команда стала заниматься крупной продуктовой разработкой для авиалиний. С ней я сотрудничаю уже больше 10 лет. А «стартап» за это время подрос до 300+ человек и сейчас автоматизирует огромное количество авиалиний, вроде JetBlue, AirСhina и других крупных игроков.

За 14 лет в EPAM мой карьерный путь выглядел так: рядовой инженер, инженер-управленец, Solution Architect (хотя тогда этой должности еще не было), Engineering Manager, Director. Невзирая на названия должностей, суть работы не менялась: я быстро схватывал то, как работают разные системы и как они могли бы интегрироваться в общее решение; рисовал на досках схемы того, как тот или иной solution landscape ложится на бизнес-проблематику; всегда был на стыке коммуникаций заказчика и команды.

Я до сих пор немного программирую на уровне D-1, но настоящее удовольствие получаю от работы с группой людей, которые хотят сделать продукт. Мне важен результат. Позднее я выяснил, что прошел классический путь Delivery Manager. Так, с приставкой Director уже три года звучит моя должность.

Как появилась позиция

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

Мы начали анализировать, есть ли в компании люди, которые способны рассуждать на таком уровне и хотят развиваться в delivery-направлении. Изначально мы искали менеджеров, которые держат руку на пульсе технических вопросов. Просмотрев множество людей, которые были близки к этой роли, мы выделили следующую формулу:

Delivery Manager (DM) — сотрудник с хорошими лидерскими и бизнес-навыками, специализация которого граничит с архитектором с одной стороны и Program Manager с другой.

Именно такое определение мы оформили в качестве позиции в компании и уже три года внедряем ее в работу.

В интернете по-прежнему можно мало что найти о Delivery Manager — института профессии не существует. Такой подход пришел из организаций, у которых давно есть позиция Service Delivery Manager (SDM). Но это понятие отличается от Delivery Manager. Сервис — повторяемая вещь. К примеру, PayPal — сервис, который обеспечивает проведение платежей миллионы раз в день, и человек, отвечающий за его работу, — Service Delivery Manager. Если взять компании вроде EPAM в широком смысле, то они занимаются бизнесом по разработке IT-решений. Но сами решения обычно имеют продуктовый характер и уникальность. Поэтому позиции SDM и DM пересекаются лишь незначительно.

Когда есть команда, способная реализовывать проект, технический бэкграунд (когда вы знаете, что это точно можно сделать), начинается процесс создания решения. При этом важен не процесс, не организация, а конечный результат — продукт. И управление delivery — как раз и есть управление для достижения результата.

Роль в проекте

Роль и распределение обязанностей Delivery Manager зависит от стадии проекта.

Сначала DM ждет много разговоров о проблемах заказчика и о том, как их решить. Это ближе к бизнес-требованиям, продакт-менеджменту и архитектуре решений.

Затем включается классический program- или product-менеджер (зависит от объема работы), который обсчитывает: риски, расписание всего проекта, потребность в специалистах, подход, в котором они будут работать, детали реализации систем, внедрение.

Когда проект уже в процессе разработки, DM каждый день работает с вопросами: «Что сегодня критично сделать? Какие есть риски и проблемы, которые ставят delivery под угрозу? Какие есть возможности для успеха и что для них нужно сделать сейчас?» Основанный на анализе рисков подход позволяет заблаговременно заметить проблему и решать ее так, чтобы она как можно меньше повлияла на сроки delivery.

Есть определенный набор вещей, за которыми DM должен следить постоянно:

  • Знаем ли мы, что надо сделать?
  • Делаем ли мы правильные вещи?
  • Делаем ли правильные вещи первыми?
  • Делаем ли мы эти вещи правильно?

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

Delivery Manager контролирует проделанную работу и убеждается, что она приближает команду к цели.

Большая часть обязанностей DM — общение и решение проблем разных уровней. В этом аспекте Delivery Manager отличается от Program Manager тем, что если задача касается технологий, он хорошо понимает, в какой момент потребуется консультация со стороны. Как любой инженер он знает, что в шинах могут не доходить сообщения; в базе стоит искать риски в конкурентных записях; IoT устройству часто не хватает памяти.

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

Если что-то пошло не так

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

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

  • Почему возникла проблема?
  • Насколько критично она влияет на проект?
  • Какая форма обязательств с клиентом, что предполагает контракт?
  • Как, собственно, ее можно решить?

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

Главные инструменты менеджера — мозг и речевой аппарат (именно в такой последовательности). Главный навык руководителя — искусство убеждения. Его эффективность зависит от того, насколько интеллектуально происходит убеждение и насколько человек понимает суть разговора.

Самый большой вызов Delivery Manager — как все сделать, получая разные объемы информации из «разных миров»? Как обеспечить решение классического конфликта между клиентом и компанией, компанией и сотрудником, сотрудником и клиентом? Как жить в этом треугольнике, при этом добавляя четвертое измерение — реализацию качественного продукта?

Как стать Delivery Manager

Наиболее простой эволюционный путь для специалиста, который в итоге займет позицию Delivery Manager, выглядит так.

Разработчик, назовем его Игорь, работает с одной технологией и как лидер собирает группу ребят. Эта команда делает определенную часть проекта. Если их работа ограничивается одним компонентом или частью системы, то хоть delivery в микрообъеме и происходит, речь не идет о конечном решении. О начальном уровне DM можно говорить, когда происходит переход от компонента к общей сущности, которая для бизнеса выполняет новую функцию или сервис.

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

Когда Игорь провел команду через весь проект до конечного результата, у него естественным образом «прорастают» необходимые для DM компетенции. Он понимает, как организовывать архитектуру от пользователя до уровня хранения данных и построить процессы в команде, потому что он проделал это своими руками.

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

Похожий путь Игорь может пройти, начав с роли QA или аналитика. Если он стал лидером команды, и благодаря взаимодействию с ней разберется во всех системах, подходах и архитектуре, то он тоже может превратиться в DM.

Развенчаю слухи о том, что PM и другие нетехнические специалисты не могут стать Delivery Manager — для этого нет никаких преград. Нужно стечение обстоятельств, чтобы попасть на проекты и стать их лидером.

Путь с начала работы на проекте до позиции DM может занять два-три года. Чтобы пройти его так быстро, нужны:

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

Лучшая среда для роста — если у вас будет наставник с большим опытом, который будет выполнять роль «первого пилота».

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

Что учить

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

В сети есть огромное количество теоретических материалов и курсов. Попрактиковаться в архитектуре сложнее. Можно поучаствовать в существующем проекте или самостоятельно развивать opensource-проект. В этом случае комьюнити наверняка придет на помощь.

Чтобы улучшить навыки в сфере управления проектами, помимо знания гибких методологий, которые набрали популярности, стоит не забывать «матчасть». Нет ничего лучше терминологии PMBook, и, возможно, стоит даже получить PMP-сертификат. Это не обязательная, но достаточно интересная и сложная задача. В рамках ее прохождения придется познакомиться с вещами, о которых даже не думаешь при работе «в полях», вроде просчета финансовых рисков или индексов выполнения сроков/стоимости.

Для улучшения коммуникативных навыков есть специализированные тренинги, вроде управленческих поединков Владимира Тарасова. Если говорить про классический менеджмент как дисциплину (что можно делегировать, leadership vs management и прочее), то можно начать с виртуальных курсов и участия в жизни комьюнити agile- и проектных менеджеров. Их полно на просторах сети.

Когда базовые знания получены, возникает главный вопрос — практика. Если в текущей компании нет подходящих условий, нужно либо создавать свой проект, либо участвовать в open-source. Можно собрать из друзей небольшую команду и сделать первое маленькое delivery. А вдруг еще и взлетит? За практикой на крупных и сложных проектах лучше идти в большие компании. В таких случаях самообразования, как и тренажера будущему пилоту A380, — не хватит.

Рынок Delivery Management в Украине и СНГ

Как профессия, Delivery Management, делает только первые шаги. Пока рекламы курсов подготовки DM нет в метро, говорить о ее зрелости рано.

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

Уже есть люди, которые воспринимают Delivery Management как хайп и начинают судорожно искать возможности стать его частью. Но формирование такой тенденции тоже занимает время, и даже таких людей на рынке немного.

Предложение не поспевает за рынком, но нужно понимать, что многие сотрудники уже давно выполняют роль Delivery Manager. Просто формально она никогда не была описана. Такие специалисты попадают в ситуации, когда им предлагают ставку вдвое выше привычной, и недоумевают. Им тоже требуется осознание ситуации.

Еще один источник развития DM — растущие количество продуктовых стартапов в нашем регионе. Их CTO, VP of Engineering обладают всеми качествами DM. Если их продукт успешен, то, очевидно, идти на позицию Delivery Manager в крупные сервисные компании они не захотят. Но в отличие от разработки одного продукта, здесь им могут предложить вариативность и возможность пробовать себя в работе с разными и сложными клиентами.

Путь в Delivery Management решает классическую проблему человека, который вчера писал код, и ему это по-прежнему нравится, и управленца, у которого еще не все получается, но он растет в этом направлении. Это ответ на вопрос: «Мне технологии забыть и идти в менеджмент или бросить лидерство и писать код?»

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному11
LinkedIn

Схожі статті




26 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо за статью!

Мне кажется, что ответ на вопрос в чем отличие от технического ПМа, кроется не в «как появилась эта роль», а в «зачем появилась эта роль».

В моем понимании, ДМ отличается от технического ПМ тем, что помимо стандартного набора задач ведения проекта, лидерства команды, управления ожиданиями клиента итд., он еще в состоянии развивать текущие аккаунты, делая апсейл и успешно участвуя в продаже новых комплексных решений «под ключ» (тот самый консалтинг, в который все хотят). И, разумеется, это гораздо проще делать, имея технический бэкграунд, чем не имея его.

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

В NetCracker, например, на проектах есть и Project Manager, и Technical Manager.

PM занимается тем, что завещал ему PMBook — риски, долгосрочное планирование, стаффинг, административка, общение с руководством заказчика.

TM занимается архитектурой и деливери солюшена, управлением командами девелоперов, тестеров и аналиков, общается с ответственными (и/или техническими) представителями заказчика и отвечает за краткосрочные планы до ближайшего майлстоуна.

Такое разделение позволяет «техническим» людям оставаться близко к девелопменту и качать leadership & management скиллы, не распыляясь еще и на PMские активности, для выполнения которых programming background не обязателен и роль ПМа могут выполнять люди, пришедшие из QA, BA и т.п.

Но чем больше пилоты летают, тем меньше они нервничают, когда три из четырех двигателей отказывают

Еще как нервничают...

у него естественным образом «прорастают» необходимые для DM компетенции.

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

Спасибо за статью! Ищем Delivery Manager очень вот с таким вот dev бекграундом :)

Хорошая статья, спасибо!
Я бы еще уточнил, что это специфика роли именно в EPAM, так как во многих других компаниях Delivery Manager далеко не всегда имеет технический бекграунд и часто — это просто обычный РМ в новой упаковке :)

Ага, пм тот же — митинги другие))

похоже на то, что Delivery Manager — это просто тот случай, когда менеджером проекта стал не управленец, а технарь)) Что тот занимается командой, проектом и проблемами, что тот, да только уровни осознания происходящего в команде/индустрии разные.

Компетентный впариватель

Полностью согласен — не вижу разницы между PM с tech bg и Delivery Manager :)

В самом определении подчеркиваются лидерские и бизнес-навыки и держится интрига про технологические навыки.

Хотелось бы понять в чем же разница между Tech PM & DM. Можно получить такой ответ?

Ближе всего DM и Tech PM в середине карьеры. там сходство просто _очень_ сильное (особенно взяв Amazon-style определения TPMов), но...

Три отличия, почему мы не выбрали это имя для EPAM.

0. Начальный уровень DM — это Multi(hybrid)-Skilled Team Leader. Все же это не Tech PM. и нам хотелось сделать разницу.

1. Для Senior DM и далее мы хотели заложить больше продуктового менеджмента (выбирать правильные вещи первыми, делать эффективно) и дать развитие карьеры в направления индустрии или практики как enterprise architect, что чуть различается от «классического» (тоже на-тоненького) определения TPM (Technical Project/Program Manager)

2. Мы IT компания. У нас все в той или иной степени Technical PM :) Различие было в сути вопросов, на который отвечают люди носящие той или иной тайтл. Помимо общих вопросов менеджера «Что?», «Когда?» (и да, технический PM быстрее найдет ответ на первые два), + «Сколько?». DM-а же мы просим ответить на дополнительный вопрос «Как» — т.е. уклон в способности управлять решениями «под ключ» и уметь копать в детали.

+ one more thing, может это и главное

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

p.s. опережая вопрос — «а чем отличается это от Product Manager и Solution Architect» :) но тут вроде понятно — Prd.M отвечает за стратегию и успех платформы на рынке но не факт что сам управляет процессом созидания. Архитектор еще менее вероятно, что управляет.

Надеюсь, ответил.

О как, оказывается я ближе всего к DM’ам по украинским классификациям. Не знаю про Амазон, но в Гугле TPM часто имеет и внешние функции, работая с партнерами, часто бывают и продуктовые функции.

Из этого поста выглядит так, как будто просто заморочились на новую лычку. Проще было взять готовую и на нее сделать необходимые вам R&R. А так рынок до ума никогда не дойдет — engineering manager, project manager, delivery manager, release manager, release engineer, tech project manager, agile project manager — и в каждой компании вкладывают в каждый тайтл абсолютно авторский смысл. А потом подавай «2+ years of agile release manager» и бедные эйчары просят написать сопроводительное письмо, где ты бы оправдался за то, что именно с таким тайтлом никогда не работал (реальный кейс).

туди ж можна додати і Product owner

То есть DM — это вроде Solution Architect, но с бОльшими полномочиями в управлении процессом созидания? Если на проекте есть и тот, и другой (и нет БА), то как распределяются обязанности именно по техническому проектированию, кто переводит бизнес-задачу на язык технарей? Особенно интересно, кто определяет (решает, окончательно выбирает между вариантами) каким приложению быть по архитектуре?

Обычно никто из них не участвует в технической части, обычно максимум это PoC от солюшен архитектора до старта проекта, а после старта у них обоих только менеджерские активности

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

Апликейшен архитектор участвует частично, солюшен обычно нет

Спасибо, очень интересная статья. Подробно описано видение развития и роли деливери менеджера в вашей компании. А есть ли риски такого пути развития деливери, когда на стыке миров лидер старается остаться экспертом в этих параллельных мирах одновременно, и есть ли способы защититься от ошибки выжившего при выборе такого направления?

Риск «Jack of all trades....» явный, чего таить.
Советы такие:
1) выбрать какой-то индустриальный домен и достаточно долгое время (ибо менять можно и нужно) «дышать» технологиями этого домена. Фокус-фактор выше, момент — сильнее.
2) или выбрать некую область технологии (мы называем это практикой), например, data solutions — которые деливерить на множество клиентов.

Знание техники морфирует от уровня к уровню: от деталей кода на первых уровнях, до понимания, какие задачи бизнеса решает те или иные системы и какие риски на масштабирование и поддержку они приносят — считайте, Enterprise Architect.

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

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

В таком случае, роль деливери менеджера в перспективе и на достаточно сложных проектах сводится к роли супер-техлида с выраженной клиентоориентированностью, другими софт скилами и знанием домена, правильно? Он будет решать поставленные задачи успешно, но потребуется еще как-то генерировать постановку задач? Кто в такой системе сможет генерировать задачи/проблемы?

верно. Задачи генерит бизнес или рынок (например, ритэйлы сейчас срочно переходят в digital). А вот как решить эту задачу — это уже команда решает во главе с DMом, да

Підписатись на коментарі