Podcast sobre Calidad y Ética en Ingeniería de Software

Kapitoly

El mito del programador solitario

¿Software a medida o para todos?

La obsesión por la calidad

El software no es un coche

El código de ética del ingeniero

¿Producto o Proceso?

¿Por Qué el Software Es Diferente?

Los Problemas Ocultos del Software

La Solución: Hablar el Mismo Idioma

¿Cómo Nace una Norma?

Midiendo lo Intangible

Orígenes de la Calidad

Un Cambio Impulsado por la Guerra

La Revolución Japonesa

¿Qué es la Calidad Hoy?

Un mercado para todos

Las apps de cada día

De artesanos a obreros

La gestión científica de Taylor

Nace la supervisión y el adiós

Přepis

Carmen: La mayoría de la gente piensa que la ingeniería de software es solo para genios que escriben código a la velocidad de la luz, encerrados en un sótano.

Hugo: Totalmente. Pero la verdad es que escribir el código es solo una pequeña, pequeñísima parte del rompecabezas. La verdadera ingeniería de software es mucho más que eso.

Carmen: ¿En serio? Entonces, ¿qué es exactamente? Creía que todo se reducía a teclear sin parar.

Hugo: Para nada. Imagina construir un rascacielos. No solo pones ladrillos uno encima de otro, ¿verdad? Necesitas planos, un equipo, materiales de calidad y un proceso para que no se caiga.

Carmen: Claro, sería un desastre si no.

Hugo: Pues con el software es igual. La ingeniería de software es la disciplina que se encarga de todo el proceso de producción de software. Desde la idea inicial hasta la entrega y el mantenimiento, buscando siempre la máxima calidad.

Carmen: Entendido. O sea, es la diferencia entre hacer una cabaña con ramas y construir una casa sólida. Estás escuchando Studyfi Podcast, donde desglosamos los temas de tus exámenes.

Hugo: Exacto. Cualquiera puede escribir un programa que funcione a medias, pero un verdadero ingeniero de software crea un producto de calidad, que es robusto, eficiente y fácil de mantener.

Carmen: Mencionaste la palabra "software" varias veces. Sé que suena obvio, pero ¿qué incluye exactamente ese término? ¿Solo las aplicaciones de mi teléfono?

Hugo: Buena pregunta. El software no son solo los programas de ordenador o las apps. También incluye toda la documentación asociada: manuales de usuario, especificaciones técnicas, todo lo que ayuda a entenderlo y usarlo.

Carmen: Ah, ¡la letra pequeña que nunca leemos!

Hugo: ¡Esa misma! Y estos productos de software se pueden dividir en dos grandes categorías: genéricos y personalizados.

Carmen: A ver, explícame eso. ¿Como la ropa de una tienda departamental versus un traje hecho a medida?

Hugo: ¡Perfecta analogía! Los productos genéricos son como la ropa de la tienda. Se desarrollan para un mercado general. Piensa en un procesador de textos o una app de edición de fotos. Millones de personas usan la misma versión.

Carmen: Tiene sentido. ¿Y los personalizados?

Hugo: Esos son el traje a medida. Se desarrollan para un cliente específico, con necesidades muy particulares. Por ejemplo, el sistema que controla el tráfico aéreo o el software que maneja la logística de una gran empresa.

Carmen: Ya veo. En los genéricos, la empresa que lo hace decide cómo funciona. En los personalizados, el cliente es el que manda y dice exactamente lo que necesita.

Hugo: Precisamente. Aunque hoy en día esa línea es un poco borrosa. Muchas empresas toman un producto genérico y lo adaptan para un cliente. El mejor ejemplo son los sistemas de planificación de recursos empresariales, como SAP.

Carmen: Fascinante. Es como comprar un traje de la tienda y luego llevarlo a un sastre para que te quede perfecto.

Hugo: Y en ambos casos, ya sea genérico o personalizado, hay una palabra clave que lo une todo: calidad.

Carmen: ¿Por qué es tan importante? Si el programa hace lo que tiene que hacer, ¿no es suficiente?

Hugo: Es que ahí está el truco. No es suficiente que funcione hoy. Debe ser confiable, seguro y fácil de modificar en el futuro. La idea de control de calidad no es nueva, de hecho, viene de la Revolución Industrial.

Carmen: ¿De las fábricas?

