Hay muchos enfoques diferentes para abordar un proyecto de software modernisation. El enfoque correcto dependerá de muchos factores, como los objetivos de negocio que tiene tu organización, el estado actual de los sistemas y de la organización, las presiones comerciales predominantes, los recursos disponibles para llevar a cabo el proyecto y las estructuras de asignación de recursos dentro del propio negocio.
En este artículo, abordamos algunas formas diferentes de liderar un programa de software modernisation con sus pros y sus contras. El objetivo es ayudarte a comprender cuál sería el enfoque más adecuado para tu organización según el estado actual de los sistemas y los objetivos de negocio que se desean alcanzar mediante software modernisation.
Las personas que trabajan regularmente con la tecnología en las organizaciones, como los desarrolladores de software, los equipos de infraestructura (si los hay), los grupos de control de calidad, los administradores de bases de datos, los grupos de seguridad de la información o de aplicaciones, son probablemente quienes mejor entienden los problemas que existen en las empresas. Parece lógico, incluso obvio, confiar en estos grupos para entender el problema, asegurar el presupuesto y ejecutar un programa de modernización de software.
En el caso de los cambios dirigidos por la tecnología, normalmente habrá una lista de entregas centradas en la tecnología, como "migrar nuestra base de datos a la nube", "actualizar nuestra plataforma central de comercio electrónico a la última versión" o "reescribir nuestra aplicación monolítica en microservicios". El grupo responsable de la modernización determinará los plazos de entrega y encontrará la manera de implantar las mejoras sin que ello afecte a los servicios críticos de la empresa que deben continuar en paralelo.
El proyecto estará dirigido por las personas que mejor saben cómo modernizar el estado de la tecnología.
Dado que los resultados suelen estar contenidos en un único sistema, es probable que cada uno de ellos esté contenido en un único flujo de valor propiedad de un único grupo. Esto debería garantizar que el cambio pueda ser impulsado rápidamente.
El valor empresarial puede no ser evidente fuera del grupo que ejecuta el programa. Esto puede llevar a una falta de apoyo por parte de los stakeholders de mayor nivel.
Dado que los stakeholders del programa se centran en la tecnología, existe el riesgo de que la modernización, aunque mejore la tecnología, no aporte beneficios empresariales reales.
Cualquier cambio liderado por la tecnología corre el riesgo de quedar aislado dentro de un único grupo y que no sirva para abordar de forma holística los problemas de la organización.
Los equipos de desarrollo pueden caer en la tentación de sobrediseñar los sistemas e introducir nuevas tecnologías "cool", sin considerar todos los beneficios y costes.
Un enfoque ascendente de la modernización de software sitúa la responsabilidad de los objetivos de modernización en los equipos de producto existentes. La organización entenderá que la modernización de software es necesaria porque el estado actual de los sistemas dificulta la consecución de sus objetivos empresariales. Cada equipo de producto está facultado para crear ítems del backlog que cumplan los objetivos de la modernización del software y añadirlos a su backlog. Por lo general, la dirección de la organización ordenará que una determinada proporción de los recursos de cada equipo se asigne a los elementos de modernización, mientras que el resto de los recursos disponibles se destinarán al trabajo de las funcionalidades.
Cada equipo de producto puede elegir los elementos del backlog de modernización que solucionan sus propios puntos débiles, lo que debería conducir a una buena motivación y aceptación.
Los trabajos de acondicionamiento deben continuar a lo largo del programa de modernización.
La falta de un equipo de implementación que se encargue específicamente de los elementos de la modernización de software podría provocar que los objetivos, resultados y métricas sean difíciles de articular.
En una organización en la que el estado actual de los sistemas está causando grandes cantidades de trabajo no planificado, es probable que la empresa pueda presionar a los propietarios de los productos para que quiten prioridad a los elementos de la modernización en favor del trabajo de las funciones.
Muchos de los síntomas del cambio positivo que ofrece un programa de modernización de software serán visibles mediante la mejora del enfoque de la organización respecto a las prácticas de DevOps. El equipo de transformación de DevOps se encargará de mejorar las herramientas y las prácticas en torno a todos los flujos de valor de la tecnología con el objetivo de permitir que cada equipo de producto sea autosuficiente.
Hay que entender que este equipo no debe tratar de ser un guardián, al estilo de un equipo tradicional de operaciones o servicios de producción, sino que debe crear herramientas y prácticas que permitan a cada equipo de producto ser su propio guardián de calidad de la producción. Para aprovechar las nuevas formas de trabajo que ofrece el equipo de DevOps, cada equipo de producto tendrá que modernizar partes de los sistemas que posee.
Ningún equipo de producto debería quedarse atrás con este enfoque, ya que las nuevas herramientas estarán disponibles para todos.
Los equipos de producto pueden seguir trabajando en sus propios backlogs con las prioridades establecidas por sus propietarios de producto.
Cada equipo de producto puede establecer su propia agenda de mejora y, por lo tanto, encontrar momentos adecuados para trabajar en la modernización de software junto con su trabajo en curso.
Para que este planteamiento tenga éxito, es necesario que toda la organización, y no sólo los que participan directamente en el programa, lo acepten.
Los propietarios de los productos necesitan tener un nivel de comprensión sobre cómo el trabajo de modernización del software mejorará su flujo de características con el tiempo, para poder tomar decisiones informadas sobre prioridades.
Existe el peligro de que se perciban los objetivos de los equipos de producto como desalineados con los del equipo de transformación DevOps.
La idea del cambio de liderado por el producto es que la modernización se impulse mediante la reorganización de los equipos de software en torno a verticales de producto con una estrecha participación de la empresa.Para garantizar que cada nueva vertical de productos tenga la capacidad de cumplir autónomamente con sus resultados, es inevitable que se produzca un proyecto de modernización. Los objetivos están, por tanto, vinculados al valor empresarial evidente, primero a través de los esfuerzos de desacoplamiento para facilitar los equipos autónomos y, después, a través de la iteración constante de las herramientas para apoyar los flujos de valor.
El objetivo final en este tipo de programa de modernización será ver a toda la organización realineada en torno a los resultados orientados al cliente, que serán atendidos por equipos autónomos e interfuncionales.Debido a las preocupaciones sobre la continuidad de la actividad, es poco probable que se pueda llevar a cabo algún tipo de transformación organizativa "a lo grande". La interrupción de la actividad a corto plazo se reducirá al mínimo si los nuevos equipos centrados en el producto se crean de forma iterativa.
Una buena manera de empezar es identificar el resultado más fácil de aislar del resto de los sistemas, crear un equipo que se encargue de ese resultado y capacitarlo para que haga la modernización necesaria en los sistemas, a fin de aislar su flujo de valor antes de ofrecer su solución. Si los stakeholders de alto nivel están nerviosos por el riesgo de las actividades en curso, se puede considerar la posibilidad de seleccionar un producto o resultado de bajo riesgo, o quizás una oportunidad innovadora, para el nuevo equipo.
Cuando el primer equipo de producto esté aportando valor de forma regular, la confianza y el entusiasmo por el nuevo modelo deberían estar aumentando en toda la organización. En este punto, se puede considerar la creación del siguiente equipo o equipos en función de lo que vaya a suponer un mayor impacto, ya sea en términos de valor inmediato de cara al cliente, de agilidad empresarial o una combinación de ambos.
Este enfoque demuestra el valor de romper los silos mediante la creación de verticales basados en el producto en lugar de horizontales basados en la tecnología.
Existe un valor empresarial evidente a través del producto escogido como centro de la modernización de software.
Si la empresa se compone de muchos silos tecnológicos, las primeras fases del programa de modernización pueden ser muy frustrantes, ya que el nuevo equipo de productos intentará comprender no sólo lo que hacen los distintos sistemas, sino también por qué lo hacen.
Puede haber resistencia interna a este tipo de cambio porque la reorganización de los equipos se percibirá como una amenaza para algunos intereses personales.
En algunas organizaciones, especialmente las más grandes, puede tener sentido utilizar una combinación de enfoques. Una fórmula que puede funcionar muy bien es combinar el enfoque del equipo de transformación DevOps con el enfoque dirigido por el producto. Este planteamiento puede reducir las posibles fricciones entre el nuevo equipo de producto y el equipo de infraestructura (o de sistemas de producción u operaciones) existente, ya que este último formará el núcleo del equipo de DevOps, que estará alineado con el de producto, y juntos se centrarán en los objetivos de la modernización de software.
Un enfoque híbrido en el que participen más personas dentro de la tecnología debería garantizar una mejor alineación en todo el grupo, lo que permitiría obtener mejores resultados.
Cualquier tipo de enfoque híbrido puede ser diseñado para equilibrar las dificultades tácticas con los objetivos estratégicos.
Un enfoque híbrido, en particular uno que incluya equipos de desarrollo, producto y operaciones, puede atravesar las verticales de negocio existentes y, por lo tanto, afectar a algunos presupuestos. Por eso, será necesario conseguir un alto nivel de alineación y cooperación para que este enfoque tenga éxito.
Un enfoque híbrido será necesariamente un programa más amplio que implique a más personas y, por tanto, puede ser caro.
En última instancia, cada organización es diferente. Hay diferentes razones por las que puede ser necesario modernizar el software, diferentes estructuras presupuestarias dentro de la organización y diferentes presiones externas que deben equilibrarse entre sí. También es muy probable que un programa ambicioso de modernización de software traspase los límites organizativos existentes y, en última instancia, pueda dar lugar a un reajuste de esos límites que muchos podrían percibir como una amenaza.
Hay que considerar cuidadosamente cómo se pueden alcanzar los objetivos de la empresa y mantener contentos a los stakeholders, especialmente los responsables del presupuesto. Demostrar el valor desde el principio será clave para crear un impulso y un apoyo general dentro de la organización, garantizando que su presupuesto no se cuestione y dándole la mejor oportunidad de éxito a largo plazo.
La modernización de software puede ser un viaje largo y a veces frustrante. Siempre que tú y los stakeholders lo entiendan y sigas algunos de estos principios que te ayudarán a elegir la metodología que más posibilidades de éxito tenga a largo plazo, el viaje debería ser muy gratificante.
La deuda técnica, aunque ampliamente debatida, rara vez se aborda de manera efectiva. Según un estudio de McKinsey, representa cerca del 40% de los..
En enero de 2022, la última versión de AngularJS dejó de recibir soporte. No habrá más actualizaciones oficiales ni parches de seguridad para..
El panorama tecnológico cambia constantemente, por eso a menudo vemos cómo algunas aplicaciones no resisten el paso del tiempo. Para contrarrestar..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores
