Onboarding Rápido de Nuevos Miembros | GitScrum

Haz que nuevos devs sean productivos rápido con onboarding estructurado, documentación clara y responsabilidad progresiva.

9 min de lectura

El onboarding de nuevos miembros del equipo es costoso—semanas de productividad reducida tanto para el nuevo empleado como para su buddy. El onboarding efectivo minimiza este costo a través de preparación, estructura y complejidad incremental, haciendo que los desarrolladores contribuyan valor real en días en lugar de meses.

Fases del Onboarding

Preparación Pre-Inicio

Antes del Día 1

CHECKLIST DE PRE-ONBOARDING
═══════════════════════════

CUENTAS Y ACCESO:
─────────────────────────────────────
□ Cuenta GitHub/GitLab agregada a org
□ Acceso a GitScrum provisionado
□ Slack/Teams agregado a canales
□ Email/calendario configurado
□ Credenciales VPN creadas
□ SSO configurado
□ Licencias de herramientas de desarrollo
□ Acceso a consola cloud (si necesario)

EQUIPO:
─────────────────────────────────────
□ Laptop ordenada y configurada
□ Herramientas de desarrollo pre-instaladas
□ Acceso a repositorio verificado
□ Puede clonar y ejecutar proyecto localmente
□ IDE configurado con settings del equipo

DOCUMENTACIÓN:
─────────────────────────────────────
□ Guía de onboarding lista
□ Docs de arquitectura actualizados
□ Guía de setup de desarrollo probada
□ Primeras tareas identificadas
□ Mentor asignado

PREPARACIÓN DEL EQUIPO:
─────────────────────────────────────
□ Equipo notificado de fecha de inicio
□ Mentor/buddy confirmado
□ Invitaciones de calendario para reuniones clave
□ Mensaje de bienvenida redactado
□ Agenda del primer día establecida

Día 1

Bienvenida y Setup

ESTRUCTURA DEL DÍA 1
════════════════════

MAÑANA:
─────────────────────────────────────
09:00  Reunión de bienvenida con manager
       ├── Visión general del equipo
       ├── Expectativas del rol
       ├── Metas de 30/60/90 días
       └── Preguntas y respuestas

10:00  Verificación de IT/Cuentas
       ├── Confirmar que todo el acceso funciona
       ├── Arreglar cualquier problema inmediatamente
       └── Instalar herramientas faltantes

11:00  Conocer al equipo
       ├── Presentaciones breves
       ├── Quién hace qué
       └── Tour de oficina (si es presencial)

TARDE:
─────────────────────────────────────
13:00  Setup del entorno de desarrollo
       ├── Clonar repositorios
       ├── Ejecutar scripts de setup
       ├── Verificar que build funciona
       ├── Ejecutar tests localmente
       └── Meta: "Hello World" ejecutándose

15:00  Introducción a primera tarea
       ├── Tarea pequeña, bien definida
       ├── Ruta no crítica
       ├── Criterios de éxito claros
       └── Buddy disponible para preguntas

16:30  Debrief del Día 1 con buddy
       ├── ¿Preguntas hasta ahora?
       ├── ¿Bloqueadores?
       ├── Plan para mañana
       └── Verificar estado mental

META DEL DÍA 1:
├── Todo el acceso funcionando
├── Entorno de desarrollo ejecutándose
├── Primera tarea iniciada
└── Sintiéndose bienvenido, no abrumado

Primera Semana

Programa de Semana 1

AGENDA DE SEMANA 1
══════════════════

DÍA 2: ORIENTACIÓN DEL CODEBASE
─────────────────────────────────────
Mañana:
├── Recorrido de arquitectura (2 hrs)
│   ├── Diseño de sistema de alto nivel
│   ├── Servicios/componentes clave
│   ├── Flujo de datos
│   └── Por qué se tomaron decisiones
│
├── Tour del codebase (1 hr)
│   ├── Estructura del repositorio
│   ├── Archivos/módulos clave
│   ├── Dónde viven las cosas
│   └── Convenciones de nombres

Tarde:
├── Continuar primera tarea
├── Sesión de pair programming (opcional)
└── Preguntas con buddy

DÍA 3: PROCESOS
─────────────────────────────────────
├── Flujo de trabajo de desarrollo
│   ├── Estrategia de branching
│   ├── Proceso de PR
│   ├── Expectativas de code review
│   └── Pipeline de CI/CD
│
├── Ceremonias ágiles
│   ├── Ritmo del sprint
│   ├── Formato de standup
│   ├── Proceso de retro
│   └── Uso de GitScrum

