×Закрыть

Як перестати сидіти в чаті та почати працювати. 10 практик асинхронної комунікації

Я вже 10 років розвиваю проєкти, команди та комунікацію в аутсорсингових і продуктових компаніях на позиції СОО. А останні кілька років консультую на теми корпоративної культури, People Operations і бренду роботодавця. Саме завдяки консалтингу побачила, як сильно проблеми внутрішньої комунікації з’їдають продуктивність і додають стресу. Найчастіше ще й роблять це непомітно.

Стаття буде корисна усім — від джунів до СхО і власників бізнесу, тому що комунікація — дуже важливий складник щоденної роботи. Проте особливо рекомендую PM’ам, тімлідам і керівникам, адже саме ви можете впровадити ці 10 практик на рівні команди або компанії.

А тепер задумайтесь, як часто ви ловите себе на цих думках?

  • Я чекаю на відповідь у чаті, й це затримує роботу.
  • Іноді пропускаю інформацію в чаті, тому що її там забагато.
  • Робота заблокована, бо маю довго чекати на відповідь.
  • Коли надходить завдання, треба витратити ще купу часу, щоб зрозуміти, що саме від мене хочуть.
  • Наявність червоних кружечків, непрочитаних повідомлень у чаті, не дає мені зосередитись. Маю перевірити, а раптом там щось важливе.
  • Пошук потрібної інформації в листуванні займає забагато часу і зусиль.
  • І те, що я чую найчастіше: «Не можу сконцентруватися на великому завданні, тому що мене часто відволікають».

Знайте, ви не самі :) Я нещодавно провела вебінар з асинхронної комунікації, і ось результати опитування 44 людей з ІТ:

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

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

У будь-якому разі прокачані практики асинхронної комунікації принесуть користь і збережуть нерви.

Синхронність і асинхронність

Але як би вас не злили нескінченні зустрічі чи непродуктивний чат, що весь час відриває від роботи, це лише симптоми. Причина цих проблем — неправильно налаштовані процеси синхронної та асинхронної комунікації та відсутній баланс між ними.

Що таке синхронна та асинхронна комунікація? Це той випадок, коли термін здається складним, а його значення дуже просте.

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

Асинхронна комунікація — це спілкування з відкладеною відповіддю. Наприклад, пошта, інструменти для управління проєктами, коментарі в репозиторіях на GitHub або в документах Google Docs, чат, у якому ніхто не чекає на швидку реакцію.

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

Є компанії, які працюють майже повністю ремоутно: Basecamp, Doist, GitLab, Zapier і Buffer. Вони, як правило, і є прихильниками здебільшого асинхронної роботи. Та більшість покладається на суміш синхронності й асинхронності.

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

У чому проблема, коли забагато синхронної комунікації?

  • Часто відриває від роботи, залишає мало часу для зосередження над складними завданнями.
  • Ставить перебування на зв’язку вище за продуктивність.
  • Збільшує кількість дискусій і часто зменшує їхню якість.
  • Часто призводить до неоптимальних рішень.

Та це не проблеми власне синхронної комунікації. Радше це недоречне її використання як інструменту.

Коли вона працює? Синхронна комунікація ефективна для:

  • зустрічей один на один або з командою;
  • надання фідбеку;
  • воркшопів та брейнштормів;
  • динамічних середовищ із багатьма змінними;
  • кризових ситуацій, що потребують негайної уваги.

Для всього іншого краще підходить асинхронна комунікація, але тільки правильно організована та органічно вбудована в робочі процеси.

Тож як прокачати асинхронну комунікацію на особистому, командному та корпоративному рівнях? Розберімо 10 практик, які справді працюють на будь-якому з них.

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

Починаємо з письмової комунікації. Тема холіварна, тож тримайтесь!

1. Оверкомунікуйте

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

Розберемо приклад:

У чому проблема з варіантом зліва?

  1. Створює купу додаткових питань (звіт із якого саме проєкту? У нас їх три). На ці питання треба буде витратити купу часу — і того, хто має виконати завдання, і того, хто дає його.
  2. Завдання буде виконане, але не те, що треба. Співробітник може не поставити жодного питання і зробити так, як вважає за потрібне. І тоді доведеться переробляти все спочатку.
  3. Не вказує термін виконання. Керівникам особливо важливо звернути увагу на цю проблему. Коли завдання прилітає від них, співробітник може відкласти насправді важливіші справи: «Омг, мені написав СЕО, то точно горить і треба зробити вже».

