La forma habitual de empezar a crear misiones de onboarding es esta: reunir las páginas de onboarding de la wiki, sacar la frase clave de cada una y convertirla en una pregunta. Lo que sale es un cuestionario. Veinte preguntas sobre quién aprueba una solicitud de cambio, que las nuevas incorporaciones responden buscando en el documento. Sacan buena nota y aun así se quedan bloqueadas la primera vez que llega una solicitud de cambio real.
Convertir documentos en misiones no consiste en transformar frases en preguntas. Es el trabajo de encontrar los puntos de decisión que los documentos nunca escribieron. Los cinco pasos siguientes cambian el resultado si de verdad los sigues en orden.
Por qué no se puede pasar la wiki tal cual a misiones
Una wiki interna está hecha para consultarse. Como se lee cuando hace falta, normalmente le faltan el orden del razonamiento y el manejo de las excepciones. Lo que recoge es la forma final de una norma. “Los despliegues urgentes salen después de que los apruebe el jefe de equipo” es exacto, pero qué hacer cuando el jefe de equipo está de vacaciones, y dónde está el límite de lo urgente, no aparece.
Ese hueco es justo donde se atascan las nuevas incorporaciones. Por eso el punto de partida de la conversión no es la wiki. Son las preguntas que quedan después de leerla.
El flujo de conversión en cinco pasos
Paso 1. Reúne las preguntas repetidas
Reúne las preguntas que surgieron de verdad en los últimos dos o tres meses. Las fuentes ya existen: lo que las nuevas incorporaciones preguntaron en los canales del equipo, los registros del chatbot interno, las notas de las reuniones individuales, las respuestas que la persona responsable del onboarding repite una y otra vez y los comentarios que se repiten en las revisiones de código.
Cuenta tipos de pregunta, no frases. “¿A quién le pregunto esto?” y “¿quién toma esta decisión?” son el mismo tipo. Cuando tengas entre treinta y cincuenta, los diez tipos principales supondrán más de la mitad del volumen. Crea misiones solo a partir de esos diez.
Una ronda de recopilación queda más o menos así: cómo gestionar una solicitud de cambio que llega, nueve veces; a quién avisar y en qué orden durante una incidencia, siete; el criterio para lanzar o no cuando se detecta un problema antes del lanzamiento, seis; cómo cuestionar un requisito vago, seis; cuándo pedir la revisión de un entregable, cuatro.
Paso 2. Extrae el punto de decisión
De cada tipo de pregunta, saca exactamente un punto en el que el comportamiento cambia de verdad. La prueba es si elegir mal ahí cuesta algo. Si no se pierde nada, pertenece a un documento, no a una misión.
En el tipo de la solicitud de cambio, por ejemplo, el punto de decisión no es quién tiene la autoridad para aprobar. Eso es una consulta. El verdadero punto de decisión es lo que pasa en el minuto siguiente a que llegue la solicitud: comprobar primero el impacto, avisar primero a los roles afectados o decirle primero al cliente cuándo tendrá respuesta.
Una misión lleva un punto de decisión. Si pones dos, el jugador no sabe por qué se equivocó, y los datos de respuestas incorrectas se vuelven imposibles de interpretar.
Paso 3. Escribe la tarjeta de situación
Lleva el punto de decisión a una situación concreta. Las tarjetas de situación tienen que ser cortas; a partir de cinco frases la gente deja de leer y salta a las opciones. Necesitan cuatro elementos: el momento, el actor, el suceso y una restricción.
Situación: A cuatro días del lanzamiento, el cliente envía un correo pidiendo una nueva zona de banner en la página principal. El diseño ya está cerrado, la maquetación está en curso y el QA empieza dentro de dos días. Pregunta: Como PMO del proyecto, ¿qué haces primero?
El momento, el actor, el suceso y la restricción caben en un solo párrafo. Cuanto más se parezca la restricción a un proyecto real, mejor. Cuando las fechas y los nombres de los entregables se parecen a los reales, la implicación cambia de forma notable.
Paso 4. Diseña las opciones y la retroalimentación
En este paso es donde se separa la calidad. La mayoría de los cuestionarios de onboarding fallan porque las respuestas incorrectas están mal hechas. Nadie elige una opción que dice “ignora al cliente”.
Las buenas respuestas incorrectas son medio correctas. Tienen que ser cosas que una nueva incorporación haría de forma plausible. Para la tarjeta del banner anterior, las opciones pueden quedar así.
- Responder que el cambio es imposible porque el diseño está cerrado.
- Preguntar primero al maquetador web si el trabajo es viable.
- Documentar la petición, comprobar el impacto en el calendario, el alcance y el QA, y luego decirle al cliente cuándo llegará una decisión.
- Tratar el banner como un trabajo pequeño sin impacto en el QA y pedir al equipo que lo haga de inmediato.
Las opciones 2 y 4 aparecen constantemente en proyectos reales. La opción 2 no tiene mala intención, solo el orden equivocado. La opción 4 resolvió el impacto adivinando. Respuestas incorrectas así son las que hacen que valga la pena leer los datos de respuestas incorrectas.
La retroalimentación debe explicar el motivo en lugar de anunciar el veredicto. A quien eligió la opción 4 se le explica que nunca se comprobó el alcance de QA que añade un nuevo banner, y que el tamaño del trabajo y el impacto en el QA son cuestiones distintas. Con dos o tres frases basta, más un enlace al documento correspondiente.
Paso 5. Ubica por dificultad y rol, y conecta el informe
Ahora toca ubicar las misiones. Ajusta la dificultad por la cantidad de contexto, no por lo difícil que sea la respuesta. El nivel inicial tiene una restricción, el intermedio tiene dos restricciones en conflicto y el avanzado no tiene una única respuesta limpia y pide al jugador que justifique una.
Para ubicarlas por rol, reutiliza el mismo suceso. Esa única petición de banner da cinco misiones. El PMO se ocupa del orden de las acciones, el planificador hace las preguntas que concretan el requisito, el diseñador sopesa el conflicto con la jerarquía visual existente, el maquetador web revisa el impacto en la maquetación adaptable y el desarrollador acota el cambio en la estructura del CMS. Ver una misma situación a través de cinco roles ya es en sí la lección.
Por último, conéctalo con el informe. Etiqueta cada misión con un tipo de criterio y, después de una sesión de juego, tendrás el porcentaje de aciertos por tipo. Gestión de cambios, escalado, aclaración de requisitos y nivel de calidad son categorías suficientes para empezar. El informe sirve a la persona y a la organización a la vez: cuando todos fallan el mismo tipo, lo que hay que corregir es el documento, no a las personas.
Patrones de fallo habituales
- Respuestas obvias. Si solo una de las cuatro opciones es larga y educada, esa es la respuesta.
- Cuestionarios de consulta. Si buscar en el documento da la respuesta, un enlace al documento cumple mejor que una misión.
- Tarjetas con más de un punto de decisión. No puedes saber qué salió mal.
- Demasiado juego. Si primero construyes puntos, insignias y clasificaciones, ocultarán un problema de calidad del contenido.
- Respuestas caducadas. Cuando el proceso cambia y la misión no, estás enseñando a las nuevas incorporaciones un procedimiento obsoleto.
- Veinte misiones de golpe. Crea cinco, haz una prueba piloto, mira dónde se concentran las respuestas incorrectas y luego amplía.
Lista de comprobación de la conversión
- ¿Contaste tipos de pregunta en lugar de frases?
- ¿Creaste misiones solo a partir de los diez tipos principales?
- ¿Cada misión tiene exactamente un punto de decisión?
- ¿Cada tarjeta de situación tiene momento, actor, suceso y una restricción?
- ¿Al menos dos opciones incorrectas son cosas que alguien haría de forma plausible?
- ¿La retroalimentación explica el motivo en lugar del veredicto?
- ¿Cada misión está etiquetada por tipo de criterio para que el informe pueda agregarla?
- ¿Hay alguien responsable de actualizar las misiones cuando cambia el proceso?
Para terminar
El núcleo de este flujo es el paso uno, no el paso tres. Si reúnes bien las preguntas repetidas, el conjunto de misiones que vale la pena crear se reduce por sí solo, y dejas de escribir problemas sobre cosas que nadie preguntó nunca. La wiki sigue importando. Solo que, una vez que sabes qué preguntas no responde, queda claro lo que el onboarding necesita construir.
Prueba situaciones reales como misiones de onboarding
¿Quieres ver cómo quedan los documentos internos convertidos en misiones? Juega la demo de First Run. Jugar el onboarding