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