Archivo de la etiqueta: agile

9+1 razones por las que trabajo en Sngular

Publicado el por
Sngular MIT

Cuando me fui con Dani, Emilio y César a Boston

Una de las actividades a la que más tiempo dedico al día es a expresar de forma emocional, pero a partir de argumentos objetivos, por qué Sngular es la empresa más adecuada para hacer un proyecto digital construido sobre tecnología. Esa explicación debe ser única, específica para cliente con el que hablo y para cada proyecto que presento; y debe ser algo diferente de lo que podría contar cualquier otra empresa de las que están tratando de hacer las cosas que hacemos en Sngular. Hasta que no encuentro esa propuesta de valor diferencial no me quedo tranquilo, noto que algo me falta y no doy por terminada una propuesta.

Hoy en cambio voy a escribir sobre por qué creo que cualquier profesional de tecnología interesado por su carrera debería pasar por Sngular, marcarse unos objetivos a medio plazo, conseguirlos, y a partir de ahí comprobar si tiene recorrido o no.

1) Tenemos cultura de startup. Es normal, aplicamos los principios del agilismo, organizaciones distribuidas, equipos por conocimiento técnicos… y sobre todo, delegamos la toma de decisión porque no creemos en las organizaciones basadas en Comités y en Burocracias. No sólo tenemos cultura de startup, es que hace años montamos una y luego se la vendimos a Amazon. Todos los años invertimos en proyectos de emprendimiento, a veces tiempo, otras dinero, siempre en nuevas ideas que nos ilusionan y que pensamos que tienen futuro.

Soy una persona flexible que se adapta

2) Unidos somos mejores. Tenemos claro que el todo es más que la suma de las partes. Nos gusta trabajar en equipo porque sabemos que de la unión de las capacidades de las personas y de su mezcla se crea valor. Sabemos que en realidad el Llanero Solitario iba con su caballo Silver y con Tonto el Comanche.

Quiero llegar lejos, no quiero llegar rápido

3) Construimos software, no somos una empresa papelera. En Sngular nos dedicamos a crear e implementar la ventaja competitiva de nuestros clientes. No estamos aquí para rellenar documentos, ni queremos sepultar a nadie con papeles. Por cierto, que respetamos profundamente que haya gente que lo haga (siempre que sean responsables con el medio ambiente).

Me gusta construir

4) Acabamos lo que empezamos, nunca dejamos las cosas a medias. No sólo somos una empresa de tecnología, es que siempre terminamos lo que empezamos. Incluso a veces terminamos lo que otros empiezan. Eso significa «compromiso», una de tantas palabras prostituidas del sector. Sabemos que las cosas se tuercen, incluso sabemos que algunas nacen torcidas. Sinceramente, nunca nos ha preocupado de quién sea la culpa, sabemos que alguien tiene que terminar los proyectos, y esos somos nosotros. Es nuestra forma de entender el «compromiso».

Nada termina hasta que está terminado

5) Retos técnicos por doquier, porque nos gusta cacharrear. Tenemos la suerte o la desgracia de trabajar con tecnologías de vanguardia. Sí, esas de las que no hay mucha documentación, con tendencia a ser versiones previas o beta, adoptadas por pequeñas comunidades incipientes, donde quizá no haya mucha gente a la vuelta de la esquina para preguntar. Esas tecnologías disruptivas que traen una promesa de eficiencia y productividad que nadie quiere pasar por alto, y que alguien tiene que ser el primero en poner en producción. Como cuando empezamos a trabajar en entornos reales con Amazon AWS en 2009, con Angular y BackboneJS en el año 2012, con Polymer desde el 2014, etc.

Tengo espíritu aventurero y me gusta explorar

6) Reconocimiento y visibilidad de nuestros proyectos. En Sngular hacemos proyectos que impactan en la sociedad.Tiendas online, startups, apps móviles, bancas digitales, aplicaciones corporativas… nuestros proyectos salen a la luz y los usan las personas. Son prácticos porque tienen como objetivo hacer un poquito mejor la vida de la gente que los usa. A veces incluso lo consiguen. Lo importante es que nuestro trabajo no acaba en un cajón, ni cogiendo polvo en una biblioteca.

Por fin podré contarle a mi abuela a qué me dedico

