7 min lectura • Guide 657 of 877
Cómo Usar GitScrum para Onboarding de Desarrolladores
Un buen onboarding transforma nuevos empleados en miembros productivos del equipo mientras construye su confianza y conexión con el equipo. GitScrum ayuda a estructurar onboarding con checklists de tareas, tracking de progreso y visibilidad del journey de aprendizaje.
Estructura de Onboarding
Plan de 90 Días
TIMELINE DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEMANA 1: SETUP Y ORIENTACIÓN │
│ ├── Día 1: Bienvenida, admin, intros del equipo │
│ ├── Día 2-3: Setup de ambiente, accesos │
│ └── Día 4-5: Tour del codebase, visión de arquitectura │
│ Meta: Ambiente funcionando, puede correr tests │
│ │
│ SEMANAS 2-4: PRIMERAS CONTRIBUCIONES │
│ ├── Semana 2: Primer bug fix con pair programming │
│ ├── Semana 3: Mejoras de documentación │
│ └── Semana 4: Segundo bug fix independientemente │
│ Meta: Primer PR mergeado, entiende el flujo │
│ │
│ MES 2: CONSTRUYENDO CONFIANZA │
│ ├── Semana 5-6: Trabajo de features pequeñas │
│ ├── Semana 7-8: Comenzar code reviews │
│ Meta: Contribuyendo al trabajo del sprint │
│ │
│ MES 3: AUMENTANDO OWNERSHIP │
│ ├── Semana 9-10: Features medianas │
│ └── Semana 11-12: Owner de área pequeña del proyecto │
│ Meta: Contribuidor independiente │
└─────────────────────────────────────────────────────────────┘
Tablero de Onboarding
TABLERO DE PROYECTO DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ Nuevo Empleado: Alex Chen | Inicio: Ene 8 | Buddy: Sarah │
├───────────────┬─────────────┬─────────────┬─────────────────┤
│ POR HACER │ EN PROGRESO │ BLOQUEADO │ HECHO │
├───────────────┼─────────────┼─────────────┼─────────────────┤
│ │ │ │ │
│ □ Revisar │ ■ Setup de │ │ ✓ Conocer equipo│
│ docs de │ ambiente │ │ │
│ arquitectura│ local │ │ ✓ Admin HR │
│ │ │ │ │
│ □ Primer bug │ ■ Completar │ │ ✓ Obtener laptop│
│ fix (#234) │ training │ │ │
│ │ seguridad │ │ ✓ Acceso a │
│ □ Observar │ │ │ cuentas │
│ standup │ │ │ │
│ │ │ │ │
└───────────────┴─────────────┴─────────────┴─────────────────┘
Checklist Semana 1
Tareas del Día 1
CHECKLIST DÍA 1:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ADMIN (Mañana): │
│ ☐ Firmar papeles con HR │
│ ☐ Obtener laptop y equipamiento │
│ ☐ Configurar email y calendario │
│ ☐ Unirse a Slack/Teams │
│ │
│ PRESENTACIONES (Tarde): │
│ ☐ Conocer al manager (30 min) │
│ ☐ Conocer al equipo (almuerzo de equipo) │
│ ☐ Conocer al buddy de onboarding │
│ ☐ Tour oficina/workspace virtual │
│ │
│ ORIENTACIÓN: │
│ ☐ Revisar handbook de la empresa │
│ ☐ Entender estructura del equipo │
│ ☐ Agregar reuniones recurrentes al calendario │
│ │
│ FIN DEL DÍA: │
│ ☐ Check-in de 15 min con buddy │
│ ☐ Preguntas documentadas para mañana │
└─────────────────────────────────────────────────────────────┘
Setup de Ambiente
CHECKLIST DE AMBIENTE DE DESARROLLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ACCESOS (Día 2): │
│ ☐ Agregado a organización GitHub/GitLab │
│ ☐ Acceso a consola AWS/Cloud │
│ ☐ Acceso a sistema CI/CD │
│ ☐ Herramientas internas (Jira, Confluence, etc.) │
│ ☐ Acceso a vault de password manager │
│ │
│ SETUP LOCAL (Día 2-3): │
│ ☐ Clonar repositorios principales │
│ ☐ Instalar dependencias de desarrollo │
│ ☐ Configurar IDE con settings del equipo │
│ ☐ Setup de base de datos local │
│ ☐ Correr aplicación localmente │
│ ☐ Correr suite de tests exitosamente │
│ │
│ VERIFICACIÓN (Día 3): │
│ ☐ Hacer cambio de test local │
│ ☐ Crear branch de test │
│ ☐ Abrir PR draft (no mergear) │
│ ☐ Verificar que CI corre correctamente │
└─────────────────────────────────────────────────────────────┘
Primeras Tareas
Primeras Tareas Ideales
CARACTERÍSTICAS DE PRIMERAS TAREAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUENAS PRIMERAS TAREAS: │
│ ✓ Alcance bien definido │
│ ✓ Criterios de aceptación claros │
│ ✓ Aisladas (pocas dependencias) │
│ ✓ Bajo riesgo si se retrasan │
│ ✓ Tocan código real (no solo docs) │
│ ✓ Existen ejemplos similares │
│ │
│ EJEMPLOS: │
│ • Fix typo en mensaje de error │
│ • Actualizar documentación desactualizada │
│ • Agregar caso de test faltante │
│ • Mejorar manejo de errores en lugar conocido │
│ • Pequeño cambio de copy en UI │
│ │
│ EVITAR PARA PRIMERAS TAREAS: │
│ ✗ Lógica de negocio compleja │
│ ✗ Dependencias cross-equipo │
│ ✗ Deadlines ajustados │
│ ✗ Requisitos poco claros │
│ ✗ Trabajo de path crítico │
└─────────────────────────────────────────────────────────────┘
Plantilla de Tarea
PLANTILLA DE TAREA PARA NUEVO EMPLEADO:
┌─────────────────────────────────────────────────────────────┐
│ Tarea: Agregar indicador de carga a búsqueda de usuarios │
├─────────────────────────────────────────────────────────────┤
│ │
│ CONTEXTO: │
│ Actualmente, la búsqueda de usuarios no muestra feedback │
│ mientras carga, causando confusión. │
│ │
│ QUÉ HACER: │
│ 1. Agregar spinner de carga mientras corre llamada API │
│ 2. Ocultar spinner cuando llegan resultados │
│ 3. Mostrar mensaje de error si API falla │
│ │
│ ARCHIVOS A VER: │
│ • src/components/UserSearch.tsx (modificar) │
│ • src/components/Spinner.tsx (usar este) │
│ • src/components/ProductSearch.tsx (ejemplo similar) │
│ │
│ CRITERIOS DE ACEPTACIÓN: │
│ ☐ Spinner se muestra durante búsqueda │
│ ☐ Spinner se oculta en éxito │
│ ☐ Estado de error maneja falla de API │
│ ☐ Tests existentes siguen pasando │
│ │
│ SOPORTE: │
│ Buddy: @Sarah - mensaje si atascado > 30 min │
│ Tiempo estimado: 2-4 horas │
└─────────────────────────────────────────────────────────────┘
Tracking de Progreso
Calendario de Check-ins
CHECK-INS DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DIARIO (Semana 1): │
│ 15 min con buddy │
│ "¿Qué no está claro? ¿Algún bloqueador?" │
│ │
│ SEMANAL (Semanas 1-4): │
│ 30 min con manager │
│ Revisión de progreso, feedback, preguntas │
│ │
│ BI-SEMANAL (Mes 2-3): │
│ 45 min con manager │
│ Discusión de carrera más profunda, performance │
│ │
│ CHECK-INS DE MILESTONES: │
│ │
│ Día 5: ¿Ambiente funcionando? ¿Preguntas? │
│ Día 14: ¿Primer PR mergeado? ¿Flujo del equipo claro? │
│ Día 30: ¿Contribuyendo a sprints? ¿Cómodo? │
│ Día 60: ¿Creciendo independencia? ¿Áreas a mejorar? │
│ Día 90: ¿Onboarding completo? ¿Próximas áreas de crec.? │
└─────────────────────────────────────────────────────────────┘
Métricas de Éxito
INDICADORES DE ÉXITO DE ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEMANA 1: │
│ ✓ Ambiente funcionando │
│ ✓ Puede correr tests localmente │
│ ✓ Entiende flujo del equipo │
│ │
│ SEMANA 2-4: │
│ ✓ Primer PR mergeado │
│ ✓ Asistió a todas las ceremonias del equipo │
│ ✓ Hace preguntas proactivamente │
│ │
│ MES 2: │
│ ✓ Completando features pequeñas │
│ ✓ Haciendo code reviews │
│ ✓ Contribuyendo en standups │
│ │
│ MES 3: │
│ ✓ Contribuidor independiente │
│ ✓ Mentoreando otros nuevos │
│ ✓ Proponiendo mejoras │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Buddy asignado para soporte día a día
- Tareas bien definidas con contexto completo
- Check-ins regulares pero no abrumadores
- Expectativas claras para cada fase
- Celebrar primeros logros para construir confianza
- Feedback temprano para corregir rumbo