Хто такий Delivery Manager: плюси та мінуси ролі, необхідні навички і виклики в роботі

Всім привіт! Мене звати Ігор, я працюю у ролі Delivery Manager близько шести років і встиг попрацювати з кількома десятками цікавих і не дуже клієнтів. На цей момент мій акаунт складається з 13 проєктів різної величини, від 1 до 40 членів команди.

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

Моя розповідь може бути корисна тим, хто недавно працює у ролі DM, PM, тімлідам, які планують рухатись по менеджмент-вертикалі, а також для всіх інших, хто просто цікавиться індустрією.

В обов’язки делівері-менеджера входить розвиток акаунту в компанії, енгейджмент з новими клієнтами, моніторинг за наявними проєктами, підтримка хорошого рівня надання сервісів, активності, пов’язані з ресурсингом цих проєктів. Та найголовніше на мою думку — слідкувати, щоб ці проєкти були прибутковими для компанії. В різних компаніях обов’язки DM можуть відрізнятись, особливо залежно від розміру компанії, але суть залишиться тою самою.

Мій карʼєрний шлях до делівері-менеджера

Декілька слів про мій карʼєрний шлях. На менеджерську посаду я перейшов з розробки. В першій компанії ще студентом працював з різними технологіями й мовами програмування, та на жаль, ні в чому конкретно експертом я так і не став, тому вирішив сконцентруватись на JavaScript. В той час, приблизно дев’ять років тому, це був «наймодніший» напрямок: всі конференції, техтоки, івенти й мітапи були про MEAN-стек. Підтягнувши знання і попрактикувавшись на невеликих пет-проєктах я таки отримав роботу як Middle JavaScript Developer. Згодом — став лідом проєкту, на якому працював.

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

Плюси та мінуси цієї ролі

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

➕ Можливість працювати з великою кількістю клієнтів на різних проєктах. Мені як розробнику завжди хотілося набувати нового досвіду, та не кожен проєкт дає таку змогу. Деякі не дуже швидко розвиваються, та не спішать використовувати нові інструменти чи оновлювати старі. Тому, якщо застрягаєш на такому проєкті, то зростає бажання його змінити, а це, як правило, стрес пошуків, ризики, що новий проєкт не буде цікавим тощо. Не кажучи вже про те, що більшість стартапів за деякий час закриваються. У ролі DM в мене є можливість співпрацювати з щонайменше п’ятьма новими клієнтами щороку.

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

➕ Побудова свого нетворку контактів. Як правило, власники стартапів чи бізнесів — це цікаві особистості з різноманітним досвідом. Наприклад, один з моїх клієнтів працював у CERN, а також розробляв софт для військових підводних човнів. Деякі клієнти приводять своїх знайомих до нас для співпраці, а також виступають хорошими референсами для нових клієнтів, які ще вагаються. Насправді, з мого досвіду, найкраще джерело розвитку акаунту — це референси від наявних клієнтів.

➕ Розуміння ринку і поточної ситуації. Залученість до процесу рекрутингу, сейлз та фінансових показників компанії дає більше розуміння ситуації на ринку кандидатів, на ринку інвестицій та стану компанії.

➖ Дуже багато комунікації. Поки я не навчився добре делегувати задачі та обов’язки, були моменти, коли цілий тиждень — одні мітинги. Пресейл-мітинги, weekly, monthly-статуси, salary та перформанс-ревю, інтерв’ю, мітинги з оферів і контроферів тощо.

➖ Емоційні моменти в роботі. Здебільшого це стосується скорочень на проєктах, а через те, що останні роки ситуація на ринку не дуже позитивна, доводилось робити це досить часто.

➖ Невизначеність. Чи є в клієнта гроші? Чи його продукт має якийсь трекшн з ринком? Наскільки довго можна розраховувати на співпрацю з ним? Чи вірити, коли він каже, що от вже завтра внесе оплату за інвойсом? Який потенціал у цього клієнта в майбутньому? Чи варто для нього робити якийсь екстрамайл? Коли в пайплайні з’явиться новий хороший клієнт? Ці та ще багато інших питань періодично крутяться в голові та можуть створювати дискомфорт.

Які знання та навички будуть корисні для DM