Hugo: Sí. Al principio, en la producción en masa, la calidad se basaba en la inspección. Un supervisor miraba el producto final y decidía si estaba bien o mal. Era como revisar los deberes al final y solo poner una nota.

Carmen: Suena un poco ineficiente. Si algo estaba mal, ya era tarde.

Hugo: Exacto. Luego, la cosa evolucionó. Se empezó a prestar más atención al proceso, a la forma de hacer el trabajo. Y el gran salto llegó en los años 30 con el Dr. Shewhart y su control de calidad estadístico.

Carmen: ¿Estadístico? Suena a muchas matemáticas.

Hugo: Un poco, sí. Creó los gráficos de control para monitorear el proceso de producción en tiempo real. La idea era detectar problemas mientras ocurrían, no al final. Así podías corregir el rumbo antes de que fuera un desastre.

Carmen: Y supongo que esa misma idea se aplica al software. Mejorar el proceso de creación para asegurar un buen producto final.

Hugo: ¡Has dado en el clavo! No esperamos a que el programa falle con miles de usuarios. Implementamos técnicas y métodos durante todo el desarrollo para garantizar su calidad desde el principio.

Carmen: Entonces, el software es un producto de ingeniería, pero me da la sensación de que es... diferente. No es como construir un puente o un coche.

Hugo: Es muy, muy diferente. Y esas diferencias son clave. Primero, el software no se deteriora con el tiempo como el hardware. Un chip se puede quemar, un disco duro puede fallar, pero el código no se "gasta".

Carmen: Pero a veces mis apps dejan de funcionar bien con las actualizaciones...

Hugo: ¡Ah! Eso no es deterioro, eso es obsolescencia o la introducción de nuevos errores. El código original sigue intacto. El problema es que el mantenimiento del software es mucho más complejo que el del hardware.

Carmen: ¿Más complejo que cambiarle el motor a un coche?

Hugo: Mucho más. Porque el software es en gran medida artesanal. Cada pieza está interconectada de formas complejas y a veces invisibles. Cambiar una cosa puede tener efectos inesperados en otra parte del sistema.

Carmen: El famoso efecto mariposa, pero con código.

Hugo: ¡Totalmente! Y eso nos lleva a otra característica peligrosa: es engañosamente fácil realizar cambios en el software. Parece que solo es borrar y escribir unas líneas.

Carmen: Sí, suena más fácil que cambiar una viga en un edificio.

Hugo: Exacto. Pero es una trampa. Ese pequeño cambio puede introducir un fallo catastrófico. Es como si un arquitecto te dijera que puede quitar una columna de soporte "fácilmente". Seguro que sí.

Carmen: Con esa complejidad, y sabiendo que el software controla desde los aviones hasta las finanzas, supongo que los ingenieros de software tienen una gran responsabilidad.

Hugo: Una responsabilidad inmensa. Piensa en ello: casi todos los países y todas las industrias dependen de sistemas informáticos. El software está en todas partes.

Carmen: Da un poco de vértigo.

Hugo: Por eso existe un código de ética para la ingeniería de software. No es solo un conjunto de reglas aburridas; es una guía para asegurarse de que el poder que tienen se usa para hacer el bien.

Carmen: ¿Como un juramento hipocrático para programadores?

Hugo: Algo así. Hay ocho principios clave, pero el primero es el más importante: actuar siempre en consonancia con el interés público.

Carmen: ¿Qué significa eso en la práctica?

Hugo: Significa que tu lealtad principal no es solo con tu jefe o tu cliente, sino con la sociedad. Si te piden que desarrolles un software que sabes que es inseguro o que podría dañar a la gente, tu ética te obliga a oponerte.

Carmen: Vaya, eso es potente. Pone la seguridad y el bienestar de las personas por encima de todo.

Hugo: Exacto. Otro principio es el de "Producto". Debes asegurarte de que lo que creas cumple con los más altos estándares profesionales. No vale con un "bueno, funciona". Tiene que ser excelente.

Carmen: Y también hay uno sobre los colegas, ¿verdad? Ser imparcial y apoyarlos.

Hugo: Sí, porque la ingeniería de software es un trabajo en equipo. La cultura de culpar a otros o de no compartir conocimiento es tóxica y lleva a productos de mala calidad. Se trata de ayudarse mutuamente para crecer y construir cosas mejores juntos.

