Карьера в IT: должность Delivery Manager

Image via Shutterstock.

Этой статьей я продолжу цикл статей «Карьера в ИТ» на ДОУ.

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

При декомпозиции термина «Delivery Manager» мы получаем Delivery и Manager. Если с менеджером всё более-менее понятно (это человек, ставящий задачи, контролирующий их выполнение и обеспечивающий согласованность поставленных задач со стратегией компании) то вот с Delivery не совсем ясно.

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

В зависимости от того, что подразумевается под термином Delivery, получаются две версии Delivery Manager’а (в реальности их гораздо больше, но эти две являются «полюсами», между которыми находится множество).

Версия № 1: «Узкий и глубокий»

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

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

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

Если говорить терминами модели RACI, он — и ответственный, и исполняющий (Accountable/Responsible). Т.е. в большинстве случаев он не делегирует контроль над оценкой и планированием, а лично занимается ими вместе с командой.

Что касается стратегии, Delivery Manager играет две роли:
— Consulted — с ним консультируются касательно возможности и реалестичности изменений в стратегии в части Delivery
— Informed — Account/Project/Programme/Product Manager держат Delivery Manager’а в курсе стратегии и изменений в ней.

На уровне проекта DM’у должны быть даны полномочия на свое усмотрение использовать «и кнут, и пряник» с единственной целью — обеспечить поставку разрабатываемой функциональности заказчику в обещанный срок, в обещанном размере и с оговоренным качеством.

Навыки и умения

Для успешной работы Delivery Manager первого типа должен обладать следующими навыками:
— хороший опыт и понимание процесса разработки, ролей, их взаимодействия;
— умение разрешать человеческие конфликты;
— умение быстро принимать решения;
— умение брать на себя ответственность;
— понимание концепции win-win и желание работать по ней;
— отличные коммуникационные навыки и навык аргументации;
— обладать навыками наставничества и менторинга.

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

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

Карьерный путь

Delivery Manager первого типа занимается тактическими задачами, принимая участие в разработке и имплементации стратегии. Таким специалистом проще всего стать программисту или тестировщику-автоматизатору, прошедшему карьеру: Специалист → Tech Lead → Team Lead → Project Manager (optional).

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

По мере карьерного роста DM первого типа превращается в очень толкового менеджера проекта (или программы) либо Account Manager’а.

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

Версия № 2: «Мелкий и широкий»

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

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

При таком подходе роль Delivery Managerа сводится к интеграции и тому, что по-английски называется governance и orchestration процесса создания решения.

В таком случае Delivery Manager должен обладать 20% знаний и умений каждой из ролей (Dev, QA, Architect, PM, CM etc.), которые дадут ему следующие 80%:
— возможность адекватно оценивать потребность в том или ином специалисте, компенсирующем «мелкость» DMа в конкретной области (например, нанимает PMа, чтобы выстроить процессы в проекте, QM для создания тест-стратегии и т.д.)
— возможность проверять информацию, получаемую от «узких и глубоких» (чтобы не навешали лапши о том, что всё хорошо)
— возможность понимать получаемую информацию и корректно доносить ее до участников процесса.

Основной фокус «мелкого и широкого» Delivery Manager’а — поставка качественного решения, максимально учитывающего потребности заказчика.

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

Навыки и умения

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

Приведу следующий пример, иллюстрирующий потребность в Delivery Manager второго типа:

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

Сейчас подобного рода проект чаще всего выполнялся бы по контракту «Time and Materials» где V предоставил бы менеджера проекта и команду со своей стороны, а менеджер на стороне С осуществлял бы постановку задач. Т.к. почти везде менеджер получает годовой бонус в зависимости от выполненных за год задач, менеджеру С будет выгоднее запланировато то, что можно сделать за год его управления проектом и получить за это бонус. На второй год приходит новый менеджер С, пытающийся сделать то же самое. Та же ситуация повторяется и на третий год.

Вероятность успешного завершения подобного проекта — 60-70%. Причины — Менеджер в начале проекта не уделяет внимания событиям с датой за горизонтом в один год. Поэтому, скорее всего, менеджер С, управляющий проектом на втором году, при смене в январе примерно в мае обнаружит нехватку серверов, требований, планов по интеграции и т.д.

В реальности Time and Materials эта ситуация для V более менее приемлема, т.к. деньги платятся не за результат, а за время и ресурсы. Но стоит V согласиться работать над подобного рода проектом на основе контракта «Fixed Price» — проект обернется катастрофой. Введение роли Delivery Managerа второго типа для V служит элементом снижения рисков т.к. появляется человек, присутсвующий на проекте с самого начала и заинтересованный в его успешном окончании через 3 года.

Выше я привел лишь одну из причин. На самом деле их гораздо больше. Приведенный сценарий довольно типичен для украинского аутсорсинга. И учитывая тенденции последних лет — при отсутсвии изменений в подходах к работе связанные с ним проблемы будут лишь усугубляться.

