Los años 90 del siglo pasado vieron el florecimiento de las herramientas CASE (Computer Aided Software Engineering), unos ingenios software dedicados a la generación de código fuente mediante la definición de reglas de alto nivel. La mentalidad por encima del desarrollo de estas herramientas era que la mayoría del código desarrollado es repetitivo y de baja complejidad, con lo que utilizando estas herramientas se podía lograr, por una parte, acercar el desarrollo software a las unidades de negocio, y por otra, abaratar el coste de desarrollo al emplear personal de menor cualificación y coste que los desarrolladores convencionales. El hecho de que hablemos de estas herramientas en pretérito es ya una señal clara de que en última instancia no consiguieron el propósito que perseguían.
Tampoco se consiguió el propósito último de las herramientas BPMS (Business Process Management Software). Y no es porque el modelo detrás del BPM fuera erróneo, sino porque con estas utilidades se perseguía el mismo objetivo que con las herramientas CASE aunque un par de decenios más tarde, sin considerar que para que una herramienta pueda alcanzar los objetivos que se persiguen con ella, lo menos importante es la propia herramienta. De este modo, en ambos casos terminó sucediendo en muchos casos que los programadores se vieron en la necesidad de aprender a manejar la nueva herramienta, toda vez que el personal de las áreas de negocio veía su manejo muy alejado de su actividad habitual. Y, al fin y al cabo, para obtener el mismo resultado final ¿por qué complicar la vida a los programadores con un nuevo “invento”?
Estas reflexiones vienen al caso con el florecimiento de una nueva familia de herramientas llamadas Low-Code y No-Code. Estas herramientas vienen para generar un “revolución” en el mundo TI en el que, en palabras de la consultora Forrester, “el personal de áreas de negocio puede crear aplicaciones completas empleando estas plataformas, con mayor provecho que el que demuestran en el uso de sus aplicaciones de productividad personal”. Y, si bien es cierto que en nuestros equipos ágiles las personas con perfil de negocio pueden ampliar su contribución significativamente con la utilización de herramientas de este estilo, también es cierto que podemos encontrarnos ante el mismo problema al que nos enfrentamos en las dos oleadas anteriores.
En un interesante y muy bien fundamentado artículo en la web Medium, Mina Pêcheux recoge todas las ventajas del acercamiento de estas soluciones de facilitación del desarrollo software para los departamentos de negocio, y desarrolla cómo las organizaciones pueden beneficiarse de una mayor involucración de la visión de negocio en la construcción de productos. Exactamente ese es uno de los objetivos que siempre hemos perseguido desde las unidades de TI, y que estamos logrando finalmente alcanzar gracias a la incorporación de metodologías Agile. Pero la autora apunta algunas cuestiones de importancia, entre las que considero relevante señalar 2:
- No basta con acercar el desarrollo software al negocio. También es necesario acercar el negocio al desarrollo software. El personal de negocio no puede hacer una buena labor si no entiende cuestiones como los riesgos que conlleva, por ejemplo, la introducción de cambios en producción, las relaciones entre unos sistemas y otros o la necesidad de mantener una arquitectura del dato. Obviar estas cuestiones puede ocasionar problemas complejos y elevados costes de resolución.
- Desarrollar software no es solamente escribir líneas de código. Es necesario elaborar un diseño, realizar un análisis y, nunca podremos insistir suficientemente, realizar un buen plan de pruebas. Y aunque las metodologías ágiles nos ayuden a simplificar el proceso y darle elasticidad, de ellos depende la calidad del resultado.
Nos encontramos sin ninguna duda ante una nueva oportunidad para nuestras organizaciones. Pero del mismo modo que con las herramientas Agile decimos que limitarse a instalarlas e imponer su utilización, sin más, no significa que nos hayamos transformado en Agile, del mismo modo para poder obtener el mejor aprovechamiento de estas nuevas plataformas necesitaremos un proceso de asimilación que va más allá de la formación técnica en el uso de sus posibilidades técnicas. Si somos capaces de obtener lo mejor de ellas, significarán un respaldo significativo en nuestro proceso de transformación Agile.
Imágen: Pixabay en pexels.com.