Las metodologías ágiles como el catalizador del cambio

1
6576

Estas últimas semanas he estado leyendo mucho sobre la gestión del cambio. Me comprometí a dar unos cursos por no volverme cómodo y asumir nuevos retos y me he dado cuenta que, hasta que no me he puesto a contar algunas cosas, yo mismo no me he dado cuenta «de verdad» de ellas.

Es un articulo largo y espeso para la inmediatez que buscamos todos hoy en día. De todos modos, marco con una raya un buen punto para parar …

La situación actual

La profesión informática parece que ya no es atractiva para los profesionales. Hay un sentimiento bastante generalizado de no aportar el nivel de satisfacción adecuado. En la universidades las clases se quedan vacías porque no atrae a nuevos candidatos.

También sucede lo contrario: parece que los profesionales informáticos tampoco son capaces de satisfacer las necesidades del mercado. Se provoca por un lado radicalismo de los más vocacionales y una apatía de una gran masa que ha terminado trabajando de informático sin ningún interés más allá de cubrir el expediente con una política de mínimos y pagar las letras a final de mes (licito pero obviamente no es el público objetivo de este artículo).

Adicionalmente, parece que no se acaba de encontrar el equilibrio entre la gestión y la tecnología. Los buenos técnicos reniegan de los gestores y los gestores se separan cada vez más de los técnicos donde parece que nunca nada está lo suficientemente bien construido. Es más, la obsesión de los más vocacionales hace que, en muchos casos, los más apáticos acaben gestionando. Y los más curioso, cuando pasa lo contrario, que el vocacional gestiona, hasta es peor.

¿Cómo hemos llegado hasta este punto?

Algo ha pasado sin darnos cuenta en estos últimos años y vamos a tratar de buscar algunas explicaciones.

Se produce una degradación del valor de lo profesional: Imagínate que en hospital, en urgencias, hubieras perdido que un celador (con todo el respeto para ellos) te hubiera ayudado a colocar una fractura excepcionalmente por una crisis. Como lo hace bien, decides que a partir de ese momento vas a despedir a los médicos porque muchas tareas la pueden hacer el celador: experimentalmente has demostrado que se puede. O bien, decides que le bajas el sueldo al médico para que se aproxime al de un celador. Entonces, cuando la calidad general del cliente se percibe como baja, se degrada el servicio y los celadores empiezan a reclamar el sueldo de los médicos, decides externalizarlo para que otra empresa te sirva esos servicios (sin entrar si son médicos o celadores) a precio de celadores mal pagados.

Entonces, en vez de tener una comunidad de profesionales cada vez más orgullosos y preocupados por su profesión, tienes un ola depresiva en torno a una compleja profesión. En vez de tener calidad y conocimiento tienes la inmediatez de un precio barato a corto plazo. Cuando te acostumbras a la falta de calidad solo queda el precio.

Sumamos a esto que hay muchas empresas y grupos de tecnología que se mueven en la dirección incorrecta, al no entender la diferencia entre eficiencia y eficacia (voy a abusar un poco de esto). Imagínate que te dedicas a plantar trigo y lleva tu familia 100 años haciéndolo. Puedes tener una experiencia ancestral y ser perfectamente eficaz creando terrazas en una montaña. Otra persona, con una escavadora y un operario podría obtener un resultado mucho más eficiente.

En algunos casos (no es todos) podemos encontrar comportamiento curiosos:

A lo mejor los departamentos de tecnología han aprendido a ser más eficaces:

– Intentando dar la mejor solución técnica sin entender el negocio y sus variables.

– Apretando en compras y bajando la tarifa de un perfil concreto sin preocuparse de que hay detrás de ese perfil: simplemente recursos clónicos sustituibles.

– Creando departamentos de arquitectura, certificación, oficina de proyecto, seguridad, integración, procedimientos, etc. que en vez de ser un motor de cambio y mejora son culpados de los errores en la parte de construcción y, para evitar responsabilidad, se consolidan como cuellos de botella con tiempos de respuesta lentos y objetivos propios desalineados de negocio.

