El onboarding se vive, no se lee: lo que decides se queda más que lo que lees

En el artículo anterior vimos, con ojos de PM, por qué el onboarding importa en los proyectos. La conclusión fue esta: los objetivos, el alcance, quién decide y el proceso de cambios se pueden transmitir con documentos, pero cómo decidir en las situaciones que se repiten viaja mal en papel.

Este artículo recoge la siguiente pregunta. Entonces, ¿cómo es un buen onboarding?

Mucho material de onboarding, y la gente se sigue perdiendo

Muchos onboardings se parecen. Unos cuantos enlaces a la wiki, una presentación de la empresa, documentos de procesos y un amable "pregúntame lo que quieras". La web de First Run resume en cuatro puntos por qué este tipo de onboarding suele fallar:

Problema	Qué pasa
Explicaciones repetidas	El equipo cuenta una y otra vez el mismo contexto de la empresa y del proyecto
Documentos que nadie lee	Hay material de sobra, pero cuesta terminarlo o recordarlo
Adaptación lenta	Hasta que se enfrentan a situaciones reales, no saben cómo actuar
Criterios distintos por rol	Desarrollo, PMO, planificación, diseño y maquetación necesitan cosas distintas

El que creo que está debajo de todos es el tercero. Incluso quien se ha leído todo se atasca, porque conocer una regla y reconocer el momento en que se aplica son habilidades distintas.

Supón que el documento de onboarding dice: "Los cambios de alcance deben llegar como solicitudes de cambio". Todo el mundo asiente. Pero el momento real no llega con la etiqueta "solicitud de cambio". Llega un viernes por la tarde, dos días antes del lanzamiento, cuando la persona de contacto del cliente, con la que te llevas bien, te escribe: "¿Puedes cambiar solo esta frase?". Reconocer ese mensaje como una solicitud de cambio no es algo que se consiga leyendo el documento una vez más.

Cuatro condiciones de un buen onboarding

Entonces, ¿de dónde sale ese instinto? Creo que un buen onboarding necesita cuatro cosas.

1. Decides en situaciones que se parecen al trabajo real

Es la más importante. Se trata de cambiar la unidad básica del onboarding: de un documento que leer a una situación que decidir. Una situación tiene contexto, tiene opciones y cada opción tiene consecuencias.

Yo viví lo mismo preparando el PMP. La mayoría de las preguntas del PMP no preguntan datos. Describen una situación de proyecto y te piden elegir qué debe hacer primero el PM. Como conté en la parte 1 de mi experiencia con el PMP, cuando memorizaba las frases de las respuestas, volvía a fallar en cuanto cambiaban un par de palabras. Así que en mi cuaderno de errores dejé de copiar preguntas y empecé a acumular reglas de decisión: "Si pasa ___, primero ___". Con el onboarding pasa lo mismo, creo. Lo que tiene que quedarse no es una lista de reglas, sino el criterio en contexto.

2. Cada rol tiene su propio camino

Un desarrollador y una diseñadora pueden entrar en el mismo proyecto y encontrarse situaciones completamente distintas la primera semana. El desarrollador tendrá que decidir ante errores de API y depuración; quien planifica, ante requisitos que chocan; quien diseña, ante reglas del sistema de diseño y revisiones de usabilidad. Un onboarding que enseña a todos las mismas diapositivas no le sirve del todo a nadie.

Eso no significa que baste con conocer tu propio rol. Los proyectos se hacen en colaboración, y las conversaciones son mucho más fáciles cuando entiendes qué preocupa a quien trabaja a tu lado. Un camino que empieza en tu rol y luego se abre a los roles vecinos es la segunda condición.

3. Recibes razones, no solo acierto o error

"Correcto" e "Incorrecto" enseñan poco por sí solos. En el trabajo, las decisiones rara vez son simplemente correctas o incorrectas: son mejores o más arriesgadas. Una opción es la mejor jugada, otra está bien pero no es ideal, y otra parece inofensiva ahora pero esconde un riesgo. Por eso la retroalimentación necesita una calificación y una razón.

Situación — Viernes por la tarde, dos días antes del lanzamiento. La persona de contacto del cliente te escribe: "¿Puedes cambiar el texto del botón de pago? Es rápido". Eres un desarrollador que entró en el proyecto esta semana. ¿Qué haces primero?

Opción	Calificación	Por qué
Compartir la petición con el PM y dejar que decida si se trata como solicitud de cambio	Excelente	Un cambio justo antes del lanzamiento puede afectar a QA, traducción y UAT, así que decide quien tiene que decidir
Preguntar primero al cliente por el impacto y luego resumírselo al PM	Bueno	La dirección es correcta, pero negociar por tu cuenta antes de una decisión puede crear expectativas
Es pequeño: cambiarlo ya y avisar al PM después del despliegue	Arriesgado	Con buena intención, pero se salta el proceso acordado y añade riesgo de regresión justo antes del lanzamiento
Decir que estás liado, proponer el lunes y no apuntarlo en ningún sitio	Deficiente	La petición se pierde y vuelve después del lanzamiento como un problema mayor

