Деливери менеджер кто это

Описание профессии Деливери менеджер

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

Не стоит сравнивать с такими профессиями, как Service Delivery Manager, Scrum Master или Agile Coach — даже по-отдельности они не характеризуют роль Delivery Manager.

Зачем нужен

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

Что делает

Задачи Деливери менеджера делятся на две группы: управление изменениями и масштабируемость практик.

Управление изменениями
Масштабируемость практик

Как делает

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

Владелец Продукта "Производственный процесс" работает с доставкой продукта от идеи до получения продукта пользователем, выстраивает горизонтальные и вертикальные партнерские связи между всеми участниками создания ценности. Он визуализирует процессы, чтобы они были понятными и управляемыми, а еще работает над улучшением метрик Discovery и Delivery и формирует прозрачную стратегию планов развития производственных процессов с учетом целей компании.

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

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

«У меня есть шутка, что на любой вопрос в сфере менеджмента есть единственный правильный ответ: «It depends!». Кто такой Delivery Manager: обзор профессии от Христи Слободян

Продолжаем цикл материалов об ИТ-специальностях. Каждую описывает «типичный представитель» — опытный специалист и просто авторитетный коллега, тот же человек, который знает все тайные уголки своей профессии. Мы надеемся, эти материалы помогут школьникам, студентам, переквалификантам, студентам и всем, кто заинтересован в выборе ИТ-специальности. Цикл не только поможет оценить перспективы, но и позволит лучше понять индустрию и особенности профессии изнутри. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его полезнее.

Сегодня своим опытом делится Христя Слободян, Delivery manager в Capgemini Engineering.

Как я стала Delivery manager

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

Теперь у меня более 15 лет опыта на разных менеджерских должностях, три из них я работаю в Capgemini Engineering (ранее — Lohika).

Delivery manager — только одно из имен, которое я примеряла за это время. Остальные должности назывались Project manager, Program manager, Resources manager, Scrum master. Было и что-то поближе к Product management — во время декретного отпуска я занималась мобильными играми для детей.

В последних двух компаниях моя должность — Delivery manager.

Я имела дело и с большими проектами (крупнейший — на 180 инженеров), и с совсем маленькими (от нескольких разработчиков). Это была классическая разработка или поддержка существующих продуктов, предоставление определенных сервисов. Был у меня отдел сисадминов, были R&D инициативы. А еще очень разные клиенты — из Европы, США, Канады. Как стартапы, так и крупные организации. Надо признать, что с разнообразием менеджерских задач мне тоже очень повезло.

Почему менеджмент

Менеджершей я стала не потому, что мне не нравилось тестировать, а потому, что на тот момент был запрос в людях, умеющих организовывать. А я, как оказалось, имела до этого задатки. В ИТ, если человек на своем месте работает хорошо, он растет. К примеру, откуда в нашей компании берутся Delivery manager? Преимущественно это люди, которые выходят из Team Lead, из технических специалистов, которые были такими хорошими инженерами, которые могли помогать другим быть хорошими инженерами. Благодаря этому становились Team Lead-ами — совмещали техническую работу и организационную. А потом получали еще больше ответственности и переходили в менеджмент.

Если честно, то в 2000-х, в начале моей карьеры, я имела амбиции развиваться в техническом направлении. Помню, хотела попробовать себя в роли Java разработчика.

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

Кто такой Delivery manager

«У меня есть шутка, что на любой вопрос в сфере менеджмента есть один единственно верный ответ: «It depends!». Так же и с тем, кто таковой Delivery manager. Если абстрактно, самая большая боль и цель этого человека — delivery. Что значит, убеждаться, что команда успешно выполняет цели, которые ставит клиент, деливерит определенную ценность в виде продуктов, релизов, сервисов. А конкретные детали уже зависят от контекста.

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

