• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

agile

Product Owner, improvisación o adaptación

La agilidad no ha parado de extenderse en los última década e incluso las organizaciones que miraban con recelo todo este movimiento están dando sus primeros pasos y viendo cómo pueden sumarse, aumentando así su competitividad. ¿Cómo está conviviendo en estas compañías mentalidades tan diferentes? ¿Cómo están respondiendo los Product Owners a las necesidades?(Extra: ¿qué es la transformación digital?)

Emma es una project manager en una gran compañía. Una telco internacional que solo en España cuenta con más de 10.000 trabajadores entre internos y externos. Ella trabaja en la parte que en su empresa llaman legacy. En otras muchas esta parte de la compañía la llaman waterfall o tradicional. Trabajan como siempre lo han hecho y ahora tienen que convivir con una parte “agile” (el uso de las comillas no es una casualidad) que ha surgido en la compañía y ha empezado a trabajar de otra manera.

Para gestionar la parte que le toca en toda esta gran maquinaria, Emma necesita cuadrar dependencias, esfuerzos y fechas. Cuando interactúa con equipos que están en la party legacy de la empresa, se entienden. Todos hablan el mismo idioma. Pero cuando se dirige a las nuevas estructuras ágiles y sus Product Owners recibe un: “No tenemos fecha concreta. Nosotros trabajamos en agile, así que no tenemos fechas”. Emma está frustrada y, con razón, duda sobre la operatividad – e incluso la profesionalidad – de los equipos ágiles.

La planificación (continua) es clave 

Existe un falso mito alrededor de la agilidad y la planificación. Analicemos por encima Scrum, por ejemplo:

  • El Product Backlog contiene el futuro del producto. Debe estar ordenado, refinado, estimado y con él es sencillo conocer cuáles serán los siguientes pasos.
  • En la Sprint Planning se crea un plan para alcanzar nuestro Sprint Goal durante el Sprint. 
  • La Daily Scrum es un evento para crear un plan de las siguientes 24h, una vez inspeccionado como va el plan del Sprint. 
  • La Sprint Review es un evento de negocio que pertenece al Product Owner dónde se analiza la situación actual del producto, del mercado, obtendremos feedback de los Stakeholders y re-planificamos el futuro de nuestro producto y lo plasmamos en el Product Backlog.
  • La Sprint Retrospective es una oportunidad para el Scrum Team de planificar acciones de mejora en el Definition of Done, procesos, herramientas o personas. 

Como podemos comprobar existe una planificación continua. La clave del éxito de la agilidad en entornos complejos no reside en la falta de planificación. Reside en darle más importancia a la planificación en sí misma, a las conversaciones, a la transparencia que subyace tras cada planificación, que al plan en sí mismo y estar dispuesto a actualizar el plan con cada nuevo descubrimiento que nos pueda aportar una ventaja competitiva. (Extra: Cómo Scrum nos ayuda a alcanzar la agilidad de negocio)

Planificando tendré oportunidad de adaptación

Tener una planificación es básico para poder desarrollar un producto o un servicio de forma profesional. El tipo de respuestas que se ven en desarrollos “ágiles” como el que le daban a Emma “Es que trabajamos en agile y no sabemos cuándo vamos a tener nada” demuestra que no es un desarrollo agile en absoluto y falta product ownership. Es un desarrollo donde se está improvisando. Improvisar y adaptar no es lo mismo. Inspeccionar y adaptar es la clave de la agilidad y eso solo puede ocurrir cuando tengo un plan, y soy capaz de modificar mi plan según las necesidades del mercado. 

Una respuesta a Emma en un entorno ágil podría ser: “Emma, con lo que sabemos hoy y con los datos históricos que tenemos, creemos que estará este día X. Cada dos viernes es nuestra Sprint Review y damos transparencia sobre la situación que tenemos y siguientes pasos. Pásate si estás interesada. Además, en este lugar está nuestro Product Backlog y release plan actualizado”. Bastante diferente, ¿no crees?

La falta de Product Ownership

Según mi experiencia el gran mal que azota a las empresas es la falta de liderazgo del producto. Muchas llamadas comienzan con “es que no sale el trabajo”, “es que los equipos no están comprometidos”, “es que no se hacen las cosas bien”. 

Cuando escarbas descubres que no existe nada relacionado con la gestión del producto (métricas de valor, releases maps, estrategia y visión de producto alineada con estrategia y visión de compañía) o gestión de la demanda. Esto hace que todo el mundo corra, pero en círculos. Todos están exhaustos, muchas horas trabajadas, mucha presión y nada de valor generado. ¿Os suena esta sensación que todos hemos tenido?

En muchos casos puedes ver un Agile Coach que corre a trabajar para que el equipo esté unido, tengan dinámicas divertidas y buena comunicación. En mi experiencia puedo decir que me he cruzado con equipos con más necesidad de tener una gestión de producto bien aterrizada, profesionalizada y bien ejecutada que con necesidad de mejorar sus interacciones sociales. Eso es algo que se alcanza cuando el equipo (incluyendo al Product Owner) se relacionan alrededor de un objetivo claro y ponen todo su conocimiento y esfuerzo al servicio del beneficio de sus clientes y, por tanto, del revenue para la empresa.

El empoderamiento del Product Owner

Un Product Owner de una gran aseguradora se quejaba de que no tenía ningún tipo de poder de decisión sobre el producto, que le gustaría poder tomar más decisiones y tener más responsabilidad. Yo le pregunté que dónde podría ver sus diferentes horizontes de planificación, sus futuras entregas a los clientes y como esperaba que esas entregas impactaran en las métricas de negocio. “No tengo nada de eso” fue la respuesta.

Para crear productos de alto valor el Product Owner debe estar empoderado. Y aquí hay un contrato de dos partes. La empresa, claro está, debe darles capacidad de maniobra y libertad. Pero no hay que olvidar que el Product Owner debe ganarse la confianza. Tener al menos una visión de producto, un roadmap, un release map y qué métricas vamos a tomar para ver si el valor del producto es el esperado, eso es básico. Sentarse a pedir más responsabilidad con todo este plan bajo el brazo suele ser más sencillo.

Conclusion

