Desde que empecé a escribir sobre RPA, las personas pueden pensar no me gusta esta tecnología. Y no es así, en la compañía la usamos desde hace años con los “bots” de pruebas automatizadas y orquestadores. Es la experiencia y conocimiento lo que nos da para informar sobre temas que se deben tener en cuenta.
¿Habrá caras de asombro? ¿Hace años ya había robots? Si, RPA es algo muy viejo introducido por Microsoft. Y la mayoría de las herramientas de RPA usan este programa de Microsoft. Es por eso que las herramientas de RPA trabajan sobre Windows mayormente.
Cuando codificamos sin entender bien la funcionalidad del requerimiento del negocio, hacemos mala programación, o parcheamos en caliente para solucionar algo, se genera la deuda técnica. Quien lo iba a pensar? Si, deuda con intereses y todo.
Habrá empresas hoy en día que su deuda no sea tan grande porque habrán aplicado buenas prácticas como arquitectura, gobierno corporativo, gobierno de datos, usaran metodologías de desarrollo al pie de la letra, harán pruebas de caja blanca o de caja negra entre otras muchas cosas que ya hay en día definidas. Pero siempre encontramos pedazos de código que no están bien, o un remedo por ahí. Pero hay empresas que tienen aplicaciones codificadas desde hace años y cada nueva modificación que se hace es más dificultosa porque es sobre algo que ya tiene mucha programación de diferentes personas, programas muy largos, parches, etc. Ahí hay un problema cuando hay que definir en el diseño como arreglar o agregar algo se toma mayor tiempo, puede que impacte otras módulos o partes de programación, haciendo los cambios más lentos. La productividad se desmejora y la moral también. Y cuando hay baja productividad vienen los jefes a decir esto hay que ponerlo en producción ya; olvídese de arreglar el código, agréguele y déjelo así después vemos. Y ahí se va adicionando a la deuda técnica.
La deuda técnica es de diferentes tipos y cuesta dinero. ¿Porque RPA adiciona deuda técnica?, pues simplemente estamos agregando un software sobre otro, necesitamos sacar los “bots” y reducir los tiempos de programación y de ejecución, y los programadores no necesariamente hacen las cosas bien. Si no fuese así, ¿cuantos bots se están reparando a diario? Porque cambio la aplicación o porque le falto excepciones o porque el diseño del bot no fue el adecuado.
¿Qué tire la piedra aquel que diga que nunca tuvo que agregarle lógica a algún bot para resolver algo? No a todos, pero a alguno. Para poder lograr la funcionalidad esperada. Y la herramienta no lo contempla, o es complicado la forma, problemáticas varias.
¿Qué estrategia hacer?
1. Hay que modernizar las aplicaciones, las aplicaciones viejas tiene deuda técnica y eso ira comprometiendo la productividad del equipo de trabajo. Si esto por inversión y tiempos no es posible.
2. Creen una estrategia por “sprints” de ir arreglando esta deuda. Un pequeño equipo que vaya resolviendo pedazos o temas o códigos de estas aplicaciones. Y con pruebas incrementales y continuas ir flexibilizando ese código.
3. Aplicar siempre la revisión de pares. Esto no es algo tan común en las áreas de desarrollo todavía. Si se está haciendo, pero no veo que sea a gran escala.
4. Revise si conviene más el uso de API en vez de RPA , sobre todo para aplicaciones legadas.
5. Trate de acomodarse a las aplicaciones comerciales más que empezar a crear programas para complementar el “como quiero que funcione”.
6. Use herramientas que le de información del código y encuentre esas áreas de mala programación.
Entiendo que hay personas de TI que sientan que eso no pasa en su organización, pero créenme somos humanos, y si sucede.
Hoy en día nosotros usamos Value Stream Mapping para diagnosticar los procesos en las áreas de TI y precisamente incluimos la deuda técnica como un factor para evaluar, medir y crear un roadmap.
Gracias por leerme, y síguenos, encontraras opinión honesta y sencilla para abordar los temas de TI.
Helen Abalo- Ceo Galiatech-habalo@galiatech.com-www.galiatech.com