Англійська мова для технічних євангелістів: конференційні розмови, демо-версії та будівництво спільноти

Технічний редактор журналу «Економіка»

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

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

Конференційний словник

Крюк

Перші 60 секунд будь-якої розмови повинні захопити увагу аудиторії. Цей розріз називається гаком.

Хороші гачки можуть мати декілька форм:

• Дивовижна статистика: «Торік, 43% виробничих інцидентів у компаніях в нашому дослідженні були викликані однією зміною конфігурації»
• Проблема, що пов’язана з цим: «Якщо ви коли-небудь зневаджували розподілену систему о 2 годині ранку без слідів, ця розмова для вас»
• Смілива заява: «Я покажу вам, що ви можете виключити всю категорію помилок виконання з однією функцією мови»

** Корисні фрази: **

• «Я хочу почати з питання, яке не давало мені спати вночі…»
• «Ось що здивувало мене, коли я вперше побачив дані…»
• “Підніміть руку, якщо ви коли-небудь переживали [проблему]…”

Розповідає про живу демонстрацію

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

Шаблони оповіді:

• “Тоді те, що я роблю тут, це створюю новий [компонент/сервіс/кінцева точка]…”
• «Зауважте, що я не зробив [X ще] — це навмисне, і ви побачите чому за хвилину»
• “Дай я запустю це зараз і покажу тобі, що відбувається…” [пауза] “…і ось вихід.”
• Якщо щось тут не так — і це може статися, це наживо — я покажу вам, як це зневаджувати»

** Фрази для відновлення (коли щось ламається): **

• “Це насправді чудова можливість показати вам повідомлення про помилку, яке ви, ймовірно, побачите…”
• “Дай мені перевірити тут журнали…”
• «Я переключуся на резервне середовище і ми можемо продовжувати — саме тому у нас завжди є план Б»

Вони охоплюють широкий спектр питань і проблем

• “Це дійсно хороша точка зору. Коротка відповідь - [X]; довша відповідь включає [Y], яку я з радістю обговорю після розмови»
• «Ви праві, що [треба турбуватися] — це справжній компроміс. Ось як команди зазвичай вирішують це…»
• «Я не маю впевненої відповіді на це зараз, але я дізнаюся і опублікую це в спільноті Slack»

Словниковий словник

** Чемпіон ** — член спільноти, який активно пропагує вашу платформу, інструмент або проект іншим. « Нашим найефективнішим каналом зростання є слово з уст чемпіонів у командах інженерів підприємства. »

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

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

Годи офісу — запланована сесія відкритого формату, де члени спільноти можуть задавати питання і отримувати допомогу. «Ми проводимо щотижневі години офісу розробників на Discord кожної середи»

** Посібник щодо внесення внесків ** — документація, яка пояснює, яким чином зовнішні співробітники можуть надсилати покращення до проекту з відкритим кодом. « Чисті посібники щодо внесків значно зменшили труднощі для тих, хто вперше робить внесок. »

DX (Developer Experience) — загальний досвід використання платформи, SDK або API з точки зору розробника, що включає документацію, інструменти, повідомлення про помилки і впровадження.

П’ять прикладів речення

1. «Я хочу почати з гачка: минулого року розробники в нашій спільноті повідомили, що витрачають в середньому чотири години на тиждень, борючись з їхнім місцевим середовищем розробки»
2. «Поки я це налаштовую, я розповім, що робить кожен крок, щоб ви могли слідкувати, навіть якщо ви не можете чітко бачити мій екран»
3. «Це справедливий виклик — підхід, який я показую, додає деяку початкову складність, але він відплачується у скороченому часі зневадження протягом життя проекту»
4. «Наша програма чемпіонів працює вже шість місяців, і ці 20 спільних адвокатів привели до більшого прийняття, ніж весь наш платний рекламний бюджет»
5. «Ми затягнули петлю зворотнього зв’язку, додавши механізм голосування до нашої публічної дорожньої карти, щоб спільнота могла безпосередньо впливати на те, які функції ми ставимо на перше місце»

Структуруйте свою розмову

Найпростіша надійна структура для технічної розмови: Проблема → Рішення → Демонстрація → Виклик до дії. Начните с того, чтобы зрители почувствовали боль от проблемы. Покажіть своє рішення концептуально. Покажите, как это работает в демо. Закрити з чітким наступним кроком — спробувати навчальний посібник, відкрити сховище, приєднатися до Discord.

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

Розширення вашого лінгвістичного набору інструментів: англійська для ненаціональних технічних євангелістів

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

Давайте будем честными. Бути технічним євангелістом - це не просто знати свій продукт зсередини і ззовні; це про те, як ясно і переконливо повідомляти ці знання різноманітним аудиторіям. А для не-рідних носіїв англійської мови, це може дати унікальний набір викликів - не тільки навколо граматики і мови, але також навколо конкретного словникового запасу і фразування, що використовуються в професійних середовищах розвитку. Легко впасти в шаблони, які не резонують з аудиторією, що призводить до непорозумінь або втрачених можливостей.

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

Крім того, оволодіння етикетом Slack - швидкі, короткі повідомлення є життєво важливими - вимагає ретельної фразування. Замість того, щоб вводити « Чи можете ви подивитися на це? », спробуйте « Чи можете ви переглянути долучені PR на предмет потенційних проблем з продуктивністю? » Різниця невелика, але вона демонструє професіоналізм і повагу до часу ваших колег. Навчання вираження складних ідей коротко в межах обмеженої кількості символів є цінним вмінням само по собі. Задумайтеся про те, як ви описали б проблему - уникаючи жаргону і зосереджуючись на * впливі * («Ця помилка спричиняє періодичні переривання обслуговування») завжди буде ефективніше, ніж просто сказати «Є проблема з сервером»

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

Ось приклад того, як ви можете використовувати git для ілюстрації точки зору щодо стратегій розгалуження:

# Creating a new branch for feature development
git checkout -b feature/new-authentication

# After making changes...
git commit -m "Implement user authentication flow"

# Pushing the branch to the remote repository
git push origin feature/new-authentication

Ця проста команда демонструє основний робочий процес, і пояснює його чітко: «Ми створили нову гілку з назвою «feature/new-authentication», щоб ізольувати нашу роботу над системою автентифікації. Я зафіксував зміни з описовим повідомленням, і відштовхнув гілку до віддаленого сховища для співпраці. ” – є набагато ефективнішим, ніж просто вказувати саму команду. Він демонструє розуміння концепцій контролю версій і полегшує комунікацію.