El Product Ownership brilla por su ausencia en el desarrollo ágil de productos. Esto nos lleva a falta de planificación e improvisación que suele terminar en desastre. Este “Product Management Vacuum” ocasionado, en muchas ocasiones, por tener Product Managers (o Product Owners) más enfocados en gestión de personas, en planes de proyecto y en cumplir hitos que en tener una visión, generar valor y validar que, con los usuarios reales, que esto está ocurriendo.

El foco de un Product Owner debe estar en las tres V: Visión, Valor y Validación. Una vez que tengamos esto, podemos empezar a trabajar en un desarrollo ágil de producto que permita alcanzar agilidad empresarial a toda la organización.

Si quieres saber más sobre Product Ownership:

  • Los 10 mejores libros para Product Owners
  • Nuestra academia online: Vídeos grabados y exámenes. Organizáte como quieras.
  • Nuestros cursos virtuales: Para facilitar la formación en tiempo de COVID estamos dando nuestros cursos en formato remoto.
  • Path de Scrum.org para Product Owners: Conjunto de recursos muy recomendable para todos los perfiles: Scrum Masters, Agile Coaches, Product Owners o jefes de proyecto

Agile Open Camp España 2019. ¡Empieza la cuenta atrás!

Los comienzos

Tras haber comenzado el año anterior mi incursión en el agilismo formándome con Jerónimo Palacios & Associates tuve oportunidad de conocer en febrero de este año 2019 el Agile Open Camp (AOC). Se trata de un evento sobre agilidad que ya había tenido varias ediciones en Argentina, Chile y Colombia. Ahora, impulsado por tres profesionales de la cultura Agile, Ingrid Astiz, Thomas Wallet y David Roncero, se quería lanzar el Agile Open Camp España 2019, y para ello estaban pidiendo gente voluntaria para su organización. Y no lo dudé un momento y me enrolé.

Como por entonces estaba todavía “haciendo el rodaje”, en lo que a agilidad se refiere, tenía un cierto temor por no encajar. La primera reunión a la que acudí con una mezcla de incertidumbre y expectación, la recuerdo perfectamente. Fue un 1 de febrero, en Vallecas (barrio ilustre de Madrid, para los que no sean de Madrid) una tarde que llovía sin parar. Tuve la oportunidad de conocer a muchos de mis compañeros y compañeras actuales en la organización del AOC España 2019, distribuidos (literalmente) entre Europa y América. La incertidumbre y el temor a no encajar desapareció de inmediato. Me encontré con gente que te acogía desde el primer momento, mostrando una generosidad y entrega absoluta para colaborar en un proyecto que en esas fechas estaba empezando a andar.

¿Cómo nos coordinamos para sacar adelante el AOC España 2019?

En aquella reunión nos repartimos en diferentes tribus de auto-organización: finanzas, logística y el transporte y otros, la difusión y comunicación. Las tribus de auto-organización son un mecanismo de facilitación de eventos que permite delegar a sus mismas participantes distintos aspectos de su organización y facilitación. Las tribus son responsables que algunas cosas sucedan, no necesariamente de hacerlas ellas mismas.

Desde ese día y a golpe de Trello y Slack hemos ido trabajando para dar forma al primer Agile Open Camp (AOC) de España, celebrando muchas reuniones virtuales, a las que cada uno se conectaba desde los lugares más insospechados y sacando tiempo de donde no lo tenían.

Para la difusión se apostó por la celebración de meetups en los que se hablara de temas vinculados a la cultura de la agilidad. Hasta la fecha se han organizado 5:

  • “El rol de RRHH en la transformación Agile de las organizaciones”, en el que discutimos sobre el papel que ha de tener los equipos de RRHH en el aterrizaje de la agilidad en las organizaciones.
  • “Aterrizando la filosofía oriental al manifiesto ágil” un meetup en el que se nos explicó cómo los elementos de la medicina China (Madera, Fuego, Tierra, Metal y Agua) se conectan con el Manifiesto Agile.
  • “¿Puede ser una organización emocionalmente inteligente?” Hablamos de los cambios de cultura de las organizaciones para afrontar retos como el de la transformación digital.
  • “Cómo ser creativos” En una atmósfera de cambio constante, surge la necesidad de adaptarnos de forma continua y aquí hablamos de cómo la creatividad puede ayudarnos.
  • ¿Por qué fallan las iniciativas de cambio en grandes organizaciones? . La sesión enfocada a impulsar un proceso de inteligencia colectiva en el que se reflexionara sobre las razones del fracaso de las iniciativas de cambio.

Agile Open Camp España 2019 ya es una realidad, pero … ¿en qué consiste?

El objetivo del evento es dar la oportunidad a todas aquellas personas interesadas en la agilidad y el cambio agile, independientemente de su grado de conocimiento, a unirse a un evento abierto, relajado e informal. Además todo mezclado con actividades gastronómicas, turísticas, deportivas y de entretenimiento, en el que todos puedan aprender y disfrutar. El lema convocante es: “¿Y si construimos nuestro futuro como un equipo ágil?.”

El Agile Open Camp España 2019 tendrá lugar entre los días 26 al 29 de septiembre de 2019 en Vector Academy, situado en un paraje de Navaluenga, provincia de Ávila.

San Saru

El 1 de julio comenzó el plazo para postularse. El sistema elegido para las postulaciones y registro es el de “san saru”, inspirado en los tres monos sabios (san saru, en japonés) Mizaru (no ver), Kikazaru (no oír), Iwazaru (no decir). Es un sistema muy colaborativo y distribuido que evita que las personas más rápidas en inscribirse sean solo las que asisten al evento. El “san saru” consta de tres etapas:

1. Postulación: Los interesados cuentan quiénes son, a qué se dedican, su relación con la agilidad, qué ideas pueden aportar al evento y qué esperan llevarse.

2. Selección: El 1 de julio los tres monos, representados por 3 impulsores del AOC en España, inician el proceso. Cada uno selecciona a dos postulantes para participar del evento. Cada persona seleccionada podrá elegir otros dos postulantes, y así sucesivamente. Lo que hace especial este sistema es que el criterio de selección es distribuido entre las personas que van siendo escogidas.

3. Inscripción: Las personas seleccionadas deben hacer efectiva su inscripción abonando el pago de su entrada.