Итак, если первый тип у нас — и Accountable, и Responsible, то у второго типа из тактических действий остается A, а из стратегических — и A и R.

Delivery Manager второго типа делает следующее:
— Принимает участие на первых встречах с заказчиком, выработке предложения, заключении контракта
— Принимает участие в выборе методологии работы и ее имплементации
— Принимает участие в подборе ключевых людей, построении процессов
— Служит «Single Point of Contact» для стейкхолдеров проекта
— Выступает гарантом соблюдения договоренностей
и т.д.

Если в проектах с первым типом Delivery Managerа ответственным за весь проект является Account Manager/Programme Manager/Project Manager, а Delivery Manager отвечает лишь за своевременную поставку (не вникает в экономическую целесообразность и т.д.) то в случае второго типа главным на проекте является именно он.

Если вкратце, то цель Delivery Managerа второго типа — пообещать и сделать.

Он должен обладать выраженной компетенцией «ладить с людьми» т.к. он «доделывает до конца, закатывая рукава других людей». Этому типу Delivery Managerа требуется более высокий уровень развития лидерства т.к. от него требуется мотивировать и вдохновлять людей «довести дело до конца» несмотря на трудности, разочарования и отсутствие мотивации.

Карьерный путь

Delivery Manager второго типа занимается стратегическими задачами, помогая подчиненным транслировать (декомпозировать) стратегию в тактические планы и следя за их выполнением. Таким менеджером проще всего стать специалисту с техническим прошлым, прошедшему следующий карьерный путь: Специалист → Tech Lead → Team Lead → Project Manager / Delivery Manager (первого типа) / Programme Manager / Account Manager.

На такой позиции он будет отвечать за общий результат взаимодействия с заказчиком (начало, выполнение и завершение проекта целиком). Должен обладать всеми полномочиями, требуемыми для достижения долгосрочного результата (возможно, иногда даже уходом в минус по деньгам в краткосрочной перспективе с целью получения выгоды в долгосрочной). Обеспечивает результат, работая руками других людей. Должен быть способным этих других людей нанимать/увольнять, вдохновлять и мотивировать. Типичный пример — Project/Programme/Account Manager с хорошим «техническим прошлым», обладающий жизненной позицией Delivery Managerа второго типа.

Как стать Delivery Manager’ом

Технический background

Прежде всего, Delivery Manager’у необходим технический background. Зачем? Ответ на этот вопрос очень прост. Delivery Manager’у первого типа прошлое программиста либо QA необходимо, чтобы оценивать и улучшать эффективность процессов и работы сотрудников. Не имея «темного прошлого», такой менеджер вынужден будет постоянно обращаться за советами/консультациями/информацией к посторонним, что сведет на нет все преимущества данной роли в проекте.

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

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

Так что самым «затратным» (с точки зрения времени и ресурсов) в карьере Delivery Managerа является развитие технических компетенций (понимание архитектуры на уровне концептов, знание технологий, знание подходов и методологий разработки и т.д.). Именно поэтому Delivery Managerом проще всего стать программисту либо тестировщику-автоматизатору т.к. роль Delivery Managerа является гармоничным продолжением их карьерного пути (они смогут переиспользовать максимум приобретенных ранее знаний и умений).

Управленческий опыт

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

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

Для Delivery Managerа требуется опыт Team Lead или Project Manager. При этом и для первой, и для второй позиций требуется проект, где ответственность за результат несет исполнитель. Иными словами, в качестве опыта не подходят проекты, где Team Lead или Project Manager может сказать «ну, не получилось» — и за это его компания не понесет как минимум серьезных репутационных или финансовых потерь.

Для обоих типов Delivery Managerа крайне критично брать на себя ПОЛНУЮ ответственность и достигать результата, иногда даже игнорируя цену, которую за этот результат придется заплатить.

Soft Skills

Следующими в очереди идут социальные компетенции. Обоим типам Delivery Managerа очень важно иметь 4 базовые компетенции, «прокачанные» до уровня «Advanced»:

— Умение говорить — сюда можно включить «внятно и складно излагать свои мысли», «отсутсвие слов-паразитов», «правильно структурировать и доностить информацию в зависимости от аудитории» (иными словами, с топ-менеджментом общаемся словами из категории RAG (Red/Amber/Green), а с программистами — словами из категории «написали столько-то строк кода/пофиксили столько-то багов/закрыли столько-то айтемов, и т.д.)

— Умение слушать — «активное слушание» (пытаться понять, почему собеседник говорит именно это и именно так. Что именно он пытается сказать и зачем).

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

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

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

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

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

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

Схожі статті




23 коментарі

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

Спасибо за статью. Все просто и доступно

Не совсем согласен про technical background. Технологии обновляются каждые 5 лет. Через 5 лет менеджер будет работать с проектами, где уже мало что останется, от того, что он знал

Да, это так. Зато опыт в менеджменте выростет. Поэтому, если ДМ не единственный менеджер в компании с единственным продуктом (или технологией), то из категории 1 он эволюционно перейдет в категорию 2.

