Todos los que hemos trabajado alguna vez haciendo soporte técnico hemos tenido que pasar por el proceso de "Troubleshooting". La palabra parece evocar escenas de película de cowboys en las que el héroe camina solitariamente por el centro del pueblo disparándole a los "malos" que se aparecen de sorpresa por las puertas y ventanas de las construcciones.
Si tan sólo fuera tan fácil...
El proceso de "troubleshooting", que a falta de una única palabra en español podríamos traducir como "diagnóstico y solución de problemas", puede ser un proceso tortuoso, desesperante y de apariencia inacabable. ¡Especialmente si es tu responsabilidad resolver dichos problemas!
¿Qué puedes hacer para volverte más eficiente y eficaz para resolver problemas? ¿Hay algún tipo de magia negra que puedas aprender? La respuesta a esta última pregunta afortunadamente es ¡no! y existen muchas ideas que puedes poner en práctica para volverte mejor en estas artes obscuras. He aquí algunas recomendaciones.
- Domina tu área de conocimiento
- Define el problema en "tus" términos
Si, esto es evidente, pero ¿lo has intentado? ¿Te has puesto a estudiar cómo funciona la tecnología que se supone que tienes que reparar? Muchas veces funciona el enfoque de la "caja negra", con el cual observas lo que entra y sale de un sistema y tratas de controlarlo para que produzca las salidas deseadas. Sin embargo, sería mucho mejor si supieras lo que hay adentro ¿no crees?
No lo dejes para cuando tengas la urgencia. El aprendizaje de tu especialidad debe ser una actividad contínua.
El usuario que te reportó el problema tiene su propia visión de las cosas, igual que tú. No te saltes pasos. El "trasfondo de obviedad" son todas las cosas que para tí son evidentes, pero para el usuario ese trasfondo puede ser completamente diferente. Debes escuchar lo que te dice (y documentarlo) pero lo más importante es que extraigas una descripción del problema usando tus propios términos y conocimientos.
- Verifica si el problema se presenta tal como lo has definido
Nuevamente es algo que parece obvio, pero si te saltas este paso corres el riesgo de resolver un problema que ¡no existe! Al tratar de reproducir el problema te puedes dar cuenta si tu descripción fue suficiente, y completa. Incluso puede que descubras otros problemas que no había percibido la persona que los reportó originalmente.
- Propón una o varias hipótesis para explicar el problema
Esta puede ser la parte más difícil. Dependiendo de tu nivel de conocimiento y experiencia, puede que identifiques de inmediato las causas del problema, pero también puede suceder que te quedes con la mente "en blanco" sin la menor idea de por dónde empezar. Muchas veces te puede ayudar hacerte la pregunta siguiente: "si yo quisiera que las cosas fallen exactamente de esta manera, ¿qué tendría que hacer?".
- Reúne información para apoyar o descartar tus hipótesis
En este punto debes empezar a trabajar como un detective. Abre diferentes "líneas de investigación" basadas en cada una de las hipótesis que generaste, y trata de recopilar información que te permita apoyar o descartar cada una de ellas. Puede ser buena idea hacer notas breves de las "evidencias" clave (salida de comandos, pantallas, etc.) que te sirvieron para confirmar la hipótesis triunfadora y descartar las alternativas.
- Aprende a pedir ayuda
Bien dicen que "en el pedir está el dar". Puede ser motivo de orgullo que hayas resuelto el problema tú solito, pero si te tardas demasiado en hacerlo no estás apoyando a tu organización. Los ingenieros tendemos a ser muy testarudos cuando algo parece confirmar nuestras ideas, y tendemos a trabajar en forma muy individualista. Aprende a colaborar con tus compañeros de trabajo. Aprende a platicar con ellos. Aprende a pedir (y brindar) favores. Puede ser que alguno de tus compañeros tenga una pieza clave para resolver el rompecabezas. Haz a un lado la soberbia y aunque tú seas el especialista no tengas miedo de decir "no sé". ¡Todos estamos aprendiendo!
Una vez que hayas comprobado la hipótesis que te permite explicar el problema, la naturaleza de la misma te permitirá proponer una solución. Ejemplo: si la hipótesis es que el servidor X está afectando el servicio porque funciona muy lento, ahora tendrías que proponer formas para acelerar su desempeño (cambiar el CPU, incrementar la memoria, virtualizarlo y poner una granja de servidores en la nube , etc.). Por supuesto que las búsquedas en Google y en foros de soporte son invaluables, pero ¡aquí también te ayudará el dominio de tu área de conocimiento!
No olvides documentar lo que hiciste. Idealmente, tu organización debería tener una "base de conocimiento" (Knowledge Base) compuesta, como mínimo, de bitácoras de servicio para cada uno de los equipos. Estas bitácoras pueden ser electrónicas para facilitar búsquedas y análisis de largo plazo. Si aún no lo estás haciendo, cualquier herramienta que elijas para llevar estas bitácoras estará bien. No seas improvisado y permite que tu aprendizaje contribuya al aprendizaje colectivo de tu organización.
Finalmente, no podemos subrayar de más la importancia de trabajar en equipo. Aún si tú eres el único responsable de resolver el problema, te puede ayudar "contarle tus tribulaciones" a un compañero de trabajo, porque al hacerlo estarás verbalizando muchas de las acciones arriba mencionadas. Tener una "red de ayuda" siempre es conveniente, incluso fuera de tu organización. Ese amigo que trabaja en algo muy parecido a lo tuyo pero en otra empresa, ¿a la mejor le podrías pedir ayuda por chat? ¿o por teléfono si fuera muy urgente? Además, contarle a alguien lo que haces también es una forma de promoverte, y hasta te pueden surgir oportunidades laborales como consecuencia.
La analogía del vaquero disparándole a los problemas ya no funciona por individualista. La era del "Llanero Solitario" ha terminado. Ahora estamos en la era de los superhéroes, pero ¿ya viste que hasta ellos se están agrupando para hacer frente a los problemas?