Un apoyo valioso

Este evento se podrá celebrar gracias a la colaboración de todas las personas que están desinteresadamente involucradas en la organización. Y también gracias a los sponsors, entre ellos, Jerónimo Palacios & Associates a los que aprovechamos este post para darles las gracias por su apoyo.

Termino compartiendo mi alegría por haber sido seleccionado para participar en este primer Agile Open Camp. Tengo una enorme ilusión porque entre otras cosas voy a poder compartir experiencias con gente con la que sin conocerla personalmente, ya se de antemano que tenemos muchas cosas en común. Y con esas personas colaboraré en la creación de los contenidos que se traten en el AOC, participaré en charlas con diferentes aproximaciones a la agilidad y disfrutaré de las actividades de ocio que entre todos propongamos. A la vuelta compartiré como ha sido la experiencia y si se han cumplido las expectativas.

Para más información puedes ir a la página web http://spain.agileopen.camp/ o a las redes habituales: slack y twitter Twitter @AgileOpenCamp.

Nacho Escobar
Alumno de Jerónimo Palacios & Associates y otras cosas

Evento Agile en A Coruña – NOA 2019

Este pasado sábado 30 de marzo, tanto mi compañera Laura como yo, disfrutamos de la oportunidad de asistir en A Coruña al evento Agile NOA 2019 (Noroeste Agile 2019).

Ya que el encuentro se realizó en una imponente sala de cine de las instalaciones Cinesa Marineda City, me gustaría abrir con una frase de una de mis películas favoritas, Million Dollar Baby. Si no la habéis visto todavía, os lanzo mi recomendación para que lo hagáis. La cita en cuestión es:

Los ganadores son simplemente aquellos que están dispuestos a hacer cosas que no harían los perdedores.

Para mí, los organizadores de esta sesión son unos auténticos ganadores. Todavía recuerdo nuestra primera conversación donde se suponía que querían preparar un evento Agile para unos pocos amigos. Luego pasó a ser algo similar a un Meetup de unas 30 o 40 personas. Después empezaron a ocupar una pequeña sala de cine. Finalmente han permitido que tuviese lugar uno de los espacios con mayor asistencia a nivel nacional. Algo más de 300 personas hemos podido vivir en persona esta primera edición del evento Agile NOA.

Coged las palomitas que paso a hablaros del contenido en cuestión.

Registro gráfico

Todas las sesiones contaron con el apoyo de Laura para registrar de forma gráfica los principales conceptos que se trataban en cada una de ellas.

Personalmente me parece algo mágico ver cómo un espacio en blanco va cobrando vida a la vez que va incrementando la información que proyecta. En el resumen de cada una de las charlas que aparece más abajo podéis ver el registro final elaborado por Laura. Simplemente espectacular.

Charlas

Cuatro fuimos los escogidos por la organización para compartir nuestros aprendizajes y experiencias dentro del apasionante mundo de la agilidad. Lo hicimos hablando de distintos temas aunque de principio a fin todos ellos estaban conectados.

Os hago un breve resumen de cada una de las charlas que tuvieron lugar junto a los principales puntos que destacaría de cada una de ellas.

1. Claves para crear productos y servicios de éxito en un contexto de cambio

Marta Falcón abrió con la primera charla. Estuvo impresionante hablándonos sobre creación de productos y servicios basándonos en tener en el centro al cliente.

De su ponencia me llevo principalmente:

  • En entornos VUCA lo que más nos preocupa es la incertidumbre y para ello, lo más importante es aumentar la capacidad de adaptación a tu equipo, al contexto y al usuario.
  • Evitemos la técnica del mazo: hagamos productos/servicios que encajen directamente al usuario y no hagamos productos/servicios que luego tengamos que hacer que encajen a mazazos. Entendamos al usuario antes de construirle una solución.
  • Construyamos productos/servicios por medio de una visión sistémica teniendo en cuenta: tiempo, usuario, empresa, valor, interacciones y muy importante también, las emociones.

Os dejo también su Twitter: Marta Falcón.

Por último, el registro gráfico:

2. ¡Scrum se cuenta en 2 minutos y encima falla!

La segunda charla de este evento Agile que iba viento en popa, fue de la mano de Benjamín Garrido, quien también estuvo espectacular hablando sobre Scrum.

Benjamín empezó haciendo una explicación de Scrum en 2 minutos en la que, a pesar de faltarle el aliento, fue capaz de contar de dónde nace, qué es y qué 11 elementos contiene. A partir de ese momento, ya todos podíamos decir que sabíamos de Scrum y que podíamos ser Scrum Master.

En este caso me apunté:

  • Tal y como dice en la guía, Scrum es ligero, simple de entender y difícil de dominar. De hecho Benjamín pudo contar prácticamente todo en 2 minutos. Después mostró los problemas a la hora de ponerlo en práctica y de no entender realmente sus fundamentos, sus raíces.
  • Un buen conjunto de anti-patrones que ha vivido e ido recopilando. Por ejemplo: Hardening Sprint, Sprint 0, Release Sprint, Test Event, etc.
  • Otro gran grupo de mitos que nuevamente recopila desde su experiencia y que es importante conocer para evitarlos. Ejemplos: Scrum sólo sirve para Software, el Product Backlog sólo contiene Historias de Usuario, etc.

Me gustó mucho una cita que puso de Mr. Robot así que dejarla también aquí porque estoy totalmente de acuerdo con lo que dice:

El mundo es un lugar peligroso. No por las personas que hacen el mal, sino por las que miran y no hacen nada.

Os dejo también su Twitter: Benjamín Garrido.

Por último, el registro gráfico:

3. Introducción a Management 3.0

Ahora era mi turno y nuevamente hablé de Management 3.0 a través de una introducción de por qué surge y qué es.

En lugar de hacer lo mismo que con mis “compañeros de reparto”, os dejo 3 artículos que considero fundamentales y que engloban más información de la que di en la charla en cuestión:

  • Management 3.0 – ¿Por qué surge?
  • Management 3.0 – ¿Qué es?
  • Management 3.0 – Principios guía

Como siempre digo, si tenéis cualquier duda o queréis que comentemos algo, no dudéis en escribirme por LinkedIn o Twitter.

