Todos los caminos conducen a UX

ux ui

Enriquecer la etapa de Inception con actividades UX (User eXperience) que nos permitan empatizar con nuestros usuarios, evaluar sus necesidades y diseñar prototipos para evaluar la experiencia de lo que proponemos con personas reales, nos brinda la posibilidad de crear productos realmente sorprendentes.

Cuando dejamos de hacer Actas de constitución de proyectos y Kick-off’s y comenzamos a hacer inceptions, nos acercamos muchísimo más a la realidad de los interesados y de sus necesidades y eso nos brinda  una visión más real sobre cómo afrontar los proyectos. Dejamos de pensar directamente en el “cómo” para entender con más detalle el “qué”. El hecho de trabajar de manera colaborativa con los principales interesados de negocio amplió nuestra visión sobre las principales dolencias de los usuarios. Las soluciones empezaron a ser más objetivas y acertadas. Actividades como los PechaKucha, el Vecindario, el Sí y él No, los Miedos, las cajas de producto, los discursos de elevador,  las listas de requisitos no funcionales y tableros de visión de producto además de darnos un panorama claro sobre lo que se necesita, generan un ambiente de confianza, colaboración y fraternidad entre las personas del proyecto sin importar sus cargos, roles o salarios (Team Building).

Sin embargo la visión de proyecto es corta comparada con la realidad. Los proyectos terminan pero los productos continúan. Un proyecto, según la definición del PMI es un evento único e irrepetible en el tiempo con un inicio y un fin definidos. Un producto tiene un ciclo de vida mucho más complejo ya que muta y evoluciona a través del tiempo, con los cambios del mercado y con las tendencias de las sociedades.

En el contexto de los productos digitales, es un acierto pensar nuestros productos basados en los usuarios, ¿por qué? porque ellos son los que los van a usar, porque si ellos no se sienten cómodos usándolos van a buscar otra alternativa, porque la razón de ser de los productos digitales es que puedan ser fácilmente entendidos por cualquiera: por los que estudian, por gente adulta, por niños, por gente con discapacidades ¿por qué no?. Esto nos cambia el panorama de nuestro proyecto, esto es un reto inmenso que se debe aceptar y afrontar con profesionalismo y responsabilidad. Es una gran inversión en tiempo, esfuerzo y dinero que hará que tu producto sea único, diferente y que se acerque más a cumplir su objetivo.

La etapa de Inception es clave para que UX guíe la búsqueda del norte de nuestro producto. ¿Qué es UX? Andrea Cantú lo define en su blog como: “UX (por sus siglas en inglés User eXperience) o en español Experiencia de Usuario, es aquello que una persona percibe al interactuar con un producto o servicio. Logramos una buena UX al enfocarnos en diseñar productos útiles, usables y deseables, lo cual influye en que el usuario se sienta satisfecho, feliz y encantado.” La forma de lograr una buena experiencia de usuario es basar nuestro producto en un diseño centrado en las personas, teniendo en cuenta los objetivos de negocio, las necesidades del usuario y las limitantes técnicas, explica Andrea.

Una buena forma de integrar UX consiste en preguntarnos dentro de la etapa de Inception: ¿Quiénes van a usar nuestro producto? ¿cómo son esas personas? ¿qué hacen esas personas? ¿cómo es un día en la vida de ellos? ¿qué les interesa? ¿cómo es una jornada de sus vidas cuando se le presenta la necesidad que nosotros queremos suplir?, si no existe la capacidad de tener contacto con usuarios reales, una buena opción es crear proto-personas: personajes ficticios  que nos ayudan a recrear el comportamiento de los posibles usuarios reales. Cuando yo entiendo cómo ellos piensan, lo que sienten y lo que hacen, podemos diseñar nuestro producto a favor de ellos.

Design Sprint nos ayuda a darle un orden al proceso creativo con las siguientes etapas: Compartir información y entenderla, Imaginar, crear y definir posibles formas, Construir un prototipo y probarlo con usuarios reales. Se puede iterar cuantas veces sea necesario para llegar a un prototipo que realmente genera una buena experiencia basado en las necesidades del usuario. ¿Cómo se construye el prototipo? definiendo funcionalidades que ayuden a suplir las necesidades principales, no pensando en  “cómo”, pensar en “cómo” nos limita la creatividad, seguramente las personas puedan llegar a imaginar soluciones para las cuales no exista la tecnología necesaria o simplemente el equipo no tenga la capacidad, pero dentro de las propuestas seguramente se encontrarán soluciones que harán de tu producto un diferencial con el factor WOW que es el que buscamos todo el tiempo.