7) Excelentes personas. Antes que profesionales somos personas, y en particular en Sngular además queremos trabajar con grandes personas. Con gente que tiene una mente abierta, que sabe compartir, que cree en el trabajo en equipo, y que deja lo que está haciendo para ayudar a un compañero en apuros. Esa clase de personas que nunca son un obstáculo ni un pero, sino un apoyo. La gente que quieres tener a tu lado cuando llegan los problemas, porque te hace sentir que no estás solo. La verdad es que para mí es una suerte trabajar con tantas personas que el mero hecho de intentar nombrarlas sería sonrojante. También ha sido una suerte haber trabajado con otras muchas personas que luego tomaron otros caminos como las sucias comadrejas que son.

Lo importante son las personas

8) Referentes técnicos. Siempre decimos que no importa la antigüedad o la experiencia, en Sngular esperamos que todo el mundo sea el mejor en su trabajo. Fomentamos una cultura en la que cualquiera puede aportar y donde de todo el mundo se puede aprender. Nos gusta que las personas tengan un referente, es más, nos gusta que las personas puedan convertirse en referente. Es una pena que nuestros compañeros tengan más interés por trabajar, aprender y construir que por conseguir followers; pero aquí se aprende cada día.

Reconozco que tengo mucho que aprender

9) Aspiraciones en el largo plazo. Si llevamos desde el año 95 en tecnología y seguimos creciendo año tras año es porque nunca tomamos decisiones pensando en el corto plazo y en salir del paso. A veces nos toca tomar decisiones difíciles, pero lo hacemos siempre desde la coherencia con nuestros valores, y pensando que en el largo plazo será lo mejor. Y sobre todo, que nos gusta poder mirar a los ojos a las personas y poder cruzarnos con ellas por la calle sin tener que agachar la cabeza.

Quiero construir catedrales, no picar piedras

Seguramente cada uno de las 320 personas que hacen Sngular tendrán sus propios motivos de por qué han elegido trabajar aquí; estos sólo son los míos y responden a mi vivencia personal después de 6 años. Se que habrá gente que lo verá de otra manera, lo cual es respetable y sano. Pero estos son mis 9 motivos, si los recorres verás que el más importante es TU CARRERA. Si crees que son lo suficientemente buenos para ti, echa un vistazo a nuestras oportunidades en Madrid, Oviedo, Badajoz, Dallas, Birmingham o Ciudad de México http://sngular.team/es/jobs

¿Y en tu caso? ¿Qué es lo que hace que todas las mañanas vayas a tu trabajo, y no a otro?

House D. T. (Design Thinking)

Publicado el por

Bien, empecemos por el principio. ¿Qué es el Design Thinking? Es una aproximación a la resolución de problemas. Ah, muy bien. ¿De qué tipo de problemas? Problemas de todo tipo. Nos pensamos que esto sólo vale para crear servicios y productos digitales, pero no. Ah, qué pasa, ¿qué antes no se podía innovar? Por supuesto que sí. ¿Entonces por qué se ha puesto de moda? Por lo mismo que las aproximaciones Lean al ciclo de vida de un producto digital, o el desarrollo ágil a la construcción de software. Porque está orientado al éxito en el mundo de la transformación digital, caracterizado por la incertidumbre, la necesidad de adaptación al cambio y la evolución tecnológica que habilita la disrupción.

Vale. ¿Y qué tiene que ver HOUSE en esto?

House Design Thinking

Manos a la obra (Imagen de Cris HE)

No se si alguna vez habéis visto esa serie. Va de un doctor insoportable que dice todas las impertinencias que se le pasan por la cabeza disfrazándolas de honestidad, pero la gente se lo consiente porque acababa por resolver los casos más difíciles del hospital. Bueno, cuando termines de leer este post podrás decir que el Design Thinking es como un capítulo de HOUSE, sólo que sin un cojo cabrón que te da bastonazos (y sin que muera gente cuando te equivocas)

No es Lupus

Gracias a House descubrimos lo que es el Lupus, ya que era una hipótesis prácticamente en todos los episodios. Bueno, para mí el DT es en cierta medida el proceso de diagnóstico diferencial que hacía el doctor House con su equipo.

Si recordáis en todos los capítulos (casos) se probaban diferentes hipótesis, ninguna era la buena, salvo la que se probaba antes del final del episodio. Cosa normal por otra parte, forma parte del estilo de este tipo de series; en CSI el sospechoso culpable es el último al que interrogan y en Mentes Criminales la chica secuestrada siempre está en la última granja que registran.