Además, si queréis tener más información sobre nuestros cursos de Management 3.0, no dudéis en escribirnos o consultarlo directamente en la página web.

Por último, el registro gráfico:

4. Las organizaciones del futuro: ¿Estamos preparados?

Finalmente tuvimos el enorme placer de contar con Santi Vidal, quien puso el broche hablando de modelos organizativos y de cómo han evolucionado a lo largo de la historia, donde destacaría:

  • Seguimos utilizando modelos organizativos clásicos, demasiado antiguos e inadaptados a la mayoría de las situaciones que estamos viviendo, donde debido a la complejidad e incertidumbre necesitamos organizaciones adaptativas.
  • Es importante utilizar modelos diferentes a la jerarquía a pesar de que esta es necesaria. Hay que valorar las redes de conocimiento como alternativa donde realmente tenga sentido aplicarlas. Pasemos de jerarquías cerradas a equipos multidisciplinares descentralizados que giran alrededor de áreas de soporte.
  • A la hora de diseñar nuestras organizaciones adaptativas, tengamos en cuenta los principios sobre las reglas; las dinámicas sobre las estructuras; los roles sobre los títulos. Si queréis más información podéis encontrarla aquí.
  • LiquidO, un ejemplo de modelo organizacional bastante aterrizado que se basa en cuatro pilares. Hablaremos de ello en otro artículo.

Os dejo también su Twitter: Santi Vidal.

Por último, el registro gráfico:

Conclusión

El evento Agile NOA 2019 ha superado con creces mis expectativas en todos los sentidos. Me ha encantado de haber podido asistir, compartir experiencias y conversaciones, conocer a más personas que están interesadas en la agilidad empresarial y como no, de haber disfrutado de un fantástico fin de semana con mi gran amiga y compañera Laura en la fabulosa A Coruña.

Para cerrar, me gustaría lanzar un gran “¡GRACIAS!” tanto a asistentes, ponentes, organizadores y patrocinadores pues sin cada uno de ellos este tipo de encuentros sería imposible.

Ciencia de Datos, Producto y Agilidad

Muchas son las empresas que se están amparando en la agilidad para sobrevivir ante un mercado y contexto social cada vez más dinámico y donde la disrupción de tecnologías, nuevos modelos de negocio y gestión del talento han hecho que antiguas mentalidades y formas de trabajo no sean las más adecuadas para estos tiempos.

La agilidad nos lleva a trabajar colaborativamente con equipos multidisciplinares y esto no excluye a disciplinas como la ciencia de datos, que además entendemos estratégica a todos los niveles de una organización. Cada vez son más las empresas que apuestan por obtener valor de sus activos en forma de datos, utilizando el talento de los científicos de datos para impactar considerablemente en el negocio.

Sin embargo, la (relativa) novedad de la ciencia de datos y la cada vez más habitual aplicación de las metodologías ágiles no siempre tienen una convivencia fácil en el contexto de creación de productos.

El objetivo de este artículo es buscar un punto de encuentro entre responsables de producto y los equipos involucrados en la creación de producto, asumiendo que la involucración de la disciplina de datos cada vez va a ser más habitual.

Nos gustaría Identificar y explicar los momentos donde esta disciplina es un factor diferencial en la creación de productos y cómo se podría organizar de forma ágil.

Cada responsable de producto tiene su propia manera de crear productos, basada normalmente en frameworks, métodos, gurús o experiencia (Lean Startup, Design Thinking, Scrum, SAFe, Less, etc) o una combinación de todo lo anterior.

Para evitar que nuestra conversación se focalice en frameworks o métodos, vamos a suponer que independientemente del framework que utilice, un equipo involucrado en la creación de un producto pasaría por ciertos “planos”, que representamos en la siguiente figura.

  • Identificación de oportunidades: Registro de oportunidades que pueden venir  de cualquier miembro o grupo de trabajo de la empresa.
  • Entendimiento de la oportunidad: Entendemos el problema a solucionar o la necesidad a cubrir junto con el potencial impacto de negocio.
  • Ideación de soluciones: Identificamos las posibles soluciones para solventar los problemas y las necesidades.
  • Implementación de soluciones: Desarrollamos y entregamos los incrementos de producto a nuestros beneficiarios.
  • Feedback contínuo: Comúnmente hablamos de feedback en relación al impacto y el valor esperado de la solución pero podemos pensar en el feedback como planos transversales a los anteriores, unos más orientados a la forma de trabajo y otros relativos al valor entregado.

Supuestamente a medida que avanzamos desde ideación hasta feedback, vamos disminuyendo nuestro nivel de incertidumbre (de ahí la forma de funnel). Además, la madurez del producto con respecto a su ciclo de vida influye a la hora de organizar el trabajo de creación de dicho producto.

A continuación vamos a recorrer cada plano explicándolo con más detalle:

Plano Identificación de Oportunidades

Asumimos que este plano representa el espacio donde todas las ideas u oportunidades son merecedoras de consideración. Dichas oportunidades pueden haberse originado en workshops de ideación, discovery, design thinking, resultados de una investigación con usuarios, estudios de mercado, análisis de la competencia, ideas de cualquier grupo de trabajo o miembro de un equipo que participe en la creación del producto, refinamientos, revisiones, etc.

Todas estas potenciales oportunidades de mejora o evolución del producto son recogidas de forma que puedan pasar a otros planos, normalmente a lo que llamamos Entendimiento donde articulamos dichas oportunidades (lo explicamos en el siguiente apartado)

En esta fase, el papel de la disciplina de datos y en particular la del científico de datos no se diferencia de la de otros roles, excepto porque las ideas podrían venir de un proceso relativo a la ciencia de datos, como por ejemplo el uso de nuevas fuentes de datos externas o internas, los avances técnicos en algoritmos o la identificación de ciclos de adquisición y realimentación de datos.

Uso de nuevas fuentes de datos (externas o internas)

En muchos productos uno de los diferenciadores puede ser el uso de datos. En este sentido identificar fuentes de datos diferenciales y poder valorar su utilidad en etapas tempranas del proyecto es clave para la viabilidad de las ideas generadas. Por ejemplo, podemos tener la idea de que la información en portales públicos de compra venta de pisos podría ser utilizada para mejorar  la valoración del precio de una vivienda, que hasta ahora era generada basada en datos internos.