:)

Статья довольно интересная, с двумя категориями DM я согласен, конечно могут быть разные вариации на эту тему, но не стоит на них распыляться. Принципиально то что первый тип — это узкий профи, появляющийся на фазе Delivery, а во втором случае это ответственный за координацию разных менеджеров, (саб)проектов и за разовую или периодическую поставку продукта клиенту. При этом да — для сложных программных продуктов, включающих разные технологии, выбор первого типа ДМ будет не самым удачным, пожалуй.
Если чуть детальнее то можно было бы описать активности данной роли на фазах UAT и собственно Delivery.
Спасибо автору.
Жду статью про Engagement manager и (Technical) Account Manager

Не понятно чем Project Manager отличается от Delivery Manager-а в IT аутсорсинге.

Думаю так:
1) охватом фаз проекта (у деливери — шире)
2) работой пред клиентом от лица программы или нескольких раздельных команд. Здесь могут быть несколько ПМ.
3) возглавляя один из Delivery units (офисов/центров разработки софта)

1. Я и роли Project Manager-а отвечал за вопросы начиная с подписания с заказчиком SOW и заканчивая введением в эксплуатацию и поддержку
2. Я и в роли Project Manager-а работал от лица команд. Если от лица программы, тогда это уже Program Manager
3. Если он возглавляет Unit, тогда он уже Delivery Director

Ни в коем случае не отрицаю вами сказанного. Бывает так что и СТО садится кодировать, или конфигурить 1С :)

Если в проектах с первым типом Delivery Managerа ответственным за весь проект является Account Manager/Programme Manager/Project Manager, а Delivery Manager отвечает лишь за своевременную поставку (не вникает в экономическую целесообразность и т.д.) то в случае второго типа главным на проекте является именно он.
По пунктам 1 и 2 — да, зависит от полномочий, предписанных данной роли. Бывает так в ауторсе, что с зарубежными клиентами и со своими зарубежными коллегами работаетт ДМ, а внутри юнитов работают ПМы, часто не над одним, а над несколькими проектами параллельно, и в таком случае ответственность ПМов в большей степени лежит за девелопмент продукта, не включая фазу деливери.
3. Ну да — Delivery Director или Delivery Head, Delivery Unit Manager, Senior Delivery Manager. Тут уж как овнерам понравится.

Ух ты. Спасибо! Уже почти год не понимал как себя назвать. Эникейщик, дыркозатыкатель или делатель всего подряд на проекте, а оказалось DM 2го типа!

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

Оказывается есть специальный термин!
Подскажите, откуда взято это название? Если где-то его определение и место в IT пищевой цепочке?

Шепотом на ухо: «Оттуда!» :)
А в госпредприятиях название должности строго соглаасно штатного расписания, и не вздумайте хоть на буковку ошибиться, прописывая должность на согласующих или утверждающих записях! Так что думать не надо! Кадровикам виднее, кака называть :)

Льоша, здається, у вас в Компанії зараз якраз вводять Delivery Mgr, як нову компетенцію.

Юрий, не пали! Дай Алексею немного постебаться ;)

В крупную компанию на работу устроились два людоеда. Генеральный директор, принимая их на работу, проводит профилактическую беседу.
— Ну вот, теперь вы — члены нашей большой, дружной компании, практически семьи. На первом этаже нашего здания — столовая, где вы все сможете бесплатно обедать каждый день, не беспокоя при этом других сотрудников.
Людоеды в ответ клянутся, что никого никогда больше есть не будут.
Проходит месяц, два, три. Всё идет нормально, людоеды работают исправно, шеф доволен. На четвёртый месяц в офисе загадочным образом пропадает уборщица. В офисе грязь, пыль, урны не убраны, стаканы не мыты, на кухне — тараканы...
Генеральный вызывает людоедов.
— Ребята, вы случайно уборщицу не видели?
Те клянутся — нет, мол, не видели, мы ни при чём.
Выходят из кабинета.
— Ну? И кто съел уборщицу?
Второй людоед мнётся.
— Ну я...
— Козёл, придурок чёртов! Мы три месяца жрали пи-ар менеджеров, брэнд-менеджеров, специалистов по маркетингу и развитию, охранников, бухгалтеров, и никто ничего не замечал! Ну скажи, на какой хрен ты сожрал УБОРЩИЦУ?!

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

Особисто в моєму розумінні Delivery Manager — це або логіст, або кур’єр. З таким підходом, як у статті, скоро доведеться університети (або, як мінімум, піврічні курси) закінчувати, щоб на прибиральницю влаштуватися.

Особисто в моєму розумінні Delivery Manager — це або логіст, або кур’єр.

А Developer мабуть — будівельник.

Developer — строитель, Delivery manager — подносчик раствора.

Ну ясно дело — сисадмин!

Delivery Manager
 — тот, кто доставляет, в широком смысле.

Будет вялый тролинг на тему Delivery Unit Manager?=)

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