Помню, как я объясняла, кто такой Delivery manager, новому клиенту, используя метафору «zoom in/zoom out». Как DM, я могу удаляться (zoom out) и оперировать очень поверхностно, присматривать за процессом издалека, фактически, не мешать команде, которая и так умеет работать самоорганизованно.

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

Какие функции Delivery manager

Возьмем в качестве примера одного из моих актуальных клиентов. Это довольно крупная организация, с определенными целями в квартал, дедлайнами, иногда fixed price задачами. Здесь важны элементы проектного менеджмента: построить квартальный план разработки (роадмапа), произвести оценку усилий, сосчитать бюджет. А еще отчитываться, планировать спринты, налаживать сотрудничество с другими командами, вендорами. Девелоперы работают в agile командах, а я помогаю с общей координацией работы.

Фактически моя команда помощников на каждом проекте — это технические руководители разных направлений: Team Lead/Tech Lead, Архитектор, QA/AQA Lead.

Но точечно с инженерами тоже пересекаюсь. В нашей компании Delivery manager также вовлечены в performance evaluation процесс, построение планов развития инженеров, предоставление обратной связи. Во времена активного роста компании моя работа также включает в себя подбор новых людей на проект, собеседования с кандидатами, работу с пропоузалами для потенциальных клиентов и т. д.

В моей неделе есть регулярные звонки с клиентами и моими Team Lead-ами (раз или дважды в неделю), есть стендапы команд, на которые я тоже избирательно хожу, есть церемонии в соответствии с agile подходом — планированием, ретростпективой и т. д. В зависимости от того, на каком этапе квартала мы находимся, есть дополнительные активности. Если приближается планирование, это разговоры на тему приоритетов, зависимостей, проработки проблем. Середина квартала — можно сместить фокус, например, на технические улучшения, которые клиент нас не просит делать, но у них есть потребность или оптимизация определенного процесса.

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

Какая ценность работы Delivery manager

По-моему, необходимость этой должности определяется уровнем зрелости команды разработки и уровнем зрелости клиента. Если команда научена работать в Agile, Scrum, SAFe, эти подходы уже дают ответы на многие вопросы, а в центре этих парадигм — самоорганизованная зрелая команда. Но бывает, что на стороне клиента происходит хаос. Тогда, чтобы не мешать команде работать, Delivery manager пытается построить процесс, натренировать клиента, убедиться, что на стороне клиента есть правильные роли. К примеру, Product owner. Ведь если нет человека, четко объясняющего запрос, то даже самая лучшая команда не совершит чудо, будет разочарование и разные ожидания.

Здесь менеджер выступает неким переводчиком, ментором, человеком, который внимательно слушает, замечает, что не работает, и налаживает процессы. А потом, когда первая фаза этой отладки пройдена, проект встал на рельсы, Delivery manager может немного отойти. Менеджер должен стремиться к тому, чтобы система была саморегулируемой, люди росли, могли справляться без него.

Какие навыки необходимы Delivery manager

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

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

Delivery manager community

Для менеджера важна широта восприятия, осознание того, насколько разнообразны могут быть ситуации, с которыми мы сталкиваемся. И умение к ним приспосабливаться. Поэтому классно, что у нас у компании есть Delivery managers community.

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

У нас есть вещи, которые в этом плане драйвит компания, например, специальные интроспективы, где коллеги представляют свои кейсы, чтобы дополнить ими портфолио компании. Но в какой-то момент я почувствовала, что нужно еще что-нибудь. Место, где можно было бы откровенно делиться, через что мы проходим как менеджеры, в каких моментах бывает сложно, и как, наконец, удается с этим справиться. У меня была потребность видеть, что происходит в компании шире, не в рамках моих проектов, а в рамках целой организации (только в Украине у нас около 1300 человек, не говоря уже о других центрах разработки по миру).