– Definiendo acuerdos de nivel de servicio y penalizaciones a proveedores con indeterminación voluntaria de lo que hay que hacer y plazos imposibles de cumplir.

Pero estos departamentos de tecnología pueden no haber aprendido ha satisfacer las necesidades de negocio siendo más eficientes.

Las consultoras también trabajan la eficacia:

-Vendiendo proyectos, cuanto más grandes mejor, con personal muy cualificado en preventa e intentando ejecutarlo por fuerza bruta con personal poco cualificado.

-Consiguiendo horas voluntarias de trabajo no remunerado para compensar la mala definición de los proyectos.

-Trasladando a sus clientes la poca importancia de la cercanía entre el cliente y el equipo, creando factorías deslocalizadas.

-Dando una gran importancia a la gerencia y una escasa relevancia a los conocimientos profundos.

-Realizando una contribución escasa a la comunidad de desarrolladores. Centradas en el cliente pero no en el profesional.

Que haya un descontento general y el precio haya bajado al de coste demuestra que no han sido muy eficientes desarrollando un sector.

Los individuos también siguen su camino a la eficacia:

-Aprendiendo a hacer lo mismo de 100 modos distintos en vez de aprender a hacerlo bien, arrastrándose por las modas y por la presión de los micro-blogs.

-Aprovechando para enchufar todo lo que van descubriendo sin ser realmente necesario por tener un sentimiento continuo de estar al día.

– Pensando en reconstruir en vez de reparar para satisfacer la necesidad e hacer las cosas desde cero.

-Sobrevalorando la individualidad sobre el trabajo en equipo. Entrando en competiciones con sus compañeros en vez de colaborar y gestionar el conocimiento común.

-Eludiendo el compromiso y responsabilidad de su trabajo escudados en el descontrol de los proyectos.

-Poniendo en primer lugar el salario sobre las condiciones laborales y profesionales, aceptando situaciones ilegales como las decenas de horas de más semanales. Con rotaciones antinaturales e impaciencia por no hacer de inmediato solamente lo deseado.

Su estrategia no debe ser muy eficiente cuando hay en descontento bastante generalizado y donde hay techos salariales relativamente bajos para perfiles técnicos expertos.

¿Y ha cambiado algo o está cambiando?

Las metodologías ágiles y su contexto para mí han sido un chorro de aire fresco en el sector y han propiciado el inicio de un cambio fundamental: la auto conciencia de la profesionalidad; el nacimiento de un sentimiento de orgullo y responsabilidad sobre el propio trabajo. Un sentimiento de necesidad de aprender, con trabajo duro y personal, a hacer las cosas bien: no solo hacerlas. De transferir valor al negocio y no solamente software. La necesidad de sentirse parte de una comunidad de profesionales donde ser valorado por las aportaciones ya no solo dentro de la empresa, que muchas veces es un reto escaso, sino a otros pares fuera de la misma, donde hay batalla.

Esto está calando el los propios profesionales en proveedores y, sobre todo, en clientes cansados de mediocridad y sometidos por las políticas y culturas incorrectas donde lo barato prevalece aunque no sea lo más conveniente. Los buenos profesionales de los clientes también empiezan a demandar buenos profesionales en sus proveedores.

Empiezan a resonar el nombre de individuos de grupos auto-organizados y no ligados a una empresa concreta, como agile-spain.com. Empieza a trasnscender que detrás de esos grupos hay conocimiento y ganas. Que no vale todo y que no se acepta todo.

¿Pero este cambio como afecta al negocio? ¿Por qué les puede interesar?

Los departamento de negocio saben que algo falla. La velocidad y calidad que demandan no es la adecuada y la externalización, lejos de arreglar los problemas, añade capas a esos problemas.

Negocio lee a personajes como Jack Welch cuando dice «si el cambio dentro de la empresa es más lento que fuera de ella, el final es inevitable».

Los cambios que se han producido en la empresa van por muchas dimensiones:

-Estrategia: Más anticipatoria, con ciclos más cortos y ágil (entendiendo ágil como adaptativa al cambio).

-Organización: Menos jerárquica (más ligera), más plana y flexible.

-Mando: Menos control total y más empowerment (potenciar las capacidades del equipo)

