Resolución de problemas

Uno de los indicadores más claros, en mi opinión, de la validez (aptitud y actitud, principalmente) de alguien en un trabajo es la forma en la que afronta un problema. Por ejemplo, plantear un problema en una aplicación web en una entrevista de trabajo, puede permitir conocer muchas cosas del entrevistado:

  • ¿Comprende el modelo cliente/servidor? No sería la primera vez que escucho a gente que no comprende dónde se ejecuta el PHP y dónde el Javascript.
  • ¿Es capaz de leer los errores? Lejos quedan aquellos volcados típicos de ensamblador o C. Los lenguajes y los entornos de hoy suelen dar información significativa de lo que ocurre cuando hay un problema. Sin embargo, no todo el mundo realmente se para a interpretarlo.
  • ¿Está acostumbrado a programar tests? Hoy en día se puede probar casi todo, desde el acceso a datos hasta problemas de interfaz. Sugerir programar una prueba cuando aparece un problema sería un muy buen síntoma.
  • ¿Tiene recursos? Pensar en problemas frecuentes o ofrecer alternativas de solución suelen ir relacionado con experiencia real.
Cuando alguien me pide ayuda y su discurso está plagado de "no sé", "esto debería funcionar", "antes iba bien", tiemblo, y si encima se remata con un "no, no he probado eso" o "espera que miro qué pone el error", directamente se me cae el alma a los pies. Es habitual decir que un ingeniero se dedica a resolver problemas. Viendo la ineptitud que a veces presentamos para hacerlo, no me extraña que nadie considere la Informática una Ingeniería.

Me encantan 'C.S.I.' y 'House'. Ambas tienen en común que el leitmotiv es la resolución de un problema. La primera se centra en la recopilación de pruebas, mientras que la segunda es sobre investigación del problema en sí y prueba y error. De hecho, ofrecen dos perspectivas diferentes de cómo afrontar un problema:
  • En C.S.I. es necesario ser muy meticuloso y seguir unos protocolos establecidos (por temas legales) y se dispone de una cantidad razonablemente alta de recursos (un departamento, helicópteros, alta tecnología...). No se presupone nada. Se recopilan y analizan pruebas, y cuando surge una hipótesis se deben conseguir hechos que lo contrasten. Si no se hace así, el señor juez dejará libre al malo por no validez del proceso. La ventaja de esta aproximación es que, con tiempo, la verdad suele salir a la luz por sí misma: el mismo proceso de recopilación de pruebas te lleva al asesino, no hay crimen perfécto (¿o sí?). Ellos tienen el agravante de que su problema (el malo) sigue corriendo mientras ellos avanzan.
  • En House se suele trabajar con prisas (el paciente se muere cada vez más rápido) una cantidad limitada de recursos (no puedes dedicar todo el hospital para un paciente) pero muy buenos (tiene un equipo de los mejores profesionales). Hay procedimientos, sí, pero los protagonistas suelen estar por encima de ellos, considerando como único protocolo el conseguir que el paciente no muera. Mediante diagnóstico diferencial, similar al método socrático, y un (exagerado) proceso de prueba y error se genera el conocimiento que permite localizar el problema.
En mi opinión en informática la resolución de errores se asemeja a House. Cuando encuentras un fallo (aparece un síntoma), hay que...
  1. Pensar posibles lugares problemáticos (posibles enfermedades): ¿problema de configuración del servidor? ¿Fallo en la lógica de negocio? ¿Problema con el acceso a datos?
  2. Hacer los análisis no costosos ni intrusivos: "¿está enchufado?" "¿El usuario y password son correctos?" "¿La base de datos está levantada?".
  3. Priorizar (por probabilidad y coste) los problemas posibles, y comenzar la prueba y error. Nota: quita el tratamiento después de cada prueba (deja el código como estaba).
A éstos añadiría un punto 0 que no encaja en la analogía: prepara una prueba que primero demuestre que hay un problema, y que después te sirva para demostrar que lo has resuelto.

Posted by Juan Ignacio Sánchez Lara 19:06  

0 Comments:

Post a Comment