Варіант справа повністю розв’язує ці проблеми. Це десятки разів менше переробляння, змарнованого часу та нервів. У ньому є:

  1. Чіткі умови: обсяг, метрики, порівняння.
  2. Конкретні терміни (і не сьогодні на сьогодні).
  3. Референс необхідного результату, який значно спрощує виконання.

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

2. Заохотьте прокачку навичок письмової комунікації

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

Але сьогодні кожен має вміти зрозуміло писати, тому що ціна поганої комунікації занадто висока.

Розберемо кілька прикладів проблемної комунікації і з’ясуємо, як це поліпшити.

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

Ми повністю вирішуємо ці проблеми у варіанті справа.

  • Ближче до діла. У першому ж реченні є найважливіша інформація.
  • Є конкретні дати та час.
  • Завдання чіткі та структуровані.
  • Додано пояснення, чому це важливо.

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

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

Розберемо приклади.

Реакція на повідомлення зліва: мене про щось інформують. Прочитаю, як буде час.

— Ось новий макет банера. — Ну ок.

— Проблеми з коментарями. — В інтернеті так весь час.

— Ура, нове опитування. — Піду відкоркую шампанське (ні).

Реакція на повідомлення справа: від мене чогось хочуть, мені треба відгукнутися.

— Що думаєш про меми? — Ці меми вже застаріли, Карл!

— Що порадиш з коментарями? — Перевір налаштування користувачів у адмінці.

— Прошу заповнити до п’ятниці. — Ок, заповню.

А ще гірше, коли це масова розсилка, у якій має зреагувати лише кілька людей. У такому разі додайте їхні імена або затегайте.

Головне: якщо ви потребуєте від людини реакції, сформуйте запит.

3. Звертайте увагу на тональність повідомлень

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

Розберімо тональність на конкретному прикладі:

Схоже, Аня розізлила автора картки та зробила помилку. Що нам з цим робити?

У варіанті зліва ми:

  • постійно вказуємо на помилку, але не кажемо, як її виправити;
  • додаємо кілька риторичних запитань. А навіщо? :) Вони можуть засоромити отримувача, але теж не наближують до розв’язання задачі.

Загалом варіант зліва можна скоротити до «ти тупиш і дратуєш мене». Це справді може бути так, але знов-таки це непродуктивно.

У варіанті справа ми:

  • дякуємо за зусилля, вказуємо, що й чому треба зробити, щоб виправити ситуацію;
  • закріплюємо такий алгоритм у майбутньому.

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

До речі, дуже рекомендую використовувати підхід API = Assume Positive Intent:

Assume positive intent for whatever message you receive.

And then for messages that you put out, the reverse of this is: take the extra moment to consider how it might be misinterpreted or perhaps add a little extra fluff or, sort of, warmth to the message.

Ще один цікавий момент: у роботі з керівниками та менеджерами я іноді чую: «А чого це я маю писати тут „прошу-перепрошую-дякую“, якщо це їхня робота. За що мені дякувати весь час?».

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

TLDR: краще писати сухо (не плутати з грубістю), але по ділу, ніж «прошу-перепрошую», але до суті так і не дійти.

Поїхали далі! Прокачаємо менеджмент часу та інформації (це вже не така холіварна тема) за допомогою наступних практик!

4. Плануйте заздалегідь і дайте людям час на відповідь

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

Приклад:

Проблеми зліва

  • Ну що за питання, чи зараз ти вільний? По-перше, воно вимагає окремої уваги та відповіді. По-друге, більшість працівників на роботі весь час зайняті, не сидять і чекають такого повідомлення :) Переходьте одразу до справи, а колега, коли матиме час, відповість.
  • Дедлайн за годину. А що як людина має кілька зустрічей підряд або інше пріоритетне завдання?

Ключові моменти справа

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

5. Встановіть стандартний час реакції для кожної групи завдань

Швидкість відповіді у різних комунікаційних каналах залежить від особливостей бізнесу та навіть різних відділів компанії. Але в будь-якому разі ці правила мають узгоджуватися з реальними завданнями та бути прозорими. Наприклад, мати такий вигляд:

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