Finalizada la etapa de Inception y con un mínimo producto viable trabajando en vivo con los usuarios debemos medir y herramientas como Data.Studio de google analytics o Hotjar nos permiten tener información cuantitativa y cualitativa. Las preguntas que debemos hacernos pueden ser: ¿los usuarios si están usando mi producto? ¿a los usuarios les gusta mi producto? ¿lo entienden? ¿cuántos usuarios abandonan el proceso de mi producto? ¿en qué pasos abandonan? ¿por qué?, las decisiones que tomemos con respecto a lo que debemos mejorar de nuestro producto deben estar basadas en esta información lo cual nos permitirá generar hipótesis de mejoras y ajustes mucho más acertadas. Solo lo que esté funcionando en producción y que esté medido podrá darnos la información adecuada.

Los conceptos y filosofía de UX guían este procesos en el ciclo de vida de los productos digitales, esta guía hace que el trabajo de las personas que construyen el producto esté bien enfocado, que el desperdicio sea menor, que la mejora se vea de manera temprana y que el factor WOW este cada vez más cercano. Como facilitadores ágiles es nuestro deber entender, manejar y ayudar a integrar la interacción y guía de áreas como Ux, Analytics y Marketing Digital dentro de los equipos de trabajo cross funcionales desde la etapa de Inception.

Alejandro Posada

Scrum Master

Agilistas: ¡Cuidado con la arrogancia!

7cb1b34d85ddd065021c266deb0d3156

Cuando las personas creemos que conocemos la verdad y el camino de lo correcto, nos sentimos superiores a los demás, nos sentimos iluminados, vemos todos los errores en los otros y nos compadecemos de ellos, hacemos chistes entre los nuestros burlándonos de cómo los otros se equivocan. Así como como aquel que deja de fumar se siente superior al que fuma o el que va al gimnasio mira con lástima al gordito que come helados de manera insaciable, sucede algo parecido con el agilismo.  Me he visto, como Scrum Master en esa posición de arrogancia, alimentando mi ego insaciable y pensando que poseo todas las soluciones a los problemas de las organizaciones, criticando con desdén a las personas que trabajan haciendo planes en diagramas de Gantt y de hecho mirando por encima del hombro a todos aquellos que no son “ágiles”. Este ha sido el obstáculo (Iceberg) más grande que he encontrado en mi trabajo (y en mi personalidad).

La arrogancia, petulancia y soberbia de creer que sabemos la verdad verdadera nos ciega en nuestro trabajo como facilitadores y evangelizadores de la mejora continua. Creemos que las personas deben ejecutar inmediatamente las fabulosas ideas que se nos ocurren para ser más ágiles y para que la organización vivan una verdadera evolución.  Esta ceguera es grave y si, es un impedimento, ya que no nos permite observar y entender el ecosistema actual. La arrogancia es un par de lentes  que solo nos dejan ver los defectos, pero no nos permiten vivir qué es lo que sucede en el estado actual. Cada grupo de personas funciona distinto, todos los grupos de personas generan sub culturas diferentes, las tradiciones son otras. Todas las compañías tienen historias y sus presentes responden a causas que es necesario entender. Las motivaciones son diversas y es nuestro deber como agentes de cambio primero conocer, sentir, respirar y leer ese entorno en el que estamos. Esa comprensión de lectura es la base indispensable para empezar promover cambios significativos acordes y consecuentes con la realidad. La arrogancia solo nos permitirá criticar y seguramente chocar sin razón con aquello que nos rodea.

El agilismo y la evolución hacia un mejor sistema no consiste solamente en pregonar valores y principios sin razón, recomendar marcos de trabajo o prácticas solo por que a otros les funcionó, no todo el mundo necesita Scrum, no a todo el mundo le sirve Safe o Nexus. Una buena forma de iniciar (y de continuar) es conocer a las personas, saludarlas, hablar con ellas, trabajar con ellas y sentir sus dolores. En vez de imponer cambios, alimenta el sistema actual con prácticas que orgánicamente estén acordes con el presente, igual, los resultados hablarán por sí solos.

 