Для того чтобы такое сообщество родилось, нужно хотя бы несколько человек, которые загорятся этой идеей. В нашем случае это были: я, Михаил Дяченко и Иванна Мельник, мои коллеги из Одессы. Я затронула тему, что нам было бы хорошо иметь экосистему, где мы можем делиться всем. Неважно, это что-то формальное (типа примеров шаблонов для заполнения, когда стартует новый проект), или неформальное (скажем, «Не могу найти такого специалиста, может ли кто-то одолжить на две недели?»). Так мы создали Delivery managers community. Это неформальное объединение Delivery manager-ов компании, которое со временем привлекало также руководителей из других подразделений, не только инжиниринга.

Мы придумали несколько рубрик, в рамках которых организовываем встречи. К примеру, в DM Guests мы приглашаем людей из соседних отделов компании, где они рассказывают, чем занимаются; DM Hot topics — это обсуждение актуальных тем (типа, как мотивировать людей во время войны; как работать в условиях реорганизации в компании; или, скажем, о нашумевшем Chat GPT и чем он может быть нам полезен). DM Stories — это рубрика, где менеджеры рассказывают о своем карьерном пути, о вещах, которые им важны в работе, короче ближе знакомятся между собой. И еще есть обучающие активности, DM Learning. В организации комьюнити задействован «оргкомитет», время от времени возобновляемый добровольцами (сейчас нас в нем 5-7 активных участников), мы планируем встречи на несколько недель вперед.

У меня есть ощущение, что наше сообщество сыграло немаловажную роль и во времена COVID-пандемии, и в начале полномасштабной войны. Все были в некоторой степени растеряны, но у нас была дополнительная площадка, чтобы созвониться и просто поговорить: «Как вы?», «С чем сталкиваетесь?», «Как справляетесь?». От менеджера ожидают стойкости, что он будет собирать и держать в тонусе свою команду, но менеджер — это человек, которому тоже нужна поддержка. Имея сообщество людей одного уровня, можно поделиться, чувствовать себя комфортно, позволить себе признаться, что страшно, что морально трудно где-то. На самом деле наша комьюнити расшевелила значительно большую аудиторию, потому что в наш general чат впоследствии пришли и все Engineering managers, и директора, и руководители других отделов.

Как стать Delivery Manager?

Если я, например, Team Lead, и нацеливаюсь на позицию Delivery, скорее всего, мне будет не хватать как раз хард скилов проектного менеджмента. То, что покрывает Project Management Body of Knowledge, — это книга, почти как энциклопедия от Project Management Institute, о разных фазах происходящего там проекта. Это классика, которую обычно проходят все менеджеры. Также Agile, Scrum, Kanban и все, что с ними связано. Если кстати, то SAFe, LeSS или другая методология масштабирования Agile.

На практике Team Lead должен сообщить своему руководителю, куда бы он хотел двигаться. Тогда руководитель немного приоткрывает для него занавес происходящего на этом посту, создает дополнительные возможности получить необходимый опыт. У нас, в Capgemini, мы даем возможность пробовать все на практике — либо делать больше на своем проекте, либо параллельным вовлечением в какие-то pre-sale активности или внутренние проекты компании. В таком случае и человек, и руководитель видят, готов ли он сменить роль или нет.

Также у Сapgemini Engineering есть возможность, пройти дружеское собеседование с действующими Delivery или Engineering managers. У них есть чеклист soft и hard навыков управленца. Так тоже можно обнаружить, готов ли ты к позиции с точки зрения знаний, имеешь ли какие-то пробелы. Тогда коллеги могут посоветовать, как их подтянуть: курсы, книги или новые практики, которые следовало бы ввести на текущем проекте. На мой взгляд, самый легкий способ запустить свой рост — это заручиться поддержкой ментора, руководителя или более опытного коллеги. Расспрашивать и смотреть, как все происходит.

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

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

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

«Спрос на DM уже огромный, но в будущем он будет еще больше. Когда большинство компаний на рынке поймут, что подобные гибридные навыки очень полезны, то запрос на DM значительно возрастет. «. О роли Delivery manager в компании и своем пути от инженера до Director of Delivery Management рассказал наш коллега Дмитрий Разоренов.