DÍA 4-5: PRIMERA CONTRIBUCIÓN
─────────────────────────────────────
├── Completar primera tarea
├── Enviar primer PR
├── Code review recibido
├── Iterar con feedback
├── ¡Primer merge! 🎉
└── Celebrar pequeña victoria

META DE SEMANA 1:
├── Primer PR mergeado
├── Entiende arquitectura básica
├── Conoce procesos del equipo
├── Ha hecho muchas preguntas
└── Relación con buddy establecida

Primer Mes

Complejidad Progresiva

SEMANA 2-4: CONSTRUYENDO COMPETENCIA
════════════════════════════════════

SEMANA 2: FEATURES PEQUEÑAS
─────────────────────────────────────
├── 2-3 tareas pequeñas, independientes
├── Diferentes áreas del codebase
├── Construyendo amplitud de exposición
├── Aún con soporte del buddy
└── Asistiendo a todas las ceremonias

SEMANA 3: FEATURES MEDIANAS
─────────────────────────────────────
├── Alcance ligeramente mayor
├── Algunas decisiones de diseño
├── Trabajo cross-componentes
├── Más independiente
└── Menos check-ins con buddy

SEMANA 4: TRABAJO REGULAR
─────────────────────────────────────
├── Tomando trabajo regular del sprint
├── Participando en planning
├── Haciendo code reviews
├── Respondiendo sus propias preguntas
└── Ayudando al próximo nuevo (si aplica)

CHECK-IN DE 30 DÍAS:
─────────────────────────────────────
Reunión con manager:
├── ¿Cómo va todo? (feedback honesto)
├── ¿Qué aún no está claro?
├── ¿Qué está funcionando bien?
├── ¿Qué podría mejorar?
├── Actualizar metas de 60 días si necesario
└── Abordar cualquier preocupación temprano

Tareas Iniciales

Buenas Primeras Tareas

PRIMERAS TAREAS IDEALES
═══════════════════════

CARACTERÍSTICAS:
─────────────────────────────────────
✓ Alcance bien definido
✓ Ruta no crítica
✓ Feedback inmediato posible
✓ Toca codebase real
✓ Completable en 1-2 días
✓ Tiene criterios de éxito claros
✓ Relacionado con trabajo del equipo

EJEMPLOS:
─────────────────────────────────────
1. CORRECCIÓN DE BUGS
   ├── Bug simple, aislado
   ├── Pasos claros de reproducción
   ├── Toca un archivo/módulo
   └── Aprende proceso de debugging

2. DOCUMENTACIÓN
   ├── Actualizar README desactualizado
   ├── Agregar comentarios faltantes
   ├── Mejorar instrucciones de setup
   └── Aprende codebase a través de docs

3. FEATURES PEQUEÑAS
   ├── Agregar campo de formulario
   ├── Nuevo endpoint API (simple)
   ├── Ajuste de UI
   └── Aprende flujo de desarrollo

4. TESTS
   ├── Agregar caso de test faltante
   ├── Mejorar cobertura para módulo
   ├── Arreglar test flaky
   └── Aprende enfoque de testing

5. REFACTORING
   ├── Renombrar variable confusa
   ├── Extraer función helper
   ├── Aplicar convenciones del equipo
   └── Aprende estándares de código

Tarea en GitScrum

SETUP DE ONBOARDING EN GITSCRUM
═══════════════════════════════

ETIQUETA: onboarding-friendly
─────────────────────────────────────
Marcar tareas apropiadas en backlog:
├── Etiqueta: "onboarding-friendly"
├── Descripción bien escrita
├── Criterios de aceptación claros
├── Estimada (1-3 puntos)
└── No crítica en tiempo

ASIGNACIÓN:
─────────────────────────────────────
Al asignar a nuevo empleado:
├── Asignar tarea
├── Agregar mentor como observador
├── Establecer fecha límite razonable
├── Enlazar a docs relevantes
└── Agregar contexto en comentarios

SEGUIMIENTO:
─────────────────────────────────────
Rastrear tareas de onboarding:
├── Tiempo desde asignación a completar
├── Número de iteraciones
├── Preguntas hechas
├── Bloqueadores encontrados
└── Usar para mejora del proceso

Documentación

Docs Esenciales

DOCUMENTACIÓN DE ONBOARDING
═══════════════════════════

GUÍA DE SETUP:
─────────────────────────────────────
Título: "Comenzando"