Transición de la ceremonia de reunión diaria (Daily)

dailyDurante 8 meses he trabajado como Scrum Master en un equipo de desarrollo compuesto por cuatro personas. Hemos llevado a cabo 4 proyectos. Durante este tiempo la ceremonia diaria (Daily) ha pasado por varios estados. El día de hoy  presencié el mejor Daily de todos.  En este post contaré como ha sido el proceso.

Antes de mi llegada como Scrum Master el equipo estaba empezando a usar las ceremonias Scrum. En una aplicación web gestionaban las Historias de Usuario y actividades a las cuales se comprometían en un Sprint. No tenían una ceremonia Daily formal, cada persona era responsable de sus Historia de Usuario y se hablaban cuando lo consideraban necesario. Inicialmente elaboré un tablero kanban para que el equipo tuviera de manera física el estado del sprint y así poder llevar a cabo la ceremonia como lo sugiere la guía: de pie, en un mismo sitio y a una misma hora.  Esto produjo que el equipo adoptara una rutina de reunión por la mañana, pero era una reunión de estado. Cada persona del equipo me contaba qué había hecho y qué estaba haciendo. Cuando alguien hablaba lo hacía dirigiéndose a mi. Me estaba convirtiendo en un Project Manager…

Luego de dos meses me asignaron como Scrum Master de otros equipos más, así que ya no podía estar en la ceremonia con el equipo todos los días, esto tuvo las siguientes consecuencias: El equipo algunas veces hacia el Daily y cuando lo hacían lo usaban principalmente para actualizar el tablero kanban.

Con el paso de los días el Daily era algo así como una obligación, algo que tocaba hacer pero que muchas veces no se hacía, pero el equipo empezó a tener problemas. No tenían una buena comunicación a pesar de que se hablaban todo el día.  Aparecían detalles técnicos a los cuales no les brindaron importancia y luego les pasaron factura e hicieron desarrollos por caminos equivocados, además la comunicación con el equipo de producto pudo haber evitado algunos problemas pero era algo que no se estaba dando.  La siguiente Retrospectiva fue clave: El equipo no cumplió con sus objetivos del sprint ya que hicieron trabajo que se desperdició y se les presentaron errores a los cuales no les prestaron atención.  Yo como facilitador solo les pregunté cómo podrían evitar este tipo de incidentes: todos estuvieron de acuerdo en que les hacía falta tener un buen Daily.

La siguiente fase se convirtió en una reunión con todo el equipo de proyecto: equipo de negocio y equipo solucionador, pero también tendía a ser una reunión de estado del equipo solucionador hacia el equipo de negocio. Todo el equipo técnico le rendía cuentas al equipo de negocio. Además el Product Owner asistía la ceremonia por vía telefónica lo que cual centraba la atención en él.

Nuevamente en la retrospectiva salieron varios problemas a flote y aunque el equipo intentó mejorar la ceremonia todavía se presentaban problemas de comunicación, sin embargo todos estaban de acuerdo en que el espacio del Daily podía ser mejor , para ello una de las personas del equipo propuso tener en cuenta los riesgos técnicos para compartirlos durante la ceremonia, otro miembro del equipo empezó a elaborar una bitácora diaria en donde escribía lo comentado en la reunión para que no se olvidará al siguiente día. Yo solo les recomendé que para mantener el foco en la ceremonia, se hiciera de pie, todos los días a la misma hora, sin equipos de telecomunicación, es decir, todos de manera presencial y que recordarán que esa reunión era la oportunidad que tenían para hacer su estrategia para lograr sus objetivos.  El equipo de negocio tomó su lugar sin perder la comunicación con el equipo y el equipo solucionador ahora realiza su reunión diaria con Scrum Master o sin Scrum Master, con Product Owner o sin Product Owner; no dependen de nadie. Ahora ellos son los que me invitan a su reunión y veo como entre ellos se hablan como si fueran un equipo de Voleyboll en el entretiempo. Hoy estuve en el mejor daily que he visto en 8 meses.