Lo primero que tienes que saber sobre DT es que es un proceso para resolver problemas de forma iterativa, lo que significa que después de unas actividades más o menos descritas y consensuadas como corpus del proceso, se llega a una hipótesis. Y en la propia naturaleza del proceso se encuentra materializar esa hipótesis de una forma que permita ponerla a prueba rápidamente, antes de que caduque, y así obtener conclusiones que permitan el refinamiento. Y vuelta a empezar en el proceso.

Por tanto recuerda: nadie espera que soluciones un problema a la primera; ni House ni Horatio han resuelto un caso en su vida a la primera, pero se han hinchado a Emmys.

Los Síntomas no son la Enfermedad

Cuando los niños tienen fiebre, se les puede dar Dalsy para que les baje; pero sólo explorando el oído y viendo la otitis se les puede dar antibiótico, reducir la inflamación, curar y en el proceso, le bajará la fiebre. Pues esto es lo mismo. Aplicar el proceso de DT supone olvidarse de los síntomas del problema; e invertir tiempo en conocer y comprender sus causas, en lugar de paliar sus síntomas.

House Design Thinking

Abre tu mente, Quaid (Imagen de Peter Pham)

Una de las diferencias que aporta el Pensamiento de Diseño a otras metodologías de innovación es que las primeras etapas del proceso, el research se centra en las personas y sus propósitos, para detectar sus pain points o necesidades no detectadas. Es quizá la importancia que tiene la observación de la persona y sus problemas lo que diferencia este proceso, de otros en los que o bien el centro de la innovación es un proceso que se busca mejorar (por lo general para eficientarlo o desintermediarlo) o en los que se trabaja sobre grupos de clientes a partir de agregados estadísticos (impersonales porque se sustentan en la fuerza del número)

Todo el Mundo Miente

Hemos visto que una de las características principales de DT es que se busca el origen del problema en la experiencia / vivencia de la persona (usuario, cliente, empleado, recurso… cuanto antes olvides esas palabras y vuelvas a usar la palabra “persona”, mejor) Por eso,  una de las formas de referirse o definir DT es Human Centered Design. Podría traducirse como Diseño Centrado en la Persona, a mí al menos me gusta más, porque Diseño Centrado en el Humano suena un poco ridículo (no va a ser Diseño Centrado en el Wookie)

Precisamente, una de las frases recurrentes en los capítulos de HOUSE es que todo el mundo miente. El paciente miente. Y parte del trabajo del episodio era descubrir que el niño lleva sordo desde los 7 años pero no lo quería reconocer, que el padre oye voces, o la madre se mete unos tiros cuando nadie mira. A veces los médicos tenían incluso que colarse en casa del paciente para descubrir que tenía moho en el cabecero de la cama, etc.

En general, sabemos menos de nuestros clientes de lo que nos gusta reconocer. Por eso es tan importante para mí el pensamiento crítico, la habilidad de sacar conclusiones a partir de la objetividad evitando el sesgo o el prejuicio. Cada vez que alguien dice “es que los clientes no quieren (pon aquí lo que sea)” deberíamos preguntarle en qué datos se sustenta esa afirmación. Y si alguien dice “mi madre no usaría (pon aquí lo que sea)” hay que invitarle amablemente a dejar el equipo.

El Equipo

Aunque no lo parezca, House trabaja con un equipo de doctores que se involucran tanto en el proceso de descubrimiento del paciente, como de diagnóstico de la enfermedad; y además se reparten los papeles durante la parte de aplicar el tratamiento. Y esto es así porque cada miembro del equipo aporta desde su propia especialidad y experiencia.

De la misma forma, otra de las características del proceso de DT es la creación de equipos multidisciplinares e interdepartamentales. De esta manera, se comparte a lo largo de la organización no sólo la visión del cliente y su necesidad (¿habéis conocido a alguien de Compras a quién le importe el cliente final?) sino la resolución del problema a través de la creación de un producto o servicio. Además, se rompen silos de información y estructuras monolíticas… vamos, todo ventajas.

Deja al Doctor, que sabe lo que hace