Avances técnicos en algoritmos

Algo similar ocurre con la disponibilidad de nuevas herramientas o algoritmos para el tratamiento de datos. En ocasiones, el acceso a un nuevo algoritmo puede hacer viable, técnica o económicamente, una idea. Los avances en algoritmos de Deep Learning aplicados a Visión Artificial han permitido rebajar el número de ejemplos necesarios para clasificar imágenes abriendo la puerta a nuevas aplicaciones. Por ejemplo, gracias a estos avances decidir si una imagen proporcionada contiene un coche es ahora mucho más sencillo y preciso.

Identificación de ciclos de adquisición y realimentación de datos

Otra tipo de aportación desde el equipo de datos consiste en identificar cuáles serían los mecanismos para obtener los datos deseables para nuestro producto y definir una estrategia para su adquisición. Esta estrategia, que DJ Patil define como Data Jiujitsu, ha sido ampliamente utilizada en el caso de las redes sociales como LinkedIn o Facebook para soportar su modelo de negocio.

Cabe destacar que el feedback de los resultados generados en otros planos (Entendimiento, Ideación, Ejecución, etc. explicado en apartados posteriores) podría ser una de las fuentes más interesantes de las que se puede nutrir el plano de Identificación.

Plano Entendimiento

En este plano articulamos la oportunidad y, por lo tanto, la hipótesis que tenemos con respecto al beneficio que nos reportaría llevarla a cabo, tanto a nivel de negocio como para nuestros clientes o usuarios. Además, en este plano podemos empezar a perfilar una visión o a alinearnos con una ya existente.

Como parte de ese refinamiento, el equipo de datos puede acometer tareas como:

Análisis exploratorio de datos para validar idea

Como parte del entendimiento de una idea, el análisis de los datos del mercado nos va a ayudar a definir mejor la oportunidad (público objetivo, segmentación, modelo de negocio, etc) y a acotar el trabajo a realizar en el resto de planos.

Identificar problemas e implicaciones éticas en el uso de datos

En esta etapa es necesario profundizar en las implicaciones de usar las fuentes de datos que se hayan identificado  y la forma en la que se van a usar. En este caso hay que tener en cuenta tanto aspectos legales, de privacidad y éticos. Es el momento de identificar posibles sesgos en los datos y considerar si el producto agravaría esos sesgos.

También si es capaz de satisfacer a todos los usuarios objetivo, o por el contrario se requieren mecanismos o acciones especiales para que la solución elegida sea inclusiva. Por ejemplo, en aplicaciones que incluyen reconocimiento de voz se ha encontrado que la baja representación de ejemplos femeninos o de voces no nativas suele implicar un peor calidad en el reconocimiento para estos colectivos.  

Viabilidad y análisis crítico de los datos disponibles

Es labor del equipo de datos, además del uso responsable de los mismos, velar por la utilidad práctica de dichos datos y así como de los correspondientes algoritmos. Aunque en la etapa de ideación es necesario mantener una mentalidad abierta para identificar datos que supongan una ventaja competitiva, en esta etapa es el momento de mirar los datos desde un punto de vista más crítico. Los sesgos en la recolección de datos, además de tener implicaciones éticas, pueden invalidar o limitar su utilidad en términos analíticos. Otro problema frecuente es que no se disponga de la profundidad histórica necesaria o no se recojan los datos con la frecuencia o la resolución necesaria.

Por ejemplo, un dataset puede registrar la fecha en la que sucede un evento pero en cambio, para ser útil en un  nuevo contexto se requiere el timestamp con información de hora, minuto y segundo. Identificar este tipo de necesidades y problemas, así como corregirlos para que se disponga del histórico necesario también es responsabilidad de la disciplina de datos.

Plano Ideación de Soluciones

Este es el nivel donde pensamos en las diferentes soluciones para la creación del producto, así como todo lo necesario como para poder empezar a experimentar y aprender con algo tangible (a algunos les sonará el concepto de MVP).

El objetivo es definir las características del producto y en el caso específico de que requieran funcionalidades basadas en el uso y explotación de datos, abordar cómo se podrían construir.

A grandes rasgos las aportaciones que se pueden hacer desde el equipo de datos para contribuir a la solución se agrupan en los siguientes  grandes bloques:

  • Análisis Exploratorio de Datos: Se trata en este caso de responder preguntas de negocio, por ejemplo, mediante los datos de uso del producto. Estos análisis pueden ayudar a definir una estrategia de producto, escoger una solución o priorizar el problema en el que enfocarse.
  • Visualización y Resumen de Datos: Muchos productos basados en datos incluyen alguna forma de visualización de los propios datos generados por sus usuarios, por ejemplo un gadget destinado a medir nuestra actividad física Es labor del equipo de datos buscar una visualización eficaz y adecuada.
  • Predicción Es la capacidad para inferir el valor de una o varias variables de interés para nuestra aplicación  Puede tratarse, entre otras, de la categoría de un objeto (imagen), el valor numérico de una cantidad medible (el precio de un vuelo) o las películas en las que puede estar interesado un usuario, como en el caso de un recomendador.
  • Diseño de ciclos de realimentación de datos: Cualquier funcionalidad basada en datos tiende a obtener mejores resultados si dispone de más datos, así que parte de la labor del equipo de datos es definir mecanismos que permitan recogerlos y transformarlos en mejores predicciones o visualizaciones de mayor exactitud.
  • Otras funcionalidades: La disciplina de datos puede proporcionar otras soluciones basadas en datos como la optimización o la simulación, ambas relacionadas con los puntos anteriores.

