Асинхронное принятие решений для удаленных команд: принимайте решения без встреч

В Сан-Франциско 8:00, в Берлине 17:00, а в Сингапуре 23:00, и восемь человек участвуют в звонке, чтобы принять одно решение. Инженер в Сингапуре имеет самый актуальный контекст и наименьшее оставшееся внимание. Встреча, которая казалась легкой в офисе — все уже в комнате, белая доска за ними — стала самой дорогой вещью, которую делает эта команда, и больше всего платит тот, кто больше всего нуждается в этом решении.

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

Таким образом, честный вопрос для удаленной команды не в том, "как нам проводить более эффективные совещания по принятию решений?" А в том, "какие решения вообще должны обсуждаться на совещании?" Для значительной части из них ответ — ни одно из них; их лучше принимать письменно, в течение определенного времени, когда часовые пояса перестают иметь значение. Это асинхронное принятие решений, и для распределенных команд это не обходной путь. Это лучшее стандартное решение. Вот аргументы в его пользу, пятиминутный план действий и режимы неудач, против которых нужно проектировать.

Почему удалённым командам нужны асинхронные решения

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

Ничто из этого не означает "никогда не встречаться". Это означает, что встреча перестает быть рефлексом. Асинхронное взаимодействие — это место, где происходит принятие решений; синхронное время зарезервировано для того, что написание действительно не может сделать. Это переосмысление такое же, как и в здоровом коллективном принятии решений — цель заключается в том, чтобы принять хорошее решение, принадлежащее группе, а не в том, чтобы провести хорошо посещаемую встречу. (И у этого есть хорошо известное доказательство существования: GitLab, полностью удаленная компания с более чем 1,500 членами команды в более чем 65 странах, работает по версии этого шаблона, основанной на руководстве — записывайте, принимайте решения письменно, фиксируйте это там, где каждый может это найти.)

План действий по асинхронным решениям

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

Ловушки, которые тихо разрушают это

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

Разве асинхронность не делает всё медленнее?

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

Но задержка на одно решение — это неправильная единица измерения для распределенной команды. Звонок, который решает один вопрос за тридцать минут, стоит восьми людям синхронизированного времени — в 6 утра для одного и в 11 вечера для другого — плюс переключение контекста с обеих сторон, и он не оставляет записи. Асинхронная нить стоит каждому человеку пятнадцать сосредоточенных минут в течение своего рабочего дня, работает параллельно с каждой другой нитью и заканчивается письменным решением. Вы обмениваете небольшую скорость на одно решение на пропускную способность по всем решениям — и на качество входных данных: обоснованные, подкрепленные доказательствами аргументы, на которые самые быстрые ораторы живой встречи никогда не оставляют места. Честное разделение, таким образом, не "асинхронно всегда"; это таблица ниже — и для действительно срочного звонка встреча по-прежнему является правильным инструментом, оформленным как протокол.

Синхронные и асинхронные: какие решения куда идут

Асинхронный режим — это стандарт, а не правило. Умение заключается в том, чтобы знать, какие решения следует принимать в режиме реального времени. Простой тест: если решение в основном требует взвешенного мнения и записи, выбирайте асинхронный режим; если оно в основном требует связи в реальном времени или свежих вариантов, выбирайте синхронный режим. (Один нюанс исследования, который стоит знать: Брукс и Левав показали в Nature в 2022 году, что видеозвонки подавляют генерацию креативных идей — но не хуже для выбора между вариантами. Если задача заключается в изобретении вариантов, соберитесь в комнате или на звонке; если задача заключается в выборе и записи, подойдет письменная форма.)

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

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

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

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

Решите в письменной форме, встречайтесь с целью

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

Асинхронное принятие решений — это не утешительный приз для удаленной работы. Завершив структуру — предложение, окно, решающий, аргументы, запись — это действительно лучший процесс, чем конференц-зал, который он заменяет: более обдуманные идеи, больше голосов и память, которая переживает поток обсуждения. Команды, которые испытывают с этим трудности, не делают слишком много асинхронной работы; они делают асинхронную работу без структуры. Исправьте структуру, и карта часовых поясов на странице вашей команды перестанет быть ограничением и начнет быть причиной, по которой ваши решения вообще записываются.