-Equipo: Menos valor de la experiencia y más valor de la capacidad de aplicar conocimientos recientes (al menos en profesiones intelectuales)

-Cliente: Un potencial blogger o twittero que puede lanzarnos o hundirnos.

Las cosas han cambiado y cambian cada vez más deprisa por lo que tenemos que ser ágiles para adaptarnos.

Solo la gente preparada puede aportar esa agilidad y tener las habilidades para satisfacer las nuevas demandas. Solo la gente consciente de su contexto sabe manejar adecuadamente las variables del triangulo de hierro: calidad, precio, alcance, tiempo y aportar un flujo de valor continuo a negocio.

Y estar preparado no significa ser unicamente el mejor técnico sino el mejor profesional. Un buen profesional es capaz de montar su taller porque entiende todas las variables y no solo las restringe al plano técnico elitista de la ejecución. Son profesionales que saben como definir un producto, como valorarlo, como organizarlo y como hacerlo: hacerlo bien. Como combinar capacidades y niveles experiencias (recordar que si todo el mundo fuera un experto nadie podría empezar y todo saldría muy caro) para satisfacer las necesidades a costes razonables.

¿Y quién puede ayudar a que esto mejore?

Quien puede cambiar las cosas normalmente es el que crea la demanda. Las áreas de negocio piden a las de tecnología que solucionen sus problemas. Son las áreas de tecnología las que organizan sus equipos internamente y sub-contratan servicios. Si en este punto falla, fallará casi todo.

Si los directivos de tecnología y mandos intermedios no ven la necesidad de cambiar, si se acomodan, si son conformistas, la guerra está perdida. Hay que trabajar su lado racional y emocional y poner al descubierto lo que falla y mejor aún, lo que funciona.

También las comunidades de profesionales tienen que hacer ruido. Tienen que aprender a colaborar y promocionar el valor de sus compañeros, de su competencia. Cuanto más valiosa sea la competencia con la que te mides, más valioso eres.

Nosotros regalamos el conocimiento, regalamos nuestros libro a cientos de directivos, a cientos de profesionales porque cuanto más sepan, más conocimiento demandarán. La ignorancia solo facilita al lento, al asentado.

¿Cómo atacas al lado emocional?

Las fábulas y metáforas ayudan. Ver el problema en otro contexto resulta menos duro, os cuento una con base real a ver si alguien se da por aludido. Es la historia que acompaña a nuestro dibujo.

En un silo de grano, había agujeros en el techo. Se colaban las palomas y anidaban allí. Claro, imagínate el aspecto que tenían las palomas. Pasaban más por comportarse como torpes gallinas obesas, que solo podían dar saltos en el grano, más que como gráciles máquinas de volar. Es más, las patas no las sostenían el peso.
En el mismo silo, se había colado un gato. Al gato, en un principio, no le costaba ningún trabajo cazar a las palomas. El gato se puso también muy gordo y le era casi imposible saltar y moverse con agilidad. Estaba, con el tiempo, también fofo.

Lo espectacular de la situación era ver lo patético de la lucha a muerte entre la paloma y el gato ambos gordos. Todo se terminó el día que unos chavales se colaron con una escopeta de perdigones con sus presas incapaces de escapar eficazmente…. un agente externo rompió su dinámica.

Estaremos de acuerdo que cuando no te mueves, te vuelves gordo y fofo. Cuando no te mueves, te empiezan a doler cosas. El mundo se mueve …. Sobre todo en grandes corporaciones (aunque pasa en todas y a todos los niveles) hay mucha paloma que se ha puesto gorda y gatos que querían comérselas pero que han perdido la forma.

Ahora bien, ¿qué pasa cuando un departamento de tecnología se vuelve lento y gordo?. Muchos se escudan en metodologías y procesos formales burocratizando todo, más para proteger el estatus, en caso de un problema, que para dar un servicio rápido y de calidad a un coste razonable.

Estar en forma requiere disciplina y no siempre es fácil mantenerla. Sobre todo siempre hay escusas cuando el resto de las áreas de la compañía parece que tampoco se quiere mover.

¿Cómo se convencen a los más racionales de la necesidad de un cambio?

