Як писати ефективні Slack повідомлення в технічних командах
Як чітко спілкуватися на Slack в асинхронних технічних командах — відповіді на гілки, @згадки, чіткі CTAs, уникнення непорозумінь і професійний тон.
Slack (і подібні інструменти, такі як Teams або Discord) стали основним каналом комунікації для більшості технічних команд. Для людей, для яких англійська не є рідною мовою, Slack представляє унікальні виклики: повідомлення короткі, контекст часто відсутній, а тон важко прочитати без виразу обличчя або голосу. Повідомлення, яке здається прямим у вашій мові, може бути незграбним у англійській, а повідомлення, яке здається ввічливим, може бути настільки непрямим, що ніхто не буде діяти відповідно до нього.
Цей посібник надає вам мову і структуру для чіткого і професійного спілкування у асинхронних середовищах Slack.
Основні принципи ефективного Slack повідомлень
1. Європа Ведучий з пункту
У Slack люди сканують, а не читають. Поставте найважливішу інформацію спочатку.
Неясно:
“Гей! Я смотрел на поток развертывания и заметил кое-что. Я не впевнений, чи це помилка або навмисна поведінка, але я хотів позначити це, тому що це може бути актуальним для того, що ми обговорювали в Standup. ”
** Чисто: **
- “Для вашого відома: конвеєр розгортання не працює на PR, які торкаються каталогу
config/. Я бачу його постійно з 14:00. Чи це відома проблема?»*
2-й. Одне повідомлення, одне запитання
Не об’ єднуйте декілька не пов’ язаних між собою запитів у одне повідомлення. Кожен запит має мати власне повідомлення або гілку, щоб його можна було відстежувати і відповідати на нього незалежно.
3. Використовувати гілки
Відповідати у гілках, щоб канали було легко читати. Почати нове повідомлення верхнього рівня для нової теми. Відповісти у гілки для продовження існуючої гілки.
- “[Повідомлення верхнього рівня] Служба автентифікації повертає 503. Розслідування ведеться»
- “[Відповідь гілки] Виявлено кореневу причину: купа з’ єднань Redis була вичерпана. «Зараз йдемо»
- “[Відповідь на гілочку] Виправлено у виробництві. Мониторинг на наступні 15 хвилин
Запис чистих запитів
Коли вам щось потрібно від когось, ваше повідомлення має бути безпомилково чітким.
Використовувати явні виклики до дії
- “Чи не могли б ви переглянути цей PR до кінця дня? URL: (англ.)
- “Будь ласка, підтвердіть, чи цей підхід виглядає правильно, перш ніж я почну реалізацію.” *
“Чи може хтось, хто має доступ до консолі виробничого AWS, перевірити, чи завдання все ще запущено? @[назва] або @[назва]“
Встановіть терміни, коли вони важливі
“Нам нужно принять решение по этому вопросу до встречи по планированию в 15:00.”
“Не поспішай з цим — будь-коли, коли у тебе буде 10 хвилин на тиждень, буде добре.”
Використання @mentions коректно
@person
Скористайтеся цим, щоб надіслати повідомлення одній особі.
”@ Alex — чи не могли б ви подивитися на помилку CI у вашій гілки, коли з’ явиться така можливість?”
@here
Сповіщає всіх, хто зараз активний на каналі. Використовуйте обережно.
”@ тут — середовище перевірки не працюватиме через технічні проблеми протягом наступних 30 хвилин.”
@channel
Сповіщає всіх членів каналу, включаючи тих, кого немає на каналі. Використовувати лише для дійсно невідкладної інформації, що стосується всього каналу.
- ”@ канал — у нас є інцидент P1. Служба оплати повертає помилки для всіх користувачів. Всі інженери на гарячому, будь ласка, приєднайтесь до каналу інциденту.”*
** Поширена помилка: ** Використання @ каналу для негайної інформації. Це навчає людей ігнорувати @channel, роблячи його менш ефективним для справжніх надзвичайних ситуацій.
Тон і ввічливість в асинхронних повідомленнях
В англійській професійній культурі, додавання невеликої кількості м’якої мови зазвичай очікується - особливо при виставленні запитів. Однак, не перебільшуйте до точки, де ваше запитання стає неясним.
Хороші м’які фрази
- “Когда у тебя будет шанс, ты можешь…” *
- “Не поспішай, але можеш поглянути на…” *
“Швидке питання - чи знаєте ви, що…”
- “Я можу щось пропустити, але…” *
Уникнути нерозуміння
Короткі повідомлення без привітання або контексту можуть бути прочитані як короткі або грубі, особливо в міжкультурних командах.
Занадто різко
“Выправить ошибку.”
Краще
- « Привіт, [ім’ я], чи не могли б ви подивитися на ваду у випуску # 214, коли у вас буде на це час? Це блокує випуск.»*
** Уникайте сарказму. ** Сарказм у тексті легко неправильно розглядати, особливо у різних культурах:
- « О, чудово, ще одна зміна налаштувань, яка все пошкодила. » * — Це може здатися нешкідливим розчаруванням, але це може бути ворожим або пасивно- агресивним.
Корисні фрази для звичайних ситуацій
Актуальні новини
- “Швидке оновлення: перенесення завершено о 14: 30. Досі не спостерігалося проблем».*
*“Все еще расследую. Буде опубліковано оновлення через 30 хвилин. *
*“Решено. Основною причиною було [X]. «Завтра буде краще» (фр
Прохання про допомогу
“Я застряг на [проблема] і міг би використати другу пару очей. Проблема в [короткий опис]. Чи буде хтось вільний на 10-хвилинний дзвінок?»
- “Чи хтось раніше стикався з цією помилкою? [вставити повідомлення про помилку]. Я перевірив [те, що ви спробували], але не вдалося»
Обмін інформацією
“Для вашого відома — нові обмеження швидкості почнуть діяти з понеділка. Перевірте оновлену документацію API: [посилання]”
- “Вам варто знати: сьогодні ми злиємо велику гілку рефакторингу. Очікуйте деякий шум в системі збирання.»*
Закриття гілки
“Дякую всім — вирішено. Закриваю цю гілочку.”
«Це тепер відстежується у квитку Jira [ІД] — переміщення розмови туди.»
Спілкування у режимі Clear Slack — це професійна навичка, яка має значний вплив на вашу репутацію у віддаленій або гібридній команді. Інженери, які пишуть чітко на Slack - конкретні, орієнтовані на дії, відповідно короткі - легше працювати з ними і, як правило, отримують швидші відповіді. Взаємозв’ язки в цьому посібнику вимагають практики, але швидко стають другою природою.
Навигація по сторінках: Посібник для ненаціональних розробників
Ефективне спілкування в технічній команді сильно залежить від точної мови. Для розробників, чия перша мова не є англійською, Slack може відчувати себе особливо пригніченим - це швидкоплинне середовище, наповнене швидкими обмінами, де тонкий вибір слів може значно вплинути на розуміння і співпрацю. Це не просто передавання інформації; це сигналізація про намір, демонстрація професіоналізму і будівництво відносин у команді. Розглянемо деякі конкретні проблеми і те, як до них підійти.
Однією з поширених перешкод є використання надто буквальних перекладів фраз. Наприклад, розробник може інстинктивно сказати «Я виправив цю помилку» під час обговорення коментаря перегляду коду. Хоча технічно точна, вона може звучати різко або навіть трохи вимогливо. Більш вишуканим варіантом буде « Я вирішив проблему у цьому звіті » — включення « Я » додає тон співпраці, а « вирішив проблему » є менш прямим, ніж « виправлено ». Аналогічно, замість того, щоб сказати « @ згадка користувача, я вважаю, що це потребує уваги », розгляньте « Чи можете ви, будь ласка, переглянути це? Здається, що це може потребувати деяких пояснень. “Останній підкреслює пошук допомоги, а не заперечення проблеми. Зверніть увагу на модальні дієслова — «should», «could» і «would» часто використовуються в запитах і пропозиціях, значно пом’якшуючи тон.
Інша область, де нюанси мають значення, це опис змін. Під час написання описів PR, уникайте надто технічного жаргону, який може не бути відразу зрозумілим для всіх членів команди. Замість того, щоб вказати « Реалізовано переробку для оптимізації розподілу пам’ яті », спробуйте щось на зразок: « Цей звіт покращує продуктивність за рахунок зменшення використання пам’ яті під час [визначеної дії]. Це повинно призвести до швидшого виконання часу.” Формування зміни з точки зору * переваг * - швидше виконання, зменшення споживання ресурсів - є більш доступним і підкреслює цінність роботи. Крім того, завжди включайте коротке резюме (або « tl; dr ») на початку вашого опису — коротке речення, яке описує основні зміни.
Нарешті, пам’ятайте, що Slack за своєю суттю неформальний, але професіоналізм все ще має значення. Хоча емоджи можна використовувати розсудливо, щоб додати контекст або виразити ентузіазм, уникати надмірного покладання на них, особливо в критичних дискусіях. Ясність і точність завжди є найважливішими. Якщо ви не впевнені в найкращому способі сформулювати щось, не вагайтеся запитати колегу про зворотній зв’язок - більшість команд цінують співпрацю і з радістю допоможуть вам в оточеннях ваших комунікаційних навичок. Просте «Чи могли б ви переглянути цю фразу, перш ніж я відправлю її?» демонструє самосвідомість і бажання забезпечити чітке розуміння.