Checklist de Onboarding para Ingenieros Backend

Descripción General

Las dos primeras semanas de un ingeniero backend deciden más que su productividad — deciden si confía en el proceso del equipo, con qué rapidez se atreve a desplegar, y si seguirá aquí dentro de un año. Un onboarding sin estructura desperdicia el primer mes de contribución de un ingeniero nuevo. Sin una checklist, las nuevas incorporaciones pierden días averiguando qué repositorios clonar, qué canales de Slack importan y cómo desplegar su primer cambio — y forman su opinión sobre la competencia del equipo a partir de ese caos.

Esta checklist estructura las primeras dos semanas para que los nuevos ingenieros backend se conviertan en contribuyentes productivos rápidamente mientras absorben la cultura del equipo y los estándares técnicos. Está diseñada para copiarse, adaptarse a tu stack y mejorarse tras cada contratación — la sección de feedback del final es parte de la checklist, no decoración.

Cuándo Usar

Usa esta checklist cuando:

• Un nuevo ingeniero backend se une a tu equipo
• Un ingeniero se transfiere desde frontend u otra especialización
• Estás estandarizando el onboarding entre varios equipos
• Necesitas medir y mejorar tu proceso de onboarding

Para los documentos de apoyo que esta checklist referencia, consulta la plantilla de manual de ingeniería (estándares de código, herramientas, “cómo trabajamos”) y el documento de titularidad de servicio (lo que la nueva incorporación acabará poseyendo). Los equipos con guardias deberían además combinar los items de la Semana 2 con su documentación de incidentes y alertas.

Prerequisitos

Antes de que la nueva incorporación empiece:

• Hardware pedido y configurado (portátil, monitores, periféricos)
• Cuentas creadas (email, Slack, GitHub, proveedor cloud, VPN)
• Manager asignado y calendario bloqueado para los 1:1 de la primera semana
• Compañero de onboarding asignado del equipo de ingeniería
• Solicitudes de acceso enviadas para acceso de solo lectura a producción

Todo lo de esa lista debería estar hecho antes del primer día — una incorporación que pasa su primera mañana esperando un portátil o una invitación de GitHub aprende que el equipo no planifica, y eso es difícil de desaprender.

Antes del Primer Día

La semana anterior a que empiece la incorporación es donde el onboarding se gana o se pierde de verdad. El primer día de la checklist asume que cuatro cosas ya existen, y cada una falla de forma predecible cuando se omite:

• Hardware en mano. Envía el portátil para que llegue dos días laborables antes — aduanas, mensajería y buzones de portal se comen días. Para incorporaciones presenciales, el escritorio, la tarjeta de acceso y los periféricos deberían estar listos antes de que entren por la puerta.
• Cuentas provisionadas. Email, Slack, organización de GitHub, consola cloud, VPN, vault del gestor de contraseñas. Prueba cada login tú mismo con una cuenta nueva si puedes — “la invitación caducó” es un clásico atasco de primer día.
• Un compañero que esté realmente libre. El rol de compañero necesita capacidad planificada en el sprint. Un compañero inmerso en un deadline responderá en tres horas en lugar de tres minutos, y la incorporación aprende a dejar de preguntar.
• Un primer PR esperando. Prepara un cambio trivial — una errata en la documentación, un comentario desactualizado, una limpieza de etiquetas — para que la tarea de “mergear algo” del primer día no sea una búsqueda del tesoro.

El manager envía a la nueva incorporación un breve email previo: qué esperar el primer día, quién es su compañero y el enlace a la checklist, para que nada de la primera mañana sea una sorpresa.

Solución

# Checklist de Onboarding para Ingeniero Backend

## Nueva Incorporación: ______ | Fecha de Inicio: ______ | Manager: ______ | Compañero: ______

---

## Día 1: Bienvenida y Configuración

### Administrativo
- [ ] Completar papeleo de RRHH e inscripción de beneficios
- [ ] Recibir portátil y configuración de hardware
- [ ] Obtener tarjeta de acceso al edificio / pase de parking
- [ ] Configurar email y calendario
- [ ] Unirse a los canales esenciales de Slack/Teams
  - #general, #engineering, #backend, #incidents, #deployments
- [ ] Añadir foto de perfil y estado en Slack
- [ ] Programar 1:1s con manager, compañero y tech lead

### Entorno de Desarrollo
- [ ] Instalar el software requerido (ver el manual de ingeniería para versiones)
  - [ ] Git
  - [ ] Docker y Docker Compose
  - [ ] Node.js / Python / Java / Go (según el stack)
  - [ ] IDE (VS Code / IntelliJ / GoLand) con la configuración del equipo
  - [ ] kubectl y herramientas CLI del cloud
  - [ ] Postman o cliente de API
