El concepto de “empresa líquida” se lo debemos a la deriva de los libros de Zygmunt Bauman, Premio Príncipe de Asturias de Comunicación y Humanidades en 2010.
En el mundo que describe Bauman todo es líquido, incluso los títulos de sus novelas (Vida líquida, Maldad líquida, Amor líquido, Tiempos líquidos, Miedo líquido, Modernidad líquida…). Para él, todo es líquido, su principal idea es que hoy en día se temen las relaciones duraderas en general, todo tipo de relaciones.
Las empresas se hallan en un contexto en donde cada vez es más difícil prever situaciones futuras. Por ello, hay que aplicar nuevas técnicas que sean flexibles a los cambios inevitables e irreversibles que se producirán en distintos plazos.
Las empresas liquidas surgen como resultado de la transformación física de las estructuras organizativas funcionales de toda la vida, hieráticas, en definitiva, de las que son “como siempre”.
Una empresa líquida es una organización capaz de formar equipos multidisciplinares en función de cada proyecto, para deshacerse al terminarlo y volver a armarse, sin pausa y con las variaciones necesarias para empezar el siguiente proyecto.
Estamos en una era en la que nos comunicamos de diferente manera, quedamos en los bares de distinta manera, nos enteramos de las cosas de distinta manera, nos relacionamos de distinta manera, compramos a través de canales que hace muy poco no existían, nos divertimos a través de plataformas muy nuevas, hablamos con nuestros hijos por mensajes de texto o voz…
En definitiva, si los clientes y todos los stakeholders se comportan de distinta manera… ¿Por qué nuestros empleados tienen que relacionarse con la empresa “como siempre”? ¿Y por qué los productos o servicios han de diseñarse “como siempre”, por qué el trabajador ha de ser el “de siempre” y los equipos los “de siempre”? ¿Por qué la información que ahora se comparte, fluye y es trasparente ha de tratarse “como siempre”? La innovación surge desde cualquier área y desde cualquier persona…
Los sólidos “de siempre” se está desdibujando. Las empresas tienden a ser más líquidas. Los equipos no tienen por qué ser “siempre” los mismos: cada proyecto es independiente y distinto. ¿Por qué nuestros hijos están hiperconectados y nuestras empresas no han de estarlo. Lo nuevo de ayer, mañana ya no es más que lo “de siempre”.
Una empresa líquida supone ir más allá en la concepción de los negocios, de los equipos, de los clientes y por supuesto de los trabajadores, que es posible solo sean colaboradores en un único proyecto (o en varios). Supone trabajar con un compromiso y con una audacia que, lejos de ser un reto, es una solución para el desarrollo de proyectos empresariales. Y desde luego da mucha más libertad
Las empresas no cambian convirtiéndose en otras empresas diferentes, solo se transforman. Y son las personas las principales palancas de esa transformación.
El concepto de empresa líquida nos permite:
Además, la empresa líquida supone una cultura de proactividad y de multifuncionalidad porque, como trabajador de una empresa, un cambio de proyecto da la libertad de empezar de cero siendo mucho más creativo.
El entorno ya ha cambiado, nos demos cuenta o no. La empresa, por lo tanto, ha de cambiar. Convicción o necesidad, da igual. El cambio es una realidad.
Bauman habla de organizaciones líquidas dentro de una sociedad líquida, ¿estamos preparados?... Nuestros hijos si.
En DHSEED somos conscientes de que orientar una compañía hacia la digitalización y el Big Data supone un proceso complejo de realizar. Por ello, acompañamos a la empresa en ese proceso, ya que ofrecemos consultoría orientada a la transformación digital; somos headhunters especialistas en la evaluación, búsqueda y selección de perfiles de IT, Big Data y digital.
Hablamos de Recursos Humanos, de cuidado al empleado que trabaja en equipo y, en definitiva, de eficiencia en el empleo y gestión de grupos. Mas allá de la veracidad de los hechos de la película, y de lo enorme y grandioso de la música de un grupo que hizo historia desde muy pronto, en Bohemian Rapsody, en la historia y filosofía de Queen, podemos descubrir grandes lecciones para aplicar sobre la gestión de equipos.
Aunar fuerzas, identificarse con el objetivo, hacer que todos los esfuerzos se centren en perseguir la misma meta, es la clave de la sinergia, del trabajo común, de poder tocar el éxito que uno a uno no hubieran podido alcanzar. A pesar del gran protagonismo de Freddie Mercury, en Queen, todos los miembros de la banda eran grandes músicos, todos eran compositores, todos aportaron algo brillante en todas las canciones. Perseguir la gloria común y compartida fue lo que los llevó a lo mas alto. Cuando abandonaron el objetivo común, el éxito de cada uno de los miembros por separado fue incomparable al de todos ellos juntos.
Buddy you're a boy make a big noise
Playin' in the street gonna be a big man some day
You got mud on yo' face. You big disgrace
Kickin' your can all over the place
Singin'
We will, we will rock you
Hacer de tu objetivo algo que suponga el perder el miedo a lo desconocido, poder defender lo innovador, a pesar de los “que llevan toda la vida haciendo lo mismo”, a pesar de los “esto siempre se ha hecho así”. Tener la personalidad y el coraje de decir que no a los que no estén alineados con el objetivo, a los que no entienden, a los que se miden por patrones antiguos, a los que tienen miedo. Todo ello basado en una gran transparencia y comunicación entre los miembros, lo que hace que todos puedan ser portavoces sin importar
One dream, one soul,
One prize, one goal.
One golden glance of what should be.
It's a kindofmagic.
Freddie Mercury, desafiando todo estereotipo, y complementado con el resto de Queen, desata un universo innovador, arriesgado, transgresor y revolucionario. La frase del cartel de la película original es “fearless lives forever”.
Oh you gonna take me home tonight
Oh down beside that red fire light
Oh you gonna let it all hang out
Fat-bottomed girls you make the rocking world go round
En el cantar, en el escribir, en el desafinar, en la forma de hacer música, en el cómo, en el cuándo y en el porqué , con gran respeto por el trabajo de los otros, por sus personas, por sus familias, por sus aspectos….
I see a little silhouetto of a man,
Scaramouche, Scaramouche, willyou do the Fandango?
Thunderbolt and lightning,
Very, very frightening me.
(Galileo) Galileo
Cuando la búsqueda de la gloria personal se impone, se acaba la magia, se acaba la comunicación, la confianza y el compañerismo. Ahí se pasa a otro estado en el que es muy fácil perderse, y ya no tienen sentido el equipo, los objetivos o el trabajo común. En este caso, la separación y el tocar fondo abren al diálogo, a poder pedir perdón y a la reconciliación, dando paso de nuevo a la magia
I've paid my dues. Time after time.
I've done my sentence
But committed no crime.
And bad mistakes‒I've made a few.
I've had my share of sand kicked in my face,
But I've come through.
We are the champions, my friends
Tras la reconciliación y sin disfraces, sin maquillaje, sin parafernalia, solo cuatro músicos tocando en camiseta y disfrutando de estar juntos, llega la mayor gloria, las voces que callan, aquello que aún recordamos
I have spent all my years in believing you
But I just can't get no relief, Lord!
Somebody, somebody
Can anybody find me somebody to love?
En DHSEED somos conscientes de que orientar una compañía hacia la digitalización y el Big Data supone un proceso complejo de realizar. Por ello, acompañamos a la empresa en ese proceso, ya que ofrecemos consultoría orientada a la transformación digital; somos headhunters especialistas en la evaluación, búsqueda y selección de perfiles de IT, Big Data y digital. Para más información pincha aquí.
Tras haber ido comentando sobre los roles y las reuniones de Scrum, como se puede ver en el artículo anterior, continúo con las definiciones y artefactos que se usan a lo largo de todo el ciclo de Scrum. En concreto, hoy trataré el Product Backlog. Recuerdo que una lectura fundamental para el que se quiera iniciar en este marco de gestión es la guía de Scrum, que he tomado como base para estructurar la presente serie de artículos.
Viene a representar la hoja de ruta del producto, siendo el Product Owner el principal responsable de la misma. En concreto es fundamental que esté convenientemente priorizada según el valor aportado al negocio (posiblemente ponderado conforme a criterios de coste o esfuerzo), ya que en cada sprint se eligen preferentemente los elementos de mayor prioridad para poner el foco en su construcción.
La lista de producto está en continua evolución, hasta que el producto deje de tener sentido de negocio. Así, la visión tradicional de un proyecto cuyas condiciones de finalización son bien conocidas desde el inicio se transforma en una especie de proyecto continuo donde en cada sprint se va decidiendo lo que hacer en el futuro.
Ya podemos imaginar que las métricas típicas para medir el éxito del proyecto (desviaciones entre lo previsto y lo real a lo largo del proyecto completo), no tienen demasiado sentido en un marco tan cambiante y de un futuro muy difuso a largo plazo. Tampoco es sencillo acordar contratos a precio cerrado y fecha de entrega pactada, ya que necesariamente el proveedor tiene que limitar el número de cambios en ese marco. Esto no quiere decir que renunciemos a ciertas medidas, como la de la velocidad del sprint, y sobre todo a la del valor de lo entregado y la consecución del objetivo del sprint, pero el éxito de scrum requiere una gestión muy ligera.
Hay que tener muy claro que Scrum no está especialmente pensado para el ahorro de costes de producción, sino para que los costes (asumidos a lo largo del ciclo de vida del producto) sean convenientemente invertidos en desarrollar un producto valioso. Tampoco es buena idea mantener un sistema de control de tiempos de técnicos y tareas individuales, aunque solo sea porque amenaza el trabajo en equipo con una serie de objetivos comunes.
Otro aspecto crítico es que la lista debe ser única para un producto dado, incluso si participa más de un equipo de scrum. De esta manera resulta ser una verdadera hoja de ruta, en vez de un conjunto de peticiones de usuarios que realizan cada uno de forma independiente. Así el rol del product owner es también el de coordinador de usuarios y otros interesados, elaborando una lista representativa, coherente y priorizada, de las características que debe tener el producto.
Lo habitual es que los elementos más prioritarios aparezcan más desglosados, y por ello con estimaciones (esfuerzo, riesgos, complejidad) más fiables realizadas por el equipo de desarrollo. Recuerdo que esto se va haciendo en las reuniones de refinamiento de la lista de producto, y también en las de la planificación del inicio del sprint, aunque realmente se puede hacer en cualquier momento en que sea necesario.
El desglose tiene que llegar al menos hasta el nivel en el que los elementos pueden implementarse (terminarse) en un único sprint, de otra manera nunca podrían ser elegidos. Se deduce que es mala práctica conformarse con elementos menos desglosados cuando hay que abordar la reunión de planificación del sprint. También al flexibilizar scrum para trabajar con elementos donde se sabe que no se van a poder completar en un único sprint, algo que precisamente menciono por lo común que resulta.
Como lecciones prácticas, quiero aclarar que la lista de producto no es solo una lista de funcionalidades para negocio, aunque sí que la mayor parte del esfuerzo debería recaer sobre las mismas. Pero también tienen cabida tareas técnicas como la reestructuración del código, la formación de equipo, la investigación de nuevas técnicas, la mejora del tiempo de respuesta, etc. Teniendo potestad el equipo técnico para incluir elementos de este tipo dentro de la lista.
Esto es especialmente relevante en el contexto de los proyectos de analítica, Big Data y BI. Debemos contar con los consabidos problemas de calidad de datos. Estos exigen tareas específicas para tratarlos, sin que a veces se pueda poner algo concreto a disposición de los usuarios en un entorno de producción. En cambio, sí que podemos pensar en prototipos, ciertas entidades mejor definidas, etc., donde los usuarios tienen una responsabilidad continua respecto a la validación y las pruebas.
También necesitamos reservar tiempo para la investigación de nuevas tecnologías, porque quizás tengamos que probar varias de ellas, realizar diferentes modelos estadísticos antes de dar con uno suficientemente bueno, etc.
En resumen, no siempre se puede entregar una novedad significativa del producto en cada sprint en términos estrictamente funcionales, y por ello hay que saber buscar un equilibrio entre las entregas frecuentes y los aspectos que tienen más que ver con la calidad técnica.
A veces se considera un sprint especial cada cierto tiempo para abordar tareas que no están estrictamente asociadas a la funcionalidad, incluyendo el sprint 0 del que ya comenté en otro artículo. Pero no conviene tomar decisiones de gestión simplemente para reportar un mejor dato de velocidad. El rey es el producto, y esto incluye necesariamente tareas orientadas a asegurar la calidad del mismo, que podemos considerar prácticamente continuas, aunque puedan parecer un hándicap para la velocidad.
Me viene a la mente el interesante concepto de “deuda técnica”. Sin ser muy riguroso en la definición, diré que entregar software fabricado de manera muy rápida pero sin preocuparse de su calidad, es como haber recibido un préstamo, que nos ha permitido cumplir con un compromiso. Pero luego toca devolver los intereses, pensemos en posibles incidencias que hay que reparar de manera urgente, mantenimientos más costosos, etc. Y si los intereses empiezan a ser inabordables, tendremos que devolver todo el capital, o bien rehacer el código desde cero.
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.
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.
Avanzando sobre el contenido de la guía de Scrum.
Se trata de una breve reunión de coordinación al principio de cada día, y considero que es un evento especialmente importante para el funcionamiento de Scrum. Son los miembros del equipo de desarrollo del proyecto de Big Data, Analytics o Business Intelligence, que se supone autoorganizado (no es una reunión de reporte a un jefe de proyecto), quienes intervienen en la reunión. Cada miembro responde a tres preguntas clave:
Básicamente es el momento de saber, con cierta autocrítica, si se ha podido conseguir o no el grado de avance esperado, pero centrándose solo en un día. Por ello es fundamental que no se perciba como una reunión de reporte gerencial. Esa circunstancia incentiva el ocultar los posibles problemas o cambios ocurridos.
Hablamos de un punto de alineación entre el estado real del proyecto y el plan vigente. Recordemos, si el objetivo del sprint requiere cambios, es el momento, no habrá penalizaciones por ello. Quizás sea necesaria cierta replanificación, pero no es el objetivo de la reunión diaria. Lo que se recomienda es que haya una reunión posterior, donde se pueda entrar en más detalle, y donde posiblemente haya miembros que no tengan que asistir. De hecho, Scrum entiende que se necesitan más reuniones de las descritas, lo que marca la guía son las reuniones que considera obligatorias.
Para mí es la pregunta clave de un marco de gestión adaptativa. Puede ser que hayan aparecido incidencias inesperadas, que la planificación fuera muy optimista, que exista dependencia entre tareas incompletas, que falten conocimientos técnicos, que surjan malentendidos, etc. Un equipo autoorganizado tiene que aprender a solventar (adaptarse) a este tipo de bloqueos, pero se reconoce la gran dificultad de lograrlo.
En teoría es el Scrum Master quien ayuda a superar posibles bloqueos. Sin embargo, por mi experiencia en data science, y aunque puede ir en contra de los principios ágiles, a veces es necesario que un perfil más directivo priorice ciertas tareas, consiga más recursos, coordine diferentes equipos de Scrum, etc. Siempre que no sea con intención de penalizar errores, ni de realizar microgestión, a mí me parece admisible. Idealmente este perfil directivo no asiste a la reunión diaria, pero se ofrece a colaborar con el equipo después de la misma.
Aunque en la guía se menciona como un proceso continuo, yo creo que tiene entidad suficiente para establecer reuniones específicas. Recordemos que inmediatamente después de finalizar un sprint comienza el siguiente, con la reunión de planificación.
La idea es que durante el sprint actual, sin duda enfocado a trabajar sobre la lista de elementos del sprint en curso, se pueda reservar una pequeña parte del tiempo para trabajar también con la lista de producto (preparando futuros sprints). En concreto estamos hablando de detallar más la lista de producto, reunirse con algún stakeholder si procede, sin duda también con el Product Owner. De esta forma, ir entendiendo mejor las necesidades de los usuarios. Igualmente se pueden anticipar otros prerrequisitos técnicos, como la instalación de una base de datos o de cierto software de Big Data & Analytics, supuesto que sean tareas no abordables por el propio equipo. Así, conseguiremos que la planificación del sprint no se convierta en un punto de bloqueo justo en su inicio.
El foco de esta reunión, al final del sprint, es mostrar el incremento de producto funcionando que se ha conseguido, así como entender qué ha quedado pendiente de hacer para futuros sprints. Idealmente no se basa solo en una demostración de nuevas funcionalidades del producto, sino que se pone a disposición real de los interesados, para que puedan realizar sus propias pruebas del software ya funcionando (es admisible por ejemplo que sea un prototipo y no un paso a producción, lo importante es que los usuarios y el Product Owner puedan manejar el software).
De todas formas la reunión no debe quedar solo en la demostración. También hay que revisar una vez más la lista de producto, conjuntamente con el Product Owner, y entender cómo la repriorización frecuente ayuda de manera efectiva al negocio. De nuevo se requiere autocrítica, si hay funcionalidades que no han sido adecuadas, serán necesario modificarlas en siguientes sprints, evitando penalizaciones por ello.
Refiriéndonos a los proyectos de Analítica, Business Intelligence y Big Data, creo necesarias ciertas matizaciones para esta reunión. En concreto, pienso que requiere más tiempo que en otro tipo de proyectos, y no esperar solo al final del sprint. Está muy bien ofrecer un prototipo a los usuarios, pero también hay que considerar si cuentan con la formación suficiente, o es preferible que estén acompañados de alguien del equipo técnico durante sus revisiones.
El Product Owner tiene que velar por mantener un feedback coordinado de los diferentes interesados, ya que cada uno tendrá sus propias prioridades. Otro riesgo típico es que los interesados no entiendan que están viendo un prototipo con algunas limitaciones, lo que requiere una cierta gestión política del proyecto.
Si en la anterior reunión se pretendía revisar principalmente el producto, en la retrospectiva se quiere evaluar el propio proceso de Scrum. Esta reunión marca el fin del sprint. Es el momento de hablar sobre lo que ha funcionado mejor y peor en el resto de reuniones, y de establecer alguna mejora concreta. Por ejemplo, se ha podido descubrir que la reunión diaria se extiende excesivo tiempo porque se quiere entrar en el detalle de las incidencias, o porque cada día hay alguien diferente que llega tarde a la reunión.
Otros problemas típicos más complejos abordan la dificultad de formalizar qué se considera un trabajo terminado, o cómo repartirse tareas de forma equitativa. Igualmente se pueden tratar temas sobre barreras en la comunicación, posibles malentendidos, etc.
Pero sería un error dedicarse exclusivamente a revisar puntos negativos. También hay que evaluar puntos fuertes, y reconocer lo que sí está funcionando (ej. sustituir correos electrónicos por reuniones cara a cara), para de esta forma afianzar las prácticas más útiles.
Con esta entrada he cubierto ya todos los eventos de Scrum, y anteriormente lo hice sobre los principios ágiles y los roles. En próximos artículos realizaré consideraciones sobre los artefactos y demás conceptos básicos de Scrum. Permaneced atentos al Blog de datahack.
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.
El Sprint comienza con esta reunión, donde se pretende concretar lo suficiente el alcance del mismo, y a partir de ese momento comprometerse con el mismo sin perder el foco. Por ello hay que responder a dos preguntas fundamentales:
Debo recordar aquí que terminado significa idealmente listo para entregar al usuario. El entregable terminado durante un sprint concreto se denomina incremento de producto. Para poder responder a la pregunta anterior, lo primero que hay que conocer el histórico de entregas en sprints anteriores, sobre todo en los más recientes, para estimar la velocidad del equipo. También hay que tener en cuenta la capacidad de desarrollo prevista del equipo. Esta está condicionada, por ejemplo, por posibles vacaciones y reuniones, y especialmente por trabajar en multiproyectos, lo que anticipo que se desaconseja.
Como es lógico, en los primeros sprints falta información para ofrecer una estimación fundada; pero la idea es que, transcurridos varios, el equipo alcance una velocidad de crucero, que se puede medir y sirve para proyectar en los siguientes.
Por otro lado tiene que estar muy bien formalizada y priorizada la lista de producto, aunque todavía no he comentado sobre la misma. En este punto basta saber que es el Product Owner quien la define, y que prioriza las funcionalidades pendientes que más valor aportarán al negocio. No obstante es el Development Team quien decide cuántos de estos elementos, por orden de prioridad, puede terminar durante el sprint.
Podemos pensar que esta parte de la reunión se alarga mucho, pero se supone que en sprints anteriores se ha celebrado otra reunión específica para ir detallando y estimando la lista de producto. De esta forma la preselección se puede hacer bastante rápida.
La estimación que realiza el equipo de desarrollo suele basarse en puntos asignados a cada elemento de la lista, y que tiene en cuenta la complejidad del desarrollo, posibles riesgos, etc. En función del histórico del proyecto, se puede establecer una media de puntos entregados por sprint, y así se precisa mejor cuántos elementos de la lista son abordables en el actual.
Hay otra matización importante de este apartado, y es que se recomienda formular un objetivo concreto del sprint. Es decir, no se trata de ir implementando elementos deslavazados, sino que el equipo debe comprender cómo esos elementos conjuntamente proporcionan valor al negocio, y por qué son más prioritarios que otros, algo que debe aclarar el Product Owner.
Una vez preseleccionados los elementos de la lista de producto más prioritarios, es necesario establecer un plan de desarrollo o implementación. Esto suele requerir que el Product Owner aclare detalles funcionales que hasta el momento no eran conocidos. También es probable que el equipo de desarrollo ajuste sus estimaciones de puntos a medida que dispone de más información, o por ejemplo advierta algún riesgo que no se había considerado inicialmente. También se pueden incluir elementos menos prioritarios, pero que, por motivos técnicos, o porque convienen al objetivo, se podrían abordar en este sprint. Con todo ello se espera generar la lista de elementos pendientes para el sprint en curso, incluyendo el plan de trabajo asociado.
En este punto, el plan es todavía un tanto genérico, y aborda aspectos como las tecnologías a usar, tareas de alto nivel a llevar a cabo, medidas de calidad o de terminación del trabajo, y cómo se espera dividir el trabajo entre las diferentes personas. Es importante que de la reunión se salga con una secuenciación lógica y completa de todo el sprint, aunque sea de alto nivel.
El plan es competencia directa del equipo de desarrollo. Lejos de ser algo estático (fijado por esta reunión), va evolucionando y entrando a mayor nivel de detalle a lo largo del sprint, y está presente en el resto de reuniones. Más que con un diagrama de Gantt, el grado de avance se visualiza con esos post-its de colores que a todos nos vienen a la mente cuando se habla de agilidad.
Nota personal: El diagrama de Gantt no tiene nada de malo en las prácticas ágiles, lo malo viene cuando se entra en demasiado nivel de detalle de tareas, sabiendo que va a haber cambios diarios.
Ya intuimos que es probable tener que renegociar sobre los elementos de la lista de producto preseleccionados al completar la primera pregunta, algo característico de la agilidad, siempre que no vaya en contra del objetivo. Esto ocurre en la planificación, pero también en el día a día del sprint, donde podemos interpretar que existe cierta replanificación. Y también muy natural para los proyectos de Analítica, Big Data y Business Intelligence, donde los diferentes interesados tienen que ofrecer feedbacks frecuentes de lo que necesitan y de lo que se va entregando. Y donde se van descubriendo aspectos de la calidad y disponibilidad del dato que requieren adaptar las tareas, o lanzar procesos que duran horas.
Podemos apreciar cómo el equipo de desarrollo gana competencias de gestión respecto a la manera tradicional. Pero igualmente crece su responsabilidad ante el resto de interesados. Por ejemplo, si el equipo de desarrollo es muy conservador a la hora de realizar estimaciones, habrá alguien en la organización que pida explicaciones por ello, empezando por el Product Owner.
Sin duda, la dirección de la empresa va a esperar cada vez mayor velocidad percibida, y también hay que demostrar mejoras tangibles frente a las metodologías predictivas. En concreto, volviendo a la analítica, el Big Data y el Business Intelligence, lo primero que hay que evaluar es si los usuarios están usando nuestros productos. Y, lo segundo, si el ritmo de entregas es el adecuado (aunque siempre hay usuarios con un afán desmedido de nuevas funcionalidades, y es el Product Owner quien tiene que gestionarlo).
En último extremo el compromiso del sprint no es una lista de elementos seleccionados de la lista del producto, sino el objetivo fijado en la primera parte de la reunión. El objetivo ayuda a centrar el foco, evitando cambios durante el sprint que claramente pongan el riesgo el mismo. También afianza la idea de colaboración en equipo para conseguir un resultado conjunto. Y a la vez permite cierta flexibilidad sobre elementos concretos, que pueden entrar o salir de la lista de elementos pendientes del Sprint.
Si se quiere contar con flexibilidad ante cambios frecuentes, las renegociaciones también son frecuentes. Aquí es de utilidad el Scrum Master para ayudar a vencer momentos de bloqueo, o para evitar que una parte someta a la otra sistemáticamente.
A la hora de profundizar en los requisitos del producto, es conveniente que el equipo técnico pueda reunirse directamente con otros interesados de negocio. Si hablamos de proyectos de analítica, pasa a ser crítico. El error es pensar que el Product Owner debe conocer todos y cada uno de los requisitos de negocio, y aislar al equipo técnico del resto de la empresa. En realidad la figura es más de coordinador y facilitador de toma de requisitos (por ello se recomienda que sea una única persona).
Sí que debe vigilar que se priorizan los de mayor valor, y resolver conflictos de intereses contrapuestos de los stakeholders, para que el producto sea coherente. También debe evitar cambios en medio del sprint que pongan en riesgo el objetivo, como ya hemos visto. Seguramente un Product Owner se acerca más a la figura clásica de jefe de proyecto de negocio, que el propio Scrum Master, algo que también genera cierta confusión cuando se utiliza Scrum por primera vez.
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.