De lo anterior resalto algunas conclusiones:

  • Los errores fueron doloros pero necesarios para que el equipo se uniera y buscará soluciones al largo plazo.
  • Mantenerme al margen de los detalles técnicos y responsabilidades del equipo como Scrum Master fué fundamental para que el equipo se apropiara del proyecto.
  • La mejora del equipo se da al largo plazo.
  • Todas las etapas mencionadas fueron importantes para llegar al estado actual.
  • Cada equipo tiene comportamientos muy diferentes, no existe una regla o una hoja de ruta para empoderar a los equipos.
  • La satisfacción como facilitador es inmensa.

Dejar de Pensar: primer paso hacia un estado de Flow

“Quién iba a pensar que la solución era dejar de pensar?”

Eckhart Tolle, en su libro EL PODER DEL AHORA, me hizo entender por qué a mi cabeza le gusta preocuparse, angustiarse, sentir miedo, reprocharse y estar siempre gastando energías sobre algún tema. La respuesta es que no soy yo, es mi mente, y mi mente no soy yo. Tal y como suena. Yo tengo una herramienta, se llama mente y  en esta mente vive mi Ego o mi Yo Invisible (como le llaman en la serie de Netflix “AO”).

Organicemos las ideas:

Tu no eres tu si no tienes conciencia. Qué es la conciencia? es el estado en el que entra una persona cuando esta viviendo el presente, es decir, cuando es una persona consciente.

Cómo se vive el momento presente? despertando tus sentidos a tu entorno presente, escuchando, observando, respirando consciente mente y apagando así el ruido que hace tu mente con los problemas, angustias que tanto le gusta repasar (Ruido).

kungfupandaoogwayprophecy

Consciencia: Esta en el presente.

Mente: Le gusta pensar en el pasado o en el futuro. El autor describe a la mente como una herramienta, absolutamente útil, pero es una herramienta, si dejamos que esta nos domine, nos perdemos de nuestro presente y vivimos en angustia o con miedo. Debemos usarla para lo que necesitamos, pero es necesario volver a nuestro estado de consciencia.

Qué problema tiene estar pensando en el pasado o en el futuro?  el mas grave es que nos perdemos de nuestro presente o sea de nuestra vida misma, de lo real, de lo que sucede.

El futuro es una proyección, una idea, algo que no existe.

El pasado, no es mas que un recuerdo.

Los beneficios de estar presente y consciente son inmensos: no sentir angustia pues la angustia se siente cuando dejas que tu mente se ponga a pensar en el futuro. No sentir estrés, que es ese afán que sentimos cuando rechazamos el presente y nos resistimos a el: Ejemplo: tener afán en una congestión de vehículos y querer pasar por encima de todos (¿no es mejor poner música agradable y aceptar el presente inminente?)

Estando en el momento presente puedes planear tu futuro de una manera consciente, pero lo que no se debe permitir es convencernos que vamos a ser felices en algún momento del futuro. La felicidad solo se encontrará en el momento presente, donde estamos conectados con la vida, Aquí y Ahora, donde estamos conectados con la naturaleza, con el universo, con el mismo milagro de estar vivos.

edna

Practica la meditación: ¿Qué es? respirar y concentrarce solamente en el aire que entra y sale por tu nariz, sin pensar en lo que vas a hacer en un rato ni en el partido de fútbol de mañana (Es muy difícil no pensar, intentalo progesivamente, primero 5 segundo, luego 10, luego 15…). Sintiendo las texturas con tu tacto, escuchando lo que se mueva al rededor con tus oídos, estando en tiempo presente y verás como tu consciencia se va aumentando y verás que no vale la pena desperdiciar el poco tiempo que tenemos de vida con ese ruido mental que se genera cuando le damos vueltas y vueltas a las ideas.

Qué es la Meditación Parte 1. Por Eckhart Tolle 

Qué es la Meditación Parte 2. Por Eckhart Tolle

Qué es la Meditación Parte 3. Por Eckhart Tolle

Las mejores ideas se te ocurrirán cuando estés consciente en el momento presente.

La felicidad es ahora, no es cuándo algo suceda, cuándo me gane la lotería, cuando tenga ese trabajo soñado, aquel auto lujoso o cuando vaya de viaje. Podemos ser felices ahora mismo pues el estado presente y consiente de la mente nos conecta con esa felicidad, la felicidad milagrosa e imponente de la naturaleza a la cual pertenecemos.

Ir al sitio web de Eckhart Tolle.

Experiencia con los 12 Pasos para la Felicidad de Jurgen (12 Stepts To Happiness)

12-pasos-c

