5 min lectura • Guide 777 of 877
Gestión de Time Zones para Equipos Remotos
Las diferencias de time zone pueden tanto obstaculizar como mejorar la productividad. GitScrum ayuda a equipos distribuidos a trabajar asincrónicamente mientras se mantienen conectados.
Entendiendo el Overlap
PLANIFICACIÓN DE TIME ZONES
═══════════════════════════
EJEMPLO DE DISTRIBUCIÓN DE EQUIPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UTC 0 2 4 6 8 10 12 14 16 18 20 22 24 │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ SF ░░░░░░░░░░░░░░░░░░████████████░░░░░░░ PST (-8) │
│ NYC ░░░░░░░░░░░░░░███████████████░░░░░░░░ EST (-5) │
│ Madrid ░░░░░░░░█████████████████░░░░░░░░░░░ CET (+1) │
│ India ░░░░████████████████░░░░░░░░░░░░░░░░ IST (+5:30) │
│ Sydney ██████████████░░░░░░░░░░░░░░░░░░░███ AEDT (+11) │
│ │
│ ████ = Horas laborales (9am-6pm local) │
│ ░░░░ = Fuera de horario │
│ │
│ OVERLAP: │
│ │
│ SF + NYC: 6 horas │
│ NYC + Madrid: 5 horas │
│ Madrid + India: 4 horas │
│ SF + Madrid: 1 hora (mínimo) │
│ SF + Sydney: 0-1 horas (muy difícil) │
│ │
│ ESTRATEGIA: │
│ • Maximizar async para pares de bajo overlap │
│ • Programar meetings sync durante ventanas de overlap │
│ • No requerir todos en cada reunión │
│ │
└─────────────────────────────────────────────────────────────┘
Programación de Reuniones
DISTRIBUCIÓN JUSTA DE REUNIONES
═══════════════════════════════
ROTACIÓN DE SCHEDULE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ No hacer que siempre los mismos tengan horarios malos │
│ │
│ ROTACIÓN DE STANDUP (15 min): │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Semana 1: 9am Madrid (4am SF, 2pm India) ← SF early │ │
│ │ Semana 2: 5pm Madrid (9am SF, 10pm India) ← India late│ │
│ │ Semana 3: 1pm Madrid (5am SF, 6pm India) ← SF early │ │
│ │ Semana 4: 8am Madrid (midnight SF) ← SF async │ │
│ │ │ │
│ │ SF participa live 2 semanas, async 2 semanas │ │
│ │ El dolor es compartido │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
REUNIONES CRÍTICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Encontrar el sweet spot de overlap │
│ • Algunas personas harán sacrificio │
│ • Rotar quién se sacrifica │
│ • Grabar para ausentes │
│ │
└─────────────────────────────────────────────────────────────┘
Handoffs Efectivos
HANDOFFS A TRAVÉS DE TIME ZONES
═══════════════════════════════
PRINCIPIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "Follow the sun" - El trabajo puede continuar │
│ 24/7 si los handoffs son buenos │
│ │
└─────────────────────────────────────────────────────────────┘
HANDOFF CHECKLIST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Al final de tu día: │
│ │
│ ☐ Status actualizado en tarea │
│ ☐ Próximos pasos documentados │
│ ☐ Blockers identificados │
│ ☐ Context escrito para siguiente persona │
│ ☐ Code en estado mergeable o claramente WIP │
│ │
└─────────────────────────────────────────────────────────────┘
EJEMPLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ GS-245: Integración de Pagos │
│ │
│ Status: En progreso (60% completo) │
│ │
│ Lo que hice hoy: │
│ ├── Integración con Stripe completada │
│ ├── Unit tests escritos │
│ └── PR abierto: #423 │
│ │
│ Próximos pasos: │
│ ├── Escribir integration tests │
│ ├── Agregar manejo de errores para edge cases │
│ └── Actualizar documentación de API │
│ │
│ Blocker: │
│ Necesito clarificación sobre webhooks (ver comment) │
│ │
│ Para quien continúe: │
│ El archivo principal es payment_service.py │
│ Los tests están en tests/test_payments.py │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicación Async
DISEÑANDO PARA ASYNC
════════════════════
PRINCIPIOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Escribe como si no pudieras hacer follow-up │
│ └── Incluye todo el contexto en el primer mensaje │
│ │
│ 2. Establece expectativas de respuesta │
│ └── "Necesito respuesta para X fecha" │
│ │
│ 3. No asumas disponibilidad inmediata │
│ └── Planifica con 24 horas de buffer │
│ │
│ 4. Usa el canal apropiado │
│ ├── Urgente: Slack con @mention │
│ ├── Normal: Comentario en tarea │
│ └── Referencia: Documentación │
│ │
└─────────────────────────────────────────────────────────────┘
RESPETANDO OFF-HOURS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Usa scheduled send para mensajes │
│ • No esperes respuestas fuera de horario │
│ • Configura Do Not Disturb │
│ • Respeta boundaries de otros │
│ │
└─────────────────────────────────────────────────────────────┘
En GitScrum
TIME ZONES EN GITSCRUM
══════════════════════
VISIBILIDAD ASYNC:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Board actualizado en tiempo real │
│ • Status visible sin preguntar │
│ • Historial de actividad │
│ • Comentarios como comunicación async │
│ │
└─────────────────────────────────────────────────────────────┘
DOCUMENTACIÓN DE TAREAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Descripciones detalladas │
│ • Acceptance criteria claros │
│ • Links a recursos relevantes │
│ • Historial de discusiones │
│ │
└─────────────────────────────────────────────────────────────┘