Los gurús dicen que hay que crear un sentimiento de urgencia.

Por lo tanto, tendremos que explicar que no solo tienes que hacer las cosas bien respecto a «como se han hecho en la misma empresa» sino a como se hacen ahora en el resto del mercado. El mercado ya se ha movido y ya hemos dicho que los agentes externos se cargan nuestra plácida existencia. Copiar la eficiencia puede ser mejor que avanzar en la eficacia.

La estructura de una empresa debe seguir siempre a la estrategia de la misma. El departamento de tecnología debe seguir las estrategia de la empresa, cambiando incluso más deprisa porque los cambios externos son mucho más rápidos en este aspecto. Los cambios de los medios y tecnologías de la información son algunos de los que están moviendo el mundo: ¿quién duda que el iphone o ipad ha reactivado el mercado de dispositivos? ¿y que ha pasado con la nube, las redes sociales, tiendas online, blogs, etc..? Que se lo cuenten a los periódicos, tiendas de barrio, etc.

Cada vez es necesario construir más sistemas, en más tecnologías, por más canales, con más agilidad y con calidad. Controlar el final del proceso no es la solución. Las bases tienen que ser bueno en todo el proceso.

¿Por qué las metodologías ágiles pueden ayudar en este cambio?

Una nota antes de empezar: No es que las metodología ágiles sean el único camino pero es un buen camino y de moda y tenemos la oportunidad de aprovechar el tirón. Darle valor a las metodología ágiles tampoco implica quitárselo a todo lo demás. Nada es solo blanco o negro.

La IA o investigación afirmativa nos dice que busquemos aquellas cosas que funcionan bien en una organización y tratemos de trasladarlas dentro de la misma o de otras. Las metodología ágiles podríamos decir que son el resultado de la IA aplicada al desarrollo de software donde un conjunto de profesionales han reflexionado sobre aquellos principios que hacen que las cosas salgan bien y lo han articulado como memes.

Los memes nos puedes ayudar como catalizador del cambio. Los memes son prácticas y palabras fáciles de recordar y trasmitir que pueden hacer que las cosas cambien en una misma dirección. Las metodologías ágiles y su universo nos proporcionan muchos memes. El desconocimiento de estos memes por una gran parte de la comunidad de desarrollo de software a lo mejor nos da una idea lo acomodados que estamos. Aunque sea para criticarlos hay que molestarse en estudiarlos.

¿Qué nuevas palabras o memes introducen la metodologías ágiles?

Palabros como: Lean, scrum, xp, kanban, scrumban, artesanía del software (craftsmanship), tdd, bdd, inception, open-space, coding-dojo, code-kata, code-retreat, etc.

Cada uno de ellos representa una abstracción concreta que aporta unos principios tanto válidos para que negocio obtenga más valor como para que los técnicos tengan un entorno más satisfactorio, para que una parte del sector se desarrolle de un modo distinto al que se ha hecho hasta ahora.

No significa que todo se transforme, que tampoco es el objetivo. Basta con que unos pocos empiecen a probar en sus carnes estos nuevos valores y hablen de sus resultados. Porque si no se obtienen resultados, sería otra moda pasajera.

Buscar la satisfacción de los profesionales sin buscar el valor para los negocios está bien para casa pero no para la empresa.

Eso sí, no vale probar con tu proveedor de siempre que dice que se ha transformado y convertido. Tendrás que ir a la fuente y buscar a las personas de referencia para darle una oportunidad real. Las personas de referencia son los nombres que escuchas en las reuniones. Son las personas que, cuando se organiza un open-space proponen una charla y hay gente de pie, porque no entran en la sala, deseando escucharles. Es gente reconocida por sus pares.

Las consultoras tendremos que asegurarnos que tenemos a esa gente. Que invertimos en tenerlas. Que propiciamos el entorno para que se puedan desarrollar en nuestro entorno.

————————————————————————————————————

;¿Lean qué nos puede enseñar?

Sin convertir esta entrada en un libro solo voy a dar unas pincelada de los argumentos para facilitar el cambio en las organizaciones que nos pueden aportar.

