9 min lectura • Guide 87 of 877
Creando Onboarding Efectivo para Nuevos Desarrolladores
El onboarding de nuevos desarrolladores puede tomar semanas o meses sin estructura, dejando a los recién llegados confundidos y a los miembros existentes constantemente interrumpidos. Un programa de onboarding efectivo usa NoteVault de GitScrum para documentación, tareas iniciales cuidadosamente diseñadas, y expectativas claras para reducir el tiempo-a-primer-commit de semanas a días. El objetivo no es solo configuración técnica—es crear seguridad psicológica y construir relaciones que habiliten productividad a largo plazo.
Filosofía del Onboarding
Qué Logra un Buen Onboarding
RESULTADOS ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ MIDIENDO ÉXITO ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ ONBOARDING POBRE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Semana 1: "Lee el wiki" (desactualizado, fragmentado) ││
│ │ Semana 2: "Sombrea a alguien" (interrumpe su trabajo) ││
│ │ Semana 3: "Elige cualquier ticket" (sin contexto, falla)││
│ │ Semana 4: Aún haciendo preguntas básicas ││
│ │ Mes 2: Finalmente algo productivo ││
│ │ Mes 3: Aún descubriendo conocimiento tribal ││
│ │ ││
│ │ Resultado: Nuevo empleado se siente incompetente ││
│ │ Equipo frustrado por interrupciones ││
│ │ Primera contribución real: 4-6 semanas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ONBOARDING EFECTIVO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Día 1: Ambiente funciona, primer PR merged (fix docs) ││
│ │ Día 2-3: Completar 2-3 "good first issues" ││
│ │ Semana 1: Pareado en feature real con mentor ││
│ │ Semana 2: Primera feature propia end-to-end ││
│ │ Semana 3-4: Contribuyendo al 50% capacidad ││
│ │ Mes 2: Miembro completo, mentoreando siguiente hire ││
│ │ ││
│ │ Resultado: Nuevo empleado se siente capaz ││
│ │ Equipo gana contribuidor rápido ││
│ │ Primera contribución real: 2-3 días ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework 30-60-90 Días
EXPECTATIVAS PROGRESIVAS:
┌─────────────────────────────────────────────────────────────┐
│ FASES ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRIMEROS 30 DÍAS: APRENDIZAJE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ambiente completamente configurado y funcionando ││
│ │ • Entender arquitectura codebase ││
│ │ • Completar 5-10 tareas pequeñas ││
│ │ • Conocer todos los miembros del equipo 1:1 ││
│ │ • Saber a quién preguntar qué ││
│ │ ││
│ │ Métrica éxito: Puede ejecutar, testear, deployar ││
│ │ código independientemente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DÍAS 31-60: CONTRIBUCIÓN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ser dueño de 2-3 features medianas end-to-end ││
│ │ • Participar en code reviews (dar + recibir) ││
│ │ • Asistir y contribuir a ceremonias sprint ││
│ │ • Empezar a identificar mejoras ││
│ │ ││
│ │ Métrica éxito: Completando features con nivel ││
│ │ normal de soporte ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DÍAS 61-90: OWNERSHIP │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ser dueño de un área del codebase ││
│ │ • Tomar decisiones arquitecturales (con guía) ││
│ │ • Mejorar documentación basado en experiencia ││
│ │ • Ayudar a onboardear siguiente nuevo hire ││
│ │ ││
│ │ Métrica éxito: Miembro completo, mayormente independiente│
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Documentación en NoteVault
Runbook Onboarding
DOCUMENTACIÓN ESTRUCTURADA:
┌─────────────────────────────────────────────────────────────┐
│ ESTRUCTURA NOTEVAULT ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📓 Guía Onboarding │
│ │ │
│ ├─ 📄 Bienvenida & Overview Equipo │
│ │ • Quiénes somos, qué construimos │
│ │ • Roster equipo con fotos, roles, contacto │
│ │ • Normas comunicación (cuándo Slack vs email) │
│ │ • Calendario reuniones y expectativas │
│ │ │
│ ├─ 📄 Checklist Día 1 │
│ │ ☐ Cuentas creadas (GitHub, GitScrum, Slack) │
│ │ ☐ Repo clonado y corriendo localmente │
│ │ ☐ Primer PR merged (typo fix o README update) │
│ │ ☐ Presentado en canal Slack del equipo │
│ │ ☐ 1:1 agendado con manager │
│ │ ☐ Buddy asignado e intro meeting hecho │
│ │ │
│ ├─ 📄 Setup Desarrollo Local │
│ │ • Prerrequisitos (versión Node, Docker, etc.) │
│ │ • Instrucciones setup paso a paso │
│ │ • Errores comunes y soluciones │
│ │ • Verificación: "Terminaste cuando tests pasan" │
│ │ │
│ ├─ 📄 Overview Arquitectura │
│ │ • Diagrama sistema con explicaciones componentes │
│ │ • Archivos clave y qué hacen │
│ │ • Flujo datos para operaciones comunes │
│ │ • Punteros "empieza aquí" para cada área │
│ │ │
│ └─ 📄 FAQ & Conocimiento Tribal │
│ • "¿Por qué hacemos X de esta manera?" │
│ • Decisiones históricas y contexto │
│ • Gotchas comunes │
│ • Quién sabe qué (mapa experticia) │
│ │
└─────────────────────────────────────────────────────────────┘
Tareas Iniciales
Good First Issues
DISEÑANDO TAREAS INICIALES:
┌─────────────────────────────────────────────────────────────┐
│ PRIMERAS TAREAS IDEALES EN GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ CARACTERÍSTICAS BUENAS TAREAS INICIALES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Alcance pequeño (1-4 horas) ││
│ │ ✅ Criterios aceptación claros ││
│ │ ✅ Toca código producción real ││
│ │ ✅ Bajo riesgo si se hace incorrectamente ││
│ │ ✅ Introduce un nuevo concepto ││
│ │ ✅ Tiene patrones existentes a seguir ││
│ │ ││
│ │ ❌ NO: "Refactoriza el sistema autenticación" ││
│ │ ❌ NO: "Arregla este bug" (sin contexto) ││
│ │ ❌ NO: "Construye la nueva feature" (mucho alcance) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EJEMPLO BUENA PRIMERA TAREA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarea: Agregar estado loading a lista usuarios ││
│ │ ││
│ │ Labels: good-first-issue, onboarding ││
│ │ Estimación: 2 puntos ││
│ │ ││
│ │ Descripción: ││
│ │ Actualmente lista usuarios no muestra nada mientras ││
│ │ carga. Agregar un loading spinner. ││
│ │ ││
│ │ Criterios aceptación: ││
│ │ ☐ Spinner muestra mientras fetch usuarios ││
│ │ ☐ Spinner coincide patrón existente en ProductList ││
│ │ ☐ Test agregado para estado loading ││
│ │ ││
│ │ Para empezar: ││
│ │ 1. Ver cómo ProductList maneja loading (src/components) ││
│ │ 2. UserList está en src/features/users/UserList.tsx ││
│ │ 3. Usar componente <Spinner /> de src/ui ││
│ │ ││
│ │ Preguntar a @mentor si bloqueado más de 30 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Modelo Mentoría
Sistema Buddy
ROL BUDDY ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ RESPONSABILIDADES BUDDY │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUIÉN: Miembro experimentado equipo (no manager) │
│ │
│ DEBERES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PRIMERA SEMANA: ││
│ │ • Check-in diario 15-min ││
│ │ • Parear en primeras tareas juntos ││
│ │ • Revisar todos PRs mismo día ││
│ │ • Disponible para "preguntas tontas" (sin juicio) ││
│ │ • Presentar a miembros equipo ││
│ │ ││
│ │ SEMANAS 2-4: ││
│ │ • 2-3 check-ins por semana ││
│ │ • Primer reviewer en PRs ││
│ │ • Parear en tareas complejas ││
│ │ • Navegar preguntas organizacionales ││
│ │ ││
│ │ MES 2+: ││
│ │ • Check-in semanal ││
│ │ • Transición a relación equipo normal ││
│ │ • Retrospectiva sobre experiencia onboarding ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ASIGNACIÓN TIEMPO BUDDY: │
│ Semana 1: ~4 horas (20% de semana) │
│ Semana 2-4: ~2 horas (10% de semana) │
│ Mes 2: ~1 hora (5% de semana) │
│ │
│ Esto es TRABAJO REAL. Tareas buddy reducidas acordemente. │
│ │
└─────────────────────────────────────────────────────────────┘
Seguridad Psicológica
Creando Ambiente Seguro
PSICOLOGÍA NUEVO HIRE:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUYENDO CONFIANZA │
├─────────────────────────────────────────────────────────────┤
│ │
│ MIEDOS COMUNES NUEVO HIRE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Haré una pregunta tonta y pareceré incompetente" ││
│ │ "Todos los demás parecen saber todo" ││
│ │ "Ya debería haber descifrado esto" ││
│ │ "Mi código no es tan bueno como el de ellos" ││
│ │ "Se equivocaron contratándome" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMPORTAMIENTOS QUE CONSTRUYEN SEGURIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "Gran pregunta, no supe eso por meses" ││
│ │ ✅ "Déjame mostrarte cómo abordaría esto" ││
│ │ ✅ "Cometí el mismo error cuando empecé" ││
│ │ ✅ "Esto es lo que NO está documentado..." ││
│ │ ✅ "Tu perspectiva fresca encontró un issue real" ││
│ │ ││
│ │ ❌ "Eso está en los docs" (sin ayudar a encontrarlo) ││
│ │ ❌ "Ya deberías saber eso" ││
│ │ ❌ Suspirar cuando hacen preguntas ││
│ │ ❌ Criticar PR sin explicar por qué ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NORMAS EXPLÍCITAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Decir a nuevos hires Día 1: ││
│ │ ││
│ │ "Harás preguntas que pensamos son obvias. ││
│ │ Eso es ESPERADO. Significa que docs incompletos. ││
│ │ Tu confusión nos ayuda a mejorar. ││
│ │ ││
│ │ Si estás trabado 30 minutos, pregunta. No esperes. ││
│ │ Queremos interrupciones en semana 1. ││
│ │ Así aprendes más rápido." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