Jurgen Appelo nos comparte sus pasos para la felicidad, invitándonos a evaluar cómo estamos en 12 aspectos de la vida. Ejemplo: “Experiencias. Experimentas nuevas cosas y permites a las personas que las vivian también”

Entregué una copia de los 12 pasos a cada una de las personas del equipo para el cual soy Scrum Master. Primero pedí que los leyeran y entendieran, luego que se auto calificaran de 1 a 5 sobre cómo se sentían con cada uno de los puntos, mis conclusiones son las siguientes:

  • A todas las personas les parecieron 12 aspectos fundamentales para vivir bien y ser feliz.
  • Todos se mostraron muy agradecidos por que su Scrum Master los invitara a cuidar de dichos aspectos.
  • En cuanto a las calificaciones de los pasos, se evidencia que todos están relacionados entre si: por ejemplo, si no Comes Bien, no haces ejercicio y no estas abierto a vivir nuevas experiencias, curiosamente tampoco tienes un buen descanso. Si no estas abierto a vivir nuevas experiencias tampoco tienes una buena socialización. Pero cuando tienes buenos hábitos alimenticios, tiendes a hacer ejercicio, tienes un buen descanso y sonríes mas, además estas abierto a tener buenas experiencias (lógico cierto?).
  • Las personas que meditan tienen muy buen descanso y se sienten felices todos los días.  Así mismo caminar por la naturaleza muestra relación con estar agradecido y sonreír.
  • Las personas pegaron la hoja de los 12 pasos en sus puestos con la calificación de cada uno de los puntos y todos estuvieron de acuerdo en evaluar en un mes cómo habían mejorado.
  • Todas las personas están de acuerdo en que si son mas felices con su vida personal, se sentirán mas motivas en sus trabajos.

Realizar este taller me ayudó a conocer mejor a los miembros del equipo. Nos dio un respiro pues es un tema totalmente fuera de los aspectos cotidianos del trabajo. Así miso, tener estos aspectos presentes y compartir sobre ellos me ayuda a mejorar los que me parecen mas importantes.

Si has hecho algún ejercicio similar o tienes alguna opinión, no dudes en escribirla acá.

¿Con cuántos equipos debe trabajar un Scrum Master II?

No es tarea sencilla dejar viejos hábitos de Control obtenidos de la gerencia de proyectos como por ejemplo: decidir qué se debe hacer, asignar tareas, tomar decisiones, ordenar lineamientos, imponer fechas y pedir estados de avance. En el artículo anterior ¿Con cuántos equipos debe trabajar un Scrum Master? contaba la problemática de tener que trabajar como Scrum Master de 4 equipos y la verdad lo escribí como todo un drama.  En este momento veo ese drama  de una forma muy distinta gracias a un video de Martin Alaimo sobre las  7 claves del Coaching de Equipos.  Acá un rápido resumen sobre las 7 claves que expone Martin:

El Coaching de Equipos…, o sea lo que debe hacer un Scrum Master:

  1. Mejora del Sistema, tanto del equipo como de su entorno al largo plazo.
  2. Entiendo y actúo según la Sub cultura de la organización.
  3. Mi objetivo es elevar el nivel  de consciencia de los miembros del equipo en cuanto a: Exigirse, Conocerse y Apropiarse.
  4. Ayudo a mejorar el proceso de Toma de Decisiones, mas NO tomo decisiones por el equipo.
  5. Acompaño la toma de Decisiones y de nuevo: No toma decisiones…, por qué? por que le quitas la responsabilidad al equipo y en últimas el empoderamiento.
  6. Volverse irrelevante: Si tu equipo depende de ti como Scrum Master, tu equipo es frágil, la idea es que NO dependa, ni de ti ni de nadie, pero menos de ti como Scrum Master.
  7. Irse…, si así como suena, déjalos solos, que les toque valerse por ellos mismos, es la única forma de aprender, es la única forma de empoderarlos. Si la reunión Diaria (Daily) solo la hace cuando tu les dices o cuando tu estas, no estas haciendo bien tu trabajo de Scrum Master.

dav

Como ven, tener poco tiempo para “estar” con el equipo no es malo, de hecho te obliga a dejar que tu equipo camine solo, se organice y decida por si mismo. Con cuántos equipos debe trabajar un Scrum Master? con los que quieras, prueba y decide, solo recomiendo tener en cuenta que  las actividades que realices sean de Coaching, de facilitación y no de Project Manager, Jefe o líder de proyecto.

