Як зробити корпоративний Slack швидким і продуктивним

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

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

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

Моя попередня стаття «Як перестати сидіти в чаті та почати працювати?» отримала позитивні відгуки та понад 10к переглядів. Цей гайд — її практичне продовження для найпопулярнішого середовища робочої комунікації в IT. Я підкреслюю, що слак — не просто інструмент, а корпоративне середовище, тому раджу сформувати свій корпоративний гайд (лінк на шаблон — у кінці статті) і використовувати його у щоденній роботі.

Навіщо потрібен гайд зі Slack

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

З’ясуймо, як цього уникнути.

Для чого доречно використовувати Slack

Можна забивати цвяхи мікроскопом, але краще використовувати інструменти за призначенням. Ось справжнє призначення програми:

  1. Обговорення та ухвалення рішень у невеликій (3-10) групі людей.
  2. Вирішення ситуації, коли ви не знаєте, хто саме може відповісти на питання, та звертаєтесь до профільного каналу.
  3. Питання, з яких можна швидко досягти згоди, наприклад, підтвердження деталей вже ухваленого рішення.
  4. Оголошення та апдейти — канал #announcements або #companyupdates.
  5. Direct messages співробітникам і відділам.
  6. Автоматичні повідомлення й алерти. Є купа корисних інтеграцій зі сторонніми сервісами та ботами, наприклад:
    • Karmabot — система винагород і роздачі бонусів;
    • Geekbot — стендапи, підсумки дня, автоматизація повторюваних завдань;
    • Donut — з’єднувач людей для неформального спілкування;
    • Giphy — те, без чого робота неможлива (гіфки з котиками). А ще можна написати свою інтеграцію, наприклад у Ruby-ком’юніті Pivorak ми налаштували автоматичні сповіщення про донейти через сайт.
  7. Короткі опитування (наприклад, обрати час зустрічі) з емодзі-відповідями.
  8. Single channel guest. Це коли ви створюєте окремий канал і запрошуєте у нього людину зовні, наприклад, кандидата, фрилансера або консультанта.
  9. Щоденні асинхронні стендапи. Це одна з модних практик під час ремоуту (для цього є додаткові слак-тулзи, наприклад, Standuply), але вона підійде не кожній компанії.

Для чого краще використовувати інші інструменти

Перевірте себе, які з цих процесів у компанії відбуваються у слаку:

  1. Групові зустрічі (Zoom, Hangouts).
  2. Термінові повідомлення і дзвінки (телефон або інший інструмент на ваш смак, наприклад Telegram).
  3. Разова взаємодія зі сторонніми людьми не з вашого робочого середовища (пошта).
  4. Рев’ю та обговорення матеріалів, коду, дизайну, текстів, прототипів (Google Docs, спеціалізовані інструменти для цих завдань).
  5. Управління завданнями проєкту (ваш улюблений інструмент управління проєктами).

Як спілкуватись у Slack правильно

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

Треди чи просто повідомлення в чаті?

Взагалі я раджу робити так:

  • Якщо пишете повідомлення на нову тему, публікуйте прямо в канал.
  • Якщо відповідаєте на повідомлення, пишіть у треді під ним.

Проте це також залежить від розміру, типу каналу і мети повідомлення. У великих каналах, наприклад #kyiv-office, я рекомендую використовувати треди. Це мінімізує шум, дає змогу дискусіям відбуватися серед зацікавлених людей і не відриває інших. І навпаки, у невеликих і спеціалізованих каналах, наприклад #js-templates, пишіть прямо у канал (але тільки на відповідну тему). Чому? Тому що дискусії про темплейти JavaScript, найімовірніше, будуть корисними усім в цьому каналі.

Окрема проблема, про яку я часто чую — це канал #announcements. Його не чують, не читають, він перестає працювати. Запитайте себе:

  • Чи не забагато в ньому повідомлень і чи справді важливо, щоб усі працівники про них знали? Є приклади, коли компанії постять там оголошення два-три рази на день, люди просто ставлять канал на mute і дуже рідко до каналу повертаються. Тож рекомендую чітко визначити тих, хто може постити в #announcements, теми та частоту повідомлень. Раджу щось анонсувати максимум раз на день, а найкраще 1-2 рази на тиждень. Релевантність анонсів залежить від розміру компанії: що більше у вас працівників, то вужчий діапазон тем. Наприклад, якщо кожного місяця з’являється один новачок у компанії, доречно буде запостити це в #announcements, а якщо 15 — це заспамить канал. У такому разі робіть один пост в кінці місяця зі списком нових колег.
  • Чи є у людей можливість висловитись і обговорити ці оголошення в тредах? Інакше #announcements перетвориться на якійсь державний телеканал. А ще заохотьте колег реагувати на пости за допомогою емодзі, щоб зрозуміти їх реакцію на новини.

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

Моя порада, як цього уникнути: використовувати zero inbox principle на пошті та функцію нагадувань у слаку.

Публічні канали, приватні канали чи особисті повідомлення?