Також дійте відповідно до заданих стандартів. Не треба писати лист із 24-годинним стандартом реакції, а за три години пінгувати «чого ти досі не відповів?». Якщо завдання термінове, скористайтесь терміновим інструментом.

6. Налаштовуйте процеси так, щоб час очікування був продуктивним

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

Я часто починаю день з надсилання 5-8 запитів: прошу фідбек, чекаю відповідь на запитання, пропоную слоти для майбутніх зустрічей, надсилаю тексти на рев’ю тощо. Тоді перемикаюсь на uninterrupted time або вже заплановані заздалегідь мітинги. А вже в другій половині дня передивляюся всі відповіді на ранкові запити та реагую на них.

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

7. Підтримуйте доступність і прозорість інформації

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

Що ж варто документувати, а що ні? Для себе я визначила такий rule of thumb: якщо одне й те саме питання ставлять п’ять разів, відповідь на нього має бути в базі знань компанії або хендбуці.

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

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

Додатковий профіт для тих, хто вже має хендбук — це чудовий інструмент для поліпшення бренду роботодавця. Публікуйте його у вакансіях і на своєму сайті у розділі Careers і спробуйте скористатись ним, як магнітом: «свої» кандидати будуть притягуватись до вас. Я колекціоную хендбуки вже понад 7 років і зібрала їх у безкоштовній open-source бібліотеці Better Wiki. Наразі найбільш детальний міститься у GitLab (якщо роздрукувати, то вийде 7000+ сторінок!), а найбільш перечитаний мною — Basecamp.

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

8. Культивуйте process ownership

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

Історія тижневої давності, класика групових чатів, яка трапилась зі мною. Менеджер створив чат на 7 людей, з якими ми мали запустити опитування про employee engagement для всієї компанії. Перший alert для мене: навіщо так багато людей у груповому чаті? Адже це сповільнює робочу групу. Листування в чаті починалось зранку, в’яло протікало між зустрічами та різними таймзонами всіх 7 працівників і тривало 5 днів. Так продовжувалося б і далі, якби я не попросила менеджера призначити відповідального за процес. Хтось мав завершити непродуктивний чат, зібрати фінальні коментарі та надіслати зрештою це опитування.

Команда витратила десятки годин без власника процесу: в чаті було 7 людей і всі докладали зусиль протягом 5 днів. Після призначення ми запустили опитування вже наступного дня.

9. Оцінюйте людей за їхньою продуктивністю, а не швидкістю спілкування

Знаєте, які скарги я іноді чую від менеджерів? «Вже 30 хвилин у чаті від нього немає відповіді, де він вештається у робочий час?!». Нерідко ці питання вселяють думку, що швидкі відповіді — саме те, чого від нас чекають і за чим оцінюють. І ми починаємо перевіряти чат під час мітингів із командою, відповідати на повідомлення під час співбесід чи дзвінків із замовником — підтримувати стан «завжди онлайн», гублячи ефективність зустрічей і зосереджений час на виконання складних завдань без перемикання фокусу уваги.

Основний прогрес і цінність у більшості великих і складних проєктів створюється у блоках сконцентрованого робочого часу — uninterrupted time. Саме тоді люди пишуть код, створюють дизайн, продумують UX і знаходять нових клієнтів. Не відривайте їх від роботи без вагомої причини.

10. Підсилюйте довіру, незалежність і відповідальність

Без довіри асинхронна комунікація не працює. Однак контролюйте результати та у разі систематичного недотримання зобов’язань оперативно реагуйте. Проблеми з дисципліною на ремоуті можуть тільки підсилитись — не залишайте їх без уваги.

У своїй роботі з клієнтами я постійно повторюю: «Don’t judge many by mistakes of a few». Якщо хтось із колег мав проблеми із самоорганізацію чи дисципліною під час роботи пліч-о-пліч в офісі, то на ремоуті й при асинхронній комунікації вони, як правило, тільки поглиблюються. Вирішуйте це безпосередньо зі співробітником, але не на рівні компанії.

Часто чую від керівників, що якщо частина співробітників зловживає довірою, а команда страждає від недотримання колегами свого слова, то «й довіряти всім не можна». І тоді, наприклад, забирають можливість працювати віддалено чи гнучкий графік роботи або знову переходять на оцінювання продуктивності за перебуванням онлайн (як у 9-му пункті), а не якісними результатами. Не треба так.

Підсумки

