9 min lectura • Guide 717 of 877
Onboarding de Nuevos Miembros del Equipo de Forma Efectiva
Un buen onboarding convierte a los nuevos empleados en miembros productivos del equipo más rápido. GitScrum ayuda a estructurar el proceso de onboarding con seguimiento de tareas, acceso a documentación y coordinación de mentores que asegura que nada se pierda.
Marco de Onboarding
Línea de Tiempo
FASES DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRE-DÍA 1 (Antes de que empiecen): │
│ • Equipo ordenado y listo │
│ • Cuentas creadas (email, Slack, GitScrum, Git) │
│ • Acceso provisionado │
│ • Mentor asignado │
│ • Primera semana agendada │
│ │
│ SEMANA 1: ORIENTACIÓN │
│ • Conocer al equipo │
│ • Configurar entorno de desarrollo │
│ • Aprender visión general del codebase │
│ • Completar primera tarea pequeña │
│ Meta: Entorno funcionando, primer commit │
│ │
│ SEMANA 2-4: TRABAJO GUIADO │
│ • Trabajar en tareas amigables para principiantes │
│ • Sesiones de pair programming │
│ • Aprender procesos del equipo │
│ • Check-ins regulares con mentor │
│ Meta: Contribuir independientemente en tareas simples │
│ │
│ MES 2-3: AUMENTANDO INDEPENDENCIA │
│ • Tomar tareas de complejidad media │
│ • Menos pairing, más trabajo independiente │
│ • Comenzar a participar en discusiones de diseño │
│ • Mentor disponible pero no constante │
│ Meta: Miembro completo del equipo, asignaciones normales │
└─────────────────────────────────────────────────────────────┘
Checklist de Primera Semana
CHECKLIST DE ONBOARDING SEMANA 1:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DÍA 1: BIENVENIDA │
│ ☐ Reunión de bienvenida con manager │
│ ☐ Presentaciones del equipo │
│ ☐ Tour de oficina/setup remoto │
│ ☐ Papelería de HR completada │
│ ☐ Equipo funcionando │
│ │
│ DÍA 2: ACCESO Y HERRAMIENTAS │
│ ☐ Todas las cuentas activas y accesibles │
│ ☐ Setup del entorno de desarrollo iniciado │
│ ☐ Clonar repositorios principales │
│ ☐ IDE y herramientas configuradas │
│ ☐ Revisar normas de comunicación del equipo │
│ │
│ DÍA 3: ORIENTACIÓN DEL CODEBASE │
│ ☐ Sesión de visión general de arquitectura │
│ ☐ Ejecutar aplicación localmente │
│ ☐ Leer documentación clave │
│ ☐ Recorrer una feature reciente │
│ │
│ DÍA 4: PRIMERA TAREA │
│ ☐ Tomar "good first issue" │
│ ☐ Pair con mentor │
│ ☐ Hacer primer cambio de código │
│ ☐ Abrir primer PR │
│ │
│ DÍA 5: PROCESO Y RITMO │
│ ☐ Participar en standup del equipo │
│ ☐ Primer PR revisado y mergeado │
│ ☐ Retrospectiva de Semana 1 con mentor │
│ ☐ Plan de Semana 2 creado │
└─────────────────────────────────────────────────────────────┘
Componentes Clave
Sistema de Mentores
ROL DEL MENTOR DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RESPONSABILIDADES DEL MENTOR: │
│ │
│ Semana 1: │
│ • Check-ins diarios de 30 min │
│ • Pair en setup de entorno │
│ • Responder todas las preguntas (no hay "preguntas tontas")│
│ • Presentar a miembros del equipo │
│ • Revisar primer PR detalladamente │
│ │
│ Semana 2-4: │
│ • Check-ins 3x por semana │
│ • Pair en tareas complejas │
│ • Explicar contexto e historia del equipo │
│ • Proporcionar feedback sobre código y proceso │
│ • Ayudar a navegar la organización │
│ │
│ Mes 2-3: │
│ • Check-ins semanales │
│ • Disponible para preguntas │
│ • Ayudar con desarrollo de carrera │
│ • Reducir gradualmente la participación │
│ │
│ ASIGNACIÓN DE TIEMPO DEL MENTOR: │
│ Semana 1: 50% del tiempo del mentor │
│ Semana 2-4: 25% del tiempo del mentor │
│ Mes 2-3: 10% del tiempo del mentor │
│ │
│ SELECCIÓN DEL MENTOR: │
│ • Miembro experimentado del equipo (no necesariamente sr) │
│ • Buen comunicador y maestro │
│ • Tiene capacidad (no sobrecargar) │
│ • Rota para distribuir conocimiento │
└─────────────────────────────────────────────────────────────┘
Documentación
DOCUMENTACIÓN DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DOCS ESENCIALES (NoteVault): │
│ │
│ 📄 Guía de Bienvenida │
│ • Misión y valores del equipo │
│ • Quién es quién y qué hacen │
│ • Normas de comunicación │
│ • Dónde encontrar cosas │
│ │
│ 📄 Configuración del Entorno de Desarrollo │
│ • Instrucciones paso a paso │
│ • Problemas comunes y soluciones │
│ • Herramientas y versiones requeridas │
│ • Cómo verificar que el setup funciona │
│ │
│ 📄 Visión General de Arquitectura │
│ • Diagrama del sistema │
│ • Servicios clave y sus propósitos │
│ • Flujo de datos │
│ • Por qué se tomaron las decisiones │
│ │
│ 📄 Flujo de Trabajo de Desarrollo │
│ • Cómo usamos Git │
│ • Proceso de PR │
│ • Expectativas de code review │
│ • Definición de hecho │
│ │
│ 📄 Glosario │
│ • Términos específicos del equipo │
│ • Terminología del producto │
│ • Acrónimos │
│ │
│ MANTENER DOCS ACTUALIZADOS: │
│ Nuevo empleado encuentra problema → Arreglar doc inmediato │
│ "Si tú luchaste, alguien más también lo hará" │
└─────────────────────────────────────────────────────────────┘
Tareas Iniciales
BUENOS PRIMEROS ISSUES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CARACTERÍSTICAS DE BUENAS TAREAS INICIALES: │
│ │
│ ✅ Criterios de aceptación claros │
│ ✅ Alcance limitado (1-2 días máximo) │
│ ✅ Toca código real (no trabajo sin sentido) │
│ ✅ Bajo riesgo si hay errores │
│ ✅ Enseña algo sobre el codebase │
│ ✅ Hay alguien disponible para ayudar │
│ │
│ EJEMPLOS: │
│ │
│ GRANDES PRIMERAS TAREAS: │
│ • Corregir un typo en la UI │
│ • Agregar un campo simple a un formulario │
│ • Escribir tests para función existente │
│ • Actualizar documentación │
│ • Bug pequeño con reproducción clara │
│ │
│ EVITAR PARA NUEVOS: │
│ • Features complejas │
│ • Requisitos vagos │
│ • Trabajo de ruta crítica │
│ • Refactoring profundo │
│ • Fechas límite ajustadas │
│ │
│ PROGRESIÓN: │
│ Semana 1: Tareas triviales (construir confianza) │
│ Semana 2: Tareas pequeñas (aprender patrones) │
│ Semana 3-4: Tareas medianas (desarrollar habilidades) │
│ Mes 2+: Tareas normales (contribución completa) │
└─────────────────────────────────────────────────────────────┘
Midiendo el Éxito
Métricas de Onboarding
INDICADORES DE ÉXITO DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIEMPO A PRODUCTIVIDAD: │
│ │
│ Hito │ Objetivo │ Real │
│────────────────────────┼───────────┼─────────────────────│
│ Entorno funcionando │ Día 2 │ Día 1 ✅ │
│ Primer PR mergeado │ Día 5 │ Día 4 ✅ │
│ Tarea solo completada │ Semana 2 │ Semana 2 ✅ │
│ Feature independiente │ Semana 4 │ Semana 5 ⚠️ │
│ Velocidad completa │ Mes 3 │ Mes 2 ✅ │
│ │
│ CHECK-INS CUALITATIVOS: │
│ │
│ Final de Semana 1: │
│ "¿Te sientes preparado para el éxito?" │
│ "¿Qué no está claro o es confuso?" │
│ "¿Algo te está bloqueando?" │
│ │
│ Final de Mes 1: │
│ "¿Te sientes productivo?" │
│ "¿Qué hubiera ayudado más?" │
│ "¿Estás recibiendo suficiente soporte?" │
│ │
│ CICLO DE FEEDBACK: │
│ Sugerencias del nuevo → Mejorar onboarding │
│ Cada nuevo debería tener mejor experiencia que el anterior │
└─────────────────────────────────────────────────────────────┘
Mejora Continua
MEJORANDO EL ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DESPUÉS DE CADA NUEVO EMPLEADO: │
│ │
│ Preguntas de Retro (reunión de 30 min): │
│ 1. ¿Qué fue más útil? │
│ 2. ¿Qué fue confuso o faltó? │
│ 3. ¿Qué tomó más tiempo del esperado? │
│ 4. ¿Qué agregarías al onboarding? │
│ 5. Califica tu experiencia de onboarding (1-10) │
│ │
│ ITEMS DE ACCIÓN: │
│ • Arreglar gaps de documentación inmediatamente │
│ • Agregar al checklist de onboarding │
│ • Mejorar herramientas si el setup fue doloroso │
│ • Notas para el próximo mentor │
│ │
│ SEGUIMIENTO DE TENDENCIAS: │
│ │
│ Contrato│ Rating │ Tiempo 1er PR │ Notas │
│─────────┼────────┼───────────────┼───────────────────────│
│ Ene '24 │ 6/10 │ Día 6 │ Problemas de setup │
│ Mar '24 │ 7/10 │ Día 4 │ Docs mejorados │
│ May '24 │ 8/10 │ Día 3 │ Setup automatizado │
│ Jul '24 │ 9/10 │ Día 2 │ Gran mentor │
│ │
│ META: Cada nuevo califica mejor que el anterior │
└─────────────────────────────────────────────────────────────┘