×Закрыть

Як зробити корпоративний 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 (хоча б на особистому рівні):

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

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

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

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


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

LinkedIn

33 комментария

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

Дякую за поширення культури використання слаку! Від себе додам (читав здається у хендбуці GitLab) пораду — якщо переписка довше 3-4 повідомлень, обговорити голосом (у нас це Discord) і занотувати meeting/sync results у відповідному каналі.

Володимире, дякую за коментар! Про Гітлаб — це дуже доречно, їх гайд по слаку точно можна перечитати, він багато в чому перегукується зі статею: about.gitlab.com/...​book/communication/#slack

не давать левым людям доступ к @here и @channel
Закрывать/мютить лишние каналы

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

Перейти в Discord.
P.S. Сорри, не удержался.
P.P.S. За статью спасибо, будет полезно!

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

Дискорд работает стабильно, а слак забагованный, но дискорд это про игры, а слак это про разработку в нем очень много интеграций

Дискорд шикарен для быстрых голосовых синков. У нас есть несколько каналов-комнат в которые можно попросить в слаке быстро «впрыгнуть». А еще можно делать каналы one-on-one, зажатые по количеству участников.

Почему этот чертов slack становится стандартом? Почему его выбирают менеджеры? В чем секрет?

Тут написано, что 55% используют, популярнее только Jira :)
dou.ua/...​ortrait-2020/#chart-tools

Обычно никто не волен выбирать такие инструменты, их объявляют на уровне корпората и всех ставят перед фактом. Поэтому популярность эта дутая.

Я сейчас прыгаю между проектами/клиентами и единственным связующим звеном пока что остается Jira, она прям стандарт. В мессенджерах же все более раздражающий зоопарк, хорошо хоть скайп стал встречаться все реже. Но даже там, где слак заявлен как основной инструмент, все равно созвоны народ делает то в зуме, то в тиме, то в гугломите, но только не в в слаке.

Вероятно, слак позволяет его админ-манагерам что-то неочевидное остальным, вроде сквозного контроля за текстами во всей системе або что-то еще.

Как замена емайлам — нет, прямо вообще нет.

Как средство созвонов — он плохой.

Как система сохранения файлов или контента — он очень плохой, все теряется.

Как система для упорядочивания каналов коммуникации он адекватен только на малых оборотах, а когда тому же менеджеру приходится отслеживать по 50 каналов да с тредами внутри — он жрет эффективность.

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

Клиент слака на смартфоне жрет ресурсы, как саранча.

Но его выбирают и выбирают.

Why?

Потому что треды — это удобно. Вменяемых альнетрнатив в предыдущием топике так и не увидел.

В Teams треди краще зроблені

Если я спрошу чем, ответ будет чем в шлаке?

На самом деле, спорно. В Teams свой подход к тредам: они группируются в основном канале чата, а не являются как бы отдельными «подканалами», как в Slack

В чём-то это, да, удобнее — участвуя в треде, ты не теряешь основной контекст происходящего в канале

Предположу, что это удобнее для тех, кто раньше не пользовался каналами, а все обсуждения шли в основном чате, где были разные контексты (нити обсуждений) вперемешку.

Вполне возможно. Впрочем, я — пользовался в Slack, и то, как это реализовано в Teams, меня абсолютно не напрягает.

Конечно, треды в любом виде лучше, чем без них. Спорный вопрос был о том, лучше ли они в Teams, чем в Slack, потому что это очень субъективно.

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

Какое отношение это имеет к слаку? Это настройка workspace в конкретно вашей компании. В этом одно из достоинств слака — он даёт тонкие настройки поведения и доступов на всех уровнях: от workspace до конкретных каналов.

Как система сохранения файлов или контента — он очень плохой, все теряется.

Ничего не теряется при правильной конфигурации. Но опять же, какие здесь вопросы к слаку? Важная информация и файлы должны становиться частью проектной документации, а не болтаться в архивах коммуникации: будь то имейл, teams или слак. Потому что коммуникация и документация — это разные вещи.

