Кто такой деливери-менеджер в IT-мире
Это управленец, в компетенцию которого входит обеспечение поставок программного обеспечения (ПО) в нужное время, в нужные сроки и в заданном качестве. Он объединяет в себе технические знания в области IT, а также навыки управления проектами и командой. Деливери-менеджер (ДМ) занимается поставками ПО сразу по нескольким проектам: краткосрочным или со средней срочностью. На сложный, высоконагруженный проект может быть выделен отдельный ДМ.
Delivery-менеджер полезен для любой крупной компании (штат +100 человек), либо в стартапах, где инвестор обеспечивает постоянное финансирование.
Как появилась профессия деливери-менеджера
Раньше эту роль выполняли руководители проектов (PM), релиз-менеджеры, Tech-лиды либо QA-лиды. Дальше ускорилось развитие цифровой трансформации, увеличилось количество IT-проектов, причем не только в IT-компаниях, и появилась взаимозависимость таких проектов.
Например, один IT-проект может разрабатываться в одной компании, а другой, который тесно связан с первым, – совершенно в иной компании. Project-менеджер просто не справится с таким количеством интеграций. Поэтому появилась необходимость в новом звене, чтобы:
- Наладить поставку и интеграцию ПО.
- Правильно провести зависимость и синхронизировать процессы среди множества проектов.
- Настроить качественное функционирование среди множества IT-проектов.
Деливери-менеджер выстраивает систему, которая будет работать как часы и позволит компании быстро выпускать ПО конечным пользователям и, соответственно, получать быструю прибыль и увеличивать количество клиентов.
Кем руководит и чем занимается деливери-менеджер
Классический вариант: в подчинении ДМ находятся тимлиды и проектные менеджеры с командами. Бывает иначе, когда ДМ и PM стоят на равных позициях, где нет прямой иерархии, оказывают друг на друга косвенное влияние. Первый вариант более благоприятный, здесь больше возможностей проводить изменения в процессах, чтобы вовремя делать релизы.
Обязанности ДМ:
- Технический менеджмент. Помогает техлидам бэк-энд разработки, обеспечения качества (QA), фронт-энд разработки, аналитикам выстраивать процессы на проектах, решать возникающие проблемы с лицензиями. Например, техлид говорит, что библиотека скоро перестанет функционировать, из-за чего могут быть проблемы в релизе, тогда ДМ либо сам решает эту проблему, либо привлекает отдел закупки и покупает нужные лицензии, либо ищет пути, чтобы заменить эту библиотеку на другую.
- Управление процессами. Помогает выбирать и внедрять такие методологии управления процессами и командой, которые позволяют выпускать продукты в нужное время, в нужные сроки, в нужном качестве.
- Управление командой. Развитие тимлидов, проектных менеджеров, других сотрудников, выстраивание процесса мотивации, оценки.
- Управление ожиданиями внутренних и внешних заказчиков – стейкхолдеров. Внутренние стейкхолдеры – топ-менеджеры, СЕО, иногда даже сама команда, лид смежной команды, если его ПО зависит от процессов DM. Внешние стейкхолдеры – заказчик, пользователь и, возможно, эксперты со стороны регуляторных и контролирующих органов.
- Коммуникации с руководителями. Важно понимать операционный стратегический менеджмент: какой-то процесс вынести на эскалацию, как показать, к чему мы идем, как проходят релизы, соблюдаются ли сроки, какая эффективность и т.д.
- Операционный и стратегический менеджмент. DM должен уметь планировать, грамотно распределять ресурсы, четко ставить цели и вести за собой команды.
Как оценивают эффективность работы деливери-менеджера
- Поставка ПО заказчику идет максимально безболезненно: дешевым и удобным для компании способом, в сжатые сроки, либо в сроки, которые были заявлены.
- ПО без критических ошибок для конечных пользователей, а также выстроенная система взаимодействия с другими ПО.
- Максимально эффективно и качественно работающая команда, низкая текучка, рост внутри команд разработки.
В чем отличие деливери-менеджера от Project-менеджера
- PM занимается задачами и людьми, работающими на данном проекте. Он оценивает финансовые показатели, план работ, взаимодействия с внешними стейкхолдерами и ведет отчетность по проекту.
- DM работает с графиками и планами по поставке ПО, занимается мотивацией команд, системой оценки, проведением ассессмента, а также участвует в ретроспективах, спринтах, планировании периодов и т.д.
Какие навыки нужны деливери-менеджерам
Как правило, в профессию приходят из техлидов или проектных менеджеров, обладая высоким уровнем технических знаний, навыками разработки и аналитики. Идеальный кандидат:
- Прошел стадию командной разработки, был специалистом по обеспечению качества (QA) или системным аналитиком.
- Понимает, что происходит в процессе разработки ПО внутри проекта. Это важно при взаимодействии с другими командами, при настройке процессов.
- Хорошо разбирается в терминах, в предметной области.
- Является хорошим менеджером, умеет налаживать коммуникацию, выстраивать интеграции.
Каков уровень зарплаты деливери-менеджера
На рынке труда все чаще появляются вакансии на должность ДМ. Работодатели понимают, что необходим отдельный сотрудник, чтобы Project-менеджеры работали эффективней, не разрывались между задачами и не выгорали.
Зарплата деливери-менеджера выше, чем у проектных менеджеров. Потому что у первого в работе 5+ проектов или один, но сложный проект с высокой нагрузкой, а у второго 1-2. А значит, выше и ответственность.
Какой следующий карьерный шаг может сделать деливери-менеджер
Здесь два сценария:
- Исполнительный директор. Это сложный путь. Для этой роли нужен специалист широкого круга знаний. Нужно подтянуть навыки, понять, как функционирует офис, как работает лицензирование, как организовать работу сотрудников, вникнуть во все дела компании.
- Директор по цифровой трансформации. Этот сценарий чуть проще.
Как стать деливери-менеджером
Есть несколько путей:
- Профессиональные курсы. На курсах даются общие знания, а на проекте начинается реальная жизнь: сжатые сроки, никто не даст времени на «домашку», проблему нужно решить здесь и сейчас, а не думать несколько дней и даже недель.
- Ментор или наставник. Если кандидату не хватает опыта, то курсы могут быть бесполезными, поскольку общие моменты он вероятно уже знает, сталкивался с разными ситуациями в своей работе. Наставничество в этом случае видится лучшим решением. Ментор помогает решать практические задачи, указывает на проблемные места и вероятные ошибки.
- Внутренние системы обучения: лаборатории, школы. Опыт коллег – это золотой багаж, который они своими пробами, ошибками, различными ситуациями смогли наработать. Почему бы этим опытом не поделиться с коллегами, которые хотят освоить новую профессию и принести больше пользы для компании.
Также читайте:
В ИТ путь самопознания очень затянулся. Наверное других таких областей не было и не будет. Уже многие протопрограмммисты стали старыми или умерли, а айтишники всё время ищут свой путь. Не очень понятно - они упрощают, или усложняют процесс? Или это как у художников - каждое поколение пытается придумать своё новое направление, будь это просто имажинисты, или кубисты со смыслом?
Да, очень известные компании сейчас ищут этих ДМ. Вот например очень известная российская компания.
Правда функционал этого работника совсем не тот, кторый обсуждается в статье, совсем не тот, кторые уже пару лет раскручивается в сети. Я нигде и ни разу не встречал таких специалистов и не пытался встраивать его в команду. Не вижу его применимости и уникальности. Лицензии покупать? А разве это сложно? Согласовывать проект с субподрядчиками? А зечем было заключать договор субподряда, если теперь это стало целой задачей и даже проблемой?
Могу понять такие темы в разработке большой экосистемы. Там многие приблуды включаются довольно сложно. Были случаи с известными системами, которые опирались вроде бы на принятые в мире стандарты, но неожиданно начинали глючить из-за того, что некий Гил Бейтс что-то поменял в межсистемном взаимодействии своей системы. Но всё-таки такие случаи не являются частыми, выделение отдельного работника довольно неоправдано, на мой взгляд.
Интересно, для каких продуктов, о мнени автора, нужно такое количество управленце: тим-лидов, теч-лидов, проджект-менеджеров, деливери-менеджеров, руководителей проектов, тим-лидов фронт-енд разработки, тим-лидоы бэк-енд разработки?
Осталось только сверху добавить какого-нибудь скрум-мастера, чтоб окончательно запутать разработку.
Смущаюют и необходимые навыки этого ДМ:
Это сильно разные направления в разработке, но предлагается ждать, что из них вырастет что-то общее? В автобусе ездит водитель и пассажиры, заправляют заправщики, ремонтируют слесаря - из них можно сделать какого-нибудь тим-водителя или деливери-шофёра?
Супер, Анатолий! Какой интересный ... случай) хотела написать кейс))) но вспомнила!) Читаешь статью не будучи глубоко в теме и все вроде бы тип-топ) Смотришь на комметарий спеца в этом деле и как меняется отношение к написанному.
Спасибо, Ирина! Я очень ценю Вашу оценку!
Тема для меня очень важная, очень интересная и уж честно волнующая - полжизни в этих параноидальных делах (ну Вы помниет, да, кто там выживает?).
Программисты не выживут. Довольно скоро их роль мы просто не узнаем. Когда-то для создания автомобиля требовалось знание устройства двигателя, трансмиссии и пр и др. Теперь роль автопроизводителя свелась в целом к роли сборщика. Вот и программисты будут простыми сборщиками из готовых блоков. Часть из них будет штукатурами-отделочниками (сейчас это пока называется фронт-ендом). Конструкторов, архитекторов не будет вовсе. Их легко заменит искусственный интеллект. Хотя часть контрукторов, архитекторов, дизайнеров останется, как до сих пор остаются одинчки мастера-мебельщики, кторые выполняют дорогую, индивидуальную работу руками.
Уйдёт огромный слой сисадминов, это возьмёт ИИ на себя в первую очередь.
И самое главное - распланировать ИТ-проект сможет запросто тот же ИИ. И исчезнут эти все тим-лиды, теч-лиды, ДМ, ПМ, PM. Появится какой-нибудь ИТ-прораб, чтобы представлять некоторое промежуточное звено между заказчиком и ИИ.
Да, кстати, милые женщины, не выходите замуж за программистов. Сидячий образ жизни очень плохо влияет именно на мужчин. Оно вам надо? Даже если в ближайшие пару лет зарплаты у них останутся высокими.
Так в принипе да,так и будет. Всё на глазах меняется. Ну как-то быстро всё программирование превращается в однотипные и типизированные наборы операндов. Вдруг становится скучно. Не стоит запоминать сложные обращения к библиотекам и внешним скриптам, на то есть интернет. Не стоит задумываться об оптимизации - всё уже сделано и продумано. НЕ надо сиакать оптимальный язык или даже код, задумываться о циклах, частоте обращения к внешним процедурам. Всё уже давным-давно готово. Осталось что? Осталось, как монастырскому летописца терпеливо переписывать чужой код путём копи-паст.
Да, все меняется в этой жизни сейчас очень быстро. И чего ж программистам теперь холостыми оставаться)) ?
Нет, конечно! Я видимо погорячился с советом ))))
То-то))) А поют прекрасно)
Вся это "новизна" состоит в том, что обязанности обычного менеджера обозваны новым термином. Смысл - для кадровых агентств оживить вялый рынок в надежде чуть денег больше снять с заказчиков. Ничего нового тут нет, обычная продажа лежалого товара с новой этикеткой. От названия количество и качество не изменятся. Кадровые агентства сами в этом рынке ничего толком не понимают - знают понаслышке, сами никогда не работали, самостоятельной экспертизы не имеют.
А уж советы о том "как им стать" - уж лучше бы ничего не "сообщали"...
Пока возникает ощущение, что названия должностей размножаются почкованием.
Проверка необходимости в таких людях займет от 5 до 10 минут. Посмотрите (непредвзято) на функциональные обязанности и зоны ответственности существующих сотрудников и сравните их с известными проблемами на данный момент в конкретной компании. Если есть очевидные дыры и работы, которые никто не делает, или они делаются плохо - подумайте, как поступить. Варианты есть всегда.
Но описание функционала DM в публикации просто поражает. Стратегический менеджмент (!), управление процессами, управление ожиданиями и много чего еще - помилуйте! Таких людей не бывает. В сутках 24 часа.
Жаль, если так. Но вопрос к заказчикам, а не к агентствам. Им с этими людьми потом работать.