Resolver un problema
De algo no funciona a solucionado o escalado.
The case
Algo no funciona. No sabes exactamente qué, no sabes qué tan grave es, y lo que hagas a continuación o lo resuelve o te hace perder una hora. La mayoría de las sesiones de resolución de problemas no fracasan porque la gente sea mala arreglando cosas, sino porque no se detiene lo suficiente al principio para describir con precisión qué está pasando.
El instinto es empezar a probar cosas de inmediato. Reiniciarlo. Reinstalarlo. Buscar en Google el síntoma antes de haberlo articulado del todo. A veces funciona, por suerte — y cuando no, has introducido nuevas variables en una situación que ya era confusa.
Una rutina de resolución de problemas no es más que un árbol de decisiones con un punto de entrada consistente. Describes el problema con precisión, intentas reproducirlo, revisas qué cambió, buscas de forma deliberada y pruebas las mejores opciones en orden. En cada bifurcación, o avanzas o saltas hacia adelante. Si llegas al final sin solución, escalas — pero con algo útil, no con un encogimiento de hombros.
Lo que una rutina también aporta es una condición de parada. Sin ella, la resolución de problemas tiende a expandirse para llenar el tiempo disponible. El punto de decisión en el paso #12 obliga a hacerse la pregunta: ¿merece la pena seguir con esto, o ya es el problema de otra persona?
Resolver un problema
- Anota los pasos que seguiste, qué esperabas que pasara y qué pasó realmente.
- Intenta reproducir el problema siguiendo tu lista exactamente. Si no puedes reproducirlo, vuelve a @1 — tu lista todavía no está completa.
- Identifica qué cambió recientemente. Actualización de software, nueva entrada, cambio de configuración, lo que sea. Si no cambió nada, salta a @7.
- Deshaz el cambio. Vuelve al estado o la versión anterior. Si lo conseguiste, regresa a @2 para comprobar si el problema sigue ahí.
- Aísla el cambio. Desactiva, desconecta o elimina solo lo que cambió y vuelve a probar. El objetivo es confirmar si ese cambio es la causa antes de hacer cualquier otra cosa. Si esto lo soluciona, salta a @13.
- Vuelve a aplicar el cambio. Ya confirmaste que es el culpable. Anótalo. Salta a @13.
- Busca el mensaje de error o el síntoma exacto. Copia el error tal cual si lo hay. Las búsquedas vagas devuelven resultados vagos.
- Anota qué soluciones aparecen con más frecuencia en los resultados. La frecuencia es un punto de partida, no una prueba.
- Comprueba la fecha de lo que estás a punto de probar. Una solución de hace cinco años puede que ya no aplique.
- Prueba la solución más creíble. Si lo soluciona, salta a @13.
- Prueba la siguiente solución más creíble. Si lo soluciona, salta a @13.
- Decide: seguir intentándolo o escalar. ¿Cuánto tiempo llevas? ¿Qué tan crítico es esto? Si vas a escalar, salta a @14. Si sigues, vuelve a @10.
- Documenta qué fue lo que lo solucionó. Una frase. Lo vas a olvidar, y volverás a encontrarte con esto.
- Resume el problema para quien vaya a encargarse. Qué intentaste, qué descartaste, qué crees que puede ser. Entrégalo en orden.
Hazlo tuyo
El paso más importante es el #13, y es el que la mayoría omite. Resolver un problema y documentar la solución no son la misma tarea — la segunda es lo que evita que pierdas cuarenta minutos con lo mismo dentro de seis meses. Con una frase basta.
Los pasos #10 y #11 son marcadores para un bucle que puede extenderse. Algunos problemas requieren diez intentos antes de que algo funcione. Añade pasos según necesites y toma la decisión en el #12 sobre si seguir o pasar el relevo.
La vía de escalado en el #14 merece tomarse en serio. Una entrega clara — qué probaste, qué descartaste — es genuinamente útil para quien lo reciba. Llegar solo con "está roto" no lo es.
Si usas esta rutina para un ámbito concreto — software, hardware, un equipo — adapta los pasos intermedios a tu secuencia de diagnóstico habitual. La estructura es la misma; los detalles los pones tú.