En muchos episodios los pacientes cuestionan el conocimiento o capacidad de las personas que les están atendiendo; bueno, en episodios y en la vida real. En general y por sobre-simplificar, un doctor adquiere durante la carrera un conocimiento general de muchos temas y luego se especializa en un área concreta en la que se desarrolla profesionalmente. En el caso de HOUSE, no es sólo la especialidad la que les lleva a entrar al Departamento de Diagnóstico Médico, sino su forma de pensar, abordar problemas y en general, apertura de miras.

House Design Thinking

Vicodin, divino tesoro (Imagen de Nancy L. Stockdale)

Podríamos decir que en el caso del DT la aproximación es equivalente. Quizá el campo de conocimiento o formación en DT no tiene la formalidad ni el reconocimiento de una carrera de Medicina, es más amplio y a la vez difuso (pese a que algunos centros de formación aspiran a erigirse en referentes). Pero igualmente, serán la especialización del profesional en competencias relacionadas con la creatividad y el diseño, junto con su forma de pensar y amplitud de miras las que le llevan a formar parte del equipo de diseño.

Como decía un poco más arriba, hay una serie de prácticas o técnicas que se asocian con el proceso de DT, aunque la verdad es que son comunes a muchas metodologías y disciplinas creativas, tanto del mundo del diseño industrial, la experiencia de usuario, el desarrollo de software o la gestión de la innovación en general. Hay también un cierto consenso es que no es tan importante la formación en el proceso general, como el dominio en el uso de las técnicas concretas que cada equipo emplee durante su proceso creativo.

A veces el Enfermo Empeora

Claro, como en HOUSE el caso tiene que durar lo que dura el episodio, en el proceso se prueban diferentes alternativas hasta dar con la causa (igual que Horatio, por mucho Horatio que sea, interroga y acosa policialmente a siete antes de trincar al malo) (no como Colombo, que siempre sabía quién era el asesino desde el principio, pero ese es otro post) Durante ese proceso iterativo, House y su equipo se enfrentan al fracaso, recogen nuevas hipótesis y vuelven a empezar.

Por eso también podríamos decir que el proceso de DT requiere una predisposición mental al proceso creativo, un orden para dar con la solución, y una importante tolerancia a la frustración para ser capaz de aprender y volver a empezar.

Quizá ese es el motivo por el que en muchas organizaciones la entrada en este proceso se hace a través de pequeños experimentos (como la gaseosa)

House es Hugh Laurie

Por último, no olvidemos que HOUSE es una ficción. Una ficción que además tiene como nombre el del protagonista. Hay una serie de 8 temporadas con su nombre porque House es el dueño absoluto e indiscutible de la resolución del caso, muchas de las veces por una genial ocurrencia de última hora (durante los últimos 10 minutos del capítulo, en el bloque que sigue a la última pausa para los anuncios).  

¿Y el equipo? Los del equipo están ahí como actores secundarios, para aportar equilibrio a la trama o para dinamizar la narración.

Bien, quizá esta sea otra de las lecciones a aprender de la serie. No existe la magia. No existe House. House en realidad es un actor inglés que se llama Hugh Laurie y acabó odiando su personaje y padeciendo secuelas físicas.

No puedes confiar en la ocurrencia genial de última hora. Sólo el Chamán te dirá que el éxito en el proceso de innovación depende del Chamán. En realidad, el éxito de proceso está en manos del equipo.

El software es como un toro, ¿no?

Publicado el por

En el año 2001 tuve la suerte de conocer a una persona que trabajaba en uno de los mayores fabricantes de software del mundo. Cuando me dió su tarjeta de visita, no pude sino observar estupefacto su título: era Evangelista Técnico. Me quedé siberet. Yo era un miserable Analista Programador, y eso de ser Evangelista me parecía lo más de lo más.

Con la edad, he llegado a asumir como algo normal la existencia de toda clase de Evangelistas; no en vano, el mundo de la informática está lleno de parábolas que intentan explicar, hacer ver, abrir los ojos, o simplemente, adoctrinar, qué es o qué deja de ser un proyecto de desarrollo de software. La mayoría de las veces, se usan para que alguien que paga por un sistema entienda que va a tener un retraso en un proyecto, un aumento del precio, la imposibilidad de lograr ciertos resultados, o todas ellas.

Software es como un toro

«En peores plazas hemos toreao»

Así que, iluminado por el trabajo ingente de Antii Aarne y Stith Thomson, me embarco en la romántica tarea de recopilar fábulas y folclore tradicional de los que vivimos en el mundo de la programación. Si conoces alguna analogía que no esté aquí recogida, estaré encantado de añadirla 🙂

