Как Slack отбирает у вас продуктивность: количественный взгляд на проблему и ее решение

Главная проблема мессенджеров — моментальность. Сообщения доставляются через секунду после отправки и требуют от получателя мгновенной реакции, сигнализируя о себе уведомлением. Это постоянно отвлекает. Такие черты присущи и популярному корпоративному мессенджеру Slack, уведомления которого наверняка отвлекают пользователя именно от работы. Майкл Мьюз, директор по продукту компании Managed by Q, решил проанализировать данные о количестве сообщений в Slack своей компании и посчитать, сколько времени теряют сотрудники, отвлекаясь на запросы в мессенджере. Он также описал решение этой проблемы, которое внедрили в компании. Редакция AIN.UA приводит полный перевод его заметки, опубликованной на Medium.

Количественный взгляд на мгновенные сообщения

Если вы работали в компании, которая использует Slack, или говорили с таким человеком, то вы вероятно в курсе, что все любят этот мессенджер. Приятно, когда не нужно писать письма и архивировать их. Приятно, когда можно получить моментальные ответ, и видеть, как обсуждения приводят к решениям за минуты, а не дни. Slack позволяет пользователям чувствовать себя на 32% более эффективно, при этом будучи более прозрачным, личным и дружелюбным медиумом. К тому же, в Slack каждый день выглядит как расслабленная пятница — пунктуация, заглавные буквы и правила грамматики отступают перед эмодзи и гифками. Slack — это весело!

Так в чем подвох? Иногда Slack (или ваше любимое чат-приложение, поскольку этот текст в равной мере справедлив для любого из них) — лучший инструмент для работы, но я хотел бы углубиться в случаи, когда это не так. Каждый инструмент имеет свои плюсы и минусы. Минусы Slack столь малы, что вы можете не чувствовать или не замечать их. Поэтому я решил выразить их для вас в числовом виде, поскольку недостатки могут суммироваться. Да, это можно выразить математически. А поскольку в математических работах много сносок, у меня они тоже будут, но обещаю, что читать их будет весело!

Каждый любит Slack, потому что мы получаем выгоду концентрированно и сразу, когда начинаем разговор в нем. Тем не менее, мы оплачиваем затраты небольшими порциями, когда нас втягивают в разговоры в течение дня.

Под затратами я не имею в виду выставленный вам счет. Я имею в виду все, что вы не сделали, после того, как увидели уведомление «просто прошу глянуть на [вставьте сюда что-то, над чем не работаете в данный момент]» (Сноска 1).  Учитывая, что такие затраты нечеткие, я понимал, что нужны реальные данные, а не анекдоты, чтобы измерить насколько они велики. Они также смогут показать, как мы справились с проблемой. И не беспокойтесь, не благодаря отказу от Slack.

Затраты на пассивное участие в канале

После того, как я выгрузил данные о переписке за месяц, я просмотрел цифры. Каждый день, средний «канал» нашей компании накапливал 39 новых сообщений. (Для тех, кто не пользуется Slack, канал — название публичного командного чата на конкретную тему и большинство сотрудников состоят в нескольких из них). По всем каналам около 6 400 сообщений отправляется ежедневно только в нашей компании. Не слишком ли это много?

В каждом канале, помимо активных участников разговора, много пассивных слушателей. Консервативно оценив, что на каждый канал приходится по 10 сотрудников, можно посчитать общий охват сообщений. Получается, что участников опосредованно спрашивают «быстро взглянуть на это» около 20 млн раз в год. И это распространяется только на наших 164 пользователей Slack. Несмотря на то, что мы не просматриваем каждое сообщение, около 11% таких сообщений содержат обращения @channel или @here, которые отправляют push-уведомления. Таким образом, мы определенно просматриваем абсолютный минимум из 2 млн сообщений (Сноска 2).

Во время написания этого текста журналист ощутил отвлечение, возникающее благодаря Slack, сполна

К чему эту глупая математика? Вы не знаете того, что не измеряете. Из-за этого затраты кажутся такими мелкими на таком большом объеме, что и вызвало мой интерес. Этот простой подсчет заставил меня нырнуть еще глубже, потому что я был достаточно уверен, что никто другой не сделает этого. Результаты оказались крайне интересными.

Затраты внимания на личные сообщения

Я хотел бы специально сфокусироваться на наборе сообщений, которые не вошли в вышеописанные расчеты, потому что именно на них я начал действительно ощущать затраты по использованию Slack. Двадцатимиллионный охват сообщений касается только общения аккаунтов в каналах и группах. Несмотря на это, около двух третей сообщений мессенджера в нашей компании приходится вовсе не на каналы! Это личные сообщения (DM).

