Onboarding de Nuevos Miembros del Equipo Rápidamente

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

1. Preparar antes del Día 1 — Sin esperar por acceso
2. Primer PR en Semana 1 — Victoria temprana construye confianza
3. Complejidad progresiva — Tareas pequeñas a grandes
4. Buddy, no solo — Soporte humano esencial
5. Ciclos de feedback — Check-in a 30/60/90

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