Carmen: O sea, que ser un buen ingeniero de software no es solo saber de código, sino también ser ético, responsable y un buen compañero de equipo.

Hugo: No lo podría haber dicho mejor. Es una profesión con un impacto enorme en el mundo, y eso requiere un compromiso igual de grande.

Carmen: Y justo eso que mencionas sobre la organización de los proyectos me lleva a otra pregunta, Hugo. ¿Cómo sabemos si un software es realmente bueno? Es decir, ¿qué es la "calidad del software"?

Hugo: Esa es la pregunta del millón, Carmen. Y es mucho más profundo de lo que la gente cree. Para empezar, tenemos que diferenciar entre dos cosas: la calidad del producto y la calidad del proceso.

Carmen: ¿Dos tipos de calidad? Yo pensaba que la calidad era... bueno, calidad. O la tienes o no la tienes.

Hugo: No es tan simple. Piensa en la calidad del producto como la aplicación que usas en tu teléfono. ¿Funciona bien? ¿Es rápida? Pero luego está la calidad del proceso... cómo se diseñó y se construyó ese software.

Carmen: Ah, claro. Como la diferencia entre un coche bonito y el cómo se fabricó en la línea de montaje.

Hugo: ¡Exactamente! Y aquí está el truco: la calidad del producto depende casi por completo de la calidad del proceso. No puedes obtener un buen software si tu proceso de desarrollo es un caos. Es casi imposible.

Carmen: Tiene sentido. Un mal plano de construcción rara vez resulta en una casa sólida.

Hugo: Justo. Un buen proceso establece los objetivos de calidad desde el principio. Pero el software tiene unas características muy, muy particulares que lo diferencian de cualquier otro producto industrial.

Carmen: ¿A qué te refieres con que es diferente? Al final es un producto que se vende, ¿no?

Hugo: Sí, pero no se fabrica como un coche. Primero, el software es un producto mental. Es intangible, nace de la creatividad y la lógica de los ingenieros.

Carmen: O sea, no hay una materia prima que puedas tocar, como el acero o el plástico.

Hugo: Correcto. Se desarrolla, no se fabrica en una cadena de montaje. Por eso casi todo el coste está en la ingeniería, en las horas de pensar, diseñar y programar.

Carmen: Y supongo que eso lo hace más propenso a errores humanos.

Hugo: Totalmente. Además, la ingeniería de software como disciplina es muy joven comparada con, no sé, la ingeniería civil. ¡Aún estamos perfeccionando nuestras técnicas!

Carmen: O sea que todavía estamos construyendo puentes que a veces se caen.

Hugo: Una excelente analogía. Y aquí viene lo más curioso: un software con errores no se rechaza. Si compras un coche y los frenos no funcionan, lo devuelves. Si una app se cierra de vez en cuando... la reinicias y sigues adelante.

Carmen: Es verdad. Hemos normalizado los fallos en el software. Y me imagino que esa calidad hay que vigilarla desde el principio, no solo al final.

Hugo: ¡Claro! No puedes esperar a que el edificio esté terminado para darte cuenta de que los cimientos están mal. Revisar la calidad en cada fase —especificaciones, diseño, código— es fundamental. Arreglar un problema al final es carísimo, si es que se puede.

Carmen: Entonces, si es tan importante, ¿por qué parece que hay tanto software de mala calidad por ahí? ¿Cuál es la problemática real?

Hugo: Es una tormenta perfecta de varios factores. Primero, el software es cada vez más grande y complejo. Y además, nunca está "terminado".

Carmen: ¿A qué te refieres? Siempre hay actualizaciones, ¿no?

Hugo: Exacto. Es un producto dinámico. Evoluciona de una versión a otra. ¡Y cada cambio puede introducir nuevos problemas! Es como si a tu coche le cambiaran el motor mientras vas conduciendo.

Carmen: ¡Qué miedo! Suena a que es imposible conseguir un producto perfecto.

Hugo: Lo es. Conseguir un programa totalmente depurado es una utopía. Siempre habrá algún error escondido en algún rincón. Por eso se invierte tantísimo dinero en mantenimiento.

Carmen: Y por eso los proyectos se retrasan y se pasan de presupuesto tan a menudo, ¿verdad?

Hugo: Exacto. No se cumplen plazos, ni costes, ni a veces lo que el cliente pidió en un principio. Los costes de desarrollo suben, la productividad es baja... es un ciclo complicado.