Распределение сообщений в Slack компании Managed by Q по типам за ноябрь 2016 года

Личные сообщения могут казаться меньшей проблемой в плане отвлечения, чем публичные каналы, но они обладают совершенно иным социальным контрактом:

• В отличие от каналов, предполагается, что вы читаете их всегда. Отправитель знает, что вы получили уведомление о его сообщении.
• В отличие от каналов, вы — единственный человек, который может оценить важность сообщения, поэтому никто другой ответить на него не может. И оно ожидает вашего ответа.

Это означает, что DM воспринимаются как значительно более неотложные и важные. Когда-нибудь прерывали реальную беседу из-за того, что заметили что-то в канале Slack? Я тоже нет. Но, поверьте, я не раз останавливал разговор с человеком, чтобы ответить на сообщение в DM.

Каковы суммарные затраты внимания на личные сообщения? В нашей компании более 10 000 личных сообщений отправляются каждый рабочий день. Конечно, многие из них являются частью изложения одной мысли и отправляются друг за другом, поэтому не все из них отвлекают пользователя. Но каждое первое сообщение в разговоре именно такое. Если бы я мог оценить среднюю длину разговора в DM, я бы определил сколько из них были новыми сообщениями, вызывающими отвлечение. Как настоящий сторонник теории заговоров, я проделал работу, чтобы рассчитать такой параметр (Сноска 3).

Данные показывают, что в нашей компании сотрудник в среднем получает более 14 входящих разговоров в DM каждый день. Я поспрашивал у коллег и они ответили, что это похоже на правду.

Возьмем это в работу. 14 — подтвержденное данными, взятое по нижней границе среднее число отвлечений с высокой неотложностью и важностью, которое каждый сотрудник нашей компании получает в DM каждый день.

«Итак, — скажете вы. — Зачем делать проблему из-за того, что я 14 раз в день отвлекусь от работы? Если бы это были электронные письма, мне бы все равно в итоге пришлось на них ответить». Но вы отвечаете на них не «в итоге». Вы отвечаете на них незамедлительно.

Личные сообщения предотвращают приоритезацию

Входящие личные сообщения имеют срочность «СЕЙЧАС» и получателя «ВАС» по умолчанию. Такая срочность приводит к правилу приоритезации работы по принципу LIFO (Last In, First Out — «последним пришел — первым ушел»). Представьте, что вы работаете над задачей А и получаете DM о другой задаче В. Вы перефокусируетесь и начинаете работать с В, но затем получаете еще одно личное сообщение, перефокусируетесь снова и уже работаете над задачей С. Вы ушли от того, что было основным приоритетом вашего списка задач (А), чтобы жонглировать двумя другими проектами, которые кто-то выбрал за вас. Вы, вероятно, поставите максимальный приоритете для С, просто потому что она просто была самой последней.

Более того, часто есть другой член команды, к которому было бы лучше обратиться в DM по решению условных задач В и С. Возможно, стоимость его отвлечения сейчас меньше или он знает, как прийти к решению быстрее. Но, в случае с личным сообщением, вы — единственный вариант (Сноска 4).

Более глубокое понимание затрат внимания

Каждый раз, когда вы отвлекаетесь от своей работы, вы не просто переключаетесь на чужой приоритет. Вы также теряете некоторую часть прогресса по своему делу. Представьте, что вы пытаетесь читать книгу, при этом делая покупки в магазине. Нельзя незаметно переключаться между этими двумя задачами. В итоге, вы ужасно выполните обе (Сноска 5).

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

А теперь мы пришли к сути всей этой математики. Отвлекаясь от работы 14 раз в день, эти 5 минут каждый раз суммируются и составляют более часа (~72 минуты) потерянной продуктивности. Для каждого человека в компании.

Каждый божий день.

Во избежание недопонимания, 72 минуты — не время потраченное на новые задачи, а лишь налог на переключение, который все мы платим каждый день. Единственная причина, по которой мы еще не взяли в руки оружие для борьбы с этим в том, что никто не меряет эти затраты (Сноска 6).

Я люблю называть этот неизмеренный, непредсказуемый феномен прерывания Slack-a-Mole (игра слов, отсылка к популярному в Америке игровому автомату Whack-a-Mole, когда из дырок появляются кроты, которых нужно ударить по голове. После удара одного в другом месте тут же появляется новый. — Ред.). Не играйте в Slack-a-Mole. Вам никогда не выиграть гигантского плюшевого медведя (стандартный главный приз в Whack-a-Mole — Ред.).

Что мы с этим сделали

