Cuando alguien nuevo se une a un equipo, la mayoría de las organizaciones sigue un guion conocido: compartir los materiales de la empresa, repasar la historia del proyecto y explicar los roles y las responsabilidades. Los documentos existen y, aun así, las mismas preguntas vuelven en cuanto empieza el trabajo de verdad.
“¿A quién debo preguntar primero en esta situación?” “¿Podemos implementar ya esta petición del cliente?” “¿Retrasamos el lanzamiento porque QA ha encontrado un problema?” “¿Esto lo decide el desarrollador o el PMO?”
Según Gallup, solo el 12 % de los empleados está muy de acuerdo en que su organización hace bien el onboarding de las nuevas incorporaciones. SHRM informa de que solo el 29 % de las nuevas incorporaciones se siente preparado y respaldado para desempeñar su nuevo rol. El onboarding cuesta no solo porque falte información, sino porque las nuevas incorporaciones todavía no han practicado tomar decisiones dentro del contexto real del trabajo.
El onboarding es aprender contexto, no entregar documentos
Un buen onboarding no se queda en explicar las normas de la empresa. Ayuda a las nuevas incorporaciones a entender cómo funciona la empresa, cómo fluyen las decisiones, cómo son los estándares del proyecto y de qué se ocupa cada rol.
Muchos programas siguen dependiendo de documentos: PDF de la empresa, resúmenes del proyecto, guías de procesos, manuales de herramientas y listas de verificación por rol. Esos materiales importan. La carencia está en que leerlos no es lo mismo que decidir qué hacer cuando se retrasa una entrega o un cliente cambia el alcance en mitad de un sprint.
Un caso de la primera semana en un proyecto nuevo
Imagina a un PMO recién incorporado a la construcción de un sitio web global. La carpeta del proyecto tiene cronogramas, responsables, entregables y normas de reporte. En la primera semana, el cliente pide una funcionalidad adicional antes del lanzamiento.
El proceso de cambios está documentado. En la práctica, el nuevo PMO sigue preguntándose: ¿responder que sí de inmediato, preguntar primero a los desarrolladores, estimar el impacto en el cronograma, tratarlo como un cambio de alcance o escalarlo primero internamente?
Lo que necesita no es una definición. Necesita el orden del criterio. El onboarding basado en escenarios da esa práctica antes de que lleguen las consecuencias reales.
Por qué funciona el onboarding basado en escenarios
El onboarding con escenarios presenta situaciones cercanas al trabajo real y pide a las personas que elijan una respuesta.
Ejemplo: un cliente pide una funcionalidad nueva una semana antes del lanzamiento. Como PMO, ¿qué deberías hacer primero?
- Decir que sí porque lo pide el cliente.
- Preguntar a los desarrolladores si pueden hacer horas extra.
- Aclarar la petición y revisar su impacto en el cronograma, el alcance y los riesgos.
- Rechazarla y dejarlo todo para después del lanzamiento.
Lo importante no es solo elegir la “3”. Es explicar por qué la 3 es más segura y qué riesgos crean las demás opciones.
Qué cambia cuando conviertes los escenarios en misiones
First Run convierte estos escenarios en misiones dentro del juego. Las nuevas incorporaciones entran en Make Feelbetter, una empresa de TI ficticia, eligen un rol (Desarrollador, PMO, Maquetador web, Planificador o Diseñador) y conocen a los NPC repartidos por el mapa del campus.
Los NPC del PMO se centran en decisiones de cronograma y riesgo. Los NPC de desarrollo plantean casos de API y depuración. Los planificadores practican cómo convertir peticiones vagas en requisitos claros. Los diseñadores evalúan la jerarquía de los CTA y la coherencia de la UI.
Quien juega toma decisiones, recibe retroalimentación inmediata y sigue rutas propias de su rol que se pueden reutilizar en formaciones posteriores.
Las decisiones y la retroalimentación importan más que los puntos
El onboarding basado en juegos no es mejor automáticamente. Los puntos, las insignias y los rankings por sí solos pueden distraer del aprendizaje. La investigación sugiere que el diseño de escenarios funciona cuando quien aprende evalúa situaciones realistas, pero el exceso de adornos de juego puede estorbar.
Unas buenas misiones de onboarding deberían:
- Reflejar situaciones que ocurren a menudo en el trabajo real.
- Incluir respuestas incorrectas verosímiles, no trampas evidentes.
- Dar retroalimentación concreta después de cada decisión.
- Reflejar las responsabilidades del rol.
- Aumentar la dificultad de forma gradual.
- Terminar con un informe que muestre fortalezas y carencias.
Esa es la dirección que busca First Run: no un juego de preguntas y respuestas, sino una forma de ensayar cómo funcionan de verdad la empresa y el proyecto.
Reflexión final
Los documentos siguen teniendo su lugar en el onboarding. Lo que ocurre es que no pueden transmitir por sí solos todo el contexto del trabajo. El cambio que viene es pasar de una formación que se lee a una formación que se vive. First Run es un intento de hacerlo mediante misiones de escenarios.
Prueba situaciones reales como misiones de onboarding
¿Quieres que el onboarding de las nuevas incorporaciones sea más fácil? Prueba las misiones por rol en la demo de First Run. Jugar el onboarding