7 вопросов к Delivery Director в Luxoft — о KPI, сертификации и работе с командами со всего мира | Бизнес-школа Laba (Лаба)
Для отслеживания статуса заказа — авторизируйтесь
Введите код, который был выслан на почту Введите код с SMS, который был выслан на номер
anastasiiasytar@gmail.com
Код действителен в течение 5 минут Код с sms действителен в течение 5 минут
Вы уверены, что хотите выйти?
Сеанс завершен
На главную

Поиск

Содержание

Андрей Богданов, Luxoft: «‎Бюрократические нюансы очень "убивают" динамику IT-проекта»

7 вопросов к Delivery Director в Luxoft — о KPI, сертификации и работе с командами со всего мира.

cover-641480225a693235930331.png

Прогнозируется, что спрос на Delivery Manager в течение следующих 5 лет вырастет как минимум на 17,7%. В то же время специалиста не может заменить нашумевший ChatGPT, ведь эта роль — о взаимодействии с людьми.

Спросили у Delivery Director в Luxoft Андрея Богданова:

— что должен делать delivery manager, чтобы обеспечить успешную доставку софта

— зачем этот специалист нужен продукту

— необходима ли ему сертификация

— на каких KPI delivery-менеджеру стоит фокусироваться, а какие тормозят процесс

Андрей работал с командами в ЕС, Сингапуре, Китае, США, ОАЭ и Саудовской Аравии. У него более 14 лет практического опыта в управлении проектами, программами и доставками IT-сервисов. Реализовывал масштабные проекты и программы с бюджетами свыше $30 млн.

Скоро у Андрея стартует курс Delivery manager в Laba.

#1. Зачем Delivery Manager нужен проекту

Delivery Manager — относительно новое название управленческой роли в IT. В небольших продуктовых бизнесах и стартапах деливери может быть равен Project Manager + Business Analyst. Или же там функции DM выполняет CTO либо VP of Engineering. Однако такие компании часто сами себе стреляют в колено. Работая над продуктом, они не успевают развивать направление работы с клиентом и доставки — то есть то, что входит в круг обязанностей Delivery Manager.

Delivery Manager жонглирует всеми инструментами компании, отвечая за успешность доставки продукта. Он контролирует процессы от первого делового контакта и найма специалистов на проект до завершения сотрудничества. Настраивает процессы так, чтобы и клиент, и команда были удовлетворены. Это нечто большее, чем project или program manager, но менее масштабно, чем COO.

#2. Что должен делать Delivery Manager, если у клиента нереалистичные планы на продукт

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

Например, клиент может прийти с запросом «хочу полететь на Марс завтра». Если Delivery Manager на берегу не оговорит, что такой сценарий невозможен, и возьмется с командой за проект, это будет one-time deal. На Марс вы завтра не улетите, клиент будет недоволен и не вернется к вам с новыми проектами.

Если же DM объяснит, какое расстояние от Земли до Марса, сколько средств будет потрачено на полет, сколько времени нужно на реализацию, — клиент прислушается и уже станет вам доверять. И позже будет возвращаться с новыми идеями.

Или клиент хочет разработать программное обеспечение, которое будет разворачиваться на экран в 4K. Это требует мощных ресурсов в бэкенде на сервере. Delivery Manager должен подвести клиента к мысли, что реализовать продукт в 2K будет лучше, потому что на это нужно меньше ресурсов. Кроме того, не-геймер или не-дизайнер объективно не увидят разницы между 2K и 4K.

#3. Как разный менталитет влияет на коммуникацию и доставку IT-сервисов

В Средней Азии рабочая неделя — с воскресенья по четверг. Это нужно учитывать, планируя важный митинг или деплой.

А в Индии и на Филиппинах вы всегда будете слышать ответ «да». Однако это вовсе не означает, что команда вас, например, поняла и готова сделать то, что вы просили, к указанной дате. Чтобы докопаться до реального ответа, коллегам из этих частей мира нужно задавать вопросы «в лоб». К примеру:

Также стоит понимать, что экспат быстро впитывает местную культуру. Индиец в Индии и индиец в Европе — совершенно разные по менталитету люди. Или еще пример: мы привыкли думать, что немцы правильные и щепетильные. Однако, приезжая в Сингапур, они очень быстро становятся менее принципиальными, выбирают действовать не только по шаблону.