1. Загальне розуміння індустрії. Я вважаю, що чим більше DM знає про Computer Science, програмування, різні мови, фреймворки, бази, клауди, ШІ, клауд-платформи, а також менеджмент, сейлз, рекрутинг, ейчар, фінанси та останні новини індустрії загалом, тим ефективніше зможе комунікувати зі своїми командами та клієнтами.
2. Софт-скіли, менеджмент та лідерські скіли. Я б узагальнив таким чином великий пласт навичок: комунікація, презентація, емпатія, вміння завойовувати довіру людей, вміння фасилітувати мітинги, презентувати ідеї, мотивувати людей, налаштовувати й постійно вдосконалювати процеси.
3. Вміння вести переговори. Я б визначив це як ключову навичку для DM. Постійно доводиться домовлятись про різні речі: умови договору з клієнтом, бюджет на команду, перегляд рейтів, селері ревю з працівниками компанії тощо. А ще домовлятись з керівниками інших відділів і знаходити вихід з ситуацій, який буде прийнятним для всіх.
4. Розуміння бізнесу клієнта. Непогано було б орієнтуватись у ринку, на якому працює компанія клієнта, знати його конкурентів, як нові технології впливають на цей ринок, як він заробляє гроші, яка в нього бізнес-модель, які існують ризики. Якщо це стартап, то непогано б знати, на скільки місяців в них ще вистачить грошей.
5. Фінансова обізнаність. Велику частину роботи DM займає робота з цифрами. З зарплатами, рейтами, бюджетами, інвойсами, прогнозами, знижками, комісіями та ще багато з чим. Перед тим, як я почав працювати DM, я керував виключно своїми особистими фінансами, і то не завжди ефективно. Тому мені довелося пройти кілька онлайн-курсів, щоб краще зрозуміти цю сферу. Таким чином я дійшов до рівня, принаймні достатнього для підтримання розмови з клієнтом про інвестиції, акції, опціони, valuation, P&L тощо.

Коли йдеться про управління фінансами в делівері, то важливо розуміти, що бізнес-модель сервісних ІТ-компаній є приблизно однаковою, незалежно від розміру, а показники, за якими повинен стежити DM, не є складними для розрахунку. Достатньо бути терплячим, уважним і опанувати трохи Excel.

Виклики в роботі DM

В цьому розділі розкажу про челенджі, з якими особисто я стикнувся на цій позиції.

• Делегування

Мій шлях DM почався, коли я був у ролі тімліда, тому необхідність делегувати свої обов’язки й не втратити контроль над проєктом з’явилась щойно почав онбордити ще один проєкт.

З часом проєктів ставало більше і з менеджменту команд я перейшов у менеджмент лідів команд. Також кожен новий проєкт — це договори, бюджет, відносини з клієнтом, які треба підтримувати, це все потребує часу, концентрації та уваги. Коли масштабувати такий сетап було вже важко, я передавав декілька проєктів під управління PM, повністю end-to-end, контракти, рейти, рекрутинг тощо. І ось вже на цьому рівні почались перші челенджі, пов’язані з делегуванням.

Були кейси, коли клієнти вже звикли працювати зі мною і не хотіли переходити до PM, тому PM доводилось завойовувати довіру з нуля по суті. Те саме можна сказати про людей в командах, з ними також новому PM треба знайти спільну мову, побудувати довіру, укласти певні домовленості, показати результат тощо.

Моя стратегія полягала в тому, щоб брати на цю роль людей, з якими я вже пройшов через декілька проєктів, та знаю, що на них можна покластись. Почати передавати їм більше обов’язків, по ходу передати ті знання, яких я набув, та з часом залишити набивати свої шишки, та набиратись досвіду. Час від часу ми обговорюємо, що робити у різних едж-кейсах, також разом впроваджуємо зміни, які прийняті на рівні компанії.

Щомісяця така структура мого відділу працює все краще та потребує менше мого залучення, зараз в мене є команда з чотирьох сильних PM, на яких я можу покластись, і саме це мені дозволяє сконцентрувати частину часу на енгейджменті з новими клієнтами.

• Невизначеність

