что такое деливери менеджер
Роль Service Delivery Manager (SDM) в Канбан-методе: как нанимать SDM
Меня часто спрашивают о роли Service Delivery Manager (SDM) в Канбан. Кто должен играть эту роль? Как можно ввести эту роль в организации? Где найти правильных людей на эту роль?
Для понимания, SDM – термин, который мы используем в Канбан-методе для общего обозначения широкого круга менеджеров, отвечающих за некие сервисы, производственные линии или проекты. В круг ответственности SDM входит управление и улучшение сервиса с точки зрения удовлетворенности его клиентов.
Существует большое количество профессиональных сервисов во многих компаниях и отраслях. Вследствие чего под ролью SDM понимаются совершенно разные виды и объемы работ, что проявляется в разнообразных обязанностях, навыках, уровнях иерархии и оплаты труда. Но ответственность SDM за некие сервисы является общей характеристикой во всем многообразии трактовок. Таким образом, сложился паттерн. И мы используем термин SDM, в качестве наименования такого паттерна.
Высоки шансы того, что подходящий на роль SDM человек уже работает в вашей компании. Возможно, вам понадобится признать эту ответственность неформально или в официальной форме, повысить его, изменить название его должности или нанять на эту позицию человека извне. В зависимости от организационной культуры и истории вашей компании эти опции могут проявиться в разных пропорциях.
Далее вы найдете руководство по основным шагам поиска правильных кандидатов на такую роль.
Не существует стандартного профиля вакансии, всегда нужно учитывать специфику работы
Профиль вакансии service delivery manager’а (SDM) будет сильно зависеть от контекста того, что поставляет тот или иной сервис. Рассмотрим на следующих примерах:
Таким образом, большая часть профиля вакансии SDM будет определяться природой самого сервиса. Соответствие специфике сервиса всегда будет являться ключевым условием выбора.
Лидерские навыки
Следующий важный фильтр для подбора – лидер ские навыки. Почему вам нужен SDM? Возможно, потому что вам нужен кто-то, способный взять ответственность за сервис (ML2), сделать его лучше, даже еще лучше (ML3) и поддерживать развитие в таком ключе в течение длительного времени (ML4).
(Что означают эти сокращения ML2, ML3 и ML4? Это маркеры уровней зрелости, используемые в Модели зрелости Канбан (KMM). KMM определяет уровни зрелости таким образом, что организация на каждом уровне могла ответить вызовам бизнес-среды более высокого порядка, чем организации на менее высоких уровнях зрелости. KMM также предлагает дорожную карту повышения текущего уровня зрелости организации. Как это использовать в рамках Канбан-метода? Если коротко, то когда мы проектируем Канбан-систему внутри бизнеса, такая система хорошо покажет уровень зрелости самого бизнеса)
Итак, зрелость лидер ов является ограничивающим фактором организационной зрелости. Вам понадобятся альтруистические качества, чтобы создать коллаборацию на протяжении всего потока работ, достичь единства понимания предназначения (Einheit) и принять ответственные решения в точках обязательств сервиса. Вы не захотите нанимать индивидуалиста первого уровня зрелости (ML1) или трайбалиста (лидера племени) второго уровня зрелости (ML2), чтобы такой кандидат не стал препятствием на пути к зрелости более высокого уровня.
Модель зрелости Канбан как руководство к действию
Модель зрелости Канбан (КММ) предоставляет определенный набор ориентиров и фильтров принятия решений. Далее приведены мои инструкции в очень краткой форме по каждому уровню.
Роль SDM не подходит к ML0 или ML1. Если Вам необходимо провести “цифровую трансформацию” на ML0 или ML1, позаботьтесь о том, чтобы случайно не уволить или принудительно сменить профессиональную идеинтичность тех людей, которые в дальнейшем понадобятся Вам в роли SDM.
Роль SDM появляется со второго уровня зрелости и выше.
Для ML2: SDM должен быть способен брать на себя ответственность за сервис, определить сервис, его входы и выходы в терминах клиента, преодолевать закостенелость оргструктуры, инерцию инструментов командного уровня, относящихся к ML1. Это то, что требуется от кандидата, способен ли он выполнить такую работу? Вы не сможете описать это прямо в профиле вакансии, но вам потребуется определенная тактика проведения собеседования, чтобы выявить степень соответствия кандидата.
Для ML3: обратите внимание на два больших способа проверки. Первый – переговоры по вопросу точки обязательств – насколько хорошо кандидаты общаются с клиентами? Второй – управление рисками и задержками поставки после принятия обязательств. Может ли ваш кандидат справиться с этим?
Для ML4: Вам понадобятся организационные петли обратной связи, соединяющие бизнес-результаты и операционные решения. Что потребует создания некоего социального полотна для донесения информации и некоторой степени математической утонченности. Люди по своей природе склонны только к одной из этих двух способностей. Узнайте, кого вы нанимаете
Мой забег по карьерной лестнице: как я за год прошла путь от ПМа до деливери-менеджера
Всем привет, меня зовут Фарида. Я работаю в компании ЦВТ 4,5 года. Мы разрабатываем IT продукты полного цикла для компаний разных сфер.
Я расскажу про свой путь в ЦВТ от проектного менеджера-стажера до деливери-менеджера. Мой пример покажет, что можно добиться своих целей, если гореть делом и не бояться трудностей.
Еще в школе мне запала в душу IT-сфера, и я решила развиваться в ней. Программировать и тестировать я не любила, а вот писать умела — поэтому решила стать аналитиком. Отучилась в ИжГТУ на факультете прикладной информатики в экономике.
После института пришла устраиваться в ЦВТ. На собеседовании оказалось, что аналитик — это не совсем мое. Я системная, но недостаточно: сидеть и описывать мне было бы скучно. А вот поговорить, найти точку зрения и контакт с клиентом мне легче и интереснее. Мои личные качества больше подходили для проектного менеджера — эту должность мне и предложили.
И уже через 2 недели пригласили на стажировку в ЦВТ.
Первый проект — первые сложные задачи. Это был проект на разработку инвестиционной карты развития Удмуртской Республики. Мы с командой работали над ней 2 месяца, но в последнюю ночь пришли правки — до презентации оставалось 5 часов! Нужно было исправить несколько слайдов.
Благодаря совместным усилиям команды мы справились. И в результате даже получили благодарность от главы Удмуртской Республики Александра Бречалова.
Некоторое время я продолжала работать ПМом на проектах по разработке мобильных приложений и по медицине.
В тот период у меня появилась новая задача — пресейлы. Нужно было найти вместе с сейл-менеджером решение для обозначенной проблемы от бизнеса и упаковать в коммерческое предложение.
Сложностей в работе с пресейлами было несколько:
Было непросто, но этот этап прокачал мои личные качества. Я научилась быстро переключаться между разными задачами. Находить то, что сейчас действительно «болит» у клиента и работать с кризисными ситуациями.
Параллельно с работой ПМ мой руководитель предложил мне должность практис менеджера. Мне нравится пробовать новые роли, ставить перед собой челленджи и преодолевать их, поэтому я согласилась. Теперь в мои задачи входило:
формировать новые практики для руководителей проектов,
отвечать за проекты и качество работы ПМов,
Хотелось структурировать работу компании, которая дает мне новые возможности для самореализации. Раньше не были однозначно закреплены зоны ответственности. Участники команды могли перебрасывать задачи друг другу. Чтобы с этим разобраться, мы начали формировать базу знаний ПМов.
Но реализовать задумку помешал старт нового проекта, в котором я снова взяла на себя роль ПМ.
В новом финансовом проекте клиент решил уйти от старых подходов и полностью перейти на цифровизацию, управлять изменениями через IT-продукты. Для этих целей во втором полугодии 2019 года они искали IT-команду. И вот 25 декабря, перед самым Новым годом, мы с командой едем в Якутск на переговоры.
Тут было сразу несколько непростых ситуаций для меня.
Сложность 1. Одна в мужском коллективе. Я — менеджер проекта, и при этом одна девочка в команде. Было непросто находить общий язык и проявлять лидер ские качества в чисто мужском окружении, но я справилась.
Сложность 2. Клиент ни в какую не хотел работать с проектным менеджером, то есть со мной. Он одобрил архитектора, тестировщика, разработчика. А в мою сторону такой посыл: «Девочка, отойди, не мешай». Меня это не устраивало: куча задач, нужно наладить взаимосвязь клиента с командой, чтобы они работали и выдавали результат. Поэтому я сказала: «Вы можете меня называть как угодно, но я с командой и за команду».
За эту командировку нам удалось выявить все текущие проблемы клиента. Вернувшись домой, мы стали упаковывать их в коммерческие предложения. На работу оставалось 3 часа — необходимо отправить до Нового года. С командой получилось сформировать 3 проекта.
Самое главное мы уже сделали — нам удалось зацепить клиента и показать, что будем ему полезны. Мы подписали контракт.
После праздников мы продолжили работу, но и здесь было не все так гладко.
Сложность 3. Большое количество заинтересованных лиц. Со стороны клиента было много заинтересованных лиц — около 20 человек. Со всеми нужно общаться и стыковать их. За такую синхронизацию обычно отвечает аккаунт-менеджер.
Но работы по клиенту росли, аккаунт-менеджера на все задачи не хватало. Поэтому часть его функций забрала я. Клиенту это было даже удобнее, ведь я параллельно была ПМом и знала, что происходит в проекте.
Вскоре стало понятно, что для работ с такими масштабными клиентами не хватает деливери-менеджера, который отвечал бы перед заказчиком за все производство компании. И следил, чтобы все проекты выполнялись в оговоренные сроки и бюджет. Эти функции уже частично были на мне. Собственно, так я и стала деливери-менеджером.
Сложность 4. Презентовать результаты работы удаленно. В мае из-за пандемии мы не смогли полететь на встречу, чтобы презентовать результаты работы клиенту. Было страшно, что не получится удаленно донести достаточно тяжелые с точки зрения компетенции темы.
Но у нас все получилось. И после презентации клиент принял решение о следующем этапе работ с нами. Вместе выделили 6 приоритетных направлений развития, и 5 из них закрыли к концу финансового года. А сейчас готовим концепцию нового этапа сотрудничества с этим клиентом — уже на несколько лет.
Как итог работы с банком-клиентом — я смогла донести до заказчика свою ценность как специалиста. В начале сотрудничества он считал, что ему даже проектный менеджер не нужен, не то что деливери. А через полгода говорит: «Вот эта девочка точно нужна». Считаю это большой победой, что заказчик захотел работать с тем, кого раньше считал бесполезным.
Когда я стала деливери-менеджером, все начали с еще большим энтузиазмом обращаться ко мне с вопросами. На первых этапах это было достаточно тяжело: 20 человек на стороне клиента, 20 — внутри нашей компании и еще топ-менеджеры. Со всеми нужно коммуницировать, находить общий язык и единую точку зрения. И при этом очень важно выстроить доверительные отношения.
В команде многие ребята не знают о моем существовании, пока у них на проекте не случается кризисной ситуации. Я выступаю для них щитом и принимаю на себя все камни, которые могут полететь в команду. Во многом благодаря опыту работы с пресейлами, у меня получается найти решения их проблемы и разрулить сложные моменты.
Но и команда выступает моей опорой — чувствую от своих ребят силу и драйв. Я бы не смогла вырастить себя как профессионала, если бы компания меня не поддерживала. В любых начинаниях очень важно, чтобы в тебя верили.
Мне нравится работать с интересными сложными проектами, пробовать себя в разных ролях, прокачивать новые навыки. И ЦВТ дает мне такую возможность. Да, расти — непросто, иногда приходится переступать себя. Но я считаю, что роста без боли не бывает.
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 решает классическую проблему человека, который вчера писал код, и ему это по-прежнему нравится, и управленца, у которого еще не все получается, но он растет в этом направлении. Это ответ на вопрос: «Мне технологии забыть и идти в менеджмент или бросить лидер ство и писать код?»
Таких инженеров на стыке двух миров в нашем регионе много. А люди, которые любят создавать, готовы это делать вечно.
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.