Как система для упорядочивания каналов коммуникации он адекватен только на малых оборотах, а когда тому же менеджеру приходится отслеживать по 50 каналов да с тредами внутри — он жрет эффективность.

Тут вообще не понял о чем идёт речь. У нас несколько десятков тысяч человек в слаке. Какой ещё менеджер для отслеживания каналов с тредами? Там где нужна автоматизация, слак даёт уйму вариантов интеграции с внешними системами и ботами. Насколько я вижу, в этом вопросе ему равных на данный момент нет.

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

Teams из коробки умеет интегрироваться с OneDrive / SharePoint online. Если у компании есть подписка на Office 365, то всю важную информацию одним движением мыши можно сохранять в подходящее для этого хранилище и не надеяться на сохранность истории чата.

15 лет назад, я пришел рабоать в банк, нас в управлении было 20 человек и мы пользовались ICQ и нам ее за глаза хватало. Для того — что бы заниматься своей работой, если тебе хочется заниматься работой — достаточно желания, все остальное — это от лукавого. Меня умаривает пользоваться 100500 кол-вом клиентов. Но это имхо. Кстати в своей практике я всегда рекомендую юзать Rocket Chat, на своем сервере, отличное бесплатное решение, если в компании чутка больше чем 5 человек, ибо прайс разростается и накладных расходов становится как то овер много.

С Rocket Chat / Zulip и т.п. есть одна существенная засада — это именно чаты, в лучшем случае с корявой интеграцией с каким-нибудь Jitsi для видеозвонков.

а что для работы еще надо ? Jitsi у меня норм работало всю дорогу пока с одними ребятами работал, репорты и прочая билеберда что есть в Slack на одном проекте, было реализовано в RocketChat на другом и ею как в Slack так и в RC прогеры, qa — не особо пользовались. Видеозвонки в Slack — еще то г..но, у нас «почеу то» при платной подписке перешли на Zoom. У дргой компании где помогаю, то же слак и периодически хер дозвонишься, в итоге тупо звонишь уже на моб. номер. Платим и за то и за это, что для меня мягко говоря странно.

Ну вот у нас Jitsi, как раз, нормально работать не захотел даже на небольшой фокус-группе добровольцев :(

В Teams же всё — как часики :shrug:

Сложно что либо сказать, кто настраивал, как настраивал, RC не по щелчку заводится, но у нас на текущем проекте завернули RC по милости Пмов, которые не удосужились проверить, оно же не платное, а у нас солидный проект, от чего завернели Teams уже не помню — но подозреваю что — как раз таки «не было нужных функций — интеграций» , но в итоге так и остались на Slack и он уже который год продолжает бесить.

Треба хоча б для себе спробувати Teams :) Бачила і пробувала в користуванні майже все з месенджерів, окрім Teams. На вашу думку, в чому перевага відносно слаку?

Загальний досвід користування Teams прикольніший за досвід зі Слаком. Щось конкретно сказати важко, там багато дрібниць, які роблять все зручнішим. Teams загалом виглядає більш системним і продуманим, навіть не віриться шо це продукт Майкрософта.

Хех, последнее время меня умарил Linux на десктопе, как бы странно это не звучало, думаю про Windows на борту :) Microsoft как по мне больше продумывает свои продукты, по причине наличия возможности нанимать более гработных и толковых людей, в отличии от стартапов на коленке.

Є дуже класна стаття від stratechery щодо порівння teams & slack — stratechery.com/...​the-slack-social-network

дякую, Богдане! піду досліджувати :)

Перейти на Teams и забыть о Slack, как о страшном сне

Перейти на Teams

Лагающая параша же. Кстати шо там, цитаты номальные а не через «>» завезли на десктоп клиент уже?)

Лагающая параша же.

«А мужики-то и не знают» ©

Года с полтора назад слышал такие жалобы на клиент для Mac OS, и то только от одного человека.

цитаты номальные а не через «>» завезли на десктоп клиент уже

Вот тут соглашусь — не пойму, почему до сих пор в Teams не сделают человеческое цитирование.
Но это, наверное, единственная мелочь, которая «доставляет»

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