Я раджу спілкуватись саме у публічних каналах. Чому?

  • Формується спільне інформаційне середовище. Коли його нема, тільки частина людей в курсі того, що має бути відомо усій команді або компанії. Це марнує купу часу та нервів, не треба так.
  • Легше знайти рішення. Якщо більшість робочих каналів мають чітке призначення, це знижує рівень чат-сміття і полегшує пошук потрібної інформації. Плекайте профільність каналів. Навіть якщо в каналі #devtools сидять усі розробники, не треба там обговорювати майбутній хакатон.
  • Зниження ризику, що важлива дискусія загубиться (а потім з’ясовується, що вона взагалі була у вже видаленому приватному каналі).
  • Зменшення зайвих каналів. Коли співробітники бачать, що однакові теми обговорюються у кількох різних каналах, зайві з них «мутяться», а потім і зникають.
  • Простота шерингу. Усіма постами та файлами з публічних каналів можна поділитися в інших каналах (а з приватних — ні).

До речі, про шеринг.

Тоді вся дискусія буде в одному місці (каналі чи треді) — це швидко і зручно.

Однак використовуйте приватні канали або особисті повідомлення для:

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

@mentions людей, груп і каналів

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

Часто потрібно повідомити групу людей, наприклад QA чи техпідтримку, у більшому каналі. Для цього зручно зробити групи @qa-squad, @ts-squad і запросити до них відповідних людей (функція платного слаку).

Mention каналів — потужний інструмент, але користуйтесь ним розумно:

  • @channel: відправляє повідомлення всім людям у каналі. Раджу використовувати для оголошень, великих апдейтів і термінових завдань, що потребують негайної уваги. Можна встановити права користування в адмінці.
  • @here: надсилає повідомлення всім людям, які зараз онлайн у каналі. Варто використовувати в профільних каналах, щоб швидко отримати пораду чи відповідь від будь-кого, хто зараз онлайн.

Ефективні меседжі

Друга складова головного правила — якісні повідомлення. Я детально розбирала тему письмової комунікації з прикладами у статті «Асинхронна комунікація», але сьогодні сконцентруємось на повідомленнях у слак.

  • Почніть з теми, наприклад «Рішення», «Івент» або «Запит».
  • Опишіть головне — суть, терміни, деталі завдання.
  • Візуалізуйте деталі за допомогою скріншотів.
  • Тегайте канали, групи та людей.
  • Розбивайте текст на абзаци та списки.
  • Виділіть головне жирним шрифтом.
  • Скорочуйте. Я раджу не писати тексти в слаку на більш ніж 200 слів, це ж не стаття :)
  • Додайте корисні посилання і референси через функцію link, а не довгим посиланням.
  • Перечитайте повідомлення перед відправкою :)

Статуси

Чітко дайте колегам зрозуміти, чи ви на зв’язку і в якому робочому стані :) Можна робити це вручну або, що зручно, за допомогою інтеграції з Google-календарем. Також раджу налаштувати правила у себе в профілі, коли вам будуть надходити повідомлення. У мене, наприклад, стоїть з 8:00 до 21:00.

Слак автоматично ставить статус Active, якщо ви перебуваєте за комп’ютером (не обов’язково в програмі). Якщо хочете, щоб вас не турбували, поставте статус Away вручну. Коли робота на сьогодні завершена, виходьте зі слаку або поставте статус Do Not Disturb. До речі, можна налаштувати ці корпоративні статуси на рівні workspace.

Також статуси зручно ставити через шорткати:
/away: встановлює статус Away
/dnd: встановлює або завершує режим «Do Not Disturb»

Важливо: так варто робити, тільки якщо в компанії є channel map — карта каналів і швидкості реакції у них. Тоді, якщо раптом виникнуть термінові питання до вас, колеги зможуть скористатися каналами для термінового зв’язку, наприклад, телефоном.

Присутність онлайн і швидкість відповідей

Обережно, делікатна тема! Але й до неї є розумний підхід — ось він:

Підсумки

Ми відповідальні за зручність і продуктивність свого робочого середовища. Тому розпочнімо зі слаку, який ми використовуємо щодня:

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

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

Впровадьте підхід Assume Positive Intent (хоча б на особистому рівні):

  • припускайте позитивний намір будь-яких повідомлень, які отримуєте;
  • якщо ви відправляєте повідомлення, погляньте, чи можна їх зрозуміти неправильно? Якщо є можливість, додайте в них трохи тепла.

Перевірте повідомлення перед надсиланням. Це збереже вам спокій, а колегам — час.

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

А вас дратують червоні цяточки непрочитаних повідомлень і спам у каналах? Які з цих практик хотіли б вжух — і магічно впровадити вже вчора? Пишіть у коментарях!


Дякую за допомогу в підготовці статті Антонові Головченку.

Похожие статьи:
GitHub анонсував, що впроваджує двофакторну автентифікацію для усіх розробників, які пишуть код у будь-якому проєкті на платформі. Про...
Продовження історії про те, як я проходив співбесіди у різні компанії на різні позиції. Цього разу закриємо кілька запитань...
Цьогорічний День вишиванки українці відзначають в умовах карантину. Проте це не привід відмовитися від святкування....
Любая компания на стадии роста сталкивается с рядом типовых проблем. Как правило, они связаны с тем, что методы...
Прототипирование — это создание наброска, схемы или готового макета пользовательского интерфейса. Прототипы...
Яндекс.Метрика