Las Parábolas del Software

Lo que pasa es que el tema de las metáforas sobre el desarrollo de software tienen un riesgo inherente, ya lo decía Martin Fowler en el 2004. Utilizar esta clase de paralelismos puede no ser la mejor forma de responder a las inquietudes o problemas de la persona que está pagando por tu trabajo. Sobre todo si tu argumento se apoya en un concepto que la otra persona puede contra-argumentar, lo que en la práctica supone que has trasladado un problema a un dominio semántico diferente, en el que quizá no seas experto o no te sientas tan cómodo.

  • «9 mujeres no hacen un niño en 1 mes». Porque llega un momento en que por mucho que se añada gente a un equipo, la capacidad de reducir los plazos paralelizando el trabajo no es infinita. Sin embargo, tener un hijo es una tarea que por definición sólo puede hacer una persona y tiende a tardar en torno a 40-42 semanas. Por desgracia, lo normal es que tu proyecto de software incluya tareas que se pueden paralelizar hasta cierto límite y bajo ciertas consideraciones; y eso es exactamente lo que espera la persona que te paga por hacerlo: que seas capaz de organizar el trabajo de tu equipo dentro de ese límite.
  • «Desarrollar software es como construir una casa: necesita unos cimientos sólidos para no derrumbarse». Por eso, antes de poner las cortinas en las ventanas hay que levantar las paredes. Muy bonito, si no fuera porque el proceso de hacer los cimientos de una casa está sujeto leyes físicas, como cálculos de cargas o resistencia de materiales, profundidad, disposiciones, drenajes… Y sobre todo, donde hay normativas que cumplir. Nada de esto aplica a tu proyecto de software, la solidez de los cimientos de tu arquitectura en general depende de la persona que la diseña, y de su experiencia. Aunque hay patrones más o menos estándar, cada empresa de software construye los cimientos de sus proyectos a su manera, y la persona que los paga tiene que tener la certeza de que se están haciendo de manera correcta.
  • «Si quieres mover el baño 5cm, hay que tirar las paredes y romper los azulejos». Es una metáfora especialmente útil en aquellas situaciones en que si se hubieran pensando las cosas desde el principio, no habría que deshacer el trabajo. Nos lo recuerda habitualmente José Luis Vallejo, que además de ser mi CEO, es una de las pocas personas que conozco que ha lanzado una startup y se la ha vendido a Amazon. Sin embargo, a veces un cliente no quiere mover el baño, sólo quiere cambiar el modelo del sanitario, y para eso no hace falta picar el suelo ni romper los azulejos. Si lo haces, entonces tienes un problema.
  • «No puedes tener un Ferrari GTO al precio de un SEAT Panda». Usado para expresar que hay una relación entre calidad, potencia, rendimiento, diseño… y el precio que se ha de pagar por ello. Esta metáfora parte de la base de que una persona no sabe distinguir lo que es un Ferrari GTO de lo que es un SEAT Panda; cuando muchas veces lo único que quieren es un SEAT Panda con un motor preparado, faros tipo rally en la parrilla y unas llantas molonas.
SEAT Panda Carlos Sainz

