Continuamente encontramos publicaciones que incluyen términos como Digitalización, Big Data o Data Science. Y en contextos de negocio, economía, marketing, etc. El motivo es que los negocios cambian cada vez con más rapidez. También ha cambiado la manera en la que se relacionan las personas. Ya sea para colaborar en grupo o, simplemente para adquirir bienes y servicios.
Hace poco escuché que el 20% de la facturación de los restaurantes proviene ya del servicio de comida a domicilio, solicitado típicamente a través de apps. Seguro que los restaurantes han tenido que cambiar sus procesos en poco tiempo para adaptarse. Hay algo todavía más importante: Los propietarios de las apps, e incluso Google con su Android y su Gmail, pueden identificar clientes individuales, geolocalizarlos y analizar sus patrones de compra (hablamos de Data Analytics en general). Con ello podrán conocer mejor los gustos de los clientes, para ajustar convenientemente la oferta, y hasta promocionar otros productos que nada tienen que ver con la restauración. La gestión de proyectos también ha tenido que adaptarse a esta realidad empresarial: Los cambios son muy rápidos, las tecnologías se complican y requieren la colaboración de equipos multidisciplinares, a veces en remoto, el número de datos crece exponencialmente, son poco estructurados y externos a la empresa (por ejemplo opiniones de redes sociales), etc.
La gestión de proyectos tecnológicos durante muchos años ha sido (y sigue siendo) lo que denominamos predictiva, esto es, trata de ofrecer una estimación sobre el alcance, plazo, coste y calidad del proyecto (que suelen implicar restricciones contrapuestas, por ejemplo, más calidad puede suponer un incremento de costes y tiempos). De esta manera, la gestión predictiva observa sobre todo desviaciones reales o previstas sobre la planificación, y toma decisiones correctivas o preventivas con objeto de restablecer el equilibrio. Para poder hacer estimaciones realistas, es necesario que en fases tempranas del proyecto se conozcan con bastante detalle los requisitos y objetivos del mismo. Si bien se puede abordar por fases, la planificación irá cambiando a medida que se conozcan los detalles. La ventaja principal es que a lo largo de todo el proyecto (o al menos durante la fase que se ha planificado en detalle), se puede saber, siempre con cierto margen de error, si se van a cumplir o no las restricciones. La figura del Project Manager es la encargada de tomar decisiones, normalmente consensuadas con diferentes interesados, y de realizar el seguimiento del proyecto. La literatura sobre este tipo de gestión es muy extensa, aunque sin duda la organización PMI (Project Management Institute) y su publicación PMBOK (Project Management Body of Knowledge) son los estándares de referencia básica. PMI ofrece la certificación PMP, que estoy orgulloso de disponer desde 2.009, cuando no era tan conocida en España. También dispongo de la certificación de Scrum Master desde 2.014.
Cualquier método de gestión de proyectos conlleva cierta gestión de cambios y riesgos como pilares básicos. En el caso de gestión predictiva, por ejemplo, los cambios van a alterar alguna de las previsiones sobre alcance, tiempo, coste y calidad. Así pues, se recomienda aplicar alguna política al respecto, para priorizar unos cambios y rechazar otros, y requiere evaluar el impacto sobre la planificación. Puede haber hasta un comité de cambios que gestione los de mayor calado. No gestionar correctamente los cambios, como cuando se introducen cambios de alcance sin ningún tipo de autorización (conocido como scope creep), deviene en retrasos, sobrecostes, y entregables que los usuarios rechazan. Es decir, proyectos que acaban fracasando por no alcanzar sus objetivos. En ocasiones el Project Manager toma decisiones sin contar con su equipo. A veces acapara excesivo poder sobre él mismo. Lógicamente, el equipo técnico acaba viendo al Project Manager como una especie de capataz, que exige el cumplimiento de plazos… Pero que a la vez toma decisiones cuestionables de forma unilateral, incluso de índole técnica. Debo aclarar que el PMBOK no ampara este tipo de gestión, y establece diversos mecanismos para que esto no ocurra. No obstante, la realidad es que el trabajo bajo presión por cumplir restricciones, y un Project Manager con falta de experiencia, o quizás llevado por la cultura empresarial, acaban derivando en lo expuesto anteriormente.
Enlazando con el inicio del artículo, el negocio quiere que los entregables del proyecto reflejen los cambios solicitados lo antes posible, porque el mercado se lo exige. Por otro lado el equipo técnico reclama no ser tratado como simples productores de software (como recursos o máquinas), sino que demanda un ámbito de autoridad sobre la parte técnica, la planificación y el valor para el negocio. En este contexto se acuña el término de “agilidad” o “agile”, así como el de la gestión adaptativa frente a la predictiva. Pero no hay que confundir agilidad con rapidez de producción, el equipo técnico necesita tomarse su tiempo para entregar una solución de suficiente calidad. Si hay muchos cambios, el proyecto se alargará (las restricciones contrapuestas siguen ahí). Agilidad se refiere a aligerar los procesos de gestión, especialmente el de cambios, e incorporarlos como algo no solo inevitable sino positivo para el proyecto. En visiones provenientes de una interpretación extrema e inadecuada del PMBOK, la mayor parte de los cambios se consideraban como riesgos negativos, y por lo tanto a rechazar siempre que fuera posible. Se llegaba incluso a “castigar” al equipo técnico por querer abordar cambios, ya que es como reconocer que se habían cometido errores.
Un proyecto de Ciencia de Datos, sin ir más lejos, tiene buena parte de experimental. De inicio no se sabe muy bien si se encontrará un modelo adecuado, ni lo que puede costar hacerlo. Los usuarios de negocio no son capaces de definir requisitos detallados al principio. Y podemos dar por seguro que, antes de encontrar un buen modelo, tendremos que probar y descartar otros. Los sucesivos refinamientos de modelos ya incluyen el cambio como un elemento fundamental y beneficioso. La figura de un Project Manager obsesionado por cumplir una planificación rígida tiene poco sentido, y en su lugar una figura que ayude a superar momentos de bloqueo emerge como algo más útil. Como contrapartida, son proyectos donde el riesgo de exceder costes y tiempos aumenta, y es algo a asumir. No obstante, son necesarias prácticas para limitar el riesgo, como las que comenté en un artículo anterior. Hemos llegado al punto donde buenas prácticas de gestión ágil como SCRUM nos permiten articular ese enfoque adaptativo. En próximos artículos espero seguir profundizando sobre los beneficios del enfoque adaptativo para los proyectos de Analytics, Big Data, Ciencia de Datos y Business Intelligence. Y cómo Scrum necesita particularizarse en estos casos. Pero, para terminar, quiero aclarar otro punto típico de confusión: El PMBOK permite también gestión adaptativa, y sigue más vigente que nunca. PMI hace tiempo que ofrece certificaciones sobre agilidad. Los enfoques predictivo y adaptativo conviven dentro de los proyectos reales, y se busca un equilibrio entre cumplir con restricciones y responder a los cambios.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
Artículos anteriores estuvieron dedicados a la lista de producto (Product Backlog). En esta ocasión quiero comentar sobre el seguimiento dentro del Sprint, algo que también forma parte de la guía de Scrum.
Lo primero que hay que considerar es que las técnicas ágiles están pensadas para simplificar las tareas de gestión. Es así puesto que algunas recaen sobre el equipo de desarrollo, y siempre se prefiere que estén desarrollando antes que reportando el estado del proyecto. Todavía más crítico, el foco del seguimiento se centra en entender lo que queda para conseguir el objetivo del sprint, y en su caso modificar las estimaciones.
Sin embargo, no se pretende analizar cuánto tiempo se ha invertido en lo ya desarrollado, un hecho bastante desconcertante para quienes estén acostumbrados a las metodologías predictivas. Esto es porque Scrum no se pensó especialmente para ahorrar costes de fabricación ni tiempos de desarrollo (al menos no medidos de la forma tradicional), sino para entregar productos más adecuados a las necesidades cambiantes del negocio. Es decir, no debemos asociar ágil con veloz ni con barato, sino con productos de mejor calidad, tanto objetiva como subjetiva, y con mayor capacidad de incorporar cambios sobre la marcha. Por eso tampoco tiene mucho sentido realizar una contabilidad de horas por técnico y tarea, ya que esto inhibe la introducción de cambios, así como el trabajo en equipo.
Enlazando con lo expuesto en el artículo de planificación de sprints que publiqué anteriormente, en proyectos de Big Data, Analytics & Bussiness intelligence es el equipo de desarrollo quien estima lo que es capaz de terminar en un sprint dado, y esto lo hace mediante algún sistema de puntuación para cada ítem que acaba dentro del sprint backlog. Es común acabar convirtiendo la puntuación en horas, pero con el riesgo de caer en la contabilidad clásica de costes.
La utilidad no es tanto la conversión en horas, sino entender que un ítem valorado como 10 puntos requiere el doble de esfuerzo (tiempo supuesta una dedicación del 100%) que uno valorado en 5 puntos. Y también podemos conocer el histórico de puntos entregados en cada sprint, a medida que van sucediendo sus ciclos, para establecer una velocidad media. Esto permite ir afinando más el compromiso de entrega que alcanza el equipo de desarrollo durante la planificación del sprint, y también hacerse una idea de lo que supone el product backlog restante en cuanto a tiempo, entendiendo que es algo que irá evolucionando.
Hay varias técnicas para visualizar en medio de un sprint cómo nos encontramos respecto a la planificación. Sin duda, el artefacto más conocido es el gráfico de burn down. Aquí tenemos un ejemplo de gráfico sencillo:
En el eje horizontal aparecen los días hábiles del sprint en un proyecto de Big Data, en este caso 20, y la línea verde representa la previsión de avance diaria. En el eje vertical en este caso figura el esfuerzo restante en días (agregado para todo el equipo), aunque mi recomendación es representar mejor la valoración en puntos. Al inicio del sprint conocemos la estimación total de los puntos a terminar, e idealmente al final del sprint se habrán entregado todos ellos, por lo que la línea verde es una recta que acaba en cero para el eje vertical.
Mientras, la línea roja representa el avance real, e insisto una vez más, no como tiempo real dedicado sino como valoración de puntos de las tareas terminadas conforme al “definition of done”. La línea roja por encima de la azul nos advierte de un retraso respecto a la planificación. Por ello, es el propio equipo técnico quien debe decidir si es posible acelerar el ritmo de desarrollo, o bien considerar reducir el alcance del sprint en el supuesto de que ello no amenace el objetivo del mismo.
Aunque el gráfico de burn down resulta útil, puede inducir a error de interpretación cuando se realizan cambios de alcance durante el sprint, y ya sabemos que hay que contar con ellos si el objetivo lo requiere. Por eso me parece necesario usar también el gráfico de burn up. En la siguiente imagen se aprecia la diferencia:
Pensemos en un proyecto de Big Data donde a mitad del sprint se ve necesario introducir una nueva tarea no planificada al inicio, o bien se trata de una tarea cuya estimación se ha tenido que aumentar al ir conociendo más detalles funcionales. En el burn down podríamos volver a dibujar la recta planificada, que resultará más inclinada si es que mantenemos las escalas originales. Pero el gráfico no nos dice en qué momento se ha producido este cambio.
Viendo ahora el gráfico de burn up, la línea de trabajo planificado total pasa a ser una recta horizontal al inicio del sprint. Si hay cambios de valoración se van a poder visualizar como saltos en dicha línea. La otra línea ya no es el trabajo pendiente, sino el completado hasta el momento, y se espera que al final del sprint alcance la línea del trabajo planificado total. Si no se alcanza, al menos se puede tener una idea de hasta qué punto ha sido el cambio el que ha provocado esta situación.
La lección práctica es que parte del aprendizaje de Scrum consiste en saber cómo cambia la planificación durante el propio sprint (saltos en la línea horizontal), y planificar los siguientes sprints con suficiente holgura como para absorber este tipo de cambios inevitables. Pero, cuidado, no se trata de abrir la puerta a cualquier cambio dentro del sprint, estos cambios tienen que estar justificados siempre conforme al objetivo, en caso contrario el equipo de desarrollo se va a ir desentendiendo del mismo.
Si habéis seguido todos los artículos anteriores, y queréis profundizar un poco más allá de la guía de Scrum, os sugiero este otro documento más detallado.
José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data Analytics de datahack.