Чим займається Developer Advocate та чому ця позиція непопулярна в Україні

Посада Developer Advocate в Україні зовсім непопулярна. Як каже , який займає її в The Linux Foundation , таких спеціалістів у нас можна перерахувати на пальцях однієї руки. Натомість DA є в таких компаніях, як Google, Microsoft або Amazon. При чому часто йдеться не про одну позицію, а про цілі команди.

Тож які у Developer Advocate обов'язки, роль та місце в компанії, чим він відрізняється від sales-менеджера, як виміряти якість його роботи та яка специфіка такої позиції в комерційній компанії та оупенсорсній фундації.

Чим займається Developer Advocate

У різних компанія обов'язки такого спеціаліста матимуть свою специфіку. Проте можна виділити основні аспекти. DA, як розповідає Ігор Дворецький, — це місток між користувачами технологій та розробниками. Левова частина його роботи — виступи на конференціях, написання статей, участь у вся прикладена інформацію подкастів та інша публічна діяльність. Все це потрібно, щоб донести до користувачів інформацію про технологію: починаючи від завдання «показати, що така технологія взагалі існує» до пояснення, для яких завдань вона підходить, які проблеми розробникі виправили чі який функціонал додали в оновленнях. Водночас DA отримує фідбек від користувачів та передає його розробникам. Користувачі можуть розказати, наприклад, якого функціоналу їм бракує та з якими недоліками технології вони стикались у роботі з нею.

Важливо, що ціль DA — не продати продукт, а налагодити комунікацію між тімі, хто створює технологію, і тімі, хто нею користується. Певною мірою можна сказати, що мета DA — розвиток технології. Developer Advocate може і сам писати код, але це не обов'язково — залежить від позиції в конкретній компанії. А від розуміти код він має обов'язково.

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

Шлях до позиції Developer Advocate

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

Зараз обіймаю посаду Developer Advocate в The Linux Foundation, точніше The Cloud Native Computing Foundation (CNCF). Це одна із найбільших оупенсорсних фундацій у світі. У нас понад 30 проектів, з більшістю з яких я працюю. Один із них ключових проектів — Kubernetes. Це оупенсорсна система, розроблена Google і передана The Linux Foundation, після чого й була створена CNCF.

Перед CNCF я працював у компанії, яка випускає комерційні продукти на базі оупенсорсних технологій. Я займався OpenStack та іншими. Власне, Kubernetes — технологія, за допомогою якої, в тому числі, можеш розширити свої сценарії використання OpenStack як технології для віртуалізації.

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

Паралельно з тім почав виступати на конференціях. Одна з перших доповідей була про те, як інтегрувати і використовувати Kubernetes разом із OpenStack. Вперше виступивши із нею 2015 року на GDG DevFest у Львові. Мій попередній досвід не дозволяв написати якісь великі технології, але він був достатнім для розуміння: які технології існують на ринку, які технології варто або не варто використовувати для тихий чи інших завдань.

GDG DevFest Ukraine 2017

Початок співпраці з CNCF

Я працював пліч-о-пліч із CNCF, будучи ще в попередній компанії, — ставши першим і єдиним в Україні амбасадором за програмою CNCF Ambassadors . Амбасадори не працюють безпосередньо на CNCF (хоча можуть працювати на одну з компаній-членів фундації ). Так фактично розпочалася наша співпраця, одним із успішних прикладів якої є організація Kubernetes Day під час OpenStack Summit в Бостоні.

Також я очолював OpenStack Special Interest Group (SIG-OpenStack) — групу контриб'юторів у спільноті Kubernetes. Власне, SIG-OpenStack займалася питанням колаборації між оупенсорсними спільнотами OpenStack і Kubernetes, а також технічними питаннями інтеграції OpenStack і Kubernetes. Окрім того, вже тоді я співпрацював з Kubernetes Product Management. Ставши одним із засновників Product Management SIG (SIG-PM). Як продакт-менеджер і один з реліз-лідерів співпрацював з маркетинговою командою CNCF.

Завдяки фундації мав можливість брати участь у подкастах, публікуватись у блозі Kubernetes та інших медіа, як The New Stack. На одному зі своїх перших подкастів був гостем разом із Апарною Сінха (зараз Group Product Management Lead, Google) і Еріком Брюєром (Vice President of Infrastructure, Google).

У тієї самий годину в моїй компанії відбулась реструктуризація і моя посада стала неактуальною. А CNCF якраз відкрила вакансію Developer Advocate — до цього тут такої позиції не було. Їм потрібна була людина для тих промов, якими я вже займався у спільноті. Тому я подався, пройшов декілька раундів інтерв'ю і ставши членом команди .

Робота з аудиторією

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

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

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

CNCF організовує понад 170 мітапів по всьму світу. І вісь робота з нашою мітапною спільнотою — один із моїх обов'язків. Ми можемо робити просування в соцмережах, шукати спікерів чи навіть допомагати з футболками і наліпками. При чому, живучі у Львові, я не організовую безпосередньо мітапи у цьому місті, а працюю з глобальну мітап-спільнотою.

У комерційних компаніях, де є більший штат, може бути розподілення: цей DA, наприклад, займається більше технологічними питаннями, а інший зосереджений на роботі зі спільнотою. У CNCF мало людей в штаті, адже ми не виробляємо продукти. Разом зі мною працює ще один DA, який займається іншими проектами CNCF. Тут насправді розподіл дуже простий — у нас більше 30 проектів, і я працюю з одними, він — з іншими. У мене більше досвіду виступів на конференціях, роботи зі спільнотою тощо, а мій колега — автор кількох книг із Software Engineering і активний блогер. Але, звичайно, це не означає, що я не пишу блоги або що він не виступає на конференціях.

Remote — ще одна особливість цієї позиції. Дуже часто від DA не вимагають працювати в офісі. Навіть якщо є така вимога, буде висока ймовірність, що він там проводити небагато часу, тому що позиція передбачає постійні робочі поїздкі. Минулого року я провів 250 днів у подорожах, а загалом за останні декілька років відвідав 20 країн і 68 міст. У мене були робочі поїздкі до Австралії, Бельгії, Великобританії, Данії, Канади, Китаю, Нідерландів, Німеччини, США, Франції, Чехії, Швейцарії.

Чи обов'язково бути розробником, щоб стати DА

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

До того ж, навіть якщо ти не пишеш код, ти можеш бути контриб'ютором в оупенсорсному проекті. Я є контриб'ютором в Kubernetes ще з 2015 року. Більша частина моїх контриб'юшенів — це написання додаткової документації: наприклад, багфікси, проектний і продакт-менеджмент. Окрім цього, я був одним із реліз-менеджерів Kubernetes протягом майже двох років.

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

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

KubeСon NA 2018

Різниця між Developer Advocate та Sales Manager

Я не знаю жодної оупенсорсної фундації, де бі працював технічний Sales Manager, тому можу порівнювати ці ролі тільки в комерційних компаніях. DA сфокусований саме на технологіях. Він має глибоке розуміння того, як ці технології використовуються навіть у такому собі нейтральному, інертному середовищі. Фокус же Sales Manager — як адаптувати цю технологію до потреб реального клієнта.

Наприклад, я, як DA і людина, яка пов'язана з оупенсорсною спільнотою, зацікавлений, щоб якомога більше людей користувались Kubernetes. Ця технологія доступна на GitHub, і хто завгодно може нею користуватись. Альо при інтеграції виникає низка питань, як саме ти можеш користуватись Kubernetes. Тут можуть бути різні нюанси, тому що Kubernetes як оупенсорсний продукт може не відповідати всім вимогам конкретного клієнта і для адаптації технології під такі вимоги потрібна буде додаткова робота. На цьому етапі технологічний Sales Manager може робити тюнінг на боці клієнта. Але такий підхід властивий лише комерційним компаніям. У оупенсорсному середовищі продукт має бути максимально універсальним і відповідати завданням більшості споживачів.

Developer Advocate в комерційних компаніях

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

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

