Cómo crear y gestionar un equipo de ingeniería remoto desde Europa

Ya has elegido un partner y un modelo de colaboración. Si no, empieza por cómo evaluar un partner nearshore en Europa y por la comparativa de los tres modelos de colaboración. Este artículo trata de lo que viene después del contrato: la mecánica diaria de crear y gestionar un equipo de ingeniería remoto con ingenieros en Portugal, tanto si el resto de tu empresa está en Berlín como en Boston.

Los equipos remotos rara vez se desvían porque los ingenieros sean flojos. Se desvían porque nadie puso por escrito las reglas por defecto: nadie decidió cuándo hay que responder un mensaje, dónde queda una decisión, qué significa "hecho" ni qué horas son para reuniones. Cada sección termina con algo que puedes copiar en tu repositorio esta misma semana.

Haz primero las cuentas de las zonas horarias

El Portugal continental (Lisboa, Oporto) usa UTC+0 en invierno (WET) y UTC+1 en verano (WEST). Frente a las ciudades con las que es más probable que trabajes, Oporto va:

• Londres: a la misma hora, todo el año.
• Berlín, París, Madrid, Ámsterdam, Varsovia: una hora por detrás, todo el año.
• Helsinki, Atenas, Bucarest: dos horas por detrás, todo el año.
• Nueva York: cinco horas por delante durante la mayor parte del año.
• Chicago, Denver, San Francisco: seis, siete y ocho horas por delante.

Los desfases europeos nunca se mueven, porque la UE y el Reino Unido cambian la hora en el mismo instante: a las 01:00 UTC del último domingo de marzo y del último domingo de octubre. EE. UU. cambia a las 02:00 hora local del segundo domingo de marzo y del primer domingo de noviembre. Entre esas fechas, la diferencia transatlántica es una hora menor. En 2027, Oporto va cuatro horas por delante de Nueva York del 14 al 28 de marzo y del 31 de octubre al 7 de noviembre, y los demás desfases estadounidenses de la lista se reducen una hora en esas mismas semanas. La mayor parte de Arizona nunca cambia la hora, así que Phoenix va siete horas por detrás de Oporto en invierno y ocho en verano.

Esas semanas rompen las reuniones recurrentes. Un evento de calendario queda fijado a la zona horaria en la que se creó, así que una reunión creada en Nueva York para las 11:00 (las 16:00 en Oporto) aparece a las 15:00 en Oporto durante esas semanas. Decide qué reloj manda en cada reunión recurrente, déjalo por escrito y avisa al otro lado antes de cada cambio.

Un ejemplo práctico

Supón que todo el mundo trabaja de 09:00 a 18:00 hora local, con la comida incluida. La ventana compartida va del inicio más tardío al final más temprano, una vez que ambos están en el mismo reloj:

• Oporto y Nueva York: las 09:00 en Nueva York son las 14:00 en Oporto, y Oporto termina a las 18:00, así que la ventana compartida es de 14:00 a 18:00 hora de Oporto (de 09:00 a 13:00 en Nueva York). Cuatro horas, cinco en las semanas de desajuste.
• Oporto y Chicago: tres horas, cuatro en las semanas de desajuste.
• Oporto y San Francisco: una hora, dos en las semanas de desajuste.
• Oporto y Berlín: ocho horas. Oporto y Helsinki: siete.

Ahora resta la comida. Si en Nueva York comen a las 12:00, son las 17:00 en Oporto, y las cuatro horas se quedan en tres útiles. Si los ingenieros de Oporto aceptan trabajar de 11:00 a 20:00, la ventana con Nueva York sube a seis horas y San Francisco consigue tres. Eso sale de las tardes de los ingenieros, así que va en el acuerdo escrito y se revisa; nunca se da por hecho.

Para comprobar tus propios números en cualquier fecha (Python 3.9 o posterior; en Windows, ejecuta antes pip install tzdata):

from datetime import date, datetime, time, timedelta
from zoneinfo import ZoneInfo

def overlap_hours(day, a, b):
    """a and b are (timezone, start, end) working days on the same date."""
    def window(tz, start, end):
        zone = ZoneInfo(tz)
        return datetime.combine(day, start, zone), datetime.combine(day, end, zone)
    a_start, a_end = window(*a)
    b_start, b_end = window(*b)
    shared = min(a_end, b_end) - max(a_start, b_start)
    return max(shared / timedelta(hours=1), 0)

porto = ("Europe/Lisbon", time(9), time(18))
new_york = ("America/New_York", time(9), time(18))
for day in [date(2027, 1, 18), date(2027, 3, 22), date(2027, 7, 19)]:
    print(day, overlap_hours(day, porto, new_york))

Imprime 4.0 para enero, 5.0 para la semana de desajuste de marzo y 4.0 para julio.

Programar dentro del solapamiento