Como ejemplo, pensemos en una funcionalidad familiar para muchos de nosotros: organizar las fotografías de nuestro dispositivo móvil según las personas que aparecen.Si tratamos de asociar las aportaciones al diseño que puede aportar un científico de datos:

  • En primer lugar, puede ser necesario clasificar qué fotografías tienen personas y cuáles no, que claramente es un problema de predicción.
  • Del mismo modo, agrupar qué fotografías son de la misma persona aunque puede ser abordado de diferentes formas como clustering, clasificación o ranking, es en general, otro ejemplo de problema de predicción.
  • Un tercer punto es cómo mostrar los grupos de fotografías que se podría clasificar como un problema de visualización de datos. Si bien podemos usar heurísticos sencillos (primero los grupos más numerosos o los que tienen alguna foto más reciente), también podríamos pensar en otros  más complejos (primero las personas que aparecen en más selfies) que a su vez podría requerir más problemas de predicción.
  • Además, podríamos facilitar que los usuarios pudiesen hacer sus propios grupos o quitar, poner o mover una foto mal clasificada. Si capturamos este tipo de acciones, podríamos usarlas para mejorar los modelos de predicción anteriores, que serían un buen ejemplo de la creación de un ciclo de realimentación de datos.

Para cada funcionalidad donde la ciencia de datos contribuye, hay que considerar la participación del resto de disciplinas (UX, visual design, backend, frontend, servicios, etc) y pensar en ¿qué impacto tiene para nuestros beneficiarios y/o negocio el hecho de ofrecer dicha funcionalidad? En este caso, podemos expresarlo como hipótesis de beneficio.

Por ejemplo, si incluimos la funcionalidad de ver fotos organizadas por personas, aumentará un 20% el tiempo que pasan los usuarios en la aplicación y crecerán los usuarios que suscriban un plan superior partiendo del journey “ver sus fotos organizadas”. Como consecuencia de esta funcionalidad esperamos aumenta nuestro beneficios un 5%. Es en este caso, el que el equipo de científicos de datos también puede colaborar definiendo los KPIs de negocio, definiendo el experimento científico y facilitando la obtención de conclusiones.  Del mismo modo, mediante por ejemplo la realización de test A/B, podemos validar los resultados obtenidos con la entrega de un incremento de producto.

Plano Implementación

Este es el plano donde generamos un incremento de producto de forma que entregamos valor al cliente o beneficiario. Aquí el científico de datos tiene la oportunidad de contribuir en el impacto esperado con dicho incremento, “exprimiendo” lo trabajado en todos los planos anteriores y de forma conjunta con el resto del equipo, para así entregarlo a los correspondientes beneficiarios o clientes finales.

Se asume que gran parte del trabajo en entendimiento del negocio y en la decisión del enfoque análitico se ha llevado a cabo en los planos etapas previas de entendimiento e ideación. Para la disciplina de datos este plano abarca desde el trabajo técnico de la  ingesta de datos, la validación de estos mismos, exploración, construcción del modelo predictivo (o de una visualización) hasta la posterior validación de sus resultados y en el mejor de los casos el despliegue de la funcionalidad y la infraestructura adecuada. Dejamos aparte  la medición de los resultados del proyecto, y por tanto la obtención de feedback, como parte los niveles transversales.

Construcción interaccionando con otras disciplinas

Muchas veces existen complicaciones al compatibilizar el ciclo de desarrollo tradicional de la disciplina  de datos con las iteraciones llevadas a cabo por el resto del equipo. Suponemos que el equipo en su conjunto es capaz de entregar un incremento de producto por ellos mismos, pero  las dependencias y la burocracia son típicas complicaciones que entorpecen el flujo de valor. De hecho, son habituales no sólo para científicos de datos si no para cualquier equipo ágil en general. En muchos casos la solución está más relacionada con la organización y estilos de liderazgo. Aunque esta es una discusión muy interesante, no la abordamos directamente aunque sí podemos comentar una serie de comportamientos que obstaculizan la inclusión de un científico de datos en un equipo ágil.   Se trata del mismo concepto pero abordado desde dos perspectivas diferentes, una desde el responsable de producto y la otra desde el científico de datos:

  • El responsable de producto piensa que todos los miembros del equipo tienen que contribuir en cada iteración con un incremento de funcionalidad y no tanto en un incremento de valor, no entendiendo que la ciencia de datos conlleva cierta parte de experimentación (incluso investigación) con niveles bajos de predictibilidad: Esta preocupación se hace más latente cuando un equipo no trabaja de manera multidisciplinar y colaborativamente para conseguir un objetivo, sino que se distribuyen el trabajo por disciplina o tecnología. La peor consecuencia de esta forma de trabajo es la imposibilidad de entregar valor con un flujo continuo, haciendo necesaria la integración (en algún punto futuro) de las diferentes partes implementadas a lo largo de los anteriores sprints, creando un estilo de trabajo waterfall. Por lo tanto, es importante entender que el científico de datos podría tener como resultado final de una iteración, un aprendizaje o algo que no se incluya directamente en el incremento de producto. Pero son estos experimentos los que nos llevan iterativamente a conseguir algo que finalmente sí contribuya en el incremento de producto (normalmente de manera muy significativa).
  • El científico de datos trabaja en una caja negra que se integra con el resto de funcionalidad cuando tiene un rendimiento determinado: Entendemos que las iteraciones deberían de ser incrementales, pero del producto y no solo de la parte de datos. Hay que entender que es el equipo el que tiene como objetivo entregar un incremento de producto que aporte valor en cada iteración, y no partes específicas  del equipo o individuos concretos. Como consecuencia, los ciclos de inspección y adaptación son del producto, donde el valor aportado por un incremento depende de todas las disciplinas aunque alguna sea más estratégica que otras. Por ejemplo, por muy brillante que sea un algoritmo, no va a tener el impacto esperado si UX o el visual designer no lo hace deseable o usable para el usuario, o de igual forma, las personas de operaciones no han conseguido la disponibilidad que el usuario espera.

Cadencia, Timebox, Avance Iterativo e Incremental

Creemos que merece la pena comentar un tema bastante habitual cuando científicos de datos pertenecen a un equipo ágil que itera con un timebox típico de por ejemplo 2 semanas.

Al final de la iteración se espera un incremento de valor, este incremento puede tener diferente naturaleza, aunque al final muchos entiendan o simplifiquen este valor a beneficio financiero, que ya sea de forma directa o indirecta.

La naturaleza del valor aportado en esta fase puede tener un potencial de predictibilidad diferente, de forma que ciertos trabajos sean más de research con un nivel de predictibilidad bajo y otros más de ejecución con alto nivel de predictibilidad. Normalmente está relacionado con los planos explicados con anterioridad, donde por ejemplo la predicción es complicada si nos encontramos con actividades del nivel de identificación de oportunidades o entendimento.

