He desarrollado una buena cantidad de proyectos de data science, y pucha que fácil es diverger del camino que nos lleva al éxito. ¿Cuál es ese éxito te preguntarás? Un clásico, agregar valor. No importa cómo, pero que lo que se estaba haciendo antes de alguna forma, ahora se esté haciendo mejor, y que eso traiga consecuencias positivas al entorno (eg. aumentando eficiencia usemos menos recursos, o usemos mejor los recursos que ya tenemos).

De esto ya se ha escrito bastante, pero quería registrarlo a mí manera, sin inspirarme en ningún otro artículo. Creo que eso le agrega ortogonalidad al tema y a la web.

Suena fácil, pero aparte de la solución en sí misma, hay que acordarse que adoptar mecanismos que no entendemos es re difícil. No queremos hacerlo, no queremos sufrir de más. Es como tener que disparar esas super pistolas de Men in Black: prefiero mil veces una menos colorinche y con menos berrinche pero que haga la pega y no me falle. También hay personas que prefieren de primera las pistolas de Men in Black y podrían decir: “qué tipo conservador! vamos por lo más coool”. Y eso está bien. Disparar un rato esas pistolas y jugar con ellas puede ser bacán. Pero ¿me llevaría una de esas tremendas cosas a una pelea real? Tal vez sí, si fueran más livianas, si las supiera arreglar yo sólo, si fueran un poco más chicas. Por eso acá digo: lleguemos hasta allá construyendo desde lo más simple, y pensemos como si fuesemos ese usuario final.

Para no generalizar hablaré por mí. En estos casos, mi mayor enemigo es la complejidad. Pareciera que mientras algo es más complejo, es mejor. Para mi, la complejidad por sí misma sostiene cierta belleza que me atrae e hipnotiza un poco. Es sexy. Pero la verdad, es que la complejidad no se sostiene por sí sola, y hay que llamarla cuando se le necesita.

Por otro lado, existe como cierta verguenza a mostrar cosas simples que funcionan. Es como si uno quedara expuesto al trolleo público de otro que lo puede hacer mejor. Hoy en día, padecemos de este mal en que todos los ejercicios los transformamos en una competencia. Prefiero no caer en eso, y hacer cosas simples sin verguenza.

Ahora, si la cosa simple no alcanza, claro… hay que llamar a la señora complejidad.

Introducción #

El objetivo es lograr cambiar nuestro approach:

• “simplemente resolver problemas técnicos” ❌
• “crear productos que entreguen valor real” ✅

Pensando como un product developer desde el día uno podremos conectar nuestro trabajo directamente con las necesidades de un usuario (para hacerlo más real y acentuar las ganas que tenemos de generar impacto, entiéndase mejor como las necesidades de una persona).

Descubriendo el problema #

Primero, necesitamos entender a quién estamos ayudando.

No es la organización, no es el stakeholder, no es el champion. Encontremos quién es! Preguntémosle su nombre, conozcámoslo, conversemos con esa persona. Acompañémoslo una mañana entera. Seamos su sicólogo por un rato, y entendamos los dolores que tiene, y también sus éxitos. Imaginemos que se llama Roberto.

Si nos preguntan qué estamos haciendo, nuestra respuesta nunca puede ser: “Estoy construyendo un modelo de churn”. En realidad estamos ayudando a Roberto. Estamos ayudando a identificar usuarios en riesgo de irse de la compañia, a los cuáles queremos intentar retener. Eso se puede hacer con un modelo de churn. Pero también se puede hacer de mil formas más. También necesitamos encontrar una forma en que Roberto pueda interactuar con la cosa. También necesitamos integrar la cosa con los sistemas de Roberto. También necesitamos que Roberto tal vez puede identificar fallas de la cosa, para que esta pueda evolucionar en el tiempo, y construir sobre ella.

Esta lista de cosas son bastante más que sólo un modelo de churn, y ayuda a hacer el mind shift de producto que buscamos.

En resumen, algunas preguntas importantes acá son:

• ¿Quién usará esta herramienta y cómo?
• ¿Qué decisiones mejorarían si tuvieramos mejores data insights?
• ¿Cómo se vería un escenario de éxito para el usuario?

Segundo, diseñemos métricas correctas para medir el éxito.

Más que reportar que la cosa tiene un accuracy del 92%, midamos en qué porcentaje estamos mejorando el churn, y cuál es el porcentaje de churn mensual que buscamos/medimos.

Diseñando la solución #

Una vez identificado el problema y el usuario, dibujemos (sí, literalmente) la navegación o el journey de ese usuario a través de la cosa, de principio a fin.

Por ejemplo, “Roberto abre su dashboard el lunes a.m. y ve una lista priorizada de cuentas, cada una con sus factores de riesgos subrayados”. Necesitamos entonces sentarnos a dibujar estos recorridos y representarlos a través de frases simples. El objetivo es tener una colección de frases que construyan e viaje, y entender que esto no lo hacemos solos ni para nosotros, sino que para ayudar a Roberto. Pregúntemosle a Roberto si este viaje le parece y qué comentarios tiene. Y los consideramos, e iteramos.

