Entre las bambalinas de Awerty
La idea de este artículo surgió de una sesuda reunión de dos horas en la que dos de los técnicos de Awerty y servidor tratamos de dilucidar qué mejoras convenía implantar en uno de nuestros clientes principales. Era una de esas reuniones en las que se analizan un conjunto de problemáticas que afectan a diversas partes de los sistemas informáticos, desde pequeñas aplicaciones de apoyo a los usuarios que no están funcionando de forma habitual y se convierten en un auténtico quebradero de cabeza, hasta problemas estructurales que requieren un análisis exhaustivo pero, al mismo tiempo, respuestas y acciones inmediatas.
En estos casos utilizamos un método de análisis exhaustivo. Exponemos la problemática en su globalidad (qué ha pasado, desde cuándo, dónde se originó el problema, quién lo causó, etc. ) para después evaluar en profundidad los aspectos más nimios. Este momento de entrar en el detalle es algo que, francamente, detesto, pero que resulta imprescindible. Me explico.
Me enerva porque son reuniones a contrarreloj y los detalles consumen un tiempo que tú crees que te será mucho más útil cuando llegue el momento de dar con la solución. Error. Sin el detalle previo no se pueden definir posibles acciones correctoras. Por eso, yo llamo las llamo reuniones constructivas.
Reuniones constructivas en Awerty
En el caso que nos ocupa, la discusión generó tensión sobre qué factor era el desencadenante de un problema estructural a nivel de TI en la empresa del cliente. Analizamos desde cuándo se produjo y la gran cantidad de productos diversos que la componen (sistemas operativos de usuarios desfasados, hardware servidor recientemente actualizado, electrónica de comunicaciones pendiente de actualización de firmware pero que no garantiza una resolución especifica del problema y sistema operativo servidor pendiente de actualizar a nivel de parches). Paulatinamente, se fue generando tensión.
Bajo mi punto de vista, lo importante era hacer un cambio más rápido sobre los sistemas operativos desfasados de los usuarios. No porque creyese que era el principal causante del problema, sino porque consideraba que mejoraría el rendimiento de la infraestructura en general y, al mismo tiempo, nos permitiría cumplir con el objetivo fijado de migrar estos SO antes de finalizar el mes. Mis compañeros, en cambio, defendían el mantenimiento temporalmente de estos sistemas y me instaban a centrarnos únicamente en la migración de los usuarios conflictivos, al tiempo que seguíamos analizando y reparando las causas de los problemas informáticos estructurales que nos afectaban. El reloj corría y a todos nosotros se nos añadió otro temor: finalizar la reunión sin nada claro; acabarla, como tantas otras, teniendo la sensación de que lo único a la que ha contribuido es a empeorar la situación.
No fue así. La reunión concluyó satisfactoriamente. Justo después de acabarla, nos pusimos a trabajar en aspectos prácticos para mirar de ir corrigiendo el problema, un listado de los siguientes clientes que han de migrar su sistema a la nueva maqueta que tenemos preparada de SO y, en paralelo, la actualización de los sistemas operativos servidor. Pero más allá de haber dado con la solución concreta, el aspecto que más valoro de estas reuniones es que me reafirma en mi creecia de que el problema es un factor capital en nuestro trabajo diario, así como la necesidad constante de mejorar nuestra capacidad de análisis. Sólo así, en una lluvia de argumentos, de análisis, de ideas, ayudamos al cliente y multiplicamos nuestro conocimiento.