• Dedica como máximo la mitad del solapamiento a reuniones programadas. Guarda el resto para desbloquear: pair programming, una llamada rápida sobre una revisión atascada.
• Pon el solapamiento en los calendarios de ambos equipos como un bloque con nombre, para que nadie lo ocupe.
• Todo lo demás, asíncrono por defecto: estado, code review, propuestas de diseño.
• Una pregunta hecha después del solapamiento se responde a la mañana siguiente, así que cada ingeniero tiene siempre un segundo ticket preparado.

Pon el acuerdo de trabajo por escrito

El acuerdo de trabajo es un archivo corto en el repositorio, WORKING_AGREEMENT.md, que se cambia mediante pull requests, igual que el código. En un equipo dedicado con su propio tech lead, el responsable es el tech lead; en una team extension, tu engineering manager. Los valores de abajo son un punto de partida; lo que importa es que los dos lados los hayan aceptado por escrito.

• Horario común: el solapamiento, indicado en las dos zonas horarias (14:00–18:00 Oporto, 09:00–13:00 Nueva York), con las semanas de desajuste anotadas.
• Chat: respuesta en menos de una hora durante el horario común. Fuera de él, no se espera respuesta.
• Revisión de pull requests: primera revisión en un día laborable como máximo desde que se marca como listo.
• Urgente: la herramienta de paging, nunca el chat. Si no merece un aviso, no es urgente.
• Decisiones: todo lo que cambie una interfaz, una dependencia o un modelo de datos lleva un registro de decisión en docs/adr/, revisado como pull request. Una decisión tomada en una llamada no cuenta hasta que está escrita ahí.
• Definition of done: mergeado, tests en verde en CI, desplegado en producción (detrás de un flag si hace falta), monitorización activa, runbook actualizado y ticket enlazado al cambio.
• On-call: quién está en la rotación, qué horas cubre cada región, la ruta de escalado y cómo se compensan las horas de on-call y el descanso posterior, acordado por escrito con tu partner antes del primer turno.
• Festivos: un calendario compartido con los festivos de los dos países. Los de Portugal no coinciden con los de EE. UU. ni con los alemanes, y cada municipio añade el suyo: el 13 de junio en Lisboa, el 24 de junio en Oporto.

Un registro de decisión no tiene por qué ser largo:

docs/adr/0007-move-background-jobs-to-postgresql.md

Status:       accepted, 2027-02-03
Context:      what forces a decision now, in five lines or fewer
Options:      what was considered, one line each
Decision:     what we will do
Consequences: what gets easier, what gets harder, what we will watch
Review:       link to the pull request where this was discussed

Quien se perdió la llamada, o quien llegue el año que viene, puede leer el porqué.

Si quieres una segunda opinión antes de ponerlo en marcha, nuestra evaluación gratuita de equipos nearshore analiza justo estas piezas: tus horas reales de solapamiento a lo largo del año, tu borrador de acuerdo de trabajo y dónde se están perdiendo decisiones entre zonas horarias.

Un proceso de selección que pruebe el trabajo en remoto

Tu partner hace el primer filtro de candidatos. Aun así, tú haces tu propio proceso con la lista corta, y debe poner a prueba el trabajo tal y como se va a hacer: por escrito, con diferencia horaria y sobre código.

1. 1Una prueba de trabajo sobre código realista. Un repositorio pequeño que se parezca al tuyo: un servicio con un test que falla, un informe de bug vago y una pequeña petición de funcionalidad. Limítala a tres horas, o págala si necesita más. Pide un pull request con descripción.
2. 2Una sesión de pair programming sobre su propia entrega. De sesenta a noventa minutos, en remoto, con las herramientas que tu equipo usa a diario. Amplía la funcionalidad junto con el candidato o corrige con él algo que salió en la revisión. Observa cómo razona en voz alta, cómo acepta una sugerencia y cómo dice "no lo sé".
3. 3Un intercambio por escrito. Deja un hueco deliberado en el enunciado de la prueba y mira si pregunta antes de suponer, y cómo.

Evalúa la escritura con la misma seriedad que el código:

• Primero la conclusión, después el razonamiento.
• Las suposiciones quedan explícitas allí donde el enunciado era ambiguo.
• La descripción del pull request permite a un revisor en otra zona horaria aprobarlo sin llamada: qué ha cambiado, por qué, cómo se ha probado y qué queda fuera.
• Los mensajes de commit explican la intención, no solo el diff.

Olvídate de los acertijos de algoritmos y de las pruebas para casa de varios días sin pagar. Ninguno de los dos muestra cómo trabaja alguien en tu código, y lo segundo descarta precisamente a los ingenieros senior que tienen otras opciones.

Onboarding: un pull request mergeado en la primera semana

Casi todo el trabajo de onboarding se puede hacer antes de que el ingeniero empiece.