¿Con cuántos equipos debe trabajar un Scrum Master?

dav
Scrum Master con mas de dos equipos

Tuve la oportunidad de ser Scrum Master para cuatro (4) equipos al mismo tiempo, cada uno con proyectos diferentes. Agradezco a la vida haber tenido esta experiencia pues lo que aprendí no lo enseñan en ningún curso de certificación. Esta es mi historia:

Iniciando el año 2016 trabajé en el rol de Scrum Master con dos equipos, cada uno de 4 personas. Todo fue color de rosa, los equipos estaban sumamente entusiasmados por adoptar un marco de trabajo que se fijaba en la gente, integraba a los usuarios con el equipo y entregaba valor de manera iterativa e incremental, la experiencia les encantó y se preguntaban como era posible haber trabajado de la manera tradicional (Mando control, Diagrama de Gant, Project Managers, etc…). Pero luego la organización decidió que un Scrum Master podía trabajar con un número indeterminado de equipos siempre y cuando el número de personas no fuera  superior a  20… (wtf!!!). Con este nuevo lineamiento yo terminé siendo el Scrum Master de cuatro equipos de desarrollo de software . Cada equipo tenia  entre 3 y 4 personas.  Dado que el agilísmo nos invita a aprender de la experiencia y de los errores (falla rápido) decidí vivir dichas circunstancias haciendo el mejor esfuerzo aún sabiendo que el caos era inminente.

¿Qué sucedió? para empezar mi agenda se volvió una telaraña: tenia a una misma hora Review con un equipo y Planning con otro. Tuve que dejar de acompañar los Dailys pues no alcazaba a llegar a todos por mas que tratara de organizarlos. Cuando llegaba a visitar a alguno de los equipos trataban de contarme que le había pasado durante el día o durante la semana pero yo ya estaba descontextualizado y no entendía nada. Cuando alguno de los jefes de área me preguntaba algo sobre alguno de los proyectos yo le respondía con información de otro y si, los jefes de área seguían pensando que yo como Scrum Master también era líder técnico, jefe de equipo y project manager.  En ese momento decidí comunicarme formalmente con los jefes alertandolos de la situación: no tenia tiempo para facilitar las ceremonias, no tenia tiempo para ayudar al equipo a identificar y remover impedimentos, tampoco tenia tiempo para trabajar con las personas en un plan de mejora continua o desarrollo profesional. Comparé la situación con tener cuatro esposas: aunque te esfuerces por compartir con todas finalmente todas te van a odiar. Y si, así fue. En las retrospectivas (que siempre facilité las retrospectivas  contra viento y marea), los equipos me expresaron que yo ya no era el mismo de antes, que ya no compartía con ellos y que les hacia mucha falta. Tanto así que me preguntaban si sería lo mismo contar con un Scrum Master ausente o no tener Scrum Master…, tenían toda la razón.

Intenté hablar con los jefes, gerentes y agile coaches acerca de la situación y también busqué cual sería el “deber ser” en cuanto al número de equipos con los que debe trabajar un scrum master, la conclusión es la siguiente:

Un Scrum Master debe trabajar con un uno, máximo dos equipos. Cada equipo puede estar entre 5 y 9 personas, algunas veces mas y otras veces menos personas ese rango es ideal. No lo digo yo, lo dicen varias personas y empresas que han tenido estas mismas experiencias. Entre ellas Angel Medinilla (https://twitter.com/angel_m).

Al día de hoy trabajo con tres equipos, no es lo ideal pero ya puedo hacerlo mejor. La situación contada me sirvió para evangelizar a los jefes y gerentes sobre el Rol del Scrum Master: somos facilitadores que cultivan un sistema buscando la mejora al largo plazo. Eso es grande y es una responsabilidad muy importante. Sin embargo sigo haciendo la siguiente pregunta: ¿qué será mejor?, ¿que un Scrum Master haga deficiente su trabajo para tres o cuatro equipos o que el mismo Scrum Master haga muy bien su trabajo para uno o dos?

Si tienes preguntas sobre lo que estoy contando o has vivido algo parecido o te pareció interesante o simplemente no te gustó agradecería inmensamente cualquiera que fuera tu comentario.