Carmen: Y has mencionado algo sobre procesos artesanales. ¿No se supone que esto es alta tecnología?

Hugo: Se supone. Pero muchas veces, el desarrollo es más un arte que una ciencia. Faltan herramientas, faltan procesos estandarizados... y eso nos lleva al núcleo del problema.

Carmen: ¿Y cuál es ese núcleo? Suena a que hay muchas causas.

Hugo: Se pueden resumir en varias ausencias clave. Ausencia de especificaciones claras por parte del cliente. Ausencia de métodos de ingeniería aplicados de forma sistemática. Y escasez de personal con formación en las nuevas técnicas.

Carmen: O sea, un problema de comunicación y de método, en el fondo.

Hugo: ¡Bingo! Y la solución a un problema de comunicación es... crear un lenguaje común. En ingeniería de software, a eso lo llamamos normalización.

Carmen: ¿Normalización? ¿Como crear normas o reglas?

Hugo: Justo. La normalización es el proceso de crear guías, normas y convenciones para que todos los que trabajan en un proyecto hablen el mismo idioma. Define qué documentos crear, qué deben contener y qué pasos seguir.

Carmen: Entiendo. Es como darles a todos el mismo manual de instrucciones para que no cada uno construya a su manera.

Hugo: Exactamente. Las normas son la solución a la mayor necesidad de la industria del software: una comunicación precisa y sin ambigüedades entre los profesionales. Reduce costes, aumenta la productividad y, por supuesto, mejora la calidad.

Carmen: Pero crear estas normas debe ser un desafío enorme. ¿Quién decide qué es una norma y qué no?

Hugo: ¡Ah, es un proceso fascinante! Tomemos como ejemplo al IEEE, que es uno de los organismos más importantes. Todo empieza con una idea.

Carmen: ¿Cualquiera puede proponer una?

Hugo: Sí, un miembro puede sugerirla. Esa idea se convierte en una Petición de Autorización de Proyecto, o PAP. Se envía a todos los comités para que nadie esté trabajando en lo mismo.

Carmen: Para no inventar la rueda dos veces.

Hugo: Correcto. Luego, se crea un grupo de trabajo. Lo interesante es que cualquiera puede unirse. Se busca que participen profesionales de distintos niveles y empresas para que la norma sea lo más rica y útil posible.

Carmen: Y supongo que se reúnen, discuten, y... ¿ya está?

Hugo: ¡Ojalá fuera tan rápido! El grupo trabaja en un borrador. Ese borrador pasa por muchísimas revisiones y un proceso de votación muy estricto.

Carmen: ¿Qué tan estricto?

Hugo: Para que te hagas una idea, tiene que votar al menos el 75% de los expertos del grupo de votación, y de esos, el 75% tiene que dar el visto bueno. Todo este proceso, desde la idea inicial hasta la aprobación de la norma... puede tardar unos tres años.

Carmen: ¡Tres años! Wow. Y una vez aprobada, ¿qué pasa?

Hugo: Se publica y las empresas empiezan a usarla. Pero el ciclo no termina ahí. Los usuarios dan su feedback, sugieren mejoras... y a los cinco años, la norma se revisa por completo. Se decide si se mantiene, se modifica o se elimina porque ya hay algo mejor.

Carmen: Vale, entonces tenemos normas para mejorar el proceso. Pero volviendo al principio, ¿cómo medimos la calidad del producto final? ¿Cómo le ponemos un número a algo como la "usabilidad"?

Hugo: Muy buena pregunta. Para eso existen los modelos de calidad. Piensa en ellos como una jerarquía, una pirámide.

Carmen: De acuerdo, soy toda oídos.

Hugo: En la cima están los "factores de calidad". Esto es lo que ve el usuario: fiabilidad, eficiencia, usabilidad... los atributos externos.

Carmen: Lo que a mí, como usuaria, me importa.

Hugo: Eso es. Pero para conseguir esos factores, necesitamos bajar un nivel en la pirámide a los "criterios de calidad". Estos son atributos técnicos, internos, del propio software. Cosas que contribuyen a la fiabilidad, por ejemplo.

Carmen: Vale, lo que ven los desarrolladores.