Cuando tenemos objetivos complicados de estimar debido a que el camino para conseguirlos es difuso, las prácticas iterativas destinadas a conseguir un objetivo en un timebox determinado podrían no ser demasiado útiles. De esta forma, intentar meter todo el trabajo realizado por los equipos en todos los planos dentro de la iteración de dos semanas, no tiene sentido en muchas ocasiones. Pero eso no quiere decir que los ciclos de inspección y adaptación no sean útiles en cualquiera de los planos, en nuestra opinión siguen siendo útiles para gestionar las expectativas del propio equipo y de los diferentes stakeholders. Sería el plano de implementación donde las iteraciones con un timebox específico resultarían más adecuadas.  

Aun así, la labor de construir una funcionalidad completa basada en datos en el nivel de implementación, en un periodo de dos semanas es en general complicada. Es la labor de los responsables de producto y los científicos de datos establecer la estrategia adecuada para facilitar la entrega de incremento de producto en el menor tiempo posible sin que eso implique tener una funcionalidad completa.

Estas son algunas estrategias para facilitar el trabajo colaborativo de un DS con el resto del equipo:

  • Construir hacia atrás. En ocasiones disponemos de funcionalidades que se pueden empezar a desplegar mediante heurísticos sencillos que luego podemos reemplazar con algoritmos más complejos. En este caso podemos trabajar en integrar estos heurísticos como un stub con el resto de la aplicación y junto al resto del equipo. La gran ventaja es que podemos empezar a testear el valor que la funcionalidad  aportaría al producto sin necesidad de construir una funcionalidad completa.
  • Construir por dominios de datos. En este caso el objetivo es identificar cual es el conjunto mínimo de datos que facilitan la mejor aproximación al modelo ideal. El objetivo es centrarse solo en la adquisición de estas fuentes de datos y su explotación combinando criterios de utilidad y disponibilidad. Posteriormente se pueden ir  incrementando el número de dominios de datos a introducir.
  • Construir por incremento de resolución. Uno de los grandes problemas en el tratamiento de datos es que tanto la adquisición y limpieza de datos requieren una gran cantidad de tiempo. En muchos casos, es viable rebajar los requisitos de este procesos si en vez de un incremento de producto, buscamos un incremento de valor. Como por ejemplo determinar si una fuente de datos o un enfoque es el adecuado. 
  • Construir mediante incrementos de complejidad. En general, conviene explorar el uso de los algoritmos (o visualizaciones) más sencillos o estándar antes de buscar soluciones más complejas, y que requieren mucho más trabajo y experimentación. Hay pocas cosas peores que contrastar, gracias al feedback de los usuarios que la funcionalidad que hemos tratado de resolver, no es en realidad deseable. Es preferible determinar cuánto antes que se trata de una funcionalidad interesante aunque requiera de mayor exactitud o sofisticación para ser útil.

Planos Feedback

Representamos el feedback como planos que cortan de manera transversal al resto de los planos. Un tipo feedback serían el relativo al proceso o mejora de la forma en que se trabaja para crear el producto en cada uno de los planos. El otro tipo de feedback se corresponde con la forma con la que que podemos validar nuestras hipótesis y criterios de éxito para pivotar o persistir en nuestras siguientes iteraciones. El feedback puede tener lugar dentro de cada plano debido a que una iteración no implica necesariamente un cambio de plano.

También puede tomar varias formas, desde el feedback cualitativo del equipo o de los usuarios hasta feedback cuantitativo. Precisamente es en este último, donde la disciplina de datos también ha contribuido en el diseño de experimentos destinados a la validación de hipótesis del producto, de la solución o sobre detalles de la implementación. Cualquier cambio o mejora, como un nuevo algoritmo para una predicción o un cambio en la interfaz, es susceptible  de ser validado con usuarios reales.

Uno de los mayores retos es que el periodo para obtener feedback accionable es   demasiado largo como para trabajar en iteraciones cortas. Para afrontar esta problemática podríamos definir leading indicators que nos permitan validar nuestras hipótesis a más corto plazos.

Ejemplos de Implantación

Dependiendo del contexto la forma de aterrizar todo lo explicado en los anteriores apartados puede variar considerablemente. Especificar un framework para todos los casos sería una simplificación de una situación que seguramente es muy compleja. Incluso algunas personas pensarán que para todos o la mayoría de casos, la utilización de un framework  es un error y la mejor aproximación sería la mejora contínua de los equipos basada en principios y valores ágiles sin especificar prácticas específicas.

Con la simple intención de ayudar a generar ideas, algunas alternativas  serían:

  • Realizar el trabajo con sistemas Kanban de manera que cada work item atraviese uno o varios planos y lo completen las personas que tengan las skills oportunas.
  • Utilizar un sistema Kanban para los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum (por decir el framework de agilidad más usado) en el plano de implementación. A la hora de gestionar la capacidad (sobre todo en la estimación de scrum) habría que considerar que algunos miembros contribuyen en varios planos.
  • Trabajar con un equipo scrum en los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum en el plano de implementación. En este caso, como scrum tiene una serie de ceremonias determinadas, si un integrante del scrum de un plano pertenece o participa también en otros scrums, podría existir un riesgo de ineficiencia.

Muchas gracias por el feedback y ayudar en la divulgación a Jerónimo Palacios, Marcelo Soria, Victor Adaíl y Jairo Alberto.

Los autores de este artículo somos César de Pablo Sánchez y Félix Serrano Martín. Nos conocimos trabajando en BBVA D&A, César trabajando como Científico de Datos y Félix como Agile Coach. Las opiniones expresadas por ambos en este artículo son personales y no necesariamente las de su empleador.

César de Pablo es Ingeniero de Telecomunicaciones por la ETSIT-UPM y Doctor en Ingeniería Informática por la UC3M. Tiene más de 15 años de experiencia en desarrollo de productos y soluciones basadas en análisis de datos, aprendizaje automático y procesamiento de lenguaje natural.

#ScrumClinic: Coste de equipos ágiles vs tradicionales (waterfall)

Buenos días Jerónimo,
Quería consultarte un “run run” que está dentro del mundo agile.