До цього найважче звикнути після того, як пропрацював девелопером близько 5 років. В роботі розробника невизначеність присутня тільки у випадку, якщо клієнт дуже часто змінює пріоритети, й ти не знаєш, що будеш робити завтра. Але здебільшого робота зрозуміла і прописана на тижні наперед.

Натомість робота DM наповнена невизначеністю аж до верхів. Коли ринок процвітає, багато нових клієнтів, робота кипить — переживаєш, щоб не захантили людей, коли криза, як-от зараз — щоб у клієнтів не закінчились гроші й вони не звільняли людей.

Коли вже почали звільняти й це триває місяць, два, три, то не знаєш, чи то ми вже найгірше пережили, чи це тільки половина шляху вниз? Коли провів 3-4 мітинги з новими клієнтами й навіть дійшли домовленостей, то не знаєш точно: шлях до підписання договору займе тиждень чи декілька місяців? А що робити з людьми на бенчі, яких я розглядав на ці проєкти?

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

• Визнавати свої помилки й брати за них відповідальність

Якась частина роботи DM — це свого роду підприємницька діяльність з обмеженою відповідальністю. А це означає, що треба добре зважити ризики перед тим, як вписуватись в якусь авантюру. Для мене одні з таких авантюр — це невеликі проєкти з обмеженим бюджетом, які за умови позитивної співпраці відкривають нові можливості, а якщо це well connected-фаундер, то і хороші референси.

Проте, якщо ситуація складається не в нашу користь, то доводиться зазнавати втрат, оплачувати час розробників з бюджету делівері. Так декілька разів сталось і зі мною, під час спроби розпочати один з проєктів силами парттайм-девелопера, який працював на іншому проєкті. Ми дуже затягнули досить прості задачі й, м’яко кажучи, не вразили цим клієнта. Очевидно, що клієнт не оплатив нам ці години.

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

• Обізнаність у поточних справах клієнта

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

Інформація про ризики та потенціал бізнесу клієнта може дати відповідь на питання, чи варто скейлити цей акаунт. Якщо грошей мало, то краще нехай залишається меншим, повільніше витрачає гроші та довше протримається, можливо, навіть покаже позитивні результати й отримає черговий раунд інвестицій. А якщо ні, то потім простіше невелику команду перевести на інші проєкти.

В мене був такий приклад, коли клієнт замовчував, що в нього невеликий бюджет і при цьому наймав все більше розробників, відповідно гроші закінчувались ще швидше. Коли гроші остаточно закінчились, це був шок, навіщо тоді було наймати таку команду? На щастя, таких клієнтів небагато, але потрапити у таку пастку, як виявилось, можна.

• Приймати складні рішення, доносити погані новини

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

Загалом будь-яке рішення, або новина, яка передбачає, що хтось потенційно втратить роботу — це челендж. Треба чітко донести, що буде відбуватись, зі всіма прокомунікувати, відповісти на всі питання, скласти план, потім слідкувати, як ми рухаємося за цим планом.

Навчання

Якби мене просили порадити один курс, то це був би курс з переговорів. Серед всіх онлайн- і офлайн-програм, які я проходив про менеджмент в ІТ, скрам й еджайл, саме курс з переговорів дав максимальну практичну користь.

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

Додатково, як я писав вище, DM в пригоді стануть будь-які релевантні знання. Багато корисних статей є на ресурсі Harvard Business Review про salary review, про перформанс-ревю, про фасилітацію, про різні HR-процеси. Coursera наповнена професійними курсами з усього, що може знадобитись DM: accounting, enterprise finances, marketing, data science, startups тощо.

Для любителів книжок можу порадити The Culture Map Ерін Мейер — вона викликала найбільше обговорень на одному з наших невеликих книжкових клубів в компанії та має дуже багато практичних порад. Також Who Джеффа Смарта, про важливість приділяти максимум уваги процесу найму на ключові посади.

Завершальні думки

У висновку хотів би зазначити, що посада DM для багатьох може бути логічним продовженням кар’єрного шляху. Аспекти, які я описав вище, роблять довгострокову роботу на цій посаді цікавішою і не рутинною. Спочатку, як і у мене, буде дуже багато питань, тому важливо мати хорошого керівника або ментора, який допоможе на шляху, та згодом набутий досвід буде допомагати приймати самостійні рішення.

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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.