Hugo: Y en la base de la pirámide, el fundamento de todo, están las "métricas". Estas son las medidas cuantitativas. Números. Por ejemplo, "el tiempo de respuesta a una acción debe ser inferior a 0.5 segundos".

Carmen: ¡Ah! Por fin algo concreto que se puede medir. Entonces, mides las métricas, que te ayudan a cumplir los criterios, y esos criterios, en conjunto, te dan los factores de calidad que el usuario percibe.

Hugo: Lo has clavado. Así es como un modelo de calidad nos permite definir, medir y planificar algo tan abstracto como la calidad. Y nos ayuda a entender cómo una pequeña decisión técnica puede afectar a la experiencia final del usuario. Es fascinante cómo todo está conectado.

Carmen: Y tiene sentido que esa producción en masa cambiara todo. Pero, ¿dónde queda la calidad en esa ecuación?

Hugo: ¡Esa es la pregunta del millón, Carmen! Y es que el concepto de "calidad" ha tenido un viaje fascinante. No es algo que inventamos con la tecnología.

Carmen: ¿A no? ¿Cómo eran las cosas antes?

Hugo: Piénsalo así: antes de las fábricas, tenías artesanos. Su objetivo era simple: hacer las cosas bien. Perfectas. Sin importar el coste o el tiempo que llevara. Era una cuestión de orgullo y de crear algo único.

Carmen: Claro, la autosatisfacción de un trabajo bien hecho. Pero eso no es muy escalable, ¿verdad?

Hugo: Para nada. Y por eso llegó la Revolución Industrial y lo puso todo patas arriba. De repente, el objetivo cambió drásticamente.

Carmen: A ver... ¿hacer muchas cosas, muy rápido, sin importar si eran buenas?

Hugo: ¡Exacto! La meta era satisfacer una demanda enorme y, por supuesto, obtener beneficios. La producción en serie era la nueva definición de calidad. Si podías fabricar mil, era mejor que fabricar uno perfecto.

Carmen: Suena un poco deprimente. ¿Qué hizo que volviéramos a preocuparnos por hacer las cosas bien?

Hugo: Una guerra mundial. Durante la Segunda Guerra Mundial, la mentalidad cambió de nuevo. Ya no bastaba con tener mil tanques.

Carmen: Necesitabas mil tanques que... ya sabes, funcionaran.

Hugo: Precisamente. La prioridad era asegurar la eficacia del armamento. No importaba el coste, pero sí que funcionara y que estuviera listo a tiempo. De repente, la calidad era eficacia más plazo de entrega.

Carmen: Y después de la guerra, todo el mundo intentaba reconstruirse. ¿Siguió esa misma idea?

Hugo: No exactamente. Aquí es donde la historia se pone interesante. Mientras el resto del mundo se centraba en producir masivamente para satisfacer la demanda, los japoneses tomaron un camino diferente.

Carmen: ¿Qué hicieron?

Hugo: Se obsesionaron con la calidad. Tipos como Deming y Juran visitaron Japón y sus ideas causaron una revolución. Empezaron a aplicar un concepto radical: hacer las cosas bien a la primera.

Carmen: O sea, en lugar de inspeccionar al final para ver qué estaba roto, se aseguraban de no romperlo desde el principio.

Hugo: ¡Has dado en el clavo! La idea era minimizar costes mejorando la calidad. Prevenir errores en lugar de corregirlos. Esto les permitió satisfacer al cliente y ser increíblemente competitivos.

Carmen: Entonces, hemos pasado del artesano al soldado y luego al innovador japonés. Es toda una evolución. ¿Cómo definimos la calidad hoy en día?

Hugo: Es una mezcla de todo eso, pero centrada en una cosa: el cliente. Grandes mentes y consultoras como Feigenbaum o Arthur Andersen nos han dado definiciones, pero todas giran en torno a lo mismo.

Carmen: A ver si lo adivino... ¿satisfacer las expectativas del cliente?

Hugo: Satisfacerlas y superarlas. Y no solo del cliente que compra el producto, sino también del cliente interno, o sea, tus propios empleados. La calidad total es un proceso de mejora continua para ser competitivo y mantener a todos contentos.

Carmen: Suena a que es un trabajo que nunca termina.

Hugo: Y no lo hace. Se trata de planificar la calidad que quieres, fabricar con esa calidad en mente y, finalmente, vender la calidad que el cliente desea. Es un ciclo constante. Y ese ciclo nos lleva a las herramientas que usamos para gestionarlo todo...

