Словник для фахівців з розвитку відносин

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

---

Досвід розробки (DX)

** Досвід розробника ** (DX) стосується того, як розробники відчувають себе під час використання продукту, API, SDK або платформи - легкість запуску, якість документації, ясність повідомлень про помилки і загальна продуктивність, яку забезпечує інструмент.

• “Наше опитування розробників показало, що головною проблемою є неясні повідомлення про помилки. Розробники не могли сказати, чи вони неправильно налаштували SDK або вдарили відому помилку.”*
• “Хороший досвід розробника схожий на хороший UX, але користувач є розробником. Кожен непотрібний крок в onboarding є конверсією, яку ми втрачаємо.”*

---

Adoption

** Прийняття ** в DevRel відноситься до прийняття продукту, API або SDK розробниками. Зазвичай це вимірюється через реєстрації, API виклики, активні інтеграції і метрики зростання спільноти.

“Прийняття v2 API було сильним — понад 3000 активних інтеграцій протягом трьох місяців з моменту запуску.”

• “Ми виявили, що прийняття відмовилося після початкової реєстрації. Розробники реєструвалися, але не завершували навчальний курс « Hello World ». Це те, на чому ми зосередили наші зусилля по поліпшенню.»*

---

Champion

** Чемпіон ** (або чемпіон розробників) — це розробник у компанії або спільноті, який активно підтримує вашу платформу, говорить про неї на заходах, пише про неї і впливає на колег, щоб вони прийняли її.

• “У нас є шість зовнішніх чемпіонів, кожен з яких створив публічні проекти за допомогою нашого API. Вони посилюють наш досягнення далеко за те, що наша внутрішня команда може досягти.” * “Програми Champion, як правило, включають ранній доступ до нових можливостей, прямі канали до команди продукту, а також підтримку з конференційними розмовами і блоговими записами.”

---

Evangelism

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

• “Євангельське слово розробників полягає у створенні справжнього ентузіазму, а не в проведенні кампаній з продажу. Розробники можуть сказати різницю.”* “Наша євангелістська стратегія зосереджена на показі, а не розповіді - живі демо, відкриті прикладні проекти і покрокові навчальні матеріали, які вирішують справжні проблеми.”

---

Зворотний зв’язок

** Цикл зворотнього зв’ язку ** в DevRel є процесом, за допомогою якого вхід розробника - болючі точки, запити на функціональність, збої і похвала - захоплюються, пріоритизуються і відправляються назад до продукту і інженерних команд.

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

• “Швидкий цикл зворотнього зв’ язку є конкурентною перевагою. Якщо розробники знають, що їхній зворотній зв’язок призводить до дій, вони залучаються більш відкрито і чесно. “*

---

Friction

** Тертя ** стосується будь- чого, що ускладнює розробнику початок роботи або використання продукту — складне розпізнавання, погана документація, заплутані повідомлення про помилки, надмірна кількість обов’ язкових полів або повільні відповіді API.

• “Ми зменшили тертя під час впровадження, замінивши наш трикроковий процес налаштування API- ключів на середовище пісочниці з одним клацання. Час до першого успішного виклику API зменшився з 45 хвилин до 8.”*
• “Кожна точка тертя у подорожі розробника є потенційним відхиленням. Ми мапуємо всю подорож і приоритизуємо видалення найвищих кроків тертя. “*

---

Onboarding

** Впровадження ** у DevRel стосується процесу отримання новим розробником з нуля до їх першого успішного використання вашого продукту — ідеально, якомога швидше і гладше. «Час до першого hello world» (TTFHW) є звичайною метрикою.

• “Наша процедура реєстрації складається з трьох кроків: створення облікового запису, створення ключа API, запуск прикладного коду. Кожен крок має коротке відео і фрагмент коду копіювання-вставлення.”*
• “Ми переробили процес запуску на основі записів сеансів. Більшість відмов відбулося на другому кроці — сторінка ключа API була заплутаною щодо того, який ключ використовувати для пісочниці. “*

---

Система управління проектами (SDM)

SDK це набір бібліотек, інструментів, документації та прикладного коду, який розробники використовують для створення API платформи. Добре розроблений SDK абстрагує складність API і обробляє автентифікацію, обробку помилок, повторні спроби і серіалізацію.

