Коммуникация без срочности

Привет, Хабр! Меня зовут Дима, я бизнес‑аналитик в команде внедрения Naumen. Большая часть моей работы — это коммуникация: с клиентами, разработчиками и коллегами внутри команды. Почти вся она происходит онлайн.

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

Со временем собрал несколько правил, которые помогают сделать онлайн‑коммуникацию быстрее и не растягивать обычный рабочий вопрос на полдня.

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

Почему простой вопрос в чате растягивается на полдня

Представим простую ситуацию: мне нужно узнать статус по задаче. Я пишу коллеге в чат и жду ответа. Через какое‑то время он отвечает, но информации недостаточно. Я задаю уточняющий вопрос и снова жду.

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

Причина в том, что в офисе у нас гораздо больше контекста. Мы видим коллегу и примерно понимаем, занят он сейчас или нет. Можем дождаться подходящего момента, подойти и сразу задать вопрос. Если информации не хватает, собеседник тут же уточнит детали.

В онлайне все работает иначе. Человек не знает, что мы мысленно уже «подошли» к нему и ждем ответа. Он может быть на встрече, работать над другой задачей или вернуться к сообщениям позже.

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

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

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

Когда лучше написать, а когда созвониться

Я разделяю рабочую коммуникацию на два основных формата.

1. Синхронный формат похож на обычный живой разговор. Это может быть встреча, созвон или переписка, в которой два человека прямо сейчас обмениваются сообщениями.

2. Асинхронный формат работает иначе. Отправляем сообщение так, чтобы собеседник мог открыть его позже, получить нужный контекст, разобраться в вопросе и дать содержательный ответ.

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

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

Разберем на нескольких ситуациях.

Ситуация 1. Сегодня релиз, а в нем нашли баг

Релиз нужно отдать клиенту сегодня. В нем обнаружили баг, и его решение зависит от нашей команды.

Здесь я бы не стал писать большое сообщение и ждать, когда коллеги смогут его разобрать. Нужно быстро понять, что произошло, кто может помочь и что будем делать дальше. 

Ситуация 2. Аналитик не может разобраться с SQL-запросом

Мы находимся в начале спринта. Аналитик столкнулся с ошибкой в SQL-запросе, но результат понадобится только к концу недели.

Ситуация 3. У клиента появился баг на проде, но есть обходное решение

Как написать сообщение, чтобы на него можно было ответить без уточнений

Я использую простую структуру из трех частей: контекст → вопрос → действие.

Сначала нужно объяснить, что происходит, затем обозначить проблему и после этого объяснить, что мы ожидаем от собеседника.

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

А как быть, если контекста много?

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

Но задача не в длине. В сообщении должно быть достаточно информации, чтобы собеседник понял ситуацию.

Иногда хватит трех строк. Иногда задача действительно сложная и собеседника придется подробно погрузить в контекст.

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

Коротко: не сходятся данные в отчете. Проверил два источника, расхождение остается. Нужна помощь с проверкой расчета показателя. Детали ниже.

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

Кому вообще нужно отправлять сообщение?

Перед отправкой полезно проверить не только содержание, но и адресатов.

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

Важно спросить себя: кому действительно нужно это увидеть?

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

А если нормально сформулировать сообщение не получается?

Есть вполне обычная ситуация: конец рабочего дня, нужно что‑то уточнить у коллеги, но уже сложно собрать мысли и нормально описать контекст.

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

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

Эту же проверку можно провести и без ассистента: сможет ли человек понять, что произошло и что от него нужно, не задавая дополнительных вопросов?

Если да — сообщение готово.

Но хорошо сформулированные сообщения решают только половину проблемы. Вторая половина — постоянный поток входящих сообщений, который сам по себе начинает управлять нашим рабочим днем.

Как не отвлекаться на каждый новый чат

Есть еще одна проблема онлайн-коммуникации: даже если сообщения сформулированы хорошо, сам чат постоянно конкурирует за наше внимание. Сценарий знакомый: работаем над задачей → видим уведомление → решаем заглянуть буквально на три минуты → через полчаса обнаруживаем себя в каком-нибудь обсуждении, которое вообще нам не адресовано.

После этого нужно снова возвращаться к основной задаче и вспоминать, на чем остановился.

Чтобы меньше переключаться, я использую практику, которую называю «окнами хаоса». Заранее выделяю отдельные промежутки времени, в которые разбираю накопившиеся сообщения и текущие вопросы.

Конкретное количество таких окон зависит от объема коммуникаций: их может быть несколько в течение дня.

При этом я понимаю, что некоторые вопросы действительно требуют быстрой реакции. Их нет смысла откладывать до вечера. Но таких чатов обычно не так много.

Поэтому «окна хаоса» у меня работают вместе с настройкой уведомлений.

Я условно разделяю чаты на две группы:

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

• Все, что не требует ответа в моменте, можно разобрать в ближайшее «окно хаоса».

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

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

Что ответить, если на сам вопрос нужно больше времени

Представим: коллега прислал сообщение. Я его увидел, понял, что нужно сделать, и начал разбираться.

Для меня все понятно. А для автора сообщения картина выглядит иначе: просто «Прочитано» и тишина. Он не понимает, взял ли я вопрос в работу и когда вернусь с ответом.

Через какое‑то время мы снова получаем дополнительные пинги, от которых как раз пытались уйти.

Поэтому, когда я вижу сообщение и понимаю, когда смогу им заняться, стараюсь сразу дать короткую обратную связь.

Например:

Такой ответ занимает несколько секунд, но человек понимает, что вопрос не потерялся и когда примерно ждать ответа. Это снижает неопределенность и тревожность для коллеги.

Я же могу спокойно продолжить работу, не отвлекаясь на повторные сообщения.

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

С чего начать менять свои коммуникации

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

Для начала достаточно посмотреть на собственные рабочие чаты.

Например, обратить внимание:

• часто ли после моих сообщений коллегам приходится уточнять контекст;

• отправляю ли я сначала «Привет» или «Есть минутка?», а сам вопрос только потом;

• какие сообщения действительно требуют реакции сразу;

• как часто я отвлекаюсь на уведомления;

• даю ли я обратную связь, если ответ на вопрос займет время.

После этого можно попробовать изменить несколько вещей.

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

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

3. Несрочные чаты разбирать отдельными блоками, а уведомления оставить только там, где действительно может понадобиться быстрая реакция.

4. Если ответ требует времени — просто сказать об этом человеку.

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

Так что мир, в котором люди пишут «привет» и сам вопрос сразу в одном сообщении, кажется мне вполне достижимым.