Carmen: Entendido. Pero ahora, salgamos de esos sistemas gigantes y a medida. ¿Qué pasa con el software que todos llevamos en el bolsillo, en nuestros móviles?

Hugo: ¡Buena pregunta! Ahí entramos en un mundo completamente distinto. El del software móvil o, como también se le llama, software de producto genérico.

Carmen: Suena más sencillo, ¿no? Simplemente... una app.

Hugo: En cierto modo, sí. La idea clave es que son sistemas aislados. Una organización los desarrolla con la intención de venderlos en el mercado abierto a cualquiera que quiera comprarlos.

Carmen: O sea, no se hacen para un cliente en particular, sino para... ¿todo el mundo?

Hugo: ¡Exactamente! Es como hornear miles de galletas idénticas para vender en una tienda, en lugar de hacer un pastel de bodas personalizado para una sola pareja.

Carmen: ¡Me gusta esa analogía! Y ahora quiero una galleta. Entonces, la empresa desarrolladora básicamente adivina lo que el mercado necesita.

Hugo: Así es. Ellos definen las características, lo construyen y lo lanzan, esperando que a la gente le guste y lo compre.

Carmen: Vale, tiene todo el sentido. ¿Me das ejemplos que usemos a diario?

Hugo: ¡Claro! Piensa en las apps más comunes. Procesadores de texto, hojas de cálculo, tu app de agenda o calendario... todas son ejemplos perfectos.

Carmen: Ah, ya veo. También las apps para dibujar en una tablet o incluso las herramientas para gestionar proyectos personales, ¿no?

Hugo: Justo esas. Cualquier software que puedas descargar de una tienda de aplicaciones y que no fue hecho específicamente para ti, entra aquí.

Carmen: Perfecto, queda clarísimo. Entonces, es software "listo para llevar". Pero esto me hace pensar... ¿qué hay del software que se integra en otros productos, como en un coche?

Carmen: Y hablando de grandes cambios, no podemos cerrar el episodio sin tocar la Revolución Industrial. ¿Cómo transformó eso el trabajo para siempre?

Hugo: ¡Excelente punto para terminar, Carmen! Fue un cambio brutal. Los talleres de artesanos, donde una persona hacía un producto completo, empezaron a desaparecer.

Carmen: Y supongo que esos artesanos se convirtieron en los trabajadores de las nuevas fábricas, ¿no?

Hugo: Exacto. Pasaron a formar parte de organizaciones enormes. Pero claro, gestionar a cientos de personas era un desafío totalmente nuevo.

Carmen: ¿Y cómo lo resolvieron? ¿Pusieron a más artesanos a cargo?

Hugo: ¡Ojalá fuera tan poético! No, aquí entra un personaje clave: Frederick Taylor y su "gestión científica del trabajo".

Carmen: ¿Gestión científica? Suena... estricto. ¿Como seguir una receta de cocina sin poder cambiar ni una pizca de sal?

Hugo: ¡Es una analogía perfecta! El objetivo era crear normas súper detalladas para que los trabajadores las cumplieran al pie de la letra. Esto instauró la división del trabajo.

Carmen: O sea, que el pensamiento creativo se quedaba fuera de la fábrica.

Hugo: Totalmente. Ya no hacías una silla entera. Quizás solo te dedicabas a lijar una de las patas... todo el día.

Carmen: ¡Qué locura! Pero si cada uno solo hace una pequeña parte, ¿quién se asegura de que todas las patas terminen en la silla correcta?

Hugo: ¡Ahí está la clave! Ese sistema provocó la necesidad de una nueva figura: el supervisor. Empleados dedicados solo a coordinar y vigilar que el proceso funcionara.

Carmen: Así que, para resumir, la división del trabajo nos trajo también a los jefes. Una cosa llevó a la otra.

Hugo: Básicamente. Desde las primeras civilizaciones hasta los supervisores de fábrica, hemos visto que organizar el trabajo siempre ha sido fundamental.

Carmen: Un viaje fascinante por la historia. Muchísimas gracias, Hugo, por iluminarnos una vez más. Y a todos nuestros oyentes, ¡gracias por acompañarnos en Studyfi Podcast!

Hugo: Un placer, Carmen. ¡Hasta la próxima!