Contenidos:
├── Prerequisitos (herramientas, cuentas)
├── Clonar repositorio
├── Instalar dependencias
├── Variables de entorno
├── Ejecutar localmente
├── Ejecutar tests
├── Problemas comunes y soluciones
└── FAQ de troubleshooting

Formato:
├── Paso a paso
├── Comandos para copiar-pegar
├── Screenshots donde ayude
├── Probado con cada nuevo empleado
└── Actualizado cuando se rompe

VISIÓN GENERAL DE ARQUITECTURA:
─────────────────────────────────────
Título: "Arquitectura del Sistema"

Contenidos:
├── Diagrama de alto nivel
├── Descripciones de componentes
├── Flujo de datos
├── Tecnologías clave
├── Por qué se tomaron decisiones
├── Contexto histórico
└── Dirección futura

GUÍA DEL EQUIPO:
─────────────────────────────────────
Título: "Cómo Trabajamos"

Contenidos:
├── Miembros del equipo y roles
├── Ritmo del sprint
├── Normas de comunicación
├── Proceso de code review
├── Rotación de guardia
├── Proceso de toma de decisiones
└── Rutas de escalamiento

Sistema de Buddy

Asignación de Mentor

PROGRAMA EFECTIVO DE BUDDY
══════════════════════════

SELECCIÓN DE BUDDY:
─────────────────────────────────────
Buen buddy:
├── 6+ meses en el equipo
├── Paciente y disponible
├── Técnicamente competente
├── Buen comunicador
├── No abrumado con trabajo
└── Quiere ser mentor

No solo: Persona senior que está ocupada

RESPONSABILIDADES DEL BUDDY:
─────────────────────────────────────
Semana 1:
├── Check-ins diarios (30 min)
├── Disponible para preguntas
├── Sesiones de pair programming
├── Presentar a personas
└── Responder preguntas "tontas"

Semana 2-4:
├── 2-3 check-ins por semana
├── Mentor de code review
├── Ayudar a navegar organización
├── Celebrar victorias
└── Señalar preocupaciones al manager

En curso:
├── Café/chat semanal
├── Discusiones de carrera
├── Relación a largo plazo
└── Check-in a 6 meses

APOYO AL BUDDY:
─────────────────────────────────────
Reconocer esfuerzo del buddy:
├── Reducir trabajo del sprint del buddy
├── Contar mentoría como contribución
├── Agradecer públicamente
├── Factor en desempeño
└── Es trabajo real, tratarlo como tal

Midiendo el Éxito

Métricas de Onboarding

MÉTRICAS DE ONBOARDING
══════════════════════

TIEMPO AL PRIMER PR:
─────────────────────────────────────
Objetivo: Día 3-5
Medir: Días desde inicio a primer PR
Bueno: Menos de 5 días
Preocupación: Más de 2 semanas

TIEMPO A PRODUCTIVIDAD:
─────────────────────────────────────
Objetivo: Semana 4-6
Medir: Cuando toma trabajo regular del sprint
Bueno: Menos de 6 semanas
Preocupación: Más de 3 meses

SATISFACCIÓN DEL NUEVO EMPLEADO:
─────────────────────────────────────
Encuesta a 30, 60, 90 días:
├── Experiencia de onboarding (1-5)
├── Me siento productivo (1-5)
├── Entiendo arquitectura (1-5)
├── Sé a quién preguntar (1-5)
└── Mejoraría... (abierto)

TIEMPO DEL MENTOR:
─────────────────────────────────────
Rastrear horas gastadas del buddy:
├── Semana 1: 8-10 horas esperadas
├── Semana 2: 4-6 horas
├── Semana 3-4: 2-4 horas
└── Usar para planificación

RETENCIÓN A 90 DÍAS:
─────────────────────────────────────
Rastrear si nuevos empleados se quedan:
├── 100%: Gran onboarding
├── < 80%: Investigar problemas
└── Salida temprana = bandera roja

Mejores Prácticas

Para Onboarding

Anti-Patrones

ERRORES DE ONBOARDING:
✗ Sin acceso el Día 1
✗ "Lee el código" como onboarding
✗ Sin buddy/mentor asignado
✗ Primera tarea muy difícil
✗ Abrumar con información
✗ Sin check-ins
✗ Esperar productividad instantánea
✗ Documentación desactualizada

Soluciones Relacionadas

• Compartiendo conocimiento en equipos de desarrollo
• Mejores prácticas de documentación de equipo
• Gestionando equipos de desarrollo en crecimiento