Autor: Ludwin Durango, Expert Engineer, Sophos Solutions.

En la actualidad, con toda la industria tecnológica volcada hacia el mundo de los servicios (en todas sus ramas), cada vez vemos más segregados los roles que cumplimos los profesionales del gremio. Ahora hay desarrolladores backend, frontend, fullstack, automatizadores de pruebas, desarrolladores de infraestructura, ingenieros de datos, devops, integradores, entre muchos otros cientos de perfiles.

Esto no está mal, por el contrario, genera un beneficio enorme desde el punto de vista de la solución de problemas, necesidades del mercado, productividad, la gestión de los proyectos y los recursos que estos requieren para ejecutarse. Sin embargo, entre tantos roles, metodologías, marcos de trabajo, indicadores, frameworks y lenguajes de programación, nos estámos sumergiendo en un mundo lleno de prácticas, que en la teoría son muy bonitas y prometedoras, pero que en la vida real, están sacando de la ecuación nuestro sentido crítico, nuestra creatividad y la capacidad para aportar en las soluciones que se van a construir, porque cada vez estámos más limitados solo a «programar» lo que las empresas quieren, «como sea» pero que funcione, y además, que sea seguro, costo eficiente, rápido y entregado en el tiempo acordado.

Probablemente, eso de entregar “como sea pero que funcione”, le suena a más de uno, y tal vez lo identifican como la historia de su día a día profesional.  Para muchos, esto representa un conflicto constante en el que las expectativas de los usuarios no son del todo compatibles con la realidad de lo que se puede o no hacer en el tiempo establecido por quienes dirigen el proyecto, convirtiéndolo en una lucha contra el tiempo poco disfrutable en la que no queda espacio (o queda muy poco) para pensar en otros aspectos de suma importancia dentro de un proyecto de construcción de software como su estabilidad, la alineación con los procesos funcionales, estrategias de la compañía, el soporte durante su operación diaria o el usuario final.

En ultimas, la falta de prioridad en estos aspectos trae consecuencias que muchos conocemos y evidenciamos en nuestra labor, éstas van desde la inestabilidad de las aplicaciones o fallos recurrentes hasta graves errores por escenarios no previstos que nos pueden llevar a la improvisación al momento de solucionarlos arriesgando mucho más que indicadores o el funcionamiento del software.

Pensando en lo anterior, y hablando específicamente de los errores en el software, vemos que hoy no muchos profesionales son conscientes de lo que puede pasar si algo falla, porque el foco está en codificar y cumplir, y no siempre se mira más allá de esos indicadores de cumplimiento y calidad, más allá del código, más allá de los servicios o aún mucho más allá, donde están las personas que usan ese software, los usuarios finales.  Es decir, hay que ser conscientes de que, si algo falla en el software que construimos, alguien se verá afectado.

Lo anterior puede evidenciarse en muchas situaciones que van desde no poder cumplir alguna tarea en el trabajo, no poder hacer un pago en línea o con tarjetas en un restaurante o un hospital, hasta generar cálculos errados para un débito dejando a alguien sin dinero que puede necesitar después para alguna emergencia.  Si, puede parecer exagerado, pero es la realidad y no siempre dimensionamos lo que esto puede generar, ya sea porque no nos damos cuenta, nuestros usuarios no nos informan en los proyectos o simplemente ni siquiera pensamos en eso por que solemos creer que lo importante es entregar «a tiempo» o hacer que el código «funcione» y ya.

Finalmente, con la manifestación de este tipo de posturas, lo que se busca es invitar a ser más sensibles como profesionales, a que explotemos el sentido crítico sin miedo o vergüenza, a que hagamos preguntas que vayan más allá de lo que nos piden que codifiquemos, a que veamos el impacto de lo que hacemos, a pensar que, para desarrollar bien un software, no basta solo con programar y acogerse al cronograma del proyecto.  Creo que también debemos pensarnos como posibles usuarios o clientes de lo que estámos construyendo, considerar siempre que algo puede salir mal y prepararnos para eso, pensando y proponiendo con antelación como solucionarlo. 

Debemos involucrarnos completamente con lo que estámos construyendo para entender el por qué, el para qué y el para quién hacemos esto.  Entonces, al final nuestro trabajo no se trata solo de programar código que funcione bien según lo requerido (porque nuestro usuario no siempre tiene la razón) y crear documentación que lo soporte, no se trata tampoco de cientos de indicadores y pruebas de «laboratorio» que no reflejan la realidad, no se trata de conocer mucho la tecnología, los frameworks o los lenguajes de programación.  Se trata es de ser sensibles, de entender el contexto y comprender las necesidades que vamos a suplir con tecnología abarcando el desarrollo del software en todas sus dimensiones, desde lo teórico, lo corporativo y lo comercial hasta lo que pueda pasar con la persona común y corriente que usa esa tecnología o se ve beneficiado o afectado con ella.

Es por esto, que pienso que el desarrollo del software no debe tratarse solo de tecnología y escribir bien el código.  ¿Qué piensan ustedes?

Deja una respuesta

Cerrar menú