#4. К чему готовиться Delivery-менеджеру, который будет работать с иностранными компаниями

Процессы разработки программного обеспечения по всему миру более-менее одинаковы, чего не скажешь о темпе и традициях работы. Поэтому, начиная работать с американским проектом, DM должен понимать: теперь он на связи 24/7. Потому что клиент или коллега в какой-то момент может прислать срочный месседж — и нужно будет на него быстро ответить.

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

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

#5. Что Delivery-менеджеру дает сертификация

У меня более 7 сертификаций:

  • PPM — Professional PeopleManagement
  • Scrum Master Certified (SMC)
  • Lean Six Sigma Green Belt
  • Certified SAFe® 5 Product Owner/Product Manager
  • Certified SAFe® 5 Agilist 
  • ICAgile Certified Professional
  • ICAgile certified professional — agile project and delivery management

Поскольку специалист работает в разных доменах, компаниях, странах, отличаются и подходы к   SDLC. Один клиент будет использовать Agile, другой — Waterfall. И DM нужно разговаривать с клиентом на одном языке. То есть на проекте, где используются Waterfall-практики, ваши знания Agile релевантными не будут.

Или компания решает перейти на модель Spotify либо Product Oriented Delivery (POD). Delivery-менеджеру нужно разобраться, как она выглядит, — лучше всего делать это с помощью сертификации.

Помимо процессов разработки, сертификация может касаться технологий. Например, DM хочет развиваться в техническую сторону — архитектура, Head of Capability, внедрение облачных решений и т. д. Тогда он должен получить сертификацию в соответствии с этими решениями или технологиями. Если планирует расти как консультант — нужно изучать циклы разработки программного обеспечения, Agile, PMI.

Очень любят сертификацию в государственных органах Великобритании. Им часто важно, чтобы вся команда разработки или менеджмента была сертифицирована в PRINCE (1 либо 2).

А начиная работать над внедрением фичи в узкоспециализированном FinTech-проекте — например, SAP или Pega, — Project и Delivery Manager в основном должны иметь сертификацию в этих продуктах.

#6. Топ самых важных KPI в Delivery Management

Для меня важнее всего эти три KPI:

  • Удовлетворенность клиента. Метрика может быть связана со смежными. Ведь для одного клиента успех и, соответственно, удовлетворенность результатом — это вывод на рынок нового продукта, а для другого — рост доли рынка на 25%.
  • «На что подписались, то и сделали». Важно держать слово и выполнять обязательства, ведь это лицо команды/компании и доверие к ней.
  • Профит продукта. DM должен жонглировать ресурсами так, чтобы бизнес, в котором он работает, был максимально прибыльным, а расходы клиента на внедрение — обоснованно взвешенными.

Менее важным, по-моему, является соответствие бюрократическим нюансам. Часто в зарегулированных доменах, таких как FinTech, Healthcare и Rocket & Space, добавляются «бюрократические» KPI. Поэтому вы можете часами писать документацию, которую так никто и не прочтет. Или делать тренинги для команды, потому что это нужно «для галочки».

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

Что делать в случае, если клиент настаивает на бюрократической составляющей? Договоритесь с ним о минимальном наборе must-have контрольных точек, которые необходимо пройти, чтобы проект считался закрытым. А остальные нюансы — например, ежедневный репортинг — можно проигнорировать. Вместо этого готовить репорт, допустим, раз в неделю.

#7. Delivery Management и ChatGPT: есть ли угроза для IT-роли?

С распространением AI-решений мы оказались на пороге масштабной революции. Но есть много нюансов.

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

Рекомендуем почитать:

img-63e36021ce949584722033.png

Как использовать ChatGPT, чтобы освободить себе полжизни

Читать

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

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

Хотите получать дайджест статей?

Одно письмо с лучшими материалами за неделю. Подписывайтесь, чтобы ничего не упустить.
Спасибо за подписку!
Курс по теме:
«Delivery Manager»
Бизнес и управление
Ведет Андрей Богданов
25 мая 18 июля
Андрей Богданов