APLICANDO AGILIDAD Y DATA SCIENCE
HELLO WORLD! He tenido oportunidad de trabajar con equipos relacionados a Data Science, les agradezco infinitamente la apertura que me dieron para realizar su trabajo con una nueva perspectiva.
En este viaje, que tenía como objetivo implementar modelos que pudieran operar de manera automática y en constante contacto directo con el cliente, hubo muchos aprendizajes de los cuales quiero compartirles algunos:
- Es muy importante identificar los conceptos de PoCs, Piloto, MVP en Data Science.
- Trasladar un dato de un lugar a otro, no es un “copy paste” del dato.
- Antes de comenzar un proyecto de Data Science debemos: Identificar principales fuentes de información, ¿dónde están alojadas estas fuentes de información?, ¿quiénes son los dueños de estas fuentes de información? y ¿qué dato relevante se obtiene de estas fuentes de información?.
- No puedes aplicar / desarrollar analítica avanzada, sino tienes la información con la cual trabajar.
- Es necesario un rol de traductor tanto para el entendimiento de negocio, como para el entendimiento de los equipos de desarrollo en productivo.
Ahondaré brevemente en cada punto:
1.- Es muy importante identificar los conceptos de experimentación PoCs, Piloto, MVP en Data Science.
Antes de lanzar un nuevo producto al mercado, un buen Product Owner prueba de manera sencilla su producto para confirmar el beneficio al cliente y si vale la pena invertir tiempo, dinero y esfuerzo en lanzarlo completamente al mercado. Para ello te sirven las Pruebas de Concepto (PoCs) o pruebas no físicas como un Mockup y los Pilotos cómo probar el producto en un laboratorio con simuladores de mercado. Una vez que hayas probado la idea es cuando construyes y preparas el lanzamiento del Producto mínimo viable (PMV o Minimum Viable Product (MVP)), es decir la versión mínima del producto pero que mayor impacto tiene a los clientes.
Sin embargo, ¿cuándo el “producto” es un modelo? y ¿el objetivo es que se ejecute de manera automática? ¿cómo distingo una PoC, un Piloto y un MVP del modelo?
Bueno, lo que yo te puedo decir es que como las nuevas ideas de producto, se requiere de tiempo y esfuerzo del equipo que la construirá y por lo tanto un costo. Por tal motivo uno debe probar el modelo de la manera más rápida y económica posible. Ahí es donde entran las Pruebas de Concepto o los pilotos. Una vez que ya has probado el modelo es cuando lanzas el MVP del modelo.
En Data Science puedes realizar Pruebas de Concepto a través de modelados en Excel con bases de datos descargadas en tu computadora o lanzando campañas digitales a cierto número de clientes y analizando la información de manera manual. Una vez que tienes probado que el modelo arroja los resultados esperados entonces, es cuando comienzas a construir tu MVP es decir, que el modelo funcione de manera automática, es decir que se ejecute sin intervención humana. Ahora bien, debes considerar que necesitas las principales fuentes de información que ya estén automatizadas, de lo contrario toca automatizarlas y eso impacta directamente en tu roadmap del modelo.
2.- Trasladar un dato de un lugar a otro, no es un “copy paste” del dato.
Para ejecutar los modelos que nos ayudarán a identificar insights relevantes, necesitamos la información que el modelo correrá y para ello se necesita esa información o dato ¿correcto? Sin embargo cuando eres el líder del equipo de data y expones la necesidad del dato ¿has escuchado que el Product Owner o el Stakeholder comenta “Pues nadamas tráete el dato de la otra base de datos.”? Si es el caso, entonces ese Product Owner o Stakeholder no sabe lo que implica trasladar un dato de un lugar a otro y entonces es a lo que me refiero que los interesados piensan que es un “copy paste” del dato. Como si se utilizará un Ctrl + C y Ctrl + V para solucionar la disposición del dato para posteriormente explotarlo. No está mal que no lo sepan, sin embargo, ahí es donde puedes orientarlo con estos tips.
Probablemente no implique el desarrollo de una funcionalidad completa, ni tome el mismo tiempo de acuerdo…, aunque tampoco es cuestión de segundos. Tienes que considerar actividades como accesos y permisos para entrar a la base de datos donde está el dato, si es una base libre es fácil, pero ¿si es una base restringida? Hay que justificar el porqué y para que se necesitan los accesos, así como quienes serán las personas asignadas de tu equipo para manipular el dato, solo así el dueño de la base de datos te dará acceso.
Otra cosa, ¿tienes la herramienta correcta para manipular el dato? Hoy en día puedes utilizar herramientas de big data visualization como Tableau, Google Chart, Datawrapper, etc. ¿Ya sabes dónde guardar el dato? Hay distintas formas de guardar tu información la primera es en tu PC, sin embargo, si estamos hablando de Big Data no creo que sea lo más eficiente. Existen diferentes modalidades como un data lake, un datawarehouse o en la nube ya sea privada, pública, híbrida o multi nube. De acuerdo a las necesidades de tu organización en un presente y en un futuro es la que debes seleccionar y considerar las implicaciones de su puesta en marcha.
3.- Antes de comenzar un proyecto de Data Science debemos:
Identificar las principales fuentes de información. Debes conocer de donde se obtienen las variables clave que se utilizaran en los modelos. En cuáles bases de datos las puedo encontrar así como asegurar que la información es certera.
Saber dónde están estas fuentes de datos. Con esto me refiero a los “fierros” o el hardware donde se guarda la información. En un nombre más técnico nos referimos a los servidores, los centros de datos, las computadoras personales, los enrutadores, los conmutadores y otros equipos. Y una pregunta relevante que te tienes que hacer es ¿voy a manipular el dato directamente de la fuente o voy a alojarlo en otro contenedor? Y si es la segunda opción ¿tengo la infraestructura para almacenar y analizar mi información de una manera eficiente?
Considerar quiénes son los dueños de las fuentes de información. No es lo mismo obtener el dato del INEGI que es una base de datos gratuita y abierta para todo el mundo a obtener la información del círculo de crédito que es una base de datos privada. O en el caso interno de las organizaciones, cuando tienes que ir con el equipo dueño de la base de datos y que gestiona todo lo relacionado a ella. Tienes que buscar la manera de que primero te den prioridad para que te puedan proporcionar el dato de una manera más rápida, pero es una labor de convencimiento que se tiene que realizar sí o sí y posteriormente coordinar cómo será la compartición de la información y los requisitos a cubrir, ya que muchas veces son equipos con el objetivo de gobernar los datos y tienen políticas internas para compartir la información.
Qué tipo de datos o información se obtiene de ellas. Es decir, si es información estructurada (clasificada, ordenada, etc.) o no estructurada (datos revueltos, puede haber datos basura entre ellos), porque de ahí puedes definir los primeros pasos a realizar con tu información. Si la información ya está estructurada es más fácil aprovechar sus beneficios, el detalle es cuando no, porque se tiene que pasar por un proceso de estructuración (identificar información válida que se necesita, ordenarla en filas y columnas para que se pueda leer y extraerla).
4.- No puedes aplicar / desarrollar analítica avanzada, sino tienes la información que trabajar.
A mi consideración, el tener un modelo de 1,000 filas ejecutado en un Excel y guardado en un computadora no es la esencia o el ideal de ejecutar Analítica Avanzada, IA o ML. Entiendo que para los primeros pasos como son las pruebas de conceptos o pilotos sean los más fácil de ejecutar, sin embargo no hay que quedarse con una visión corta. Los beneficios de tener y analizar Big Data solo los podemos obtener aplicando modelos que nos puedan dar insights relevantes del cliente debido a que están ejecutando de manera constante y aprendiendo los comportamientos del cliente con exposición directa, ya sea a través de un canal físico o digital.
Y si eres de las organizaciones que tiene mucha información repartida en distintos contenedores y que no estás aprovechando esa Big Data ¿qué estás esperando? Es una herramienta que no estás utilizando, es como tener una lavadora eléctrica guardada porque no sabes usarla o instalarla y lavas a mano que te toma más tiempo y desgaste, cuando para cumplir con tus actividades diarias estas necesitando lavar y secar más rápido.
5.- Es necesario un rol de traductor tanto para el entendimiento de negocio, como para el entendimiento de los equipos de desarrollo en productivo.
En la formación de equipos de data science hay un rol que te puede servir para sincronizar al equipo y tener una mejor comunicación que se pueda ver en los entregables del equipo cada review de sprint. Este rol es de traductor y es un rol que puede ser el mismo líder del equipo de data science o el data scientist o data analyst. Su principal función es comunicar de una manera sencilla al Product Owner y el Equipo de Desarrollo, para que entiendan tanto los descubrimientos de los modelos y la información analizada, como como se tiene que conectar ese modelo de forma operativa.
Imagínate el siguiente escenario, tú como Product Owner en una sesión donde estás solicitando un modelo que te ayude a recomendar productos altamente rentables en tu tienda digital. Tú dominas la terminología de negocios (ventas, rentabilidad, OKRs, visión del producto, roadmap, etc.), el líder del equipo de modelos te comienza a hablar sobre estadística, modelado, matemáticas aplicadas y estructuración de la información y el líder del equipo de desarrollo comienza a preguntar sobre la implementación del modelo de forma operativa.
Probablemente si eres un Product Owner experimentado, esto será papita para ti, de lo contrario comenzarás a escuchar por un lado al profesor de matemáticas y por otro un extraterrestre que habla Klingon. Porque mientras más te especialices en algo, es más complicada la comunicación con los especialistas de otras ciencias. A los integrantes de mis equipos les daba gracia cuando les decía, ya estás comenzando a hablar en klingon y no te está entendiendo el foro de la sesión (por las expresiones que veía en sus caras).
En estos momentos es cuando te puede ayudar un rol de traductor, que puede ser el líder del equipo de Data, un data analyst o el Product Owner. Esto ayudará a entender la perspectiva de las tres partes, comunicarlo de una forma que todos lo entiendan o fomentar la apertura de que cualquiera de las tres partes alce la mano y diga: “No entiendo, puedes explicar más a detalle sobre el tema”, solo así se podrá tener la misma visión y se podrá encontrar la mejor solución para sacar el proyecto adelante.
Si te ha servido esta píldora de información, no dudes en compartirla. También puedes escribirme para profundizar más en el tema que gustes sobre proyectos o equipos relacionados con Data Science a mi correo: [email protected].