Я начинал с позиции инженера, но достаточно скоро мне пришлось руководить командой. Заказчик был своего рода стартапом: распределения ролей почти не было, но надо было совмещать управление, архитектуру и разработку. Со временем команда стала заниматься крупной продуктовой разработкой для авиалиний. С ней я сотрудничаю уже больше 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 решает классическую проблему человека, который вчера писал код, и ему это по-прежнему нравится, и управленца, у которого еще не все получается, но он растет в этом направлении. Это ответ на вопрос: «Мне технологии забыть и идти в менеджмент или бросить лидерство и писать код?»

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

Delivery Manager — новая роль в мире Agile

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

Зачем нужен Delivery Manager

Марти Каган (Marty Cagan) заметил тенденцию в США от Менеджера Проекта (Project Manager, кратко — PM) к Delivery Manager. Марти нравится этот тренд и новая роль по трем причинам:

“”бренд” проектного менеджера настолько поврежден, что может потребоваться ребрендинг”.
“есть вопрос о цели — завершить продукт. Задача не в исследовании, не в обучении процессам; цель исключительно в выпуске.”
Delivery Manager несет ответственность за сортировку и приоритезацию проблем продукта, тем самым освобождая Владельца Продукта.

Тем не менее, я назвал Рича Delivery Manager, не потому что мне не нравится термин “менеджер проектов”. Я не вижу особого конфликта между проектными менеджерами и Agile в целом/Agile-ролями. Также я не вижу особого смысла в ребрендинге менеджеров проектов. Я просто хочу показать людям в чем смысл Delivery Manager.

Чем занимается Delivery Manager

Если загуглить “Delivery Manager”, не стоит надеяться на много результатов. (На момент написания этой статьи в 2015 году.) Одним из первых будет материал британского Government Digital Service (GDS). В нем много интересного. Например, Марк Стэнли (Mark Stanley) описывает День из жизни Delivery Manager в GDS. Он пишет:

Delivery Manager защищает время команды, чтобы обеспечить непрерывную производительность. Время команды — драгоценное время.

В GDS также есть описание роли Delivery Manager. Основные обязанности в этой роли следующие:

Выпускать проекты и продукты, использовать подходящую agile-методологию, постоянно учиться и улучшать процессы.
Совместно с менеджером продукта разрабатывать дорожную карту и переводить ее в пользовательские истории.
Руководить коллективным, динамическим процессом планирования — основной акцент стоит на работе, которую необходимо выполнить, в условиях ограничения мощностей и возможностей команды.
Матричное управление мультидисциплинарной командой.
Убедиться в качестве продукта на всех стадиях (альфа/бета/продакшн).
Активно участвовать в сообществе Delivery Manager, делиться и находить области применения для навыков и знаний, внедрять передовые практики.

Programme Manager и Delivery Manager

У меня была определенная потребность, когда я пригласил Рича на роль Delivery Manager. Суть в следующем:

У меня было три команды разработки, которые работали в одной большой комнате — всего около 35 человек.
Мне был нужен один процесс и одна Kanban доска для всей команды.
Я присутствовал только четыре дня в неделю, один из них удаленно.

Мои отношения с Ричем можно сравнить с отношениями Главного Исполнительного Директора (Chief Executive Officer, кратко — CEO) и Главного Операционного Директора (Chief Operating Officer, кратко — COO). Как CEO, я был внешним лицом команды. Во время удаленной работы я обсуждал с удаленными старшими стейкхолдерами стратегию, чтобы убедиться в досягаемости компенсаций, адекватности приоритетов. Как COO, работа Рича была направлена внутрь команды. Он помогал ей двигаться дальше. Я проверял корректность направления. Вместе мы делали владельцев продукта счастливыми.

Как всегда ждём ваши вопросы и комментарии, которые можно оставить тут или написать их напрямую Марине на открытом уроке.