- [ ] Configurar Git con el email de empresa y la clave de firma
- [ ] Clonar los repositorios principales
  - [ ] Repositorio de la aplicación principal
  - [ ] Repositorio de infraestructura / despliegue
  - [ ] Repositorio de librerías / SDK compartidos
- [ ] Ejecutar el proyecto en local siguiendo el README
- [ ] Verificar que los tests locales pasan
- [ ] Hacer un arreglo trivial de documentación y abrir el primer PR

### Acceso y Seguridad
- [ ] Completar la formación de concienciación en seguridad
- [ ] Configurar el gestor de contraseñas con acceso al vault del equipo
- [ ] Activar MFA en todas las cuentas (GitHub, proveedor cloud, VPN)
- [ ] Solicitar y recibir acceso al entorno de staging
- [ ] Leer y aceptar las políticas de manejo de datos

---

## Semana 1: Orientación al Codebase

### Arquitectura y Sistemas
- [ ] Asistir a la sesión de visión de arquitectura (grabada si no es en directo)
- [ ] Revisar el diagrama de arquitectura y la documentación de flujo de datos
- [ ] Identificar los 5 servicios más críticos que posee tu equipo
- [ ] Entender el ciclo de vida de una petición: cliente → load balancer → servicio → base de datos
- [ ] Revisar la documentación de APIs (OpenAPI / Swagger)
- [ ] Recorrer la guía de depuración para problemas locales comunes

### Estándares de Código
- [ ] Leer el documento de estándares de código del equipo
- [ ] Revisar 5 PRs mergeados recientemente para entender los patrones de revisión
- [ ] Entender las reglas de linting y formato (ejecutar linters en local)
- [ ] Aprender la filosofía de testing del equipo (unit vs integration vs e2e)
- [ ] Revisar los patrones de manejo de errores del codebase

### Procesos
- [ ] Entender el ritmo de sprint/iteración (planning, standups, retros)
- [ ] Aprender cómo coger trabajo (sistema de tickets, tablero Kanban)
- [ ] Asistir a sprint planning y retrospectiva como observador
- [ ] Entender la rotación de guardias y los procedimientos de escalado
- [ ] Revisar los runbooks de respuesta a incidentes

### Primera Contribución
- [ ] Coger un "good first issue" (etiquetado en el tracker)
- [ ] Abrir un PR siguiendo la plantilla de PR del equipo
- [ ] Recibir y atender el feedback de la revisión de código
- [ ] Mergear el primer PR con la guía del compañero
- [ ] Verificar que el cambio se despliega a staging correctamente

---

## Semana 2: Integración Profunda

### Conciencia de Producción
- [ ] Acompañar a un ingeniero de guardia durante un turno (sin interrupciones)
- [ ] Revisar los dashboards de monitorización de producción
- [ ] Entender los umbrales de alerta y los procedimientos de paging
- [ ] Aprender a consultar logs en la herramienta de agregación del equipo
- [ ] Revisar postmortems recientes (últimos 3 meses)

### Conocimiento de Dominio
- [ ] Reunirse con el product manager para entender el roadmap actual
- [ ] Revisar funciones de cara al usuario y lógica de negocio con un experto de dominio
- [ ] Entender el modelo de datos y las relaciones entre entidades
- [ ] Revisar los puntos de integración con servicios externos
- [ ] Conocer los requisitos de cumplimiento y regulación (si aplica)

### Titularidad
- [ ] Identificar el servicio o componente que vas a poseer
- [ ] Revisar la documentación de titularidad del servicio
- [ ] Entender el pipeline de despliegue de tu servicio
- [ ] Aprender los procedimientos de rollback de tu servicio
- [ ] Añadirte a la rotación de guardias del servicio (con supervisión)

---

## Verificación de Finalización

| Área | Verificado por | Fecha | Notas |
|------|---------------|-------|-------|
| Configuración del entorno | ______ | ______ | |
| Build local funcionando | ______ | ______ | |
| Primer PR mergeado | ______ | ______ | |
| Formación de seguridad | ______ | ______ | |
| Visión de arquitectura | ______ | ______ | |
| Acompañamiento de guardia | ______ | ______ | |

## Feedback

**¿Qué fue lo más útil?**

**¿Qué faltó o resultó confuso?**

**¿Cuánto tardaste en sentirte productivo?**

**Recomendaciones para mejorar esta checklist:**

Cómo Usar Esta Checklist