Las tarifas agile son más caras que las tarifas waterfall? Que opinión tienes tu con tu experiencia.
Sinceramente por regla general creo que si,en España, y ya sabemos el motivo, capacitación y conocimiento de los equipos ágile.

Pero como una empresa grande puede romper con el mito de que el coste agile es mayor, sencillamente porque la tarfia agile es mayor? ROI, time to market …

Primitivo Cachero

Primi me escribió hace un mes y medio esta consulta y le prometí que haría un #ScrumClinic para responderle. Ya era hora.

El mundo de la consultoría

Para poder empezar, primero hay que entender como funciona el mundo de la consultoría de IT.

Lenguados Pepa es una empresa de envasado y distribución de lenguados ultracongelados con una gran implementación en el territorio Español. La empresa se fundó en 1982 y da trabajo a unas 450 personas. Los costes son ajustados y la empresa da beneficios a sus fundadores y accionistas.

Josefa Gutierrez, la directora general, ha tenido que asumir en varias ocasiones la transformación de su negocio. Uno de los impactos más grandes lo tuvo la llegada de la informática. Os ahorraré la historia: Pepa ha tenido que invertir grandes cantidades de dinero en adaptarse a los tiempos que corren. Mientras que hace quince años los pedidos se hacían por fax, hoy tienen que servir stock en tiempo real.

Para ello, Lenguados Pepa ha tenido que recurrir a la tecnología. Gestión inteligente de stock, rotación, ventas, facturación, etc… El negocio de Pepa es vender lenguados, así que ha tenido que recurrir a empresas externas que le hicieran desarrollos para su negocio.

Además, su director financiero le explicó que era mejor subcontratar empresas porque entonces no hay que disponer de periodos de amortización.

Esto quiere decir que cuando se desarrolla Software de manera propia con los empleados, el valor que este crea hay que dividirlo entre los años de utilidad, aumentando efectivamente los impuestos que paga la empresa y reduciendo la disponibilidad de circulante de la misma. Hay que pagar impuestos sociales. Hay que aumentar el personal. Subcontratando esto no ocurre. Todo son ventajas.

Por eso existe la consultoría de IT.

El negocio de la consultoría

La consultora Samson, Hawker, Intern & Thomson es especialista en vender lo que Josefa necesita. Sus comerciales visitan a los directivos de nuestro amable distribuidor de ultracongelados y les mantienen al día de las novedades de la competencia: Big Data, Machine Learning, e-commerce, JIT, etc…

SHIT les construye productos a medida “llave en mano”. Se encargan de traer todo el expertise, en forma de informáticos, ingenieros y analistas que diseñan, planifican, programan y entregan el software que Lenguados Pepa necesita. Josefa sabe de sobra que las estimaciones, predicciones y promesas que hacen nunca se cumplen y hay proyectos que multiplican por 7 las estimaciones iniciales.

Una de las cosas que más le mosquea a Josefa es el hecho de que, a pesar de que le venden productos terminados “llave en mano”, la consultora les factura por días/hombre en función del perfil. 7 ingenieros Java a 500€ diarios. 2 Consultores Senior. 1 Junior. 1 Jefe de Proyecto. Es como si Josefa le comprara a un comercial de su concesionario de Volkswagen un coche y se lo facturaran por horas de mecánico.

Preguntados por sorprendente hecho, los comerciales de SHIT le dicen que es el Software es complicado y que así es mejor, que si no le saldría más caro.

Agile y otras cosas

Un día Josefa se ata la manta a la cabeza y decide ir a un curso de Professional Scrum Master. Ha oido que en su empresa se hace Scrum y quiere saber de qué va el tema. Durante el curso aprende que Scrum promueve que haya Software funcionando al final de cada Sprint y que no hay fases. Que así se lidia mejor con la complejidad.

Cuando vuelve a su empresa, convoca al jefe de Proyecto y a su Jefe de Informática y les dice que quiere ver el software terminado que se entregó en el último Sprint. Que quiere asistir a las Sprint Review. Y que quiere conocer el Product Backlog. Caras de poker.

– “Es que lo que vosotros contratáis son equipos waterfall. Y los equipos ágiles son más caros”
– “¿Cuanto más caros?”
– “Un 50% más caros”
– “¿Por qué?”

El precio de equipos ágiles vs equipos tradicionales

Esta es una moda que se está imponiendo en las consultoras como SHIT. Cobrar un precio por perfil dependiendo de si este es ágil o “waterfall”. Lo que quiera que eso significa.

En realidad el problema es otro. El problema es que tradicionalmente, cuando el cliente ha encargado 20 kilos de programador Java, 10 kilos de consultor y cuarto y mitad de UX, la consultora ha ido y a contratado al más barato que había en el mercado. Y el muchacho o la muchacha aprendían durante sus meses trabajando en Lenguados Pepa. Así el Jefe de Proyecto mantenía la rentabilidad de su proyecto. La diferencia entre lo que le cobra a Josefa y lo que le cuesta el Junior recién salido de la facultad. Normalmente de un 50% a un 90% de margen.

Con Agile eso no funciona. Métodos como Scrum o Kanban ponen el foco en la entrega en ciclos cortos de software iterativo e incremental. Cada menos de 30 días, puedes ir a un Sprint Review y ver qué está hecho y que no.

Eso desmonta toda la estrategia de rentabilidad del Jefe de Proyecto y del proveedor, SHIT. En vez de cobrarte menos durante mucho tiempo hasta que veas algo, tengo que entregarte algo hecho cada semana o dos. Lo cual pondrá de manifiesto que no tengo ni idea de como hacerlo, y por tanto el expertise del que presumo (y por el que me pagas) se esfumará.

Igual entonces voy y contrato a una empresa seria. O ya no te contrato más. O no te pago. La solución del proveedor es por la que me pregunta Primitivo. Tener profesionales -algo- mejores que son capaces de entregar software terminado de forma iterativa e incremental.

El problema es que estos profesionales no cobran un sueldo de recién graduado de la universidad. Por tanto, si quiero tener rentabilidad, tengo que cobrártelos más caros.

Esta es la razón por la que las consultoras cobran el kilo de Agile más caro que el kilo de Waterfall.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad