Прогнозується, що попит на Delivery Manager впродовж наступних 5 років зросте щонайменше на 17,7%. Водночас фахівця не може замінити нашумілий ChatGPT, адже ця роль — про взаємодію з людьми.
Запитали в Delivery Director у Luxoft Андрія Богданова:
— що має робити delivery manager, щоб забезпечити успішну доставку софту
— навіщо цей фахівець потрібен продукту
— чи необхідна йому сертифікація
— на яких KPI delivery-менеджеру варто фокусуватися, а які гальмують процес
Андрій працював із командами в ЄС, Сінгапурі, Китаї, США, ОАЕ та Саудівській Аравії. Має понад 14 років практичного досвіду в управлінні проєктами, програмами та доставками ІТ-сервісів. Реалізовував масштабні проєкти та програми з бюджетами понад $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-продуктів можуть зберігатися десь у хмарі. Хтось може отримати доступ до них чи зламати онлайн-ресурс — і використати інформацію у своїх цілях. Наприклад, «витягнути» код, який допоможе зламати продакшн, де крутиться багато грошей.
По-друге, AI-рішення припускаються помилок. Провалідувати всю інформацію, яку вам видає штучний інтелект, не володіючи, скажімо, програмуванням, у такому випадку не вдасться. А це означає, що помилки підуть далі та можуть призвести до проблем на наступних етапах.
Наостанок, Delivery Manager працює з людьми. А люди непередбачувані, у роботі з ними не підійдуть шаблони та алгоритми. Справжній стрибок у технологічному світі відбудеться лише тоді, коли AI опанує емпатію. Тобто матиме здатність передбачати бажання людини, розуміти її потреби, емоції та прогнозуватиме реакції.
Бажаєте отримувати дайджест статей?