Колеги з Google, Microsoft, Amazon і подібних компаній розповідали мені, що їхнє ключове завдання — бути рупором від своєї компанії до оупесорсної спільноти. Наприклад, Google досі залишається ключовим контриб'ютером Kubernetes, хоча вже не є власником проекту. У клієнтів Google можуть виникнути потреби у певному функціоналі, якого в Kubernetes наразі немає. Тоді завданням DA стані донести розробникам цю інформацію. Це синергія між комерційною компанією та оупенсорсною спільнотою.

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

Ще один момент — не всі DA в комерційних компаніях спілкуються з користувачами. Для цього є, наприклад, сейлз-інженери. У такому разі DA доносять інформацію до сейлз-інженерів, а ті потім будуть передавати їм вимоги від користувачів.

KubeconEU 2018

Ієрархія

DA в більшості випадків не має в підпорядкуванні людей. Це дуже схоже з тим, як працює продакт-менеджер: йому підпорядковуються інші продакт-менеджери, альо не інженери. Так само для Developer Advocate: у його підпорядкуванні можуть бути лише інші DA.

Наприклад, мій бос — це VP Linux Foundation з Developer Relations. Мені ніхто не підпорядковується. Утім, я працюю з лідерами мітап-спільноти, CNCF-амбасадорами (найбільш визначними персоналіями в світі Cloud Native технологій), будучи фактично їхнім куратором.

Допомога в контриб'юції

Зазвичай оупенсорсні проекти розробляються людьми з комерційної компанії. Як я вже згадував, Google є топ-контриб'ютером у Kubernetes. Або, наприклад, систему моніторингу Prometheus витворили інженери SoundCloud.
У таких випадках іноді треба виконувати обов'язкову роботу, яку не роблять самі розробникі, наприклад, писати документацію. Ми можемо найняти technical writer'а. Альо коли на проектах CNCF потрібно було терміново допомогти з документацією, це робив мій колега — він має великий досвід написання технологічного тексту. Це було набагато простіше і швидше, ніж шукати контрактера на тимчасову роботу або наймати людину на фултайм.

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

Як виміряти якість роботи DА

Це доволі складно. І насправді жоден DA навіть з комерційних компаній, з якими я спілкувався, не має чіткої відповіді на це запитання. Тут, скоріше, зважають на твою активність роботи, ніж ефективність, яку тут дуже складно виміряти.

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

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

Отож, якщо ми говоримо про показники, то це — скільки ти чого написавши, де виступивши, як часто ти це робив і т. д. І здебільшого метрики є доволі суб'єкта єктивними: наскільки тобою задоволена спільнота, наскільки ти видимий, наскільки добре знають твоє ім'я.

KubeconEU 2018

Developer Advocate і український ринок

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

Причина в тому, що DA має працювати безпосередньо із продуктом. Певною мірою я можу себе охарактеризувати як продакт-менеджера, оскільки я працюю з оупенсорсною спільнотою саме як Product Manager в Kubernetes. Я розумію, які у нас були фічі у попередніх релізах, з якими фічами можна прийти до споживача чи просто виступити перед аудиторією, і знаю, які фічі будуть у майбутньому.

Ринок для цієї позиції в Україні фактично відсутній, відповідно, і рівня зарплат немає (наприклад, на DOU ви не знайдете жодної такої вакансії — ред.). Я не знаю жодного DA в Україні в моїй індустрії. Моя зарплатня нерепрезентативна — я працюю на компанію із США. Я лише живу в Україні, а фактично працюю так, нібито я перебуваю в США (за даними Glassdoor , DA у США заробляють 80-180 тисяч доларів на рік — ред.).

Навіщо говорити про недоліки технологій

У деяких компаніях посада Developer Advocate може називатись «євангеліст». Фактично це не так далеко від правди, але слово «євангеліст» більше ототожнюється з людиною, яка безальтернативно пропагує ті чи інші речі. Грубо кажучи, вона говорити: якщо ви не використовуєте цю технологію від моєї компанії, то вам всім капут, бо тільки ця технологія може дати те, що вам треба, а інші технології — просто шлак.

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

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

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

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

Місток між розробниками і користувачами

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

Опубліковано: 17/04/19 @ 11:54
Розділ Блоги

SEO Блог