El CTO de Digital Femsa revisa conceptos clave para el desarrollo de software y afirma que “agilidad a veces se confunde con ansiedad”.
Miguel Ángel Rodriguez Álvarez Icaza tiene una trayectoria remarcable en TI, habiendo desempeñado roles estratégicos y directivos en compañías como PagaTodo, Bien Para Bien, Phiveleven, entre otras. Es co-founder de dos compañías (Rodiles y WhiteShield) y MBA por la Universidad de Oviedo. Para completar el cuadro, su formación y primeros roles están asociados a la ingeniería electromecánica.
¿Cómo te ha ayudado tu formación y experiencia en ingeniería electromecánica a comprender los procesos de transformación digital y a la industria de software?
Veo el grado de madurez de una versus el grado de madurez de otra. La ingeniería es como una casa en donde hay muchos hermanos. Hermanos mayores que ya trabajan, que producen, que mueven la economía a nivel mundial. Por ejemplo, la industria automotriz, la industria aeroespacial, que en temas de QA llevan literalmente siglos de adelanto con respecto a la producción de software. El software es el hermano chiquito que todo el mundo voltea a ver. Seis Sigma, por ejemplo, parece inaplicable a nivel software. Si en software decimos que buscamos mejorar un proceso como para tener un defecto en 1 millón, no sabemos ni siquiera 1 millón de qué. ¿De funciones, de aplicaciones?
“El software es el hermano chiquito que todo el mundo voltea a ver. Seis Sigma parece inaplicable a nivel software”
¿Cómo se plantea la innovación en una compañía del tamaño de Digital FEMSA? ¿Qué lugar tiene el agilismo?
Cuando alguien aprende a usar un martillo a todo le ve cara de clavo. Creo que la metodología ágil es una herramienta más en mi caja de soluciones. No la única. Nosotros no somos una startup. Tomamos conceptos del agilismo cuando nos sirve aplicarlos, pero no siempre. Por ejemplo, en SCRUM se hace una pregunta que es imposible contestar: cuánto tiempo llevará hacer esto que no se ha hecho antes. Es imposible saberlo. Es la piedra angular para desarrollar todo el marco de entrega de valor hacia negocio, pero nadie lo puede responder con certeza. Ni los más seniors de los seniors. La innovación debería estar por encima de las metodologías. La agilidad a veces se confunde con ansiedad. No todo tiene que ser entregado rápido. Por otra parte, esto es posible cuando partimos con el tanque lleno. Las startups parten con el tanque prácticamente vacío. Es otra situación.
“En Digital Femsa tenemos una cultura de sync con el negocio. Para eso es importante construir una relación consultiva”
¿Cómo se gestionan los tradeoffs entre tiempos, calidad y necesidades del negocio?
En Digital Femsa tenemos una cultura de sync con el negocio. Desde los CTOs y CIOs hasta los PoDs. Buscamos que toda el área de IT tenga el foco puesto en comprender y entregar valor real al negocio. Para eso es importante construir una relación consultiva. Podemos pensar en un dilema típico en donde esto es relevante: optimizar el código versus hacerlo legible. Es un tradeoff importante a nivel diseño. Por ejemplo, quieres que las transacciones sean en menos de un segundo, pero a la vez quieres hacer un código mantenible. Tengo que juntarme con el negocio y considerar ese tradeoff. El código tiene que poder documentarse de cara a nuevas personas que lleguen al equipo para mantenerlo y evolucionarlo.
“El medio que usamos para construir software es lenguaje. Un lenguaje preciso que debe ser legible para la máquina y para las personas que lo mantienen”.
¿Qué recomendaciones le haces a tus ingenieros más senior para que no se pierdan en la paradoja del experto y se desconecten del resto de los equipos?
El ingeniero de software crea piezas que va reutilizando pero sin un verdadero estandar a nivel mundial. Hay mejores prácticas pero no medidas exactas. La etimología podría ser un fundamento para escribir software. Entender el origen de la función para definirla y llamarla puede llevar a trabajar esas piezas de forma estandarizada y reutilizable. Al final, el medio que usamos para construir software está hecho de lenguaje. Un lenguaje preciso que debe ser legible tanto para la máquina como por las personas que lo mantienen. Si no puedo lograr esto, es como si le hubiera comprado el software a un tercero. Deja de ser un activo estratégico propio.
“El por qué nos une a todos como equipo y permite un mayor impacto a la hora de innovar”
Pero lo que es verdaderamente clave es que todos entendamos el por qué de lo que estamos haciendo. Por eso buscamos construir equipos vocales, que pregunten mucho hacia negocio, no solo el PM y el PO. ¿Por qué este producto va a ser rentable? ¿Por qué tu prioridad es este producto? El por qué nos une a todos como equipo y nos permite tener un impacto mucho mayor a la hora de innovar, atacando el problema o aprovechando la oportunidad que se presenta en el mercado, en el mundo o en el nicho en que estamos.