Compara Arriesgado y Deficiente. Ninguna es buena opción, pero por motivos distintos. Arriesgado es el peligro de querer hacerlo demasiado bien. Deficiente es el problema de dejar que algo se escape. Escuchar esa diferencia, con su razón, es lo que cambia tu decisión la próxima vez que llegue una situación parecida.

4. Hay un lugar seguro para equivocarse

Si en un proyecto real eliges la opción Arriesgado, lo pagas después del lanzamiento. El onboarding es uno de los pocos momentos en que puedes equivocarte sin pagar ese precio. Para que funcione, tiene que quedar claro que equivocarse está bien, y tiene que haber forma de volver a intentarlo. No un examen que suspendes y se acabó, sino un campo de práctica donde ves por qué fallaste y lo intentas otra vez.

Onboarding con documentos frente a onboarding vivencial

Si pones las cuatro condiciones una al lado de la otra, la diferencia se ve clara:

	Onboarding con documentos	Onboarding vivencial
Unidad básica	Un documento que leer	Una situación que decidir
Camino	El mismo material para todos	Un camino por rol que luego se abre a otros roles
Retroalimentación	Ninguna, o acierto/error	Una calificación, la razón y un punto clave
Errores	Se cometen por primera vez en el trabajo real	Se cometen antes en la práctica y se repiten
Se termina cuando	Lo has leído todo	Sabes decidir

Para que quede claro: no digo que los documentos no sirvan. Para la información que hay que consultar, como los objetivos, el alcance o quién decide, son la mejor herramienta. Pero un onboarding que termina en los documentos deja fuera lo más difícil para quien llega: el primer momento en que tiene que decidir por su cuenta.

Por eso construí First Run

Cuando me pregunté qué formato podía reunir las cuatro condiciones a la vez, mi respuesta fue un RPG. Por eso construí First Run. Así aparecen en él las cuatro condiciones:

• Decidir en contexto: misiones basadas en situaciones reales de trabajo te preguntan qué harías primero. Son preguntas de criterio, no datos que memorizar.
• Rutas por rol: hay misiones y NPC mentores para cinco roles (desarrollador, PMO, maquetador web, planificador y diseñador), y a partir del nivel 3 también puedes jugar misiones de otros roles.
• Retroalimentación con razones: cada respuesta se califica como Excelente, Bueno, Arriesgado o Deficiente, con el razonamiento y un punto clave.
• Equivocarse sin riesgo: las misiones falladas se pueden repetir en el Tablón de repaso, y al final un informe de resultados resume tus puntos fuertes, las áreas por mejorar y las misiones de repaso recomendadas.

Todo se puede personalizar para una empresa o un proyecto. Las misiones se pueden crear a partir de tus escenarios reales y de las reglas de tus proyectos, con NPC inspirados en tus mentores, el mapa de tu oficina y tu imagen de marca. Es decir, una escena como la de la misión de ejemplo se puede llenar con situaciones reales de tu equipo.

Los documentos de onboarding no van a desaparecer. Pero donde terminan, empieza el momento en que quien llega tiene que decidir solo por primera vez. Quería que ese momento se pudiera vivir con seguridad, antes de que ocurra en un proyecto real. Por eso construí First Run.

Pruébalo tú — la demo es gratuita en el navegador, sin registro, en coreano, inglés, japonés y español. Jugar a First Run →

El próximo artículo aborda la última pregunta de la serie: por qué precisamente un juego y por qué el juego importa en el trabajo. Buscaré la respuesta en Homo ludens, de Johan Huizinga.

Preguntas frecuentes

¿Siguen haciendo falta los documentos de onboarding?+

Sí. Para la información que hay que consultar, como objetivos, alcance, quién decide y procedimientos, los documentos son la mejor herramienta. Lo que les cuesta es entrenar el criterio, es decir, decidir qué hacer primero en una situación concreta, así que creo que funciona mejor sumarles práctica basada en la experiencia.

¿En qué se diferencia First Run de un cuestionario de e-learning?+

En lugar de recordar datos, se elige qué hacer primero en situaciones de trabajo realistas. Cada respuesta recibe una de cuatro calificaciones (Excelente, Bueno, Arriesgado o Deficiente), con el razonamiento y un punto clave, y las misiones falladas se pueden repetir en el Tablón de repaso.

¿Qué roles incluye First Run?+

Cinco roles: Desarrollador, PMO, Maquetador web (HTML/CSS), Planificador y Diseñador. A partir del nivel 3 también se pueden jugar misiones de otros roles para entender mejor cómo trabajan los demás.

Fuentes

• First Run: RPG de onboarding personalizable
• Cuaderno de errores PMP: 6 pasos para convertir tus fallos en reglas