El pasado día 20 reunimos al un grupo de profesionales de Business Agility Corporation en torno a nuestra mesa de debate virtual para abordar el tema de la Transformación de los Modelos de Servicio.
Pepe González, director de transformación en Tecnofor, a quien agradecemos su colaboración con BAC, realizó la moderación del debate, que inició planteando cual debe ser la estrategia a plantear para desarrollar la orientación a servicio y producto en torno a las cadenas de valor.
Fernando Cano, responsable de Metodología dentro gobierno TI en Mapfretech, nos explicó que, en su experiencia, se suelen seguir 2 posibles estrategias: una primera condicionada por el alcance de un proyecto concreto, y una segunda construida en base a la definición de procesos. La primera opción, cuando el alcance cubre varios sistemas, el resultado del producto suele ser parcial y con algunas carencias en la responsabilidad de los Product Owner y stakeholders, tales como que existan varias figuras de responsabilidad entorno al Product Owner. Por el contrario, cuando
se ha optado por el estudio de los procesos y su impacto, el reto ha estado en la coordinación de la definición de objetivos entre los diferentes equipos involucrados. La conclusión y como lección aprendida, merece la pena pensar en la mejor orientación para definir el o los productos afectados de forma previa a la definición de una iniciativa. Y que dicha definición sea válida en el ciclo de vida del porfolio de proyectos.
Augusto Ruiz, Responsable de la Digital Product Factory en Repsol nos comenta que en su organización la orientación a producto surge no tanto como una iniciativa aislada, sino como evolución de un programa digital que existía anteriormente. En ese caso se plantea la necesidad de tener cercanía al negocio y el liderazgo por parte del negocio. Los principios ágiles y la necesidad de minimizar la inversión para obtener los primeros retornos, encajan a la perfección en este planteamiento. Cuando ves que tienes un conjunto de activos en los que la posición de liderazgo del negocio da fruto, que aparecen retornos claros, y se puede percibir el incremento de los impactos como consecuencia de la inversión y su impacto en la cuenta de resultados, surge la pregunta de si conviene mantener la filosofía de trabajo que ha llevado a este resultado, o si debemos trasladarlo al modelo convencional de mantenimiento con un jefe de servicio. En el caso de los productos digitales se ha realizado un trabajo fuerte de segmentación y categorización para decidir en qué casos el producto justificaba o no mantener los equipos dedicados.
Por su parte, Román Benito, Manager de Open Banking e Innovación Digital en Liberbank, nos comenta la importancia de contar con esponsorización al más alto nivel. En 2016 iniciaron el proceso de transformación con el desarrollo de algunos pilotos Agile. Y posteriormente se incluyó la adopción de metodologías de trabajo ágiles como un proyecto estratégico. Cambiar la inercia cultural de una gran empresa es muy complejo. Lo que aceleró la iniciativa fue poner al cliente en el centro, que se ha convertido en el primer paso al plantear cualquier proceso de ideación. Esto requiere un cambio de cultura enorme. Para garantizar el proceso de trasformación se revisan tanto presupuestos como proyectos cada 6 meses. Y en algunos casos se han incluido nuevos proyectos que no se habían considerado inicialmente.
Ainhoa García de Andoin, Responsable de la Oficina de Proyectos en Sistemas de Iberdrola, nos cuenta que en su organización comenzaron con el lanzamiento de pequeños pilotos, y la creación de una unidad Digital Hub cuya misión es acompañar al negocio. A partir de ahí se ha crecido según las necesidades de las diferentes áreas de negocio. La unidad que más trabaja la agilidad es el área comercial. Comenzamos realizando con ellos pilotos para productos concretos y se ha ido ganado madurez, que se ha traducido en proyectos de mayor tamaño y con mayor presupuesto .
Dado que la madurez de las diferentes áreas es desigual, el apoyo que se les presta también es diferente. A los negocios más maduros se les apoya aportando servicios externos a los proyectos, en los que el negocio participa aportando roles como Product Owner, con metodologías Scrum o SAFe. Mientras que a aquellos negocios menos maduros en Agile se les proporciona un coaching de acompañamiento para madurar en agilidad, e ir adoptando progresivamente las herramientas y los procesos.
Antonio Pintor, Responsable de Tecnologías de la Información en Grupo Titanes, coincide en que la clave es la centralidad en el cliente. Cuando el cliente ve un modelo de trabajo que no había visto antes, y en el que forma parte del equipo real, es muy potente, indiferentemente de si el cliente es interno o externo. Por eso es importante, durante la definición del producto, tener en cuenta cómo vas a trabajar con el cliente, cómo se le incorpora y sus expectativas.
Pepe González comenta que los procesos de transformación están evolucionando los servicios y, especialmente, sus ciclos de vida, que eran la forma de trabajo convencional en nuestras organizaciones. Pero en ocasiones no queda clara la diferencia entre producto (que podría centrarse en bienes tangibles) y servicio (que serían intangibles). Especialmente cuando trabajamos con productos digitales. ¿Cómo han afectado las transformaciones a los ciclos de vida? ¿Cómo se introduce la innovación en el extremo a extremo?
En la adopción de Agile por las organizaciones, nos comenta Román Benito, sucede como con la tortilla de patata…: la receta y los ingredientes son básicamente los mismos en todas partes, pero en cada casa se termina preparando de una forma diferente. Liberbank empezó escribiendo un playbook “Liberbank Agile Way” en el que se incluyeron los roles, las ceremonias o las fases desde Design Thinking hasta desarrollo continuo, con Devops y Entrega Continua. Este libro se formalizó internamente como guía de proceso y acompañamiento en la transformación a estas metodologías. Igualmente se decidió que los productos del ámbito de transformación digital se construyeran en Agile, y en esto no hay discusión. A partir de aquí el resto de la organización se va empapando de estas metodologías a medida que se va involucrando en los propios proyectos. Cuando se va necesitando abordar unidades más lejanas al modelo Agile (legal, marketing, etc…), se les va incorporando a los equipos, y de esa manera se va extendiendo la forma de trabajo Agile y empiezan a adoptarla y a entusiasmarse con ella. De esta manera, vamos hablando cada día más de la construcción de productos, y no tanto del desarrollo de proyectos como tal. La base para nosotros es un Product Owner con un equipo de desarrollo empoderado, autosuficiente y autogobernado, que toma sus propias decisiones. Esto es lo que ha permitido desarrollar en tiempos record proyectos tan complejos como un agregador de bancos, un iniciador de pagos con cargo en cuenta, una hipoteca 100% digital, etc. El foco está puesto actualmente en escalar el modelo hacia portfolios con diferentes squads y múltiples equipos Scrum trabajando de forma conjunta.
En el caso de Mapfretech, comenta Fernando Cano, también se ha ido ganando en confianza con el tiempo. Y aunque el impulso y la estructura para abordar iniciativas Agile son los proyectos, se han introducido elementos que pueden ayudar a clarificar una organización más ágil y aspectos de innovación tales como Design Thinking, incorporar estándares de escalado, etapas de incepción en planificación estratégica,… Un hándicap es que el presupuesto sigue siendo anual. Pero como muestra de que la transformación está calando en toda la organización, los alcances ya no definen con objetivos muy concretos a más de 3 meses vista, sino que más bien definen misiones estratégicas con una clara orientación al cliente final. Cada vez más se van dejando la definición de alcances fijos en las planificaciones de cada periodo de Sprint (2-4 semanas). También se ha avanzado en incluir en la definición de proyectos anuales con alcances más variables, que se concretarán con solicitudes que recibe el equipo de trabajo, lo que aumenta la flexibilidad del modelo de trabajo. Todo lo que nace de Design Thinking está siendo más coherente con esta visión. Aunque todavía se ejecutan también proyectos con alcance fijo, la adopción de la mentalidad Agile se centra en proyectos de más larga duración, con orientación a resultados, y no necesariamente con objetivos predefinidos.
Aunque suene antiguo, menciona Ainhoa García de Andoin, en Iberdrola hicimos un proceso de transformación de los servicios de factoría de software basados en proveedores con bagaje Agile, y en la transformación de nuestros propios servicios. Esto nos ha permitido mantener servicios de desarrollo estables con una gran capacidad, con personal bien formado y altas capacidades. Y, por otra parte, tenemos dos diferentes evoluciones en los equipos de producto. Con algunos equipos ágiles hemos percibido que se terminan reservando tiempos de los recursos Agile para hacer soporte. Suena a WAGILE y debemos vigilarlo, pero estamos dejándoles evolucionar porque al negocio le funciona. El segundo caso, que es el más ágil y digital, es la vía que utiliza el negocio comercial hacia los clientes finales. En el pasado nos sucedía, especialmente en el mundo de aplicaciones móviles, que cuando desarrollábamos un producto y éramos capaces de ponerlo en manos de la unidad comercial, ya había quedado obsoleto, El modelo Agile nos permite llegar al cliente de forma eficaz. Necesitamos ser rápidos y reutilizar. De manera que si, por ejemplo, hemos sacado una app eficaz en Portugal, somos capaces de ponerla a funcionar en Italia en 2 semanas. Esto se puede hacer respondiendo de forma ágil gracias a disponer de servicios de desarrollo con contratos a largo plazo.
Es interesante este planteamiento de construir servicios de desarrollo con orientación a producto, comenta Pepe González.
En Repsol hemos adoptado un modelo que tiene puntos en común con esta visión, según nos explica Augusto Ruiz. Tenemos algunos productos que por su entidad, tamaño o incluso su bagaje tecnológico, tiene sentido que se resuelvan extremo a extremo por el mismo equipo. Pero igualmente percibimos la necesidad de que existan otros equipos que prestan servicios transversales, a los que llamamos plataformas, y que aportan eficiencia a la hora de construir los productos sobre ellos. Un ejemplo sería la plataforma Salesforce para el mundo comercial, o en la analítica de datos, nuestra plataforma ARIA. La transformación de proyecto a producto tiene que ver con el modelo de servicios, pero primando la continuidad de los equipos y el conocimiento adquirido. Cuando evolucionas de un modelo en el que hay una transferencia de conocimiento en el paso de desarrollo a producción, a otro modelo en el que das continuidad a los equipos con un MVP en el plazo más reducido posible, sin que haya un paso a mantenimiento, resulta absolutamente necesario transformar también las políticas de sourcing. Tenemos que decidir la política de squads, y si estos deben formarse de un solo proveedor, o si deben combinarse varias áreas de experiencia. Especialmente en lo que se refiere a la gestión de los contratos con proveedores, cuando los acuerdos de nivel de servicio están muy orientadas al tiquet, y se pretende llevarlos a un modelo de gestión orientado a la satisfacción del cliente. Ahora estamos dando los primeros pasos en estos contratos que tratan de medir el desempeño de los servicios de una forma diferente.
Estaríamos hablando de un modelo de Desarrollo-as-a-Service para pasar de proyecto a producto, comenta Pepe González.
Lo que buscamos es que la relación contractual, responde Augusto Ruiz, no esté basada en el trío Inicio – Fin – Alcance. Sino que dispongamos de una linea base con un opex (gasto), otra línea de evolución con un capex (inversión) asociado, que permite conseguir objetivos de negocio. Y que seamos capaces de acordar, durante periodos de evolución, cuales son los resultados clave que pueden ayudar a alcanzar ese objetivo, especialmente teniendo en cuenta que, en muchos casos, la consecución del objetivo no está al 100% dentro de la responsabilidad de un único proveedor.
Antonio Pintor comenta que en el caso de una pyme no existe el problema de que, una vez desarrollado el MVP, deba este transferirse para que otro equipo realice el mantenimiento , ya que por las limitaciones de dimensión, habitualmente es un mismo equipo quien desarrolla y mantiene un producto, por su propia naturaleza. Lo que sí que resulta una cuestión común es la necesidad de fijar los objetivos y las métricas sobre los que basar el desarrollo del producto.
En el mundo Agile, la relación con proveedores es compleja tanto si se trata de una ayuda puntual o de prestaciones de servicios a más largo plazo, incide Román Benito. Un talón de Aquiles que podemos tener todos, y que por sí mismo podría dar lugar a un monográfico, es cómo virar de un contrato por alcance cerrado convencional, a un contrato Agile en el que, sin caer en el body shopping, solicites el desarrollo de un producto con un alcance sin precisión detallada, sabiendo que el proveedor externo debe implicarse. Esto solo puede resolverse cuando entre los equipos del cliente y el proveedor se establece una cadena de confianza, toda vez que atar el modelo de forma contractual es poco menos que imposible.
Pepe González comenta que desde BAC tomamos nota. Coincidimos en que el contrato Agile para proveedores es una cuestión de un enorme interés y la incluiremos en nuestro backlog.
Román Benito continua diciendo que es inevitable que las organizaciones de gran tamaño mantengan un modelo híbrido en el que, además de iniciativas ágiles, se mantienen proyectos convencionales gobernados desde una PMO (Project Management Office). Especialmente para el trabajo con alcances y fechas acotadas (como es el caso de las obligaciones regulatorias). De hecho, en nuestro playbook, la primera decisión incluida es cuándo tiene sentido trabajar en modo Agile, y cuándo realizarlo en waterfall.
Fernando Cano coincide en este punto y comenta que es importante aprovechar las estructuras de las que ya disponemos en nuestras organizaciones. Una PMO te aporta una plataforma con capacidad para ejecutar cosas. Aportando otro ejemplo, en su organización, la figura de Scrum Master se esta proporcionando también desde la PMO, por facilidad de aprovechar la estructura y disponibilidad de un servicio. Esta forma de hacerlo puede tener ventajas e inconvenientes, pero se trata de comenzar a trabajar con los medios que se disponen..
Volviendo al tema de los objetivos, comenta Ainhoa García de Andoin, la intención de dirigir la gestión de proveedores y desarrolladores hacia los objetivos de productividad de negocio, puede sonar a veces a leyenda urbana. Hay mucho camino por recorrer en este sentido, y nosotros no hemos sido capaces de visualizar como definir una hoja de ruta
Augusto Ruiz contesta que en Repsol, con el caso de Waylet, se pudo un objetivo en 2020 sobre numero de usuarios y número de operaciones a realizar a través de la aplicación. El equipo analizó las opciones para conseguirlo, y una de las vías fue la mejora del proceso de registro. Negocio ha definido qué espera conseguir, y se le traslada con claridad al equipo de trabajo. Cómo lograrlo es cosa del equipo. Ademas de esto, lógicamente, ha sido necesaria una actuación de marketing. Pero nos ha permitido ver como nuestro proveedor contribuye al objetivo. Por ejemplo: necesitamos una tasa
de éxito en el registro del 99,99%, o una tasa de éxito de pago en pista que no baje de un umbral, porque si baja, se nos complica el objetivo del número de operaciones. Y esto nos permite que cada equipo puede contribuir al objetivo común de todos los equipos que trabajan en torno a Waylet, aunque cada uno tenga unos objetivos clave diferentes.
Efectivamente, continua Ainhoa García de Andoin, hemos hecho algo semejante en la recarga de vehículo eléctrico. El objetivo es que el usuario que llega al punto de recarga tiene que poder recargar, y se comprueban los fallos que pueda dar el punto de recarga de una forma semejante. Lo que no hemos llegado a alcanzar es completar el enlace con el objetivo de beneficio económico.
En nuestra organización sucede algo semejante, comenta Fernando Cano. Los objetivos que utilizamos suelen ser de disponibilidad o hitos del servicio, pero no tanto económicos. Lo ideal seria que la ganancia económica comercial pudiera repercutir en la cadena de valor del producto.
Exacto, dice Ainhoa García de Andoin, y demostrar que hay una cadena de valor en cuanto al impacto en el negocio que aporta esta forma de trabajar, siendo capaces de responder mediante iteraciones rápidas, sirviendo las necesidades del cliente. Pero nos falta madurez para establecer la cadena de valor económica.
Completamente de acuerdo, concluye Augusto Ruiz. De hecho, para todos los productos digitales no podemos tener los ratios de conversión entre el negocio y el producto, pero para avanzar es fundamental que el Product Owner y su equipo estén completamente alineados en cuanto a cómo se va a obtener el impacto económico.