Async Communication for Distributed Teams: English for Remote-First Engineering (англійською)
Англійський словник і фрази для асинхронного спілкування у розподілених командах: написання чітких оновлень, документування рішень, розблокування за допомогою повідомлень і уникнення залежностей у реальному часі.
Віддалені інженерні команди працюють на асинхронному зв’язку - письмових повідомленнях, які можна читати і відповідати на них у різних часових поясах, не вимагаючи, щоб всі були онлайн одночасно. Якість асинхронного зв’ язку визначає, наскільки швидко може рухатися розподілена команда. Добре написане повідомлення Slack може розблокувати колегу в Сингапурі без зустрічі. Погано написане створює ланцюг питань, що додає день затримки до рішення. Для людей, для яких англійська не є рідною мовою, написання ясних, повних, контекстно багатих асинхронних повідомлень є одним з найважливіших навичок спілкування, які потрібно розвивати.
Ключовий словник
** Асинхронне (асинхронне) спілкування ** Комунікація, яка не вимагає негайної, одночасної участі — повідомлення, документи і коментарі, які можна прочитати і відповісти на них за бажанням отримувача.
“Ми типово використовуємо асинхронне спілкування для всього, що не вимагає співпраці у реальному часі — це враховує різні часові пояси і дає людям час подумати перед тим, як відповісти.”
** Контекстно- багате повідомлення ** Асинхронне повідомлення, яке містить достатньо інформації, щоб адресат міг зрозуміти його і виконати відповідні дії без необхідності задавати питання.
“Контекстне повідомлення містить інформацію про те, над чим ви працюєте, що вам потрібно, чому вам це потрібно, і що ви вже спробували.”
** Документація щодо рішення ** Практика запису не тільки того, що було вирішено, але і чому — включаючи розглянуті варіанти, обговорені компроміси і фактори, що призвели до остаточного вибору.
“Документація правильного рішення означає, що інженери, які приєднаються до команди через шість місяців, зможуть зрозуміти, чому система розроблена таким чином.”
Отблокировать Видалити перешкоду, яка перешкоджає комусь досягти прогресу — ключовий результат асинхронного спілкування у розподілених командах.
- “Я заблокований у контракті API — чи можете ви підтвердити, що відповідь буде містити метадані сторінкування? Мені це потрібно, щоб продовжити з реалізацією клієнта.”*
Нітка Це ланцюжок повідомлень на певну тему, які упорядковано так, щоб обговорення не втрачалися у загальному каналі.
- “Треба вести обговорення у гілки, а не у головному каналі — це полегшить людям, які приєднаються пізніше, вивчити контекст.” *
Сигнал-шум співвідношення Пропорція корисної, актуальної інформації в каналі зв’язку відносно неактуальних, низькоцінних повідомлень — команди оптимізують для високого співвідношення сигналу до шуму в асинхронних каналах.
“Ми перенесли архітектурні рішення з загального каналу Slack і в спеціальні потоки рішення - це значно поліпшило співвідношення сигналу до шуму.”
Оновлення стану Коротке, регулярне повідомлення, яке повідомляє колегам про те, над чим ви працюєте, що завершено і що заблоковано — це важливо у асинхронних командах, де для видимості слід використовувати явне повідомлення.
- « Оновлення стану наприкінці дня означає, що колеги з інших часових поясів можуть продовжити роботу з того місця, де ви її припинили, не чекаючи, поки ви під’ єднаєтеся до мережі. » *
Корисні фрази
** Написання контекстно- багатого повідомлення: **
“Контекст: Я реалізую поток автентифікації користувача і я отримав запитання про закінчення сеансу. Що я знаю: сервер встановлює JWT з 1- годинним терміном дії. Що мені потрібно знати: чи має інтерфейс беззвучно оновлювати токен, якщо користувач активний, чи перенаправляти на вхід? Що я перевірив: у документації API цього не вказано, а у старій реалізації не було логіки оновлення. Я хочу реалізувати це правильно, перш ніж я буду будувати поток перенаправлення»
** Документування рішення: **
«Рішення: ми використовуємо PostgreSQL замість MySQL для нового сервісу. Розглянуті варіанти: PostgreSQL, MySQL, CockroachDB. Причина: наша команда має більший досвід роботи з PostgreSQL, і нам потрібна підтримка JSONB для гнучких полів документа. Компроміс прийнятий: ми втрачаємо деяку сумісність з MySQL-заснованим аналітичним конвеєром — команда аналітики знає і має узгоджений варіант вирішення проблеми»
Подняти блокер:
« Заблоковано: неможливо продовжити налаштування тесту інтеграції доки не буде створено середовище перевірки. Я жду с понедельника. Може хтось з інфраструктурної команди підтвердити ETA? Я можу працювати над іншими завданнями в той час, але це на критичному шляху до мети спринту»
** Надання асинхронного оновлення стану: **
Процитовано 2011-07-24. EOD update: completed the data model migration (PR #247 open for review). Почато на кінцевій точці API — приблизно 60% виконано, завершиться завтра вранці. Без блокаторів. Одне питання в коментарях PR для [ім’я] — не терміново, можна почекати до ранку»
** Уникнення залежності реального часу: **
«Я не думаю, що нам потрібен виклик для цього — я написав два варіанти з компромісами в посиланні на документ. Якщо ви можете додати ваші переваги і аргументи як коментар, я можу зробити останній вибір і продовжити. Це дозволяє нам рухатися без необхідності шукати місце для зустрічі в різних часових поясах»
Поширені помилки
** Недостатньо контексту, щоб заощадити час ** За іронією долі, написання коротших повідомлень для економії часу часто коштує більше часу в цілому — отримувач повинен задати прояснюючі питання, створюючи затримку в обертання годин або днів в розподіленій команді. Дисципліна асинхронного зв’язку - це написання довшого повідомлення вперед. Повідомлення з повним контекстом, написання якого займає 10 хвилин, може заощадити 3 години перегляду.
Оставляя вопрос неясным Багато асинхронних повідомлень описують ситуацію без запитання конкретного питання: * “Я дивився на архітектуру кешування і здається, що є деякі проблеми з логікою анульування.” * Це твердження, а не запит. Будьте чіткими щодо того, що вам потрібно: * “Я розглядав архітектуру кешування і думаю, що у логіці анульування може бути помилка. Чи можете ви переглянути мій аналіз у пов’язаній документації і дати мені знати, чи моє розуміння запланованої поведінки є правильним?»*
** Використання мови реального часу для асинхронних запитів ** Такі фрази, як * « не могли б ви швидко подивитися » * або * « повідомте мене якомога швидше » * створюють враження невідкладності, яке може не відповідати справжньому пріоритету, і може сприйматися колегою, що перебуває у іншому часовому поясі, як тиск. Вкажіть фактичні часові рамки: * « Не поспішай з цим — будь- який час протягом наступних 48 годин працює. Якщо це займе більше часу, просто дайте мені знати, щоб я міг знайти альтернативу»
У розподіленій команді, написання є головною інженерною поверхнею — якість вашого асинхронного зв’ язку буде настільки ж видимою для ваших колег, як і якість вашого коду.
Введення в лексику: лексика для немовлят
Ефективне спілкування по часових поясах і культурах є основним викликом дистанційної інженерії. Крім простого передачі інформації, це стосується того, щоб зробити це з точністю - використовуючи мову, яка мінімізує неоднозначність і поважає різні стилі спілкування. Для не-рідних носіїв англійської мови, це може відчуватися особливо пригнічуючим, не тільки через граматичні нюанси, але і через специфічний словник, використовуваний в професійних умовах. Давайте розглянемо деякі ключові області, де цілеспрямована фраза може значно поліпшити ваш вплив як віддаленого інженера.
Однією з поширених перешкод є надання зворотнього зв’язку під час перегляду коду. Просте «Це виглядає добре» не пропонує багато порад. Замість цього, використовуйте такі фрази, як « Ця реалізація відповідає специфікації проекту — чудова робота над логікою перевірки даних! » або « Я ціную ясність цього розділу; однак, чи можемо ми додати коментар, у якому буде пояснено причину використання Promise.all у цьому розділі? » Зауважте, що у тексті використано такі терміни, як « специфікація проекту » і « причина », які часто використовуються у дискусіях з інженерних питань. Також важливо визнати зусилля: « Код добре структурований і простий у використанні — чудова робота з переробки цього модуля ». Уникнення надмірно неформальної мови, навіть коли пропонується похвала, демонструє професіоналізм і надає цінний контекст. Аналогічно, якщо вам потрібно попросити про пояснення, уникайте фраз на кшталт « Я не розумію ». Спробуйте щось більш конструктивне, наприклад, « Чи можете ви розібратися з метою функції calculateTotal? » або « Я намагаюся зв’ язати цю зміну з загальною архітектурою — чи можемо ми обговорити її інтеграцію? »
Слабкі розмови часто вимагають коротких і реальних оновлень. Замість того, щоб сказати « Просто працюю над цим », що є нечітким і не передає значення терміну, спробуйте « Працюю над вирішенням проблеми з’ єднання з базою даних — очікую виправлення за 30 хвилин ». Або, якщо ви пропонуєте рішення: « Я написав проект запиту на звантаження, щоб вирішити проблему з швидкодією за допомогою кешування. PR включає в себе докладні метрики, що демонструють його вплив. » Використання таких термінів, як «в’язка», «метрики» і «PR» (запит на витяг) демонструє знайомство з звичайними інженерними потоками. Важливо завжди підтверджувати залежності — « Очікування зворотнього зв’ язку щодо інтеграції API перед продовженням ». Це активне спілкування запобігає непорозумінням і забезпечує, щоб усі були в одному напрямку.
Нарешті, пам’ ятайте, що документація є основою асинхронного співробітництва. При описі рішення або технічного підходу у документі, надавайте перевагу ясності і точності перед розмовними виразами. Замість того, щоб сказати « Ми тільки що зрозуміли цю проблему », напишіть « Після ретельного дослідження, ми визначили, що корінною причиною помилки є … » Ця структурована мова забезпечує, що кожен розуміє обґрунтування рішення і може легко звернутися до нього пізніше. Спрямування уваги на формальний словниковий запас і чітку структуру речення значно підвищить вашу здатність ефективно співпрацювати з іншими учасниками команди.