El enemigo acá se llama ansiedad. No queremos resolver toda de una sola vez. No queremos viajes que sean como árboles con ramas y ramas de las ramas. Queremos lo esencial, ese 80/20 que ya nos posiciona en hacer algo distinto y que queremos testear. Esta resistencia a las ramificaciones se llama MVP o Minimum Viable Product. Con el MVP hacemos dos cosas:

• Encontramos y definimos las funcionalidades básicas que juntas hacen que la cosa sea una cosa, y no una suma de features revoloteantes. Y asegurémosnos que la cosa también sea una cosa nueva que agregue valor.
• Recolectamos feedback del usuario. Nunca nos olvidamos que trabajamos para Roberto, nuestro ahora amigo.

Acá nos podemos hacer las siguientes preguntas de scope:

• ¿Cómo se vería la solución más simple que agrega valor?
• ¿Cuál es la pregunta más importante que queremos responder?
• ¿Cuales son los benchmarks mínimos que necesitamos satisfacer?
• ¿Podemos entregar valor con los datos/recursos que tenemos?
• ¿Qué restricciones existen?
• ¿Existe soluciones baseline que podamos apalancar?

Y preguntas técnicas:

• ¿Tenemos suficientes datos para crear un modelo inicial robusto?
• ¿Podemos procesar por batches y luego en tiempo real?
• ¿Qué deudas técnicas podemos comprometer con tal de desarrollar rápido?
• ¿Cómo evaluamos el funcionamiento técnico del approach (eg. tiempos de respuesta)?

Si necesitamos desarrolar en equipo, tambien preguntas estratégicas:

• ¿Cuál es el timeline que tenemos?
• ¿Cuál es la forma más rápida de llegar a los usuarios para obtener feedback?
• ¿Qué aprendizajes queremos obtener de este MVP?
• ¿Qué métricas trackearemos?
• ¿Cómo incorporaremos el feedback de usuario?

Y no olvidemos de mitigar riesgos:

• ¿Cuales son los supuestos o los unkowns de nuestro approach?
• ¿Qué pasa si la cosa se desempeña bajo lo esperado?
• ¿Hay consideraciones éticas que necesitamos respetar?
• ¿Cuál es el fallback plan si el MVP no funciona?
• ¿Cómo comunciaremos las limitaciones del MVP a los stakeholders?

Por último, queremos planificar el deployment y adopción:

• ¿Cuál es la forma más simple de integrar la cosa a los workflows actuales?
• ¿Quiénes tienen que estar involucrados en probar el MVP?
• ¿Qué soporte necesitarán los usuarios (eg. documentación, manual, talleres)?
• ¿Cómo obtenemos feedback estructurado desde los usuarios?
• ¿Qué haría que los usuarios quieran seguir usando esta solución?

Arquitectura tech #

En este paso, necesitamos pensar en los huesos o los fierros que darán soporte para parar nuestro producto. Es importante tener una visión de largo plazo, que sea flexible y ágil para escalar y absorber modificaciones. Que funcione hoy, y escale mañana.

Algunos puntos a considerar para la arquitectura considerando número de usuario y tmamaño de datos son:

• Frecuencia de actualización de los datos
• Dónde y cómo sera deployeada la solución
• Puntos de integración con sistemas existentes
• Dependencias técnicas y limitaciones

Pro tip: documentar las decisiones y su razonamiento para poder compartirlas con los equipos técnicos.

Desarrollando el producto #

Si queremos ser ágiles, trabajemos agile (sí, es obvio). Planificar y compartimentar (así se dice?) el trabajo en ciclos de 1-2 semanas. Cada ciclo cumple una misión, y está compuesto por una colección de tareas. Después de cada ciclo, se comparten los progresos con los stakeholders para validar que estamos en el camino correcto. Si noes así, la idea es absorber rápido lo que necesitamos incluir mediante un plan para el sprint siguiente.

Una máxima: crear prototipos rápido para testear supuestos críticos. Mock-ups, dashboards, lo que sea pero tiene que ser rápido para reemplazar la imaginación por una cosa única sobre la que podamos opinar y construir.

Un recordatorio: colaborar cross-discipplinas. Necesitamos conectarnos con la gente de datos, infraestructura, diseño y negocio. Y Roberto, por supuesto.

Durante todo el proceso de desarrollo, es importante tener un ojo puesto en el horizonte, donde trackeamos las métricas que nos importan y vamos registrando nuestros avances cuantificables y cuantitativos.

Medición e iteración #

Una vez implementado nuestro MVP, la misión es doble:

• Monitorear (métricas, comportamientos, evaluación de usuario, impacto en el negocio)
• Mejorar (planificar modificaciones o nuevos features, priorizando por potencial impacto)

Y repetir.

Conclusión #

Cuando empiezas a ver tus proyectos de datos como si fueran productos, estás cambiando el juego. Ya no es solo códigos y modelos complicados - estás creando algo que realmente sirve y que la gente quiere usar. Con este enfoque, tu trabajo técnico se convierte en herramientas útiles que resuelven problemas reales y que la gente valora. Al final, lo que importa no es lo complejo que sea tu análisis, sino que alguien lo use y tenga una buena experiencia haciéndolo.