El CTO de la Insurtech colombiana Nubloq defiende un mayor compromiso de los tecnólogos de cara al negocio y a la realidad de los usuarios.
Con más de 18 años de experiencia en el sector tecnológico y una robusta formación académica, Mario A. Riveros T. ha liderado iniciativas en consultoría financiera, educativa y de contenidos. Hoy se desempeña como CTO de la Insurtech colombiana Nubloq. Conversamos con Mario sobre el viejo (y siempre relevante) tema de la relación entre el negocio y TI.
Durante décadas el mundo de la tecnología estuvo divido entre tecnólogos y MBAs. Algunos como Mark Schwartz hablan directamente de una guerra y de una grieta. ¿Eso ha cambiado en los últimos años?
Tech es cada vez menos un tomador de pedidos. Antes a un consultor lo contrataban sólo para hacer delivery, ejecutar pedidos y generar outputs. Que yo escriba 100 líneas de código, eso es puro output. Otra cosa es el outcome: el resultado y el impacto. O sea, cómo cambia el comportamiento de mis stakeholders a partir de esas 100 líneas de código que yo escribí y saqué a producción.
En desarrollo de producto uno necesita ser parte de los outcomes. Eso permite también que se vea a tech como una inversión y no como un centro de costos. Los artefactos y procesos que en TI gestionamos y construimos deben ser considerados activos financieros. Hay que pensar cada vez más en esos términos.
¿Cómo influyen las metodologías ágiles para reducir los riesgos de la inversión en tecnología?
Los productos de software tienen un ciclo de vida. Uno monta procesos adecuados a ese ciclo de vida, no al revés. Por ejemplo, si construimos el software embebido para una máquina de cuidados intensivos, debemos evitar que el conteo de morfina se pierda si hay un corte de luz. Un proceso ágil no sirve aquí, porque un error en la especificación del software puede matar a un paciente.
Cuando uno busca Product Market Fit, se está enfrentando a un entorno de mucha incertidumbre. Ahí el ciclo de vida del software es muy iterativo. Uno debe tirar el anzuelo, probar, botar ese anzuelo si no saca nada y volver a empezar. Los procesos ágiles hacen buen fit ahí.
“Mientras más tecnológico sea el core, más cross y más técnicos tendrán que ser los equipos”.
Mario A. Riveros T.
¿Qué pasa cuando para construir el software sí es necesario ir al mercado y validar hipótesis? ¿Cómo debería ser la relación entre TI y negocio?
Yo realmente ya no veo separado el negocio de la tecnología, el delivery del discovery, el discovery del research, la operación del delivery. En una compañía de core tecnológico, sí o sí el Product Manager debería ser un Technical Product Manager. En compañías que no tienen a la tecnología como core, uno puede encontrar perfiles donde el conocimiento del negocio es más fuerte que el de ingeniería o de experiencia de usuario. Mientras más tecnológico sea el core del negocio, más cross y más técnicos tendrán que ser los equipos.
“Básicamente, el trabajo consiste en minimizar el output, maximizando el outcome y el impacto.”
Jeff Patton, en User Story Mapping (2014)
Los procesos ágiles nos evitan “quemar” horas de ingeniería sin al menos un experimento previo. Uno ya no puede ser una feature factory que solamente reciba solicitudes de funcionalidades nuevas para programar. ¿Por qué? Mientras más output generamos, más esclavos somos de la operación y del mantenimiento de ese output. Jeff Patton, en User Story Mapping (2014) dice que cuando entendemos el juego en tech, vemos que nuestra labor no es producir más, sino producir mejor. Minimizar el output y maximizar el outcome: cambiar el comportamiento.
Mario A. Riveros T. es Ingeniero de Sistemas por la Universidad Nacional de Colombia, Especialista en Construcción de Software por la Universidad de Los Andes, Master of Software Engineering por Carnegie Mellon University, MBA de University of Illinois Urbana-Champaign. Actualmente se desempeña como CTO de la Insurtech colombiana Nubloq.