• Antes del primer día: cuentas, acceso al repositorio y a CI, chat, el gestor de incidencias, acceso de solo lectura a staging, el gestor de contraseñas y un portátil que cumpla tu política de dispositivos. Una persona es dueña de esa checklist y la cierra antes de la fecha de incorporación.
• Primer día: el ingeniero clona el repositorio, ejecuta un único comando documentado (make dev, un dev container, un archivo compose) y tiene la aplicación funcionando en local con datos de prueba. Cada paso que falla es un bug del onboarding, y corregir la documentación es su primer commit.
• Un buddy asignado: una persona, idealmente con solapamiento completo, a la que se le quita carga del sprint durante las dos primeras semanas. "Pregunta a cualquiera" significa no preguntar a nadie.
• Primera semana: un pull request mergeado. Elige la tarea antes de la fecha de incorporación: pequeña, real y que pase por el camino del deploy. Lo que importa es el ciclo: rama, test, CI, revisión, merge, deploy. Lo que tarda ese pull request en recibir revisión es la primera medición de tu propio proceso.

Después, un plan 30-60-90 con resultados que puedas comprobar:

• Día 30: ha mergeado varios pull requests en un área, ha revisado el de otra persona, ha hecho un deploy y ha acompañado un turno de on-call si el puesto lo incluye.
• Día 60: ha llevado una pequeña funcionalidad del ticket a producción, ha escrito o actualizado un registro de decisión y ha entrado en la rotación de revisiones.
• Día 90: es el primer revisor de un componente, presenta su propio trabajo en la demo y es responsable del documento de onboarding para la siguiente incorporación.

Mantén en síncrono solo lo que lo necesita

El solapamiento es tu recurso más escaso. Gástalo en lo que sale mal por escrito:

• Síncrono: planificación semanal, retros, discusiones de diseño en las que de verdad hay desacuerdo, 1:1, respuesta a incidentes y pair programming para desbloquear.
• Asíncrono: el estado diario (publicado al empezar el día de cada persona: hecho, siguiente, bloqueos), code review, propuestas de diseño y anuncios.

Las demos siguen siendo en directo, dentro del solapamiento, y las presentan los ingenieros que construyeron lo que se enseña. Si solo hace demos el equipo interno, el equipo remoto se vuelve invisible para quienes fijan las prioridades.

Para las retros, recoge los temas por escrito antes, para que la reunión se dedique a discutir. Alterna el facilitador entre sedes y convierte cada acción en un ticket con responsable. Una acción que vuelve tres retros seguidas ya es una señal por sí misma.

Si un hilo de chat ha ido y vuelto tres veces sin converger, pásalo a una llamada dentro del solapamiento y publica el resultado en el hilo.

Mídelo y vigila la deriva

Toma una línea base en el primer mes con los sistemas que ya tienes y revísala cada pocas semanas. Compara el equipo remoto consigo mismo a lo largo del tiempo y con tu equipo interno sobre el mismo código, no con el benchmark de otra empresa.

• Lead time: del primer commit a estar funcionando en producción.
• Tiempo de revisión: desde que el pull request se marca como listo hasta la primera revisión, separado según autor y revisor compartan región o no. Aquí es donde primero se nota la fricción horaria.
• Tiempo de onboarding: días desde la fecha de incorporación hasta el primer pull request mergeado, y hasta el primer cambio en producción hecho de forma autónoma. Mide tu onboarding, no a la persona.
• Retención: quién se ha ido y cuántos componentes tienen una sola persona que haya revisado alguna vez sus cambios.

Si exportas los datos de pull requests de tu plataforma Git a PostgreSQL, los números de revisión salen con una consulta:

SELECT
  date_trunc('week', ready_at) AS week,
  author_region = reviewer_region AS same_region,
  count(*) AS pull_requests,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY first_review_at - ready_at) AS median_to_first_review,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY merged_at - ready_at) AS median_to_merge
FROM pull_requests
WHERE merged_at IS NOT NULL
GROUP BY 1, 2
ORDER BY 1, 2;

La deriva aparece antes que los plazos incumplidos. Vigila:

• El tiempo de revisión entre regiones subiendo mientras el de la misma región se mantiene.
• Pull requests cada vez más grandes, porque la gente acumula trabajo cuando la revisión es lenta.
• Preguntas que pasan de los canales del equipo a los mensajes privados, o que dejan de hacerse.
• Un estado escrito cada vez más corto y vago: "sigo con el ticket".
• Decisiones tomadas en llamadas sin registro de decisión, que el otro lado descubre después.
• Ingenieros remotos que reciben tickets pero nunca problemas, y que ya no presentan en las demos.
• Mensajes enviados a las 21:00 hora de Oporto que se vuelven normales.

Una de estas señales merece salir en el próximo 1:1. Varias a la vez suelen indicar que el acuerdo de trabajo ha dejado de cumplirse: conviene revisarlo juntos en lugar de añadir otra reunión.

Por dónde empezar

Haz las cuentas del solapamiento, escribe el acuerdo y consigue que el primer pull request se mergee en la primera semana. Todo lo demás se apoya en esas tres cosas. Si estás montando un equipo de ingeniería nearshore y quieres una visión externa, nuestra evaluación gratuita revisa tu solapamiento y tu calendario de reuniones, tu acuerdo de trabajo, tu proceso de onboarding desde el portátil hasta el primer pull request mergeado y tus datos de tiempo de revisión, y te dice dónde es más probable que el equipo se desvíe.