Planteamiento y alcance
Tu equipo depende de unas pocas personas con experiencia para los pasos de lanzamiento, el diagnóstico de incidentes o las reglas de negocio. La información está dispersa en chats y notas privadas; la incorporación es lenta y los ingenieros de guardia repiten errores del pasado. Describe una ocasión en la que identificaste la brecha, elegiste el alcance correcto, involucraste a los usuarios, mediste la adopción y mantuviste la documentación actualizada.
La pregunta no se trata de producir una página visualmente atractiva. Evalúa si puedes convertir la memoria individual en una capacidad del equipo sin añadir procesos vacíos. Las habilidades fundamentales son la responsabilidad (ownership), la comunicación, la simplificación y el impacto medible, por lo que es una pregunta conductual.
Qué evalúa el entrevistador
Los entrevistadores buscan una falla concreta o un costo recurrente, no un simple “me gusta escribir documentación”. Las respuestas sólidas nombran a los lectores, los límites de decisión, los ejemplos, al responsable y los desencadenantes de actualización, y luego permiten que usuarios reales revisen y ejecuten la guía.
También esperan evidencia: tiempo que le toma a un recién llegado completar una tarea, preguntas repetidas, escalaciones en guardia, fallas de despliegue o éxito tras seguir la guía. Si la adopción se mantuvo baja o el documento quedó desactualizado, reconócelo y explica el ajuste realizado.
Preguntas para aclarar primero
- ¿Qué costo generaba el conocimiento tácito: tiempos de espera, incidentes, comunicación repetida o decisiones equivocadas?
- ¿Quiénes son los lectores y qué necesitan: procedimientos, contexto o un registro de decisiones?
- ¿Qué partes son estables y cuáles cambian con el código, los permisos, los proveedores o las políticas?
- ¿Quién es el responsable de las actualizaciones y qué evento de cambio debería detonar una revisión?
- ¿Cómo protegerás los secretos, los datos personales y la información restringida de producción?
- ¿Cuál es la señal de adopción medible más pequeña más allá de las visitas a la página?
Una respuesta de 30 segundos
“Cuantificaría la brecha a través de un incidente o un tiempo de espera repetido, y luego elegiría un flujo de trabajo de alta frecuencia, reversible y de bajo riesgo para una versión mínima. Junto con los lectores reales, documentaría los requisitos previos, los puntos de decisión, las señales observables, la verificación y la reversión (rollback), asignando un responsable y un detonante de actualización. Tras el lanzamiento, rastrearía el tiempo de resolución independiente, las preguntas repetidas y las escalaciones. Si el uso fuera bajo, eliminaría la fricción o integraría el enlace directamente en el flujo de trabajo. Validaría el cambio con una tarea real, no solo contando visitas.”
Solución paso a paso
Comienza con el contexto y una línea base: tal vez un lanzamiento se retrasó 40 minutos porque solo una persona conocía el interruptor seguro de reversión, o un recién llegado hizo la misma pregunta sobre reglas de datos tres veces. Especifica quién se vio afectado y por qué importaba ese costo; no conviertas una preferencia personal en un problema de equipo.
Reduce el alcance. Elige un flujo de trabajo frecuente, reversible y de riesgo controlado, y registra su objetivo, requisitos previos, pasos, bifurcaciones de decisión, señales de verificación, manejo de fallas y ruta de escalación. Reemplaza el “usa tu criterio” con una regla observable como “cuando la métrica X sea verdadera, haz Y”.
Invita a dos lectores reales a ejecutar la guía sin ayuda verbal. Identifica el contexto faltante y los términos confusos. Enlaza al código, tableros o tickets para que la página sea fácil de descubrir durante el trabajo. Censura secretos, datos personales y credenciales de producción, y utiliza una ruta de acceso segura.
Crea un contrato de mantenimiento: un responsable, versión o fecha de última revisión, y un desencadenante de revisión ante cambios de código, incidentes o cambios de proveedores. Si el equipo se resiste al mantenimiento, conserva únicamente el contenido que aún modifica una operación y traslada las decisiones duraderas a una plantilla de cambios o a una verificación automatizada.
Mide la adopción mediante el tiempo hasta la primera resolución independiente, las preguntas repetidas, las escalaciones en guardia, el éxito de las reversiones y la proporción de lectores que aún necesitan ayuda. Las visitas a la página son un indicador débil. Para una muestra pequeña, utiliza la observación de tareas antes y después, y describe los factores de confusión en lugar de asegurar una causalidad exacta.
Trata la resistencia como una señal de usabilidad: el punto de entrada puede estar oculto, el lenguaje ser poco familiar, los pasos demasiado largos o pueden faltar permisos. Soluciónalo con un taller breve y una tarea real, no con lecturas obligatorias. Convierte los requisitos previos estables en scripts o verificaciones de CI siempre que sea posible para que el equipo dependa menos de la memoria.
Cierra con una reflexión. Menciona qué quedó obsoleto, qué métrica no cambió y cómo eliminaste material de bajo valor, transferiste la propiedad o automatizaste una verificación. El entrevistador busca ver un ciclo de aprendizaje continuo en lugar de un evento de redacción único.
Respuesta modelo
“Durante un incidente de lanzamiento, solo un compañero sabía qué interruptor era seguro para la reversión, por lo que el equipo esperó unos 40 minutos. Revisé los tres meses anteriores de escalaciones similares y preguntas recurrentes, confirmé una brecha de conocimiento frecuente y elegí el procedimiento de reversión como la primera guía mínima.
Dos ingenieros de guardia y yo redactamos los requisitos previos, las revisiones de métricas, la ubicación del interruptor, la verificación y los pasos posteriores a la reversión, junto con un enlace a un tablero censurado. Un recién llegado realizó el ejercicio utilizando únicamente la guía; el estado ‘saludable’ no estaba definido y faltaba la ruta de permisos, así que añadí umbrales y pasos de escalación. El responsable rotativo de la guardia se encargó de mantenerla y la plantilla de lanzamiento solicitaba una actualización cada vez que cambiaba la configuración.
Cuatro semanas después, la mediana de tiempo del ejercicio para recién llegados se redujo de 25 a 10 minutos y las escalaciones relacionadas bajaron de cinco a dos por semana. Las visitas no fueron el criterio de éxito. Cuando un proveedor cambió el nombre de una métrica, actualicé la guía y agregué una verificación automatizada. El resultado fue una capacidad de equipo verificable y mantenible en lugar de depender de la memoria de una sola persona.”
Errores comunes
- “Escribí una wiki” → sin evidencia de escala o adopción → proporciona una línea base, lectores y resultados.
- Construir una enciclopedia → difícil de leer y se vuelve obsoleta rápidamente → comienza con un único flujo de trabajo frecuente.
- Listar comandos sin decisiones → los lectores no saben cuándo detenerse → define requisitos previos, señales, bifurcaciones y reversión.
- Omitir pruebas de usuario → las brechas salen a la luz durante un incidente → haz que lectores reales la ejecuten sin ayuda.
- Sin responsable asignado → el primer cambio invalida la guía → asigna responsables y desencadenantes.
- Usar visitas como prueba → las visitas no prueban que se completó la tarea → rastrea tiempo de finalización, preguntas y escalaciones.
- Capacitación obligatoria como adopción → la gente regresa a preguntar por chat → integra la guía en el flujo de trabajo y elimina la fricción de búsqueda.
- Publicar secretos → la documentación se convierte en un riesgo de seguridad → censura y utiliza acceso controlado.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué pasa si el equipo no mantiene la documentación?
Comienza con la parte operativamente crítica, asigna un responsable rotativo e incluye la revisión en la plantilla de cambios o de incidentes. Si el costo sigue siendo alto, automatiza las comprobaciones o elimina las secciones de bajo valor.
Pregunta de seguimiento 2: ¿Cómo demuestras que la mejora se debió a la guía?
Compara el tiempo de finalización, las escalaciones y los errores antes y después, y añade la observación de tareas junto con los comentarios de los lectores. Declara con honestidad el tamaño de la muestra y los factores de confusión.
Pregunta de seguimiento 3: ¿Cuándo no se debería redactar un documento?
El conocimiento puntual y de bajo riesgo que toma minutos explicar no justifica un mantenimiento a largo plazo; utiliza un comentario, un ticket o un mensaje corto. Crea un activo duradero cuando el costo repetido supere el mantenimiento.
Pregunta de seguimiento 4: ¿Cómo manejas la información confidencial?
Nunca almacenes credenciales, datos personales o capturas de producción en una página pública. Utiliza ejemplos censurados, niveles de acceso y enlaces seguros; explica cómo obtener autorización sin almacenar secretos.
Pregunta de seguimiento 5: Los recién llegados siguen haciendo las mismas preguntas. ¿Qué significa eso?
Inspecciona el punto de entrada, el lenguaje, los permisos y la ejecutabilidad en lugar de culpar a los lectores. Convierte las preguntas frecuentes en una sección de FAQ, una validación o un formulario, y observa si las dudas evolucionan hacia excepciones de mayor valor.
Pregunta de seguimiento 6: ¿Cómo manejas la documentación obsoleta?
Establece una fecha de revisión y un responsable, activa revisiones ante cambios de código, incidentes o cambios de proveedores, y marca o elimina el contenido cuya validez no se pueda confirmar.
Pregunta de seguimiento 7: ¿En qué se diferencia esto de “mejorar un proceso”?
El enfoque está en convertir la memoria dependiente de una persona en un activo de equipo localizable, verificable y mantenible. El flujo de trabajo puede seguir siendo el mismo mientras que la ejecución y las transferencias de tareas se vuelven más confiables.