Empecemos por los principios de Lean aplicados al desarrollo de software (adaptado)

-Eliminar el desperdicio: código sobrante, funcionalidad no usada, trabajo a medio terminar, etc

-Amplificar el aprendizaje: crear conocimiento técnico del equipo y de las necesidades del negocio.

-Decide tan tarde como sea posible: Retrasar la decisiones irreversibles hasta tener un conocimiento más profundo.

-Entrega tan pronto como sea posible: cumplir las necesidades actuales de los clientes, aplicar la regla de 20/80.

-Potencia a las personas: buscar buenas personas y buenos profesionales y dejar que se desarrollen y hagan su trabajo.

-Integrar la calidad: Elementos como las pruebas unitarias, de regresión y disciplina del buen hacer.

-Mira el todo: Desarrollar un producto completo no solo software. Equilibrio entre funcionalidad, flexibilidad, mantenibilidad, etc.

Sacamos como conclusión, empezando por el final que no solo hay que construir software sino solucionar problemas de negocio.

-Un plan es algo importante pero adaptarse es más importante. El todo, el negocio, debe funcionar.

-La calidad esta integrada desde un principio y se basa en contar con buenos equipos interesados en formarse continuamente y aportar valor rápido y de modo continuo.

-Hay que priorizar el trabajo para saber que se parece a valor y que se parece a desperdicio.

-No debemos planificarlo todo en un principio sino dilatar algunas decisiones hasta tener una visión más profunda del problema.

-Tenemos que crear un cambio de cultura de gestión, a cultura de profesionalidad para pasar a una cultura de empowerment y terminar en un estado de flujo, de mejora continua.

¿El manifiesto ágil qué nos sugiere?

