Я починав з позиції інженера, але досить скоро мені довелося керувати командою. Замовник був свого роду стартапом: розподілу ролей майже не було, але треба було поєднувати управління, архітектуру та розробку.


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

Таких інженерів на стику двох світів в нашому регіоні багато. А люди, які люблять створювати, готові це робити вічно.

Источник: https://dou.ua/lenta/articles/devops-engineer-position/

Додати коментар


Захисний код
Оновити

Неактивна зіркаНеактивна зіркаНеактивна зіркаНеактивна зіркаНеактивна зірка
 
Go to top