Асинхронные коммуникации в команде #

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

Что такое асинхронные коммуникации #

Допустим, у системного аналитика Оли возник вопрос по сервису или модулю, который писал разработчик Толя.

Системный аналитик Оля может:

Решить вопрос самостоятельно — без коммуникаций с Толей
Пообщаться с Толей, отвлекая его от текущего дела — то есть синхронно
Оставить Толе запрос, на который тот ответит позже — то есть асинхронно

Зачем нужны асинхронные коммуникации #

Главная проблема синхронной коммуникации в том, что вы отвлекаете коллегу от его дела:

Он теряет продуктивное «состояние потока», особенно важное решения сложных задач
Он забывает текущий контекст задачи и потом должен восстанавливать его
Он устаёт быстрее: отвлечение и затем возврат к задаче потребляют больше энергии, чем работа в «состоянии потока»

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

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

Записывайте входящие вопросы #

Первый совет — записывайте входящие вопросы, если на них не нужно отвечать сразу

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

Пройти по накопленным вопросам можно позже:

когда вы освободились от текущей задачи
в конце рабочего дня

Кстати, иногда человек за это время сам находит ответ и пишет, что вопрос уже неактуален.

Проблема №1: мета-вопросы #

Один из способов потратить чужое время — это мета-вопросы, которые подразумевают другие вопросы.

Допустим, системный аналитик Оля написала:

Привет

У меня тут есть вопрос

По сервису

Это целых 3 сообщения, ни одно из которых не отражает суть вопроса! Если разработчик Толя уже открыл чат, он вынужден писать в ответ или ждать на линии, но всё ещё не получил никакой информации.

Что делать с мета-вопросами #

Если мета-вопросы пишут вам, вы можете обозначать, что делать так не надо:

скинуть ссылку на https://nometa.xyz/ru.html
объяснить вежливо, что лучше задавать вопрос целиком и с вариантами решения, которые видит автор, чтобы не отнимать чужое время на выяснение этих деталей

Проблема №2: нехватка контекста #

Пример плохого вопроса:

Привет, я могу удалить настройку […] из докера?

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

Как правильно задавать вопросы #

Если вопрос пишете вы, постарайтесь описать:

Контекст, о котором вы говорите: какой сервис/модуль/проект
Предысторию: какую задачу вы решаете
Проблема, с которой столкнулись
Варианты решения, которые вы рассматривали
Суть вопроса

Пример:

Привет, я пытался запустить FileStorage локально, чтобы проверить интеграцию с моим сервисом MailSender. При запуске сервиса в docker-compose у меня появляется ошибка: “…”. По информации в интернете, это вызвано настройкой […]. Если её убрать, то всё работает. Не подскажешь, почему такая настройка выставлена и могу ли я просто её убрать?

Здесь есть всё необходимое:

Контекст: речь про запуск сервиса FileStorage в docker-compose на машине разработчика
Предыстория: я работаю над интеграцией FileStorage с моим сервисом
Проблема: сервис FileStorage не запускается локально
Варианты решения: нашёл настройку, при отключении которой сервис запускается
Вопрос: настройка мне мешает и выглядит ненужной, могу ли я просто убрать её?

Если вопрос без контекста задают вам #

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

Метод утёнка #

Метод утёнка (rubber duck debugging) — это техника отладки, в рамках которой разработчик шаг-за-шагом объясняет свой код мысленному собеседнику.

Когда вы пишете сообщение и в процессе осознаёте ответ на свой вопрос — это эквивалентно методу утёнка.

В таком случае можно всё-таки дописать вопрос, но переформулировать его в стиле «правильно ли я понимаю, что проблема X решается способом Y? Мне это нужно для цели Z.».

Проблема №3: XY-проблема #

Проблема XY возникает, когда человек обращается за помощью в решении проблемы X, которая возникла при попытке самостоятельно решить проблему Y каким-либо неочевидным способом.

Например:

Привет, не могу удалить каталог .git на сервере Jenkins, может у тебя есть права?

Такой вопрос сразу порождает встречные вопросы:

А для чего понадобилось удалять каталог .git где-то на сервере Jenkins?
Какую исходную проблему решает автор вопроса?
Уверен ли он, что удаление каталога .git решит исходную проблему?

Как только замечаете подобное — постарайтесь выяснить, какова исходная цель и почему возникла потребность решать проблему Y.

ИИ-чат и поиск в помощь #

Хороший навык любого специалиста — уметь самостоятельно «копнуть» непонятный вопрос до определённого уровня

копайте на уровень, до которого вы всё ещё уверены в правильности найденной информации
после сборка информации сформулируйте и задайте финальный вопрос коллеге

Пример:

Привет! Я столкнулся с проблемой […] при работе с ORM. При вызове метода […] возникает ошибка error: not in transaction. Qwen и Gemini оба советуют мне добавить флаг […] в настройки соединения. Я могу так сделать или лучше поискать другие варианты?

Синхронные встречи #

Не все коммуникации должны быть асинхронными.

Ежедневный стендап, ретро, встречи 1-на-1 — яркие примеры коммуникаций, которые следует проводить синхронно
Синхронные коммуникации лучше оформлять как встречи в календаре, чтобы каждый мог планировать свой день
Лайфхак: если встреч много и вы хотите «просто поработать», можно завести в календаре пустую встречу без коллег на N часов
- альтернатива — договориться о том, в какие часы рекомендуется назначать встречи

Полностью асинхронный формат #

Иногда коммуникации команды всё-таки случаются в асинхронном режиме

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