“Ми публікуємо SDK для Python, JavaScript, Java, Go і Ruby. Python SDK має понад 40 000 щотижневих завантажень на PyPI.” “Відмінний SDK невидимий — розробники використовують його, не думаючи про те, як він працює. Погана SDK змушує розробників читати початковий код, щоб зробити базовий виклик.”

---

Підтримка розробників

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

“Моя роль як представника розробників має два напрямки: зовнішній (допомога розробникам досягти успіху з нашою платформою) і внутрішній (донесення відгуків розробників до команди продукту).”

---

Практичні фрази для DevRel професіоналів

• • “Впровадження відстає, тому що в потоці впровадження є занадто багато тертя. Нам потрібно отримати час-до-першого-API-виклику менше десяти хвилин.”*
• “Наша програма чемпіонів була ініціативою з найвищим ROI цього кварталу. Чемпіони створили дванадцять блогів і чотири конференції.”
• • “Перетвірка повідомлень про помилки свідчить про те, що повідомлення про помилки є найважливішою проблемою. Це те, на чому інженерія повинна зосередитися далі.»*
• “Досвід розробника не є м’якою метрикою — він безпосередньо корелює з прийняттям, збереженням і словом-з-у-уста.”
• “Євангельське служіння працює, коли ви справді вирішуєте проблеми для розробників, а не просто рекламуєте свій продукт.”

---

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

Розробка мови: підтримка для не-національних розробників

Світ відносин з розробниками стає все більш глобальним, і це означає, що наша аудиторія відображає величезний спектр мовного походження. Хоча вільна англійська мова часто приймається, багато розробників, що приїжджають з інших країн, швидко розвивають свої професійні навички спілкування - і це простягається далеко за рамки простого написання коду. Зрозуміти нюанси технічного словника, особливо при створенні ясних і переконливих повідомлень, може бути значною перешкодою. Це не просто переклад слів; це передавання намірів, тону і контексту таким чином, що резонує з міжнародною аудиторією, особливо з тими, хто все ще розвиває свою вправність в англійській мові. Для не-рідних носіїв, освоєння фраз, пов’язаних з співпрацею, зворотним зв’язком і стратегічним спілкуванням, є ключовим для ефективного вкладу в спільноти розробників. Сфокусування на активному голосі, уникнення надто складних структур речень і розуміння тонких відмінностей у тому, як такі поняття, як «оптимізація» або «масштабованість» сприймаються в різних культурах, може значно поліпшити ясність і прийняття. Крім того, визнання того, що прямі переклади часто не досягають - технічний термін може мати кілька інтерпретацій залежно від регіонального використання - є важливим для створення справжніх зв’язків.

Розглянемо звичайний сценарій: коментар перегляду коду. Уявіть, що розробник з Японії відповідає на зворотній зв’ язок щодо запитів на збирання. Прямий переклад «Ця функція могла б бути більш ефективною» може не вийти добре. Замість цього, формулювання його як «Чи можемо ми дослідити оптимізацію продуктивності цієї функції?» або навіть краще, «Я помітив деякі потенційні вузли тут; давайте обговоримо, як ми можемо поліпшити ефективність цього розділу» демонструє обізнаність і запрошує до спільної дискусії, а не звучить як критика. Аналогічно, в розмовах Slack, де обговорюються темпи прийняття, сказати щось на зразок “Ми повинні звернути увагу на точки тертя, які користувачі відчувають під час набору” є більш ефективним, ніж просто сказати “Набір потребує поліпшення.” Останнє не має контексту і не запрошує рішення. Будівництво словника навколо проактивного вирішення проблем - ідентифікація викликів (“болючі точки”), запропоновані рішення (“стратегії зменшення”), і запитання зворотнього зв’язку (“збір користувацьких вражень”) - є ключем до успішних відносин з розробниками.

Інша поширена ситуація включає написання PR описів для нових випусків SDK. Розробник з Німеччини може стикатися з фразою «прийняття на ринок» - це звучить майже маркетингово-центрично. Замість цього, більш нейтральним і інформаційним підходом буде: “Це видання розширює функціональність SDK, пропонуючи розробникам розширені можливості для інтеграції [назва продукту] в їхні програми.” Сфокусування на * що * видання робить, а не * як * воно буде використовуватися іншими, може зменшити неоднозначність для тих, хто менш знайомий з англійською промо-реторикою. Це про перехід від підтримки концепції до опису функції і її переваг в ясному, фактичному вигляді.

# Example: Using `git diff` to highlight changes in a pull request description
git diff --cached --summary

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