Tres roles hacen que la checklist funcione, y el documento solo cumple su función si cada uno sabe qué posee. El manager posee el resultado — verifica la finalización, dirige los check-ins y desbloquea lo que la incorporación no puede resolver sola (solicitudes de acceso, compras, presentaciones entre equipos). El compañero posee el día a día — un par, no un mentor ni un manager, que responde las preguntas de “cómo hago…” en minutos en lugar de dejar que se acumulen en bloqueos. Asigna al compañero antes del primer día y elige a alguien que lleve en el equipo lo suficiente para saber dónde vive lo no documentado. La nueva incorporación posee la propia checklist — marca los items, señala lo que falta y rellena la sección de feedback al final.

La checklist está secuenciada deliberadamente. El Día 1 trata de eliminar fricción — hardware, cuentas, un entorno local funcionando y un PR trivial mergeado para que la incorporación acabe el día habiendo entregado algo. La Semana 1 construye contexto: arquitectura, estándares de código, procesos del equipo y una primera contribución real (pero pequeña). La Semana 2 pasa de aprender a pertenecer: conciencia de producción, conocimiento de dominio y el primer paso hacia poseer un servicio.

Dos items tienen un peso desproporcionado. El primer PR del primer día — un arreglo de documentación basta — convierte a “el nuevo” en “alguien que entrega” y saca a la luz todos los problemas de entorno mientras aún hay tiempo de arreglarlos. La tabla de verificación de finalización — un documento compartido que firman manager e incorporación — evita el modo de fallo silencioso donde todos asumen que el onboarding ocurrió y nadie lo comprobó.

La Checklist del Compañero

El compañero recibe su propia mini-checklist — un rol que nadie explica es un rol que nadie hace:

• Semana 1: check-in diario de 15 minutos (una reunión real, no “escríbeme si necesitas algo”), sentarse juntos en el primer PR, y responder cada “pregunta tonta” como si fuera razonable — porque lo es.
• Semana 2: enseñarle los dashboards, el pipeline de despliegue y el postmortem del último incidente; presentarle a las personas que poseen los servicios adyacentes.
• Semanas 3–4: bajar a un check-in dos veces por semana y empezar a revisar sus PRs como un revisor normal — las ruedas de apoyo se quitan gradualmente, no de golpe.

El compañero no es un mentor (crecimiento profesional) ni un manager (rendimiento) — es el par que sabe dónde están enterrados los cadáveres del codebase. Rota el rol entre incorporaciones para que no se convierta en el trabajo paralelo permanente de una persona.

Adaptar la Checklist

La plantilla es deliberadamente agnóstica de stack — las partes específicas de backend son las secciones de Semana 1 y Semana 2, e incluso ahí importa más la forma que los items. Antes de tu primera contratación, dedica una hora a reemplazar los items genéricos por los reales: los nombres reales de los repos, los canales reales de Slack, los dashboards reales. Una checklist que dice “clonar repositorios principales” se lee una vez; una que dice “clona api-server, infra y sdk-go” se usa.

Deja algunos items marcados “si aplica” en lugar de borrarlos — la formación de cumplimiento, por ejemplo, solo aplica a dominios regulados, pero eliminar la fila significa que la próxima incorporación en un equipo regulado no pensará en ella. La checklist crece por adición y se encoge marcando cosas como N/A, no borrándolas; así la memoria de “una vez olvidamos X” permanece en el documento.

Plan de Onboarding 30-60-90 Días

La checklist de dos semanas hace a alguien productivo; el plan 30-60-90 lo hace independiente. Cada fase tiene metas concretas y un check-in donde el manager las verifica.

=== Día 30: Contribuyendo ===

Metas:
  - Entorno completamente configurado y funcionando
  - Primeros 3-5 PRs mergeados (bug fixes, funciones pequeñas, tests)
  - Participando en revisiones de código (revisando a otros)
  - Entiende el flujo del equipo (standups, planning, retros)
  - Ha conocido a todos los miembros del equipo en 1:1
  - Formación de seguridad y cumplimiento completada

Check-in: Manager + compañero revisan el progreso, identifican bloqueos

=== Día 60: Poseyendo ===

Metas:
  - Posee un servicio o componente (revisor principal de cambios)
  - Ha acompañado guardias durante 2+ turnos
  - Participa en discusiones de diseño
  - Puede desplegar a staging de forma independiente
  - Puede depurar problemas de producción con guía
  - Ha escrito o actualizado documentación

Check-in: El manager revisa la preparación para titularidad, ajusta el alcance

=== Día 90: Independiente ===

Metas:
  - Guardias totalmente independientes (con respaldo disponible)
  - Puede desplegar a producción de forma independiente
  - Liderando una función o mejora pequeña
  - Mentorizando a la siguiente incorporación (si aplica)
  - Ha completado un postmortem o contribuido a uno
  - Revisión de rendimiento: en camino según expectativas

Check-in: Manager + nivel superior, confirman onboarding exitoso

Los checkpoints existen porque “el onboarding está hecho” es un estado difuso — cada check-in lo convierte en una pregunta de sí/no con un responsable con nombre. Si una meta no se cumple al día 30, eso es feedback del proceso: o el calendario estaba mal, faltó soporte, o hay una cuestión real de rendimiento que abordar pronto en lugar de en el mes seis.

El plan se combina con la checklist en lugar de duplicarla: la checklist cubre las dos primeras semanas tarea a tarea, el 30-60-90 cubre el trimestre meta a meta. Usa ambos — la checklist les lleva hasta el final de la semana dos, el plan les mantiene en movimiento cuando la checklist se acaba.

Dónde Falla el Onboarding

La mayoría de los fallos de onboarding parecen problemas de personas pero son problemas de proceso disfrazados:

• El onboarding-héroe: un ingeniero senior hace todo informalmente, el conocimiento vive en su cabeza, y la checklist solo existe cuando está de vacaciones. Solución: la checklist es el proceso — el héroe se convierte en el dueño que la actualiza.
• La checklist en la que nadie confía: lleva dos años sin tocarse, la mitad de los enlaces están muertos, y las incorporaciones aprenden a preguntar al compañero en lugar de leerla — comportamiento correcto ante un documento que miente. Una checklist obsoleta es peor que ninguna porque engaña mientras parece autorizada.
• El muro de la semana uno: la incorporación termina las tareas de configuración el martes y luego divaga — sin primeros issues curados, sin presentaciones programadas, nadie le dijo cómo se ve “bien” esta semana. La estructura por fases de la checklist existe para evitar exactamente ese aire muerto.
• La dificultad silenciosa: las incorporaciones remotas o junior suelen esconder la confusión para no parecer lentas. El check-in diario con el compañero no es cortesía opcional — es la instrumentación que saca a la luz el “estoy atascado” antes de que se convierta en “tres semanas de retraso”.

El fallo más fácil de pasar por alto tiene forma de éxito: la incorporación marca cada casilla, dice que el onboarding fue genial, y tres meses después aún no puede desplegar sola porque nadie verificó la habilidad, solo la asistencia. Para eso está la tabla de verificación de finalización — “verificado por” significa que alguien lo vio ocurrir, no que la incorporación dice que ocurrió.

Medir el Onboarding

Una checklist sin métricas no puede mejorar. Cuatro números cubren la mayor parte:

Métrica	Objetivo	Qué te dice
Tiempo hasta el primer PR mergeado	< 3 días	Fricción de entorno y proceso
Tiempo hasta el primer despliegue a producción	< 2 semanas	Confianza + salud del pipeline
Tiempo hasta guardia independiente	< 2 meses	Profundidad de la documentación
Satisfacción de la incorporación (encuesta día 30/60/90)	Mejorando entre contrataciones	La experiencia en sí

Rastréalas por contratación y revísalas trimestralmente — un tiempo-hasta-primer-PR creciente suele ser un problema de herramientas (portátiles lentos, setup roto), no de contratación. La sección de feedback de la checklist alimenta el mismo bucle: pregunta a cada incorporación qué faltó, qué estaba desactualizado o qué confundió, y arregla la checklist en una semana mientras el recuerdo está fresco.

La encuesta de días 30/60/90 solo necesita tres preguntas, y conviene hacerlas por escrito para que la respuesta no se tiña por la reunión: “¿Qué te sorprendió más?”, “¿Dónde te sentiste menos preparado?”, “¿Qué cambiarías de tus dos primeras semanas?” Las respuestas que se repiten entre contrataciones son el backlog del dueño de la checklist.

Variantes

Contexto	Ajustes	Notas
Onboarding de ingeniero senior	Añadir revisión de arquitectura, responsabilidades de mentoría, presentaciones entre equipos	Espera finalización más rápida (5-7 días en lugar de 10)
Contratista / consultor	Centrarse en repos del proyecto, omitir procesos de cultura/equipo	Calendario más ajustado, foco en entregable específico
Becario / ingeniero junior	Añadir repaso de fundamentos de programación, calendario de pair programming	Calendario más largo, guía más estructurada
Equipo remoto primero	Añadir normas de comunicación asíncrona, coordinación de zonas horarias, cafés virtuales	Sin setup físico; más énfasis en documentación
Fusión / adquisición de equipo	Añadir orientación de sistemas legacy, sensibilidad política, adopción de procesos nuevos	Foco en integración más que en arranque desde cero