Ojito con el Panda de Carlos Sainz (Imagen de brb83 en Slot Adictos)

  • «Esto tiene que hacerlo un experto, igual que no vas al dentista para que te opere de la cadera». No todas las personas son capaces de solucionar los mismos problemas, y con las mismas garantías. Lo que pasa es que tanto dentistas como cirujanos tienen una formación, una titulación y un Colegio que les habilita para hacer su profesión, de manera que cualquier persona puede comprobar su capacitación para esa intervención. Esto obviamente no ocurre en el mundo del software, donde muchas veces la única prueba que tiene el cliente de la capacitación del profesional proviene de su confianza en la empresa para la que trabaja.
  • «Para hacer unos huevos con bacon, la gallina se involucra, pero el cerdo se compromete» Usado durante muchos años para diferenciar el rol de las personas que son responsables del resultado del proyecto (Product Owner, Scrum Master y Equipo de Desarrollo) y los que están informados, opinan, o lo pagan. Por cierto, hace casi 5 años esta analogía desapareció de la guía Scrum, pero hay gente a la que le gusta mantenerla.
  • «No me pagas por apretar un tornillo, sino por saber qué tornillo hay que apretar». Es decir, no se juzga la tarea por la complejidad relativa a ojos de quién la observa, sino por el conocimiento que tuvo que adquirir el que la realiza. Esta es muy buena, y difícil de rebatir. En todo caso, diría que el problema muchas veces está en cuánto tiempo tarda un experto en encontrar el tornillo que hay que apretar, o que lo haga a través de un proceso de prueba y error que mine su credibilidad.
  • «Un proyecto de software es como subir al Everest: sabes de dónde sales, dónde quieres llegar y el camino que vas a seguir, crees que llevas todas las provisiones que necesitas y todos los días rezas por que no empeore el tiempo» Una metáfora útil para explicar que por muy experto que uno sea, hay circunstancias que escapan a nuestro control y que pueden hacer que todo acabe en tragedia. Esta también es buena. Sin embargo, puede volverse en tu contra si tú asumiste la responsabilidad planificar la expedición para llevar al equipo a la cumbre y ahora estás perdido en medio de la ventisca y se te ha olvidado coger el teléfono con enlace satélite.
  • «Programar es como conducir en mitad de un atasco, puedes ver lo que pasa a tu alrededor y tomar pequeñas decisiones, pero cambiar de carril no hará que el atasco termine antes» Útil para explicar que el ciclo de desarrollo es el que es, y llega un momento en que no puede acelerarse. Aquí lo que diría es que hay personas que no están dispuestas a comerse el atasco, y por eso sacan el Google Maps o el Waze antes de salir y coger una ruta más óptima, o que planifican su viaje para irse el día antes de la Operación Salida del Puente de Mayo.
  • «Un proyecto de software es como jugar con un Lego: puedes hacer una casa o un coche encajando las piezas que hayas comprado» Esta analogía que me sugería Luis Sánchez incluye además que hay es necesario un diseño preliminar tanto de la construcción como de las piezas, y que puede que no todas las piezas que tengas las necesites, ni que hayas comprado todas las que necesitas. Lo que está claro es que si el cliente quería hacer el coche, tienes que haber cogido ruedas.
  • «Cuando haces un jardín tienes una idea de cómo va a ser antes de plantarlo, aunque los detalles emergen después». Una idea de Félix Menéndez, que nos hace pensar que no sabes exactamente si debajo de la tierra habrá piedras, ni qué clase de insectos vas a encontrar, pero en cualquier caso, si no cuidas tu jardín seguramente las flores se sequen, y acabe todo lleno de malas hierbas. Interesante analogía, en este caso yo diría que es responsabilidad del jardinero haber elegido qué semillas tenía que plantar conociendo su ciclo de floración, cuándo había que regar, etc.
  • «Un proyecto de software es como hacer un pastel: necesitas una receta, reunir los ingredientes adecuados, seguir las instrucciones y respetar los tiempos de horneado» Esta idea foodie me la sugiere Daniel González, muy apropiada porque en la oficina echamos de menos las tartas que traía (a él también le echamos de menos) En este caso, es responsabilidad del cocinero haber comprado el producto en el Club del Gourmet o en los chinos. También diría que en el caso del software a medida, es el cocinero el que se ha inventado la receta, y que seguir la receta de un tercero no siempre es suficiente.
Pesadilla en la Cocina

Loca academia de cocineros

  • «Construir software es como levantar una Catedral: una combinación de arte y ciencia». Los que hemos leído «Los Pilares de la Tierra» nos sobrecogemos pensando en proyectos de 30 años y los malvados Hamleigh cuando Victor Sánchez utiliza esta metáfora. Tiene una derivada, y es que a veces las personas que están picando las piedras se olvidan de que su propósito es construir una catedral. Lo malo de construir catedrales es que a veces te coge a medio camino el cambio del románico al gótico.
  • «Desarrollar software a medida es como resolver un puzzle cuyas piezas tú mismo estás construyendo» Esta analogía es, hasta donde yo se, de mi propia cosecha. No recuerdo haberla leído, y estoy seguro de usarla desde el año 2008. Si estás resolviendo un puzzle y cambia la imagen de la referencia, seguramente las piezas que has construido ya no te sirvan. Como es mi propia analogía dejaré que seáis vosotros los que hagáis la contra-argumentación 🙂

¿Conoces más metáforas? Estoy ansioso por incorporarlas.