Producto Mínimo Viable en proyectos Big Data

MVP_Basket

Producto Mínimo Viable en proyectos Big Data

Quien con monstruos lucha cuide de convertirse a su vez en monstruo. Cuando miras largo tiempo a un abismo, el abismo también mira dentro de ti.
F. Nietzsche “Más allá del bien y del mal”

Abordar un proyecto Big Data implica Big Challenges, todo es BIG en este nuevo paradigma

 

Por supuesto, contamos con grandes cantidades de datos, que requieren grandes infraestructuras de IT para almacenarlas. Sin olvidarnos del gran esfuerzo que implica el aprovisionamiento de estos datos, cada uno generado en diferentes silos de la empresa, con su propio formato, su granularidad, su mayor o menor estructuración y, la mayor parte de las veces, sin documentación sobre cómo se genera, periodicidad, etc. El reto de convertir DATA into KNOWLEDGE requiere, también, de un gran equipo de Data Scientist y de gran capacidad de computación para atacar, procesar y modelizar los inmensos datasets para dar respuesta a los objetivos del proyecto (porque los objetivos se han definido antes de lanzar el proyecto, ¿verdad?)


Adicionalmente, este tipo de proyectos están dotados de un componente estratégico dentro de las empresas, en muchos casos, yendo de la mano con procesos de transformación digital (1), lo que implica que no solo hay muchos ojos encima, sino también la participación de un número elevado de stakeholders, interesados y beneficiarios en el mismo que, por norma general, no están acostumbrados a trabajar juntos.

La suma de todos los elementos anteriores, convierte, por tanto, la gestión del proyecto en un gran reto que requiere de las mejores capacidades que un Project Manager pueda tener, destacando, por encima de todas, las siguientes (según el estudio Agile Project Management Approach and it use in Big Data Management 2):

– Relación con clientes (del proyecto)

– Gestión de personas y comunicación

– Software funcional

– Procesos y herramientas

– Capacidad de reacción a cambios

– Ajustarse al plan

 

Cabe destacar que las capacidades más valoradas para la gestión de este tipo de proyectos coincidan con los principales puntos del Manifiesto Agile (3) lo que nos puede empezar a dar pistas de como comenzar a abordar la capa de gestión de proyectos Big Data.
En el desarrollo de un proyecto de alta complejidad, se suele contar con un dimensionamiento temporal a medio-largo plazo y, aún así, es muy común que se vaya incurriendo en retrasos y sobrecostes, fruto de la propia naturaleza del proyecto y que, como Project Manager, hay que ir gestionando. Enfoques más tradicionales de gestión tienden a penalizar las últimas fases del proyecto con la idea de contener los sobrecostes cuando se ha perdido la posibilidad de seguir aportando recursos. Esto impacta de forma muy especial en los proyectos de Big Data, puesto que, dentro del estándar de fases del proyecto, las últimas corresponden con aquellas en que se genera el aporte de valor (bajo el punto de vista de quien escribe) y están asociadas a la generación de modelos e insights, testeo y despliegue de resultados.

 

El foco de muchos proyectos Big Data ha sido montar infraestructuras Big Data (con la consiguiente inversión de grandes cantidades de recursos y tiempo), se trata ahora de explotarlas.

 

La búsqueda de un entregable final, robusto, completo y que satisfaga las necesidades de los beneficiarios del proyecto, a la par que cubre los objetivos, suele ser uno de los principales factores de fracaso en todo tipo de proyectos, especialmente en proyectos Big Data y, precisamente, por los puntos tratados hasta ahora. Introducir una mentalidad (observese que no se habla de metodología) Agile puede ser una forma efectiva de reducir el riesgo de no alcanzar los objetivos planteados o no dar respuestas a las necesidades que motivaron el inicio del proyecto.
Probablemente, una de las acciones más importantes a incluir, y quizás una de mis siglas favoritas, consistiría en definir un Producto Mínimo Viable (4) (MVP: Minimun Viable Product) que responda a las necesidades más urgentes o importantes que se han planteado.
Las principal ventaja de construir buenos MVP’s es que van a permitir acortar plazos de entrega de resultados (aunque todos los stakeholders, promotores, etc. del proyecto han hecho un voto de obediencia a la planificación inicial, los desarrollos temporales a largo plazo generan dudas, cansancio, necesidad de resultados, etc. ) y, sobre todo, que a base del feedback que genere el MVP y las sucesivas iteraciones sobre el mismo, se va a acabar generando un entregable final más adecuado a las necesidades reales y actuales de los beneficiarios  (recordemos que, hace ya tiempo, el proyecto arrancó, las necesidades o circunstancias actuales pueden ser “algo” diferentes, pocos mercados tienen ciclos de estabilidad superiores al medio plazo, las fuentes de datos crecen y cambian constantemente, etc.). Esta última afirmación no significa que un MVP tenga que alterar el alcance inicialmente definido, con un enfoque adecuado, simplemente lograremos afinar mejor los resultados.
MVP