El onboarding remoto merece nota aparte: todo lo que en una oficina ocurre por ósmosis — oír cómo funcionan los despliegues, ver a alguien depurar — hay que fabricarlo. Sobre-documenta, graba las sesiones de arquitectura y programa el contacto informal (cafés virtuales, un canal #random) explícitamente en lugar de esperar que ocurra.

Las transferencias internas forman una variante propia: se saltan la mayor parte del Día 1 (ya tienen hardware y cuentas) pero necesitan más contexto de dominio que una incorporación nueva — ya saben cómo funciona la organización, lo que les falta es qué posee este equipo. Comprime la checklist a las secciones de arquitectura y procesos de la Semana 1 más el track de titularidad, y conserva el compañero — conocer la empresa no es lo mismo que conocer el codebase.

Lo Que Funciona

Las prácticas de abajo vienen de equipos que incorporan repetidamente y lo miden — el patrón que comparten es tratar el onboarding como un producto: un proceso documentado con dueño, instrumentación y bucle de feedback, en lugar de un evento que le ocurre a la persona nueva.

1. Asigna un compañero, no solo un manager — los compañeros responden las preguntas de “cómo hago…” que los managers no pueden
2. Ten el primer PR listo el día 1 — un arreglo de documentación o un test genera confianza inmediata
3. Graba las sesiones de arquitectura — las sesiones en directo son valiosas pero no repetibles; grábalas para futuras incorporaciones
4. Mide el tiempo hasta el primer PR — es el indicador adelantado de la fricción del onboarding
5. Actualiza la checklist tras cada contratación — los ojos frescos detectan huecos inmediatamente

Errores Comunes

Estos son los patrones que convierten una checklist de dos semanas en una rampa de seis meses:

1. Centrarse solo en la configuración técnica — la cultura, las relaciones y el conocimiento de procesos importan tanto como el código
2. Lanzar a las incorporaciones a tareas complejas demasiado pronto — las primeras contribuciones deberían poder hacerse en 1-2 días
3. Omitir las explicaciones de acceso a producción — los ingenieros nuevos necesitan saber qué pueden y qué no pueden tocar
4. No explicar el “por qué” detrás de los procesos — seguir reglas sin entenderlas crea comportamiento de cargo cult
5. Olvidar los check-ins tras la semana 2 — el onboarding continúa durante 3-6 meses; la checklist es solo el principio

Un buen onboarding también se devuelve en retención. La incorporación que entrega el primer día, tiene un compañero que sabe su nombre y ve un camino de 90 días hacia poseer un servicio es la que recomienda a sus antiguos colegas. La checklist cuesta unas horas por contratación; la alternativa cuesta una dimisión.

Solución de Problemas

Los modos de fallo de abajo tratan del proceso, no de la incorporación — cuando el onboarding va mal, mira primero el sistema y luego la persona.

• La incorporación lleva días bloqueada por accesos: las solicitudes entraron tarde o a la cola equivocada — envíalas una semana antes de la fecha de inicio, y mantén un responsable con nombre por cada solicitud para que “pendiente” no sea un estado huérfano.
• El Día 1 acaba sin PR mergeado: el “arreglo trivial” no era trivial — mantén una lista curada de arreglos de documentación e issues de jardinería listos, y que el compañero conduzca el primer PR junto a la incorporación si hace falta.
• El compañero está demasiado ocupado para ayudar: el rol de compañero necesita holgura explícita en su sprint — si no es capacidad planificada, se convierte silenciosamente en capacidad cero. Rota los compañeros entre contrataciones para evitar el burnout.
• La checklist dice “hecho” pero la incorporación está perdida: los items se marcaron sin verificación — la tabla de finalización necesita un verificador (iniciales del manager o del compañero), no solo una casilla.
• Cada contratación encuentra el mismo hueco: la sección de feedback se recoge pero no se actúa sobre ella — asigna un dueño de la checklist y cierra el bucle en una semana tras cada incorporación.

Lecturas Adicionales

• GitLab Handbook — Onboarding — cómo una empresa totalmente remota estructura el onboarding a escala
• Atlassian Team Playbook — plays para la salud del equipo, incluyendo ejercicios de roles y afines al onboarding
• Relacionado en este sitio: la plantilla de manual de ingeniería para el documento que leen las incorporaciones, y la checklist de revisión de código que usarán en la semana 2.