Кожна з цих 10 практик могла б бути окремою статтею, а поради з ефективної письмової комунікації — книгою :) Тож впроваджуйте їх по одній! Оберіть тему, яка вам найбільше болить, і почніть зміни із себе чи зі своєї команди, пробуйте, помиляйтеся й вчіться з помилок, діліться результатами. Якщо все вдалося — переходьте до наступної практики.

У мене в роботі є місія — make work a better place! І щиро вірю, що ефективна і добре побудована комунікація в компанії — важлива для цього запорука.

Додатково дуже раджу почитати підбірку ремоут гайдів на Better Wiki, у яких багато уваги приділено саме асинхронній комунікації:

А ви ведете холівари про письмову комунікацію? Які з цих практик у вас працюють, а які ні? Поділіться у коментарях!

LinkedIn

37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дякую за такі цікаву та корисну статтю!

Спасибо, отличный контент и собранные воедино правила, подсказки! + оформление. Пишите еще!

Дякую щиро за такий відгук! Буду писати й надалі :) У мене багато статей ще в особистому блозі тут: makeitbetter.me/blog

Гарний матеріал. З одного боку — ніби нічого нового, але такі нагадування 100% потрібні. Дякую.

Ще можна додати, що повідомлення в чаті варто писати одним цілим, а не розбивати на декілька. Тобто в одному повідомленні формулювати своє питання / прохання з усіма уточненнями, а не:
1: привіт
2: маю ще таке питання
3: JIRA-123 вже пройшло ПО рев’ю?
Відповідно Slack постукає мені один раз, а не три.

Ну і варто ще загадати про спеціалізований сайт www.nohello.com 🙂

Андрію, дякую тобі, в точку! додам до статті-гайду по Слаку :)

Актуально і корисно :) Дякую, що зібрала в одній статті ці ключові пастки.
Шкода, що не всім це очевидно, інколи усю комунікацію вибудовують в чаті..

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

Очень круто, спасибо! Будем внедрять и у нас)

Тетяно, дякую! То є найприємніший відгук для мене, що будете впроваджувати практики асинхронної комунікації! Успіхів вам!

Елементарно: треба усім дзвонити!
[сарказм]

треба усім дзвонити!

причем сразу

Отличная статья.
Спасибо!

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

Обдумав ситуацію, прорефлексував. Дійшов до того, що я хочу працювати приблизно з 9 до 18, але інша частина команди відстає в часі на 10 годин. Також в команді прийнято усно передавати інформацію — так легше, і так швидше. Тому мені слід було б знаходитись в офісі від 19 по 20 за нашим часом. Зазначу, що на мене ніхто в тому плані не тиснув, але я все ж відчував що так буде продуктивніше.

Це породило розбіжність між моїми особистими потребами (працювати з 9 по 18) та робочими (з 11 по 20). І воно мене муляло. Я спробував ще активніше листуватись, запропонував запровадити knowledge base, etc. Все ж цього не стали робити задля моєї зручності, і я це розумію. Через короткий час я пішов з проекту.

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

Дякую, цікава стаття.

Сергію, рада, що вам сподобалась стаття!

Корисна стаття, гарні приклади наведені!

Володимире, дякую за відгук :)

Роскошная статья, спасибо! Причём от практика, а не от теоретика, что вдвойне ценно.) Забираю в свою копилочку «HR-полезности».

Еще бы прочитали эту статью те кто с левой колонки :)

надія є :) у статті вже 4к+ переглядів, то є всі шанси, що частина з цих читачів з лівої колонки :)

Дуже гарна стаття! Візьму собі на озброєння.

Вікторе, дякую за відгук! Рада, що знайшли для себе корисні поради :)

Толковая статья, спасибо !

Хороша стаття, дякую

Миколо, дякую за відгук, рада що вам сподобалось :)

Надзвичайно корисна стаття, дякую :)

Іване, дякую дуже за відгук!

Грамотно.

Легкий перефраз: надо раскрывать контекст своего обращения к удаленному асинхронному собеседнику. Если речь о баге — ссылку и заголовок, чтобы он понял сходу, о чем речь.

дякую за відгук та уточнення, абсолютно погоджуюсь — пояснення контексту дуже важливе в асинхронному спілкуванні

Анна дякую! Цінно!

дякую :) Буду користуватися.

обожнюю фразу «буду користуватись», ура :) дякую, Романе!

Подписаться на комментарии