subscripción
Ideas + Ingeniería del Software
Resolución de problemas
Febrero 8th, 2009 - [Enlace local]
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.
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.
- 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?
- Hacer los análisis no costosos ni intrusivos: "¿está enchufado?" "¿El usuario y password son correctos?" "¿La base de datos está levantada?".
- 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).