En base a lo anterior, me aventuro a compartir, de tú a tú, algunas reflexiones sobre MVP en proyectos Big Data:

– Definir un MVP y, por tanto, modelos “sencillos” suelen resolver la mayor parte de las necesidades planeadas al tiempo que permiten adivinar los riesgos y complicaciones que pueden plentearse a futuro (con un producto más sofisticado). Sin duda, lo atractivo sea usar Deep Learning, lo efectivo aplicar Machine Learning y lo primero que haya que hacer sea buscar correlaciones simples. Elige sencillez, la complejidad suele aparecer por sí misma.

Intenta definir un MVP y ponlo en producción tan pronto como puedas; independientemente del grado de avance del proyecto global. NO olvides la pirámide de la imagen, no se trata de sacar un producto a medio hacer o con pocas funcionalidades, se trata de sacar un producto que tenga la funcionalidad que resuelva un problema y lo resuelva adecuadamente.

– Otro deseable de un MVP es que se haya construido en base a una priorización de aquellas funcionalidades que tengan un mayor impacto de negocio, de esta forma, vas a conseguir la atención de los beneficiarios del proyecto y su implicación con el desarrollo del mismo.

Busca la colaboración de todos los implicados para la definición del MVP pero, sobre todo, busca su feedback para seguir desarrollándolo. Soy un convencido de la inteligencia colectiva (siempre que en la colectividad exista inteligencia, por supuesto) y de que el trabajo colaborativo genera mejores resultados que equipos especializados y departamentados. No se trata de que el Data Scientist supervise el proceso ETL, ni que el Data Engineer programe en R, se trata de poner lo mejor de cada cual para obtener un resultado mejor que haciéndolo por separado. Si logras que fluya la comunicación y generas espacios de colaboración, tu MVP estará bien definido y, sobre todo, crecerá sano y fuerte.

– El caso de estudio al que puedes acceder en este enlace (5) puede ser un buen ejemplo de aplicación de un desarrollo Agile de un MVP en un proyecto de Big Data Analytics y, sin duda, ilustra los puntos desarrollados anteriormente.

 

En definitiva, las características de los proyectos de Big Data, la necesidad de ir ofreciendo resultados a los beneficiarios del mismo y el aspiracional de desarrollar y consolidar espacios de colaboración entre diferentes stakeholders, generan una dinámica de trabajo idóneo para la inclusión de la mentalidad Agile en su gestión y, concretamente, para la definición de un Producto Mínimo Viable (MVP).  Te invito a compartir tus reflexiones y experiencias al respecto.


Fuentes y referencias

 

(1) El 55% de los directivos considera la implantación de Big Data decisión estratégica en su proceso de transformación digital. Resultados Barómetro DIVISADERO sobre el Estado de Madurez Digital de las Empresas Españolas (http://www.divisadero.es/barometro-divisadero-2017-madurez-digital-empresas-españolas)
(2) Agile Project Management Approach and it use in Big Data Management (http://www.sciencedirect.com/science/article/pii/S1877050916303052)
(3) Manifesto Agile (http://agilemanifesto.org/)
(4) Blog y Foto: How To make your MVP viable ( https://www.theodo.fr/blog/2016/10/how-to-make-your-mvp-viable/ )
(5) Caso de estudio de uso de Agile en proyecto Big Data Analytics (http://www.inspearit.com/en/blog-lean-agile/a-case-study-using-agile-method-for-big-data-analytics-projects/)

2 Comments
  • David Fernández Incio

    18 octubre, 2017 at 10:25 AM Responder

    Muy buen artículo. Y muy centrado en la problemática más importante de los proyectos Big Data. No son los recursos dedicados, ni la infraestructura, ni la calidad del personal, es la gestión del proyecto. Y estoy de acuerdo en que el momento peor tratado es el de finalización.

    Muchas veces el equipo fascinado por la tecnología que usa se convierte en esa tecnología como Nietzsche y el abismo. Y se olvidan de que es una herramienta para crear valor al cliente.

    Con mi experiencia, yo había llegado a una metodología similar a la de MVP de Jose Manuel. Yo denomino a esta metodología “Luz al final del Tunel”. Es decir, lanzarse lo más rápido posible a tener algo en producción e ir haciendo mejoras desde entonces según los recursos y tiempo disponibles.

    • Jose Manuel Glez. Corral

      18 octubre, 2017 at 12:19 PM Responder

      Gracias por tu comentario David. Me parece muy descriptivo el nombre de tu metodología. Luz al final del tunel es algo que muchos proyectos necesitan 🙂

Envíanos tu comentario

tres + 18 =

¡Suscríbete a nuestra newsletter mensual Stay Sharp!

Para más información

CONTÁCTANOS