Тайм-зоны и скорость разработки: реальная дата
Распределённая команда с 5 часами разницы в тайм-зонах имеет медианный lead time 6.8 дней на изменение. Локализованная команда на той же кодовой базе — тот же язык, тот же размер, тот же размер PR — имеет медианный lead time 3.2 дня. Это не погрешность. Это timezone-налог, и он примерно удваивается на каждые дополнительные 3-4 часа разницы. GitLab Remote Work Report 2023 назвал «3-5 часов overlap» sweet spot'ом для async-команд, и наши IDE-heartbeat данные по 100+ B2B-компаниям говорят то же — с дополнительной детализацией, куда именно уходит время.
Это не статья о том, хороша ли удалёнка (да, для многих команд). Это про конкретные механизмы, которыми разница тайм-зон замедляет доставку, и про измерения, которые скажут, платит ли ваша распределённая команда 2×-штраф по lead-time или научилась с ним жить.
{/* truncate */}
Почему эту цифру трудно найти
Большинство исследований «remote vs office» меряют self-reported продуктивность. Наш датасет меряет реальную IDE-телеметрию: coding time, PR-ревью по времени, commit timing и — ключевое здесь — heartbeats с tz-метками, которые позволяют увидеть, когда review-ожидание — это ожидание по стенным часам, а когда — по рабочим.
Путаница с timezone-impact: lead time в wall-clock выглядит ужасно, а в рабочих часах — нормально. Баг в том, что инженерия не живёт с 9 до 5. Баги шипятся в 10 вечера, потому что ревьюер из другой tz ещё онлайн. А ревью стоит 14 часов, потому что никого не было онлайн, когда PR приехал.
Наш датасет
- 100+ B2B-компаний с установленными IDE-плагинами, из них 71 — с инженерами в разных тайм-зонах
- Период наблюдения: январь 2025 — март 2026 (15 месяцев)
- Гранулярность: агрегаты по компании по timezone spread (макс. pairwise) и lead-time
- Исключены из timezone-анализа: команды <5 инженеров или с данными <3 месяцев
Lead time здесь — DORA-style commit-to-deploy, а не merge-to-deploy. См. наш разбор lead time в 4 стадиях по методологии.
Что показывает дата
Lead time растёт нелинейно с timezone spread
| Макс. spread в команде | Медианный commit-to-deploy lead time | 90-й перцентиль | n (компаний) |
|---|---|---|---|
| 0ч (один город) | 3.2 дня | 7.1 дня | 29 |
| 2ч (Киев ↔ Лиссабон) | 4.1 дня | 9.2 дня | 14 |
| 5ч (Лондон ↔ Нью-Йорк) | 6.8 дня | 16 дней | 18 |
| 8ч (Нью-Йорк ↔ Варшава) | 11.4 дня | 27 дней | 12 |
| 12ч (Нью-Йорк ↔ Сингапур) | 18.7 дня | 41 день | 9 |
Перегиб чётко на 5 часах. Ниже — handoff'ы ещё случаются в overlap-окнах. Выше — «быстрый вопрос» становится ожиданием на календарный день.
Форма почти идеально экспоненциальна в диапазоне 2ч-12ч. После 12ч сэмпл тонкий, вариативность взрывается — эти команды используют другие модели взаимодействия.
PR-ревью — самая большая компонента
Мы разложили lead-time gap по стадиям. Для 71 распределённой команды:
| Стадия | 0ч spread | 5ч spread | 8ч spread | Дельта (0ч → 8ч) |
|---|---|---|---|---|
| Commit → открыт PR | 4ч | 6ч | 9ч | +5ч |
| PR открыт → первое ревью | 7ч | 22ч | 38ч | +31ч |
| Первое ревью → merge | 8ч | 13ч | 19ч | +11ч |
| Merge → деплой | 6ч | 8ч | 11ч | +5ч |
First-review latency съедает 60-70% всего роста lead time. PR, открытый в 18:00 в Нью-Йорке, лежит 13 часов до того, как его кто-то увидит в Европе. Эти 13 часов — не «медленное ревью», это арифметика тайм-зон.
Overlap-окно важнее абсолютного spread
Команда, разнесённая на 8 часов, но с 3-часовым ежедневным overlap работает лучше, чем команда на 5 часов с 1-часовым overlap. Cross-reference по 71 команде: самый сильный предиктор lead time — не сам spread, а количество часов синхронного overlap в день.
| Ежедневный overlap | Медианный lead time | Корреляция с satisfaction |
|---|---|---|
| ≥4 часа | 4.1 дня | 0.68 |
| 2-3 часа | 7.2 дня | 0.41 |
| 1-2 часа | 12.4 дня | 0.22 |
| <1 час | 19.8 дня | -0.11 |
Корреляция с удовлетворённостью становится слегка отрицательной при <1 часа overlap — команды с полностью не-пересекающимися расписаниями отчитываются о более низкой удовлетворённости даже при стабильных delivery-цифрах. Человекам нужен хотя бы один синхронный touchpoint в день.
Heatmap overlap говорит, где реально лежит «синхронное окно» команды. Для US West + Европа — 7-10am PT / 3-6pm GMT. Любая встреча вне этого окна стоит кому-то вечера или утра.
Эффект async-зрелости
Интересное открытие: зрелые async-команды (определены как те, кто уже 18+ месяцев живёт в written-first коммуникации, сильных PR-шаблонах и decision docs) показывают на 40% меньший timezone-штраф, чем новые async-команды на том же spread.
| Async-зрелость | Lead time на 8ч spread | Lead time на 12ч spread |
|---|---|---|
| <6 мес async-опыта | 14.2 дня | 24.8 дня |
| 18+ мес async-опыта | 8.6 дня | 16.1 дня |
Это GitLab-handbook эффект. Команды, вложившиеся в письменную коммуникацию, self-serve docs и PR-first культуру, отыгрывают часть timezone-налога. Исследование Teevan et al. 2022 в Microsoft Research показало похожий эффект в крупном естественном эксперименте.
Что это значит для лидеров инженерии
1. Мерять overlap-часы, не только spread
Если дашборд команды показывает «команда в 6 timezone» — это не та метрика. Полезная — медианный ежедневный синхронный overlap по любой паре тиммейтов. Ниже 2 часов — вы управляете async-first командой, хотели того или нет. Планируйте соответственно.
2. Владеть PR-review latency
First-review latency — главная боль. Команды, которые её решают:
- Нанимают follow-the-sun review shift с 2+ ревьюерами в каждом tz-бэнде
- Принимают ожидание и пушат инженеров делать больше pre-review self-checks (линтеры, тесты, PR-чеклисты — см. наш чеклист code review)
- Делают PR меньше — мелкие PR ревьюятся быстрее независимо от spread
3. Закладывать 1.5-2× lead time при 5+ часах
Если руководство планирует по baseline локализованной команды, а у команды 5+ часов spread — каждая оценка roadmap оптимистична на 50-100% ещё до того, как добавили технические риски. Фиксированный множитель не элегантен, но ближе к реальности, чем делать вид, что расстояние бесплатно.
4. Следить за выгоранием на краях overlap
Инженеры, сидящие на краях overlap — работающие поздно, чтобы поймать Азию, или рано — чтобы поймать Европу, — показывают повышенные сигнатуры выгорания в наших данных. Их календарь выглядит «гибким», но энергетический паттерн — наказующий. Это часто невидимо менеджерам, потому что timezone-overlap работа одного конца команды выглядит «обычными часами» для другого.
Методология
Timezone spread — макс. pairwise разница часов между активными инженерами в скользящем 4-недельном окне. Ежедневный синхронный overlap — пересечение в часах типичного активного окна каждого инженера (5-95 перцентиль start-times сессий). Lead time — commit-to-deploy по определению DORA.
Честный лимит: наш датасет смещён к командам с формальным tooling-внедрением. Команды чисто на Slack без трекинга IDE в выборке недопредставлены. Наши цифры скорее недооценивают timezone-налог для сегмента с самой низкой async-зрелостью.
Контрарианский тейк
Общепринятое мнение: «remote-first компания должна нанимать где угодно в мире». Наша дата говорит: это верно только для компаний, у которых уже построена 18+ месяцев async-зрелости. Для компании в первом году распределёнки найм на 8+ часов spread — velocity-ловушка: новый нанятый стоит в 1.5-2× больше lead-time friction, чем тот же нанятый на 3 часа spread, и это не улучшается, пока async-плейбук не созрел. Большинству компаний лучше растить распределённость в 3-часовых бэндах 18 месяцев, а потом расширяться глобально, когда мышцы построены.