Cuando se aborda un producto de datos con cliente siempre hay mucha incertidumbre: ¿Solucionará el problema? ¿Cómo sería mejor abordarlo?
Una estrategia para abordarlo es, al igual que se hace en el desarrollo de producto de software y arquitecturas, aplicar Agile, de tal manera que el cliente no perciba que se va virando a soluciones diferentes sin tener claro el camino, sino que vea que hay varios caminos y que la iteración se hace necesaria en la construcción productos de datos.
Los proyectos de ciencia de datos tienen sus fases, en este caso nos basamos en CRISP-DM, en las cuales el primer paso a dar es entender el negocio para poder comprender las necesidades del cliente, y aterrizar las expectativas. Una vez conocemos las necesidades de negocio, hay que entender los datos. El cliente puede querer hacer algo pero, para ello, hay que comprobar los datos que se tienen y la calidad de los mismos, lo que permitirá valorar si es viable o no (data understanding). Además, se hace esencial completar bien una fase para poder abordar la siguiente. Sin un dataset limpio y preparado no se puede pasar a una modelización.
Diagrama de proceso que muestra la relación entre las diferentes fases de CRISP-DM. Fuente: Wikipedia.
El objetivo de aplicar metodologías Agile a proyectos de datos es aterrizar en fases el proyecto completo, de modo que no se muestre la entrega de valor solo al final con el deployment, sino dar visibilidad al trabajo que se va haciendo durante el proceso y que esto ayude al equipo a tener una mejor visión del proyecto y al cliente una mayor satisfacción y mejores expectativas de la evolución y el resultado.
El 80% de los proyectos de ciencia de datos es exploratorio y el resto es atacar hacia una solución. Crear microtareas para poder romper las historias de usuario en tareas más pequeñas, permite establecer fases de consecución de objetivos más cortas y conseguir un proyecto más evolutivo.
No obstante, en este proceso también pueden asaltarnos dudas: ¿Dónde poner el goal del proyecto en cada sprint? ¿Cómo gestionar la incertidumbre en las fases iniciales ante el desconocimiento del potencial de los datos?
Y ante esta incertidumbre nos planteamos aplicar Agile de una manera no cerrada, sino basándonos en la mejora continua.
Es importante recordar que en este tipo de productos de datos el resultado no siempre es software funcionando, especialmente en la fase de Research, que es donde se va a realizar aprendizaje por ambas partes para entender lo que pueden ofrecer los datos y, en consecuencia, entender mejor el negocio.
El equipo
Los roles de en un proyecto de ciencia de datos no difieren mucho de un equipo Agile de desarrollo de software, añadiendo la particularidad de que el científico de datos debe estar en todas las fases del proyecto. El Data Scientist no debe tener su propio backlog al margen del equipo, sino que éste debe ser compartido e integrado para facilitar la interacción. Lo que sí se puede es trabajar con PBIs desglosados en checklist por tareas / perfil de modo que se facilite el trabajo y el entendimiento del proyecto.
Responsabilidades de cada uno de los perfiles de un producto de datos:
– Product Owner: es el máximo responsable y valida todo lo que sale de cualquiera de las fases de construcción del producto de datos procurando que el resultado esté alineado con negocio, pero no es un Agile Product Owner que prioriza y mantiene el backlog, ya que la naturaleza de éste tipo de productos alberga una gran incertidumbre que se irá despejando a medida que se avanza en las diferentes fases.
– Data Scientist: traslada las necesidades del Product Owner en forma de PBIs (Product Backlog Items), es el responsable de validar la calidad del dato que se trabaja y toma decisiones en relación a las prioridades de las tareas que deben ser abordadas.
– Backend: trabaja los datos para que estén disponibles de manera adecuada y ayuda en la construcción de la solución.
– Agile practitioner: trabaja para que la comunicación sea la adecuada y fluya la información, dentro de los principios y valores Agile, asegurándose de que el equipo tiene claro el objetivo común y mantiene el foco en las necesidades de negocio.
– Arquitecto: define la arquitectura en base a las necesidades del Data Scientist y se asegura de que es la mejor solución para cubrir el objetivo.
– SysOps: desarrolla la solución diseñada por el Arquitecto, implementándola con las mejores prácticas y con el objetivo de establecer la arquitectura más adecuada.
El equipo de datos debe trabajar como una única unidad y el Product Owner, especialmente en la fase de Research, no tiene la labor tan activa habitual de priorizar el backlog, sino que es el Data Scientist quien puede conocer mejor cómo tratar los datos. Sin embargo, sí debe estar disponible para alinear las decisiones del científico de datos con las necesidades de Negocio.
Para aportar valor de forma continuada, lo que es importante es acabar la fase de Research con un pequeño MVP que valide la viabilidad del proyecto. Así como en la segunda fase, también hay que iterar e ir programando entregables MVP, pero siendo conscientes de que no terminamos nunca de aprender de los datos, por lo que podemos descubrir cosas que no habíamos visto y el objetivo puede cambiar. Por eso, aplicar Agile en proyectos de datos nos ofrece la ventaja de aprovechar los cambios para enfocarnos en aportar el máximo valor posible de acuerdo al dataset del que disponemos.
Imagen: Unsplash | @kellysikkema
Deja tu comentario