Як перестати сидіти в чаті та почати працювати?

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

Саме завдяки консалтингу я побачила, як сильно проблеми внутрішньої комунікації з'їдають продуктивність (та додають стресу) та найчастіше ще й роблять це непомітно.

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

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

В середньому кожна людина регулярно страждає від 3 проблем з цього списку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тож як прокачати асинхронну комунікацію на особистому, командному та корпоративному рівні? Давайте розберемо 10 практик, які справді працюють на будь-якому рівні. Впроваджуйте їх на тих рівнях, які вам доступні (але на особистому – обов'язково :)

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

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

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

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

В чому проблема з варіантом зліва?
Виглядає нібито нормально – коротко, ввічливо. Але він:

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

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

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

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

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

Розберемо декілька прикладів проблемної комунікації і як це покращити.

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

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

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

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

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

Розберемо приклади.
Реакція на повідомлення зліва: мене про щось інформують. Може прочитаю, як буде час.
Ось новий макет банера – Ну ок.
Проблеми з коментарями – В інтернеті так весь час.
Ура, нове опитування – Піду відкоркую шампанське (ні).

Реакція на повідомлення справа: від мене чогось хочуть, мені треба прореагувати.
Що думаєш про меми? – Ці меми вже застаріли, Карл!
Що порадиш з коментарями? – Перевір налаштування користувачів у адмінці.
Прошу заповнити до Пт – Ок, заповню.

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

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

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

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

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

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

В цілому варіант зліва можна скоротити "Ти тупиш і дратуєш мене". Й хоча це цілком може бути так, але знову ж таки непродуктивно.

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

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

В цілому варіант справа читається як "Дякую, зроби цю ж задачу іншим способом з ось цих причин, й продовжуй робити так й надалі. Домовились?".

Доречі, дуже рекомендую використовувати підхід 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 mis-interpreted or perhaps add a little extra fluff or, sort of, warmth to the message.

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

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

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

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

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

Приклад:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Remote Work At Scale by Automattic
  
• The Ultimate Guide to Remote Work by Zapier
  
• Remote Work Guides by Twist
  
• The Suddenly Remote Playbook by Toptal

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