Чим займається 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А
Моя робота передбачає те, що ти маєш швидше вміти читати код. Я не можу сказати, що на моїй позиції обов’язково саме вміти його писати. Очевидно, якщо ти вмієш читати код, то наступним етапом має бути написання. Але якщо ти пишеш код, то це має мати якусь мету.
До того ж, навіть якщо ти не пишеш код, ти можеш бути контриб’ютором в оупенсорсному проекті. Я є контриб’ютором в Kubernetes ще з 2015 року. Більша частина моїх контриб’юшенів — це написання додаткової документації: наприклад, багфікси, проектний і продакт-менеджмент. Окрім цього, я був одним із реліз-менеджерів Kubernetes протягом майже двох років.
На позиції Advocate Developer ти маєш розуміти продукт і з технологічного погляду, і з погляду ринку — не просто код як текстові файли з інформацією. Ти маєш розуміти, для чого він людям, які будуть його використовувати, як він працює. Тому що ти — фактично та людина, яка може поєднати два світи: розробників і користувачів.
Я зацікавлений в тому, щоб розробники мали можливість користуватись технологією. Моя робота — максимально спростити їм цей процес. Але я працюю не тільки із софтвер-девелоперами чи з людьми з технологічного світу. Бо це є люди, які використовують продукт, але не завжди це ті самі люди, які ухвалюють рішення на бізнес-рівні. Такі люди можуть не настільки глибоко розуміти той самий Kubernetes. Моя задача — будувати місток між розробниками технологій і людьми, які вирішують, чи будуть їхні компанії платити за користування цими технологіями.
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 в більшості випадків не має в підпорядкуванні людей. Це дуже схоже з тим, як працює продакт-менеджер: йому підпорядковуються інші продакт-менеджери, але не інженери. Так само для Advocate Developer: у його підпорядкуванні можуть бути лише інші 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 у США заробляють
Навіщо говорити про недоліки технологій
У деяких компаніях посада Developer Advocate може називатись «євангеліст». Фактично це не так далеко від правди, але слово «євангеліст» більше ототожнюється з людиною, яка безальтернативно пропагує ті чи інші речі. Грубо кажучи, вона говорить: якщо ви не використовуєте цю технологію від моєї компанії, то вам всім капут, бо тільки ця технологія може дати те, що вам треба, а інші технології — просто шлак.
Натомість для DA не буде нічого поганого, якщо на конференції перед великою аудиторією він скаже: «Ця технологія має свої недоліки». Немає ідеального продукту, проекту чи ідеальної технології. DA має розуміти недоліки продукту, в яких випадках не варто його використовувати, які є нюанси використання в тому чи іншому середовищі.
У DA немає необхідності продати технологію, в негативному сенсі слова. Коли ти спілкуєшся з аудиторію, то маєш не тільки підкреслити позитивні риси технології, а передати все максимально об’єктивно. Твоя робота — зацікавити людей, яким це потрібно, і щоб люди, яким не цікаво, все одно звернули увагу на цю технологію, з усіма її перевагами і недоліками. Можливо, через певний час у них буде потреба в чомусь подібному. В іншому випадку, ти просто збережеш їх від купи витрачених нервів.
Я не продаю продукт, але ми зацікавлені в тому, щоб в нас зростала спільнота, кількість людей, які зацікавлені продуктом. З цією метою звертати увагу на недоліки навіть краще. Адже в контексті оупенсорсних продуктів людина, яка хоче контриб’ютити, зверне увагу: в цій технології є такі-то нюанси, які працюють неідеально. І вона, маючи досвід вирішення подібних питань у комерційній компанії, прийде в оупенсорсний проект і буде йому допомагати.
Якщо ми говоримо про великі компанії, то вони знають, що, наприклад, технологія «А» не вміє робити цього. Вони можуть побудувати комерційний продукт, вирішуючи це питання. За найкращого сценарію, компанія знайде рішення, і воно буде оупенсорсним.
Місток між розробниками і користувачами
Уявіть собі звичайний міст між берегами річки. Люди і машини не ходять винятково в одному напрямку — це шлях, де рухаються в обидва боки. Так само і ми, DA, є цим містком, який дозволяє фахівцям з технологічного середовища спілкуватися з людьми з бізнесу — і навпаки. До того ж це рух навіть у не два, а в енну кількість напрямків.