Si algo entorpece el desarrollo moderno de aplicaciones son los sistemas legados y la complejidad que los propios departamentos IT añaden sin proponérselo (a veces).
Usted seguramente ha estado en más de una reunión donde se junta el comité ejecutivo y alguno de los jefes se le ocurre sugerir el desarrollo del siglo: una app que recién acaba de probar en su celular y que podría ser el santo grial de su negocio. “Dime “¿cuánto tardaría una aplicación de este tipo? […..] ¿Cuánto? […..] ¿Por qué tanto?”
Cualquier respuesta entre tres y seis meses hoy es considerada una eternidad, no vayamos más allá. La pandemia cambió para siempre el concepto de urgencia. La agilidad ya no es una ventaja competitiva, sino la condición fundamental que permitirá la sobrevivencia. Los nuevos jugadores digitales que irrumpieron en los últimos 18 meses en casi todas las industrias fueron solo la última demostración de una realidad que muchos negocios tradicionales habían querido soslayar.
Para quienes no nacieron digitales, contar con metodologías ágiles y marcos de referencia modernos no es suficiente. Empresas de todo tipo de giros apenas están buscando la orilla para desenredar la madeja de complejidades que administran, entre sistemas heredados mil veces parchados, y aplicaciones de propósito específico que fueron desarrolladas de forma independiente y sin ninguna documentación.
A ello habría que sumar la dificultad de romper los silos y las barreras entre las áreas operativas, las financieras y las tecnológicas. No se equivocaría si aplica la ley de Pareto: solo 20% de las empresas ha invertido en DevOps, en automatización de procesos digitales, en BPM, nube, low code, contenedores, nuevos lenguajes o frameworks. El 80% restante, d acuerdo con encuestas entre líderes y profesionales IT, apenas está iniciando su jornada hacia la incorporación de metodologías ágiles o está en un nivel básico de adopción.
En otras palabras, toda organización de IT debe analizar detenidamente cómo reducir el tiempo de desarrollo para hacer frente a la rapidez con la que cambian las cosas y a la urgencia de los problemas importantes.
Entonces, ¿cuáles son las empresas que pertenecen a la pequeña minoría que comenzó y terminó un proyecto de software en el último mes? ¿Y cuál es la forma en la que abordan el desarrollo de software que les permite ser tan rápidas?
Primer acto, reconocer
El punto de partida, de acuerdo con un grupo de 20 CIO de grandes organizaciones que participaron en nuestra última mesa redonda virtual, es el reconocimiento de la complejidad —heredada o no— que está provocando un freno al desarrollo.
Se requiere un ejercicio de autoevaluación en torno a la velocidad de respuesta, para lo que pueden usarse múltiples esquemas disponibles hoy en día, como los de algunas empresas expertas en gestión del cambio.
Una firma que ofrece plataformas para desarrollo ágil de aplicaciones utilizó como base la metodología propuesta por Prosci para encuestar a 2,200 profesionales IT. Se les invitó a evaluar su incorporación de metodologías ágiles, a fin de valorar su compromiso con el cambio. Se ofrecieron cinco niveles de madurez entre los que debían elegir, a saber:
- Inicial: nos falta constancia y debemos capacitarnos para estar todos alineados.
- Acaba de comenzar: los procesos no están completamente definidos. Nivel básico de adopción de metodologías ágiles.
- Definido: todo nuestro equipo está utilizando metodologías ágiles. Constantemente entregamos esprint tras esprint.
- Medido: estamos evaluando la calidad del código e incorporando otras medidas importantes.
- En proceso de optimización: llevamos a cabo mejoras sostenibles y continúas basadas en indicadores clave de rendimiento (Key Performance Indicator, KPI)
Los resultados indicaron que menos del 25% de las empresas habían superado el paso de definir su enfoque, y más del 50% acababan de comenzar. En otras palabras, aunque la vanguardia ha declarado que las metodologías ágiles han pasado a la historia y ha avanzado, la gran mayoría de los departamentos de IT todavía están pensando en cómo reinventarse para lograr una entrega más rápida ¡con tecnologías obsoletas!
Segundo acto, la deuda técnica
La deuda tecnológica o Tech-debt compromete recursos financieros y personal de IT talentoso que podría centrarse en la innovación y el crecimiento. Se estima que las grandes empresas invierten $4 de cada $10 dólares en mantener sus sistemas legados, mientras que el muy escaso personal técnico capacitado se siente frustrado por dedicar su tiempo a sistemas viejos.
Los dos factores principales detrás de la deuda técnica son: el alto número de lenguajes de desarrollo, que complica mantener y actualizar los sistemas; la rotación en los equipos, lo que deja a los nuevos empleados a cargo de plataformas que no crearon y que pueden no adoptar o comprender completamente.
Además de estos hay otros factores, como la necesidad de actualizar el hardware para apoyar el trabajo remoto y las plataformas de seguridad, que dificultan que las empresas mantener y refrescar los sistemas críticos, que no desaparecerán por sí solos.
La adopción de metodologías ágiles, el DevOps, la automatización, el RPA y la inteligencia artificial son la nueva frontera. Quizá no sea su caso, pero muchos allá afuera están enfrentando barreras comunes, como la integración con sistemas heredados, la inexistencia de API o la necesidad de mejoras, aunado a requerimientos poco claros o cambiantes por parte de los usuarios.
Como dijo una ejecutiva IT de uno de los banco más grandes de México: “Tenemos que comenzar por reconocer la complejidad que hemos introducido y que muchas veces no queremos desaparecer por temor a ser prescindibles.” Alguien más añadió: “Los esquemas y las metodologías ágiles son una buena base, pero es importante adaptarlas a la propia organización, con un poco de intuición y mucho de experiencia en el manejo del cambio.”