Vamos a leerlo: Manifiesto ágil (http://agilemanifesto.org/):

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

•A los individuos e interacciones, por encima de procesos y herramientas.

•El software que funciona, por encima de la documentación exhaustiva.

•La colaboración con el cliente, por encima de la negociación contractual.

•La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Supongo que de aquí se desprende que los individuos no son fichas intercambiables en un proceso formal. El proceso es importante pero los individuos más.

•Que el software se tiene que poder probar de un modo eficiente para demostrar sin esfuerzo que funciona. Dando valor sin restarlo.

•Que tenemos que ganar todos y que el contrato debería ser algo a nunca sacar del cajón y no una amenaza.

•Que un plan es un vector a seguir. El cliente ganará valor con el cambio y el proveedor algo distinto que hacer (entrenar al cerebro) o algo más (dinero).

Principios del Manifiesto Ágil (http://agilemanifesto.org/principles.html)

—————————————————————————

Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan:

•Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

•Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.

•Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos más breves.

•Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.

•Construcción de proyectos en torno a individuos motivados. Démosles el entorno y el respaldo que necesitan y confiemos en ellos para que realicen el trabajo.

•La forma más eficiente y efectiva de comunicar información a y con un equipo de desarrollo es mediante la conversación cara a cara.

•El software que funciona es la principal medida del progreso.

•Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.

•La atención continua a la excelencia técnica y buen diseño enaltece la agilidad.

•La simplicidad, el arte de maximizar la cantidad de trabajo que no se hace, es esencial.

•Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizanizados.

•En intervalos regulares, el equipo reflexiona sobre cómo más efectivo, entonces cambia y ajusta su conducta en consecuencia.

Esto como tal tiene algunas consecuencias directas:

•En un equipo ágil y que presenta resultados a corto plazo, la mediocridad no tiene hueco. Solo se hace evidente qué personal que sabe lo que hace puede conseguirlo. No se paga mortadela a precio de jamón de pata negra ni al revés.

•Las figuras de capas y capas intermedias de personal en las áreas de tecnología dejan de ser valiosas. Los radiadores de información, el control visual de proyectos (paredes llenas de post-it, grafías de velocidad, etc) hace que todo el mundo esté informado con acercarse a una pared o entrar en una herramienta que refleje la misma información.

•En metodología como Scrum, aparece la figura del project owner o project owner proxy y, como las comunicación es continua y las entregas se hacen en ciclos muy cortos, todas las piezas tienen que apostar y dedicar el tiempo y esfuerzo necesario por el proyecto.

•No solo hay que hacer y hacer. Hay que pararse a pensar en sesiones retrospectivas, quitar código a los desarrollo, refactorizar, hacer talleres de investigación para mejorar la técnica …

El manifiesta de la artesanía del software da una vuelta más al manifiesto ágil.

¿Y eso del craftsmanship?

El manifiesto de la artesanía del software (http://manifesto.softwarecraftsmanship.org/)

Lo leemos:

•No solo software que funciona sino también software bien diseñado.

•No solo respuesta al cambio sino también aportar valor continuamente.

•No solo individuos e interacciones sino también una comunidad de profesionales.

•No solo colaboración con clientes sino también asociaciones productivas.

En persecución de los elementos de la izquierda hemos encontrado indispensables los elementos de la derecha.

Detrás de todo esto, surge el sentimiento de «responsabilidad» sobre el trabajo que se realiza. Es decir, alguien que es consciente de su profesión, tiene las responsabilidad de su trabajo sobre incluso las presiones que sufra. Imagínate que llegas al médico con la fractura de tibia y el director de urgencia da la orden de que se le ponga un vendaje y se mande al cliente a casa, ahorrándose hasta una radiografía. El médico se volvería al director y le diría «yo no trabajo así». Para alcanzar buenos diseños, hay que practicar, practicar con gente tan inquieta como tu.

•Si no solo nos queremos adaptar al cambio sino dar valor, se puede desprender que no solo tenemos que hacer lo que nos piden sino molestarnos en entender el problema y, al menos, proponer la mejor solución que se nos ocurre. Tenemos la obligación de entender contextualmente lo que hacemos.

•No solo una relación individual. Formamos parte de un colectivo en y al que podemos apoyar para crecer juntos. Compartir el conocimiento y las inquietudes es vital. Un profesional realmente no es relevante si no lo es dentro de su comunidad. ¿Las publicaciones no son importantes en todas las profesiones?. Las palomas un poco más delgadas pueden creerse los reyes del mundo comparativamente. Solo encontrándose con mejores uno puede saber que está dentro de ellos. Los eventos tipo open-space, coding-dojo, code-retreat, etc son unos buenos foros. Los grupos locales también. Las reuniones entre emprendedores y responsables de empresas para hacer frente común en la transmisión de valores tampoco puede olvidarse.

•No solo colaboración con los clientes y pasarles la factura sino trabajar con buenos compañeros de viaje donde no sea una lucha continua a ver quien roba un poco más al otro.

Terminando

Paro aquí porque me he pasado dos pueblos….. aunque me dejo cosas para otro próximo porque el tema de inception, pruebas de vida (esto seguro que os mola), etc…

Espero que a alguien le valga alguna idea para convencerse y convencer que tenemos una oportunidad de empujar por un cambio bueno para «casi todos» (el cambio no siempre beneficia a todos, no lo hace para el que se hace rico en la situación actual).

Gandhi decía: Se tu el cambio que quieres ver en el mundo.

Hay que dejar de llorar y actuar. El cambio es movimiento. Todos seguro que tenemos que cambiar. Con movimiento procuraremos no ser los gatos y las palomas gordos esperando que nos den una perdigonada.

Enlaces de interes:

1 Comentario

  1. Genial post, una excelente síntesis de por qué el sector del desarrollo software ha llegado a donde ha llegado y cómo se puede tratar de salir de ahí. Discrepo un poquito con lo que comentas en cuanto a los equipos: \\\»Menos valor de la experiencia y más valor de la capacidad de aplicar conocimientos recientes (al menos en profesiones intelectuales)
    \\\». Lamentablemente estamos acostumbrados en España a llamar experiencia a algo que consiste básicamente en calentar la silla de la oficina con el paso de los años y poco más. Para mí la experiencia DE VERDAD, la de gente que en sus años de trabajo aprende cosas nuevas y es capaz de convertirlas en ventajas competitivas, vale más que nuca. Pero es cierto que de esos… hay muy pocos.

    En cualquier caso ojalá las cosas empiecen a cambiar.

Dejar respuesta

Please enter your comment!
Please enter your name here