Сперва моя команда создала систему заявок для запросов, которые отправляются командам поддержки. Так мы, по крайней мере, могли убрать запросы из наших DM. Я протестировал это решение, но оказалось, что системы на основе заявок — отстой. Мы тут же увидели «желаемые пути» пользователей: они предпочитали писать нам в DM «я оставлю заявку, но [вставить сюда текст проблемы]». Ух. Люди не хотят загружать веб-сайт и заполнять веб-форму, чтобы поговорить с вами. Это не лично, однонаправленно и медленно.

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

Путь к лучшему решению

Сперва мы пришли к частичному решению, скопировав то, что уже использовалось для других команд поддержки компании — специальный канал для поддержки в Slack для нашей команды. Люди могут зайти в него, оставить запрос команде, а не конкретному сотруднику лично, и при этом все еще использовать Slack. Это позволило нам снова почувствовать себя у руля и выбирать, кто над каким запросом будет работать. Член команды, который меньше всего был завален работой, мог прийти и взяться за решение проблемы.

Но проблема «сделай это сейчас» не ушла. К тому же, все мы должны были оставаться начеку, отслеживая входящие запросы, чтобы они не потерялись под «завалами ленты». Потеря сообщений из-за их постоянного потока присуща мессенджерам. Некоторые команды выделяют «дежурного» для решения этой проблемы. Но, учитывая, что у нас команда из трех человек, терять продуктивность целого сотрудника — достаточно затратное решение, которое, к тому же походило на повинность.

Поэтому мы придумали схему, требующую 20% усилий и дающую 80% результата. ФОКУСируясь на опыте конечного пользователя и используя проверенный Zapier, мы пошли навстречу «желанным путям» и дали возможность людям оставлять запрос в канал поддержки, который автоматически «сохранялся на потом». Zapier сканировал сообщения на наличие маркера ($заявка) и сохранял его в список задач нашей команды в Asana. Через Zapier мы также реализовали замыкающее петлю уведомление. Когда мы выполняли задание-$заявку в Asana, стейкхолдер получал уведомление в нашем канале, сообщающее, что работа выполнена таким-то сотрудником. Это позволяло при необходимости обратиться к нему с дополнительными вопросами.

Сделайте такое самостоятельно

Звучит интересно? Это просто! Для создания такого сценария даже есть пошаговая инструкция.

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

Результаты

Смешно, но количество входящих личных сообщений ощущается в разы ниже. Вдобавок, наш канал имеет много схожего с системой заявок, но для пользователя обладает прекрасным юзабилити Slack. $заявка — наша серебряная пуля.

Наш канал — один из самых «густонаселенных» в компании и семь других команд попросили установить систему $заявок для их отдела. Семь! Значит, что в текущий момент, в компании больше команд используют нашу систему, чем не используют. При этом, каждая из команд самостоятельно пришла к такому решению. Вирусное внутреннее применение этого решения привело меня к написанию этой статьи и инструкций, чтобы вы могли создать такую систему сами.

Как $заявка отражается на наших данных

После внедрения решения, я снова проанализировал данные о сообщениях, сфокусировавшись на семи каналах: три старых обычных информационных канала (контрольная группа), два стандартных канала поддержки и два канала поддержки с системой $заявок. Вот небольшая таблица с результатами («хорошие цифры — зеленые, а плохие — красные):

Таким образом, каналы, использующие $заявку, имеют большее вовлечение (Сноска 7) на одного участника, но при меньшем количестве усилий со стороны команды поддержки. Что даже лучше, у них почти до нуля сократился процент сообщений с упоминаниями @channel и @here, которые похожи на стрельбу по воробьями из пушки: отправка уведомлений всем участникам канала в отчаянной попытке найти решение проблемы.

Я рад, что данные укрепляют мой энтузиазм в отношении нового процесса. Я даже больше рад тому, что мы можем пользоваться всеми преимуществами Slack, избегая подвоха. Мы любим Slack!

Да, это сработает и для вашей команды

Наиболее распространенная отговорка, которую я слышу: «это просто направит на нас поток всех этих мелких «хотелок», которые требуют пользователи». Занимательно, что такое действительно происходит, но я нахожу это исключением, а не правилом. В любом случае, вспомните, что теперь вы руководите процессом приоритезации и ответов на все идеи. Мы не заключаем никакого SLA (Service Level Agreement — Соглашение об уровне предоставления услуги) для $заявок, поскольку прогресс очевиден, а мы заработали доверие, поскольку занимаемся наиболее значимыми задачами из списка. Жертвовать всеми преимуществами, которые я описал (Сноска 8), чтобы сократить приоритезацию накладных расходов, для меня, просто сумасшествие. Существуют целые веб-сайты, где вы платите хорошие деньги за получение отзывов пользователей и тестирование юзабилити. Мы создали машину, которая привлекает их органически. Это дает нам преимущество более быстрых итераций благодаря более коротким циклам обучения.