Async vs sync workflow: что подходит вашей команде?
Две команды по 30 инженеров, тот же стек, примерно одинаковая сложность продукта. Команда A работает async-first: один письменный дамп вместо стендапа в день, решения в RFC-тредах, code review в течение 48 часов. Команда B sync-first: два ежедневных стендапа, архитектурный sync дважды в неделю, решения принимаются на митингах. Мы меряли coding-time и lead-time обеих команд полный квартал. У команды A 2ч 50м медианы активного кодирования в день, lead time 4.2 дня. У команды B 48 минут медианы, lead time 2.1 дня. Один выход, разные бутылочные горла. Универсально "лучше" нет ни одного.
Async-first нарратив доминировал в 2021-2023. Handbook GitLab, Shape Up Basecamp и десятки remote-работа-thinkpieces представили синхронные митинги как productivity-театр. Обратная коррекция происходит сейчас: команды, ушедшие в полный async, обнаружили, что латенси решений тоже стоит, и возвращают часть sync-работы. Microsoft New Future of Work 2023 явно отметили: команды с нулевым синхронным временем имели на 33% более длинные циклы принятия решений, при росте индивидуального фокуса. Эта статья — о трейд-оффах в цифрах.
{/* truncate */}
Позиционирование
Async-first: письменная коммуникация по умолчанию, решения принимаются за часы/дни, митинги — эскалация, не default. Защищает фокус. Плата — латенси решений.
Sync-first: ежедневные стендапы, частые митинги, решения лицом-к-лицу (или видео-лицом). Быстро решает. Плата — фрагментация фокуса.
Гибрид: селективный sync (архитектурные ревью, жёсткие блокеры, 1:1) поверх async-дефолтов. Большинство успешных команд в 2026 — здесь, не на полюсах.
Отчёт DORA 2024: высокоперформящие инженерные команды имеют 2-3 часа синхронной коллаборации в неделю в среднем — не ноль, не ежедневно. Середина — там, где приземляются результаты, но середина уже, чем большинство команд бежит.
Что меняется под каждой моделью
Три оси, движущиеся в разных направлениях. Focus time и удовлетворённость растут в async; скорость решений — в sync. Satisfaction-числа взяты из нашего сегмента и не должны читаться как индустриальные.
Focus time
| Workflow | Медиана активного кода | Диапазон P25-P75 |
|---|---|---|
| Async-first (полностью async команды) | 2ч 50м | 2ч 10м - 3ч 30м |
| Гибрид (async + 2-3 sync в неделю) | 2ч 15м | 1ч 40м - 2ч 50м |
| Sync-first (ежедневный стендап + 2-4 митинга в неделю) | 48м | 25м - 1ч 20м |
Наши IDE heartbeat-данные со ~100 клиентов подтверждают это распределение. Разрыв sync-first vs async-first — более 2 часов медианы — эквивалент в 2.5-3 раза большей "сырой" ёмкости фокуса.
Скорость решений
Async убивает воровство фокуса, но замедляет решения. Gloria Mark из UC Irvine — автор знаменитого "23 минуты на перефокусировку" — опубликовала follow-up в 2022 по латенси решений в knowledge work. Её находка: решения в async принимались в медиане 2.4 дня vs 4.1 часа для sync-эквивалентов. Для решений, блокирующих downstream-работу, эта латенси накапливается.
Механика сбоя конкретная: async работает для решений, выигрывающих от рефлексии. Падает, где один блокер останавливает пятерых. Нехватка архитектурного решения в sync-команде решается за 30-минутный митинг завтра. Тот же кейс в async ждёт таймзону автора, потом ждёт, пока два decider прочитают, потом ждёт комментов, потом ждёт итерации автора. Здорово: 2 дня. Патологически: 2 недели.
Скорость онбординга
Async-first жесток к новичкам. Senior-инженер, выходящий в remote async-команду, ramp-up до полной продуктивности идёт на 40-60% дольше по нашим onboarding-данным (caveat: небольшая выборка, 28 наймов). Чего не хватает — периферийного обучения: подслушивания, как принимаются решения, ловли контекста в коридорных разговорах. Документация не заменяет. Sync-команды получают это бесплатно.
Гибридные команды обычно возвращают sync для первых 90 дней новичков. "Онбординг-бадди с 2 sync 30-минутными сессиями в неделю" — паттерн, который видим работающим.
Нагрузка митингами
| Workflow | Часы митингов на инженера в неделю |
|---|---|
| Полный async | 0.5-1.5ч (только 1:1) |
| Гибрид | 3-5ч |
| Sync-first | 8-14ч |
| Meeting-heavy (плохой sync) | 15-25ч |
Meeting-heavy встречается чаще, чем команды признают. Видели инженеров с 18 часами постоянных митингов в неделю. Это почти половина рабочей недели до любого кода.
Осуществимость для распределённых команд
Разброс таймзон важнее, чем признают в async/sync-дебатах.
| Разброс таймзон | Практический workflow |
|---|---|
| ±3 часа (один регион) | Любой работает. Sync дёшев. |
| ±6 часов (Европа + US East) | Гибрид обязателен. Чистый sync = инженеры до 10 вечера. |
| ±9+ часов (глобально) | Async-first или провал. Sync становится вращающейся жестокостью. |
Stack Overflow Developer Survey 2024: remote-инженеры с разбросом 8+ таймзон сообщают на 42% больше "decision-blocking" раздражения, чем внутри 3-часового разброса. Выбор async/sync часто делается за вас географией.
Матрица функций
| Измерение | Async-first | Sync-first | Гибрид |
|---|---|---|---|
| Защищает focus time | Сильно | Слабо | Средне |
| Скорость решений | Слабо | Сильно | Средне |
| Онбординг новичков | Тяжело | Легко | Средне |
| Масштабируется по таймзонам | Легко | Тяжело | Средне |
| Масштабируется по headcount | Средне | Тяжело (meeting bloat) | Сильно |
| Требует сильной культуры письма | Да (обязательно) | Нет | Да |
| Усталость от митингов | Низкая | Высокая | Средняя |
| Сохраняет историю решений | Сильно (документы) | Слабо (в головах) | Средне |
| Менторство junior | Тяжело | Легко | Средне |
Ни одна строка не универсальна. Веса ваших измерений определяют правильный ответ.
Когда что реально работает
Async-first, если:
- Разброс таймзон больше 6 часов
- Сильная культура письма (каждый инженер пишет 1-page decision doc)
- Большая часть работы — IC-кодирование со внятным scope
- Латенси решений 1-3 дня допустима
- Команда на 80% состоит из senior (мало менторства)
Sync-first, если:
- Все в одном месте или ±3 таймзоны
- Строите что-то с плотной координацией (основатели, incident work)
- Много junior, которым нужно близкое менторство
- Решения должны приниматься в часы
- Команда меньше 8 человек (meeting-overhead низкий)
Гибрид, если:
- 15-100 инженеров в 2-3 таймзонах
- Есть и junior, и senior
- Можете определить 2-3 конкретных sync-ритуала (arch review, 1:1, инцидент-колл) и всё остальное держать async
Что показывает PanDev Metrics об этом
Наши IDE heartbeat-данные отличают coding-время от meeting/context-switch-времени. Команды, объявляющие себя "async-first", но имеющие субчасовую медиану coding/день, почти всегда запускают sync-в-маскировке — Slack-сообщения, требующие ответа за 15 минут, функционируют как синхронные прерывания, независимо от среды.
Честная находка из наших данных: label, который команды дают своему workflow, предсказывает focus time хуже, чем реальная ожидаемая скорость ответа в Slack. Команды, ожидающие 2-минутных ответов в Slack, имеют sync-style фокус-профиль, даже если называют себя async. Команды с ожиданием 4-часовых ответов выглядят как async в данных, независимо от официального процесса.
Один caveat: мы видим IDE-активность напрямую, meeting-нагрузку — нет. Meeting-время в статье триангулируется из "gap time" в IDE-данных плюс интеграция с календарём клиентов. Интеграция opt-in и покрывает ~30% нашей базы — meeting-таблицы выше — это эта подвыборка плюс публичные индустриальные отчёты.
Контринтуитивный тезис
Async-first движение было в основном правым про митинги и в основном неправым про документацию. Письменно-первое работает, когда качество письма высокое и дисциплина чтения реальна. Для большинства команд — не так. Видим больше документов, чем кто-то читает; async-first превращается в "каждый проигнорирован в своей таймзоне". Команды, успешные в async, — не просто пишут больше, они читают больше, и беспощадно режут митинги, которые могли быть decisions-with-deadlines письменно.
Честный лимит: мы не контролируем состав команды, когда меряем focus-time vs workflow style. Команды, самоотбирающиеся в async-first, вероятно уже имеют senior, которые умеют фокусироваться. Команды sync-first часто имеют junior, которым это нужно. Workflow и команда формируют друг друга, и чисто разделить причину и следствие в наших данных мы не можем.
Что почитать
- Focus Time: почему 2 часа непрерывного кода = 6 часов с прерываниями
- Remote vs офис: что говорят тысячи часов данных
- 40% налог на продуктивность от context switching
Если ваша команда застряла в дебатах async vs sync, замерьте сначала: какая ваша реальная медиана фокус-времени и сколько идут решения? Ответ редко тот, что кто-то угадал.