Matz, Ruby y la felicidad del desarrollador: dando forma a la DX moderna

Matz y la idea central de la felicidad del desarrollador

Yukihiro “Matz” Matsumoto es el creador del lenguaje de programación Ruby. Cuando Ruby apareció a mediados de los años 90, Matz no intentaba ganar concursos de benchmarks ni diseñar el lenguaje “perfecto” académico. Buscaba algo más personal: un lenguaje que se sintiera bien de usar.

Qué significa “felicidad del desarrollador” (en términos sencillos)

La felicidad del desarrollador a menudo se malinterpreta como “hacer que el código sea divertido”. Está más cerca de esto: reducir la fricción cotidiana que desgasta la concentración y la confianza.

En la práctica, suele significar:

• Legibilidad: código que puedes entender rápido—even meses después.
• Flujo: menos interrupciones cuando estás resolviendo un problema (menos ceremonia, menos obstáculos).
• Disfrute: la sensación de que el lenguaje coopera contigo, no te pone a prueba.

La sintaxis y el diseño de Ruby se inclinaron hacia estas prioridades: código expresivo, convenciones amigables y una inclinación por la claridad sobre la astucia.

Qué cubre este artículo

Este artículo es un mapa de influencias de cómo esa filosofía “primero la felicidad” viajó.

Veremos cómo Ruby moldeó:

• Frameworks, especialmente Ruby on Rails y su énfasis en la convención.
• Ingeniería en startups, donde la velocidad de iteración y el código claro pueden ser decisivos.
• Expectativas modernas de DX, como herramientas suaves, testing ergonómico y valores por defecto útiles.

Lo que no es

Esto no es una biografía completa de Matz, ni una inmersión técnica en los internos de Ruby.

En su lugar, traza una idea simple—el software debería ser agradable de construir—y muestra cómo esa idea influyó en las herramientas, hábitos y normas que muchos equipos ahora dan por sentado.

Decisiones de diseño de Ruby que priorizan a las personas

Ruby se construyó sobre una premisa simple de Matz: optimizar para humanos, no para máquinas. Eso se nota en pequeños momentos cotidianos: leer código que escribiste hace tres meses, revisar un pull request rápidamente o enseñar a un nuevo compañero un patrón sin darle un manual.

“Optimizar para humanos” en términos sencillos

Ruby a menudo te permite expresar la intención directamente. Por ejemplo, 5.times { ... } se lee como una frase, y user&.email señala claramente “solo si existe”. Incluso el trabajo común con datos tiende a mantenerse legible: orders.map(&:total).sum enfatiza lo que quieres, no la mecánica del bucle.

Esta expresividad reduce la sobrecarga mental porque pasas menos tiempo traduciendo pasos “con forma de ordenador” de vuelta a significado “con forma humana”. Cuando el código se lee como la idea, los equipos pueden moverse más rápido con menos malentendidos.

Consistencia y el principio de la menor sorpresa

Ruby se apoya en convenciones que resultan predecibles una vez aprendidas: los métodos suelen comportarse de forma consistente, los nombres son por lo general literales y la librería estándar anima a patrones familiares (each, map, select). Esa predictibilidad importa a nivel de equipo.

Cuando los compañeros pueden adivinar cómo funciona una API, hacen menos preguntas, revisan código con más confianza y evitan que los debates de estilo consuman la semana. El “principio de la menor sorpresa” no significa nunca ser sorprendido: significa minimizar sorpresas innecesarias.

Compensaciones: expresividad vs. rigidez

La flexibilidad de Ruby puede ser un arma de doble filo. Varias maneras de escribir lo mismo pueden crear bases de código inconsistentes sin convenciones acordadas. Y el tipado dinámico puede trasladar ciertos errores del “tiempo de compilación” al tiempo de ejecución.

La ventaja es velocidad y claridad cuando se usa bien; el coste es disciplina: estilo compartido, buenos tests y una cultura de escribir código pensando en el siguiente lector, no solo en el autor presente.

Rails y las convenciones que simplificaron el desarrollo web

Rails convirtió la filosofía “hacer felices a los programadores” de Ruby en un flujo de trabajo práctico: deja de debatir la configuración y empieza a enviar funcionalidades. En vez de pedirte que montes cada pieza desde cero, Rails asume una estructura por defecto sensata y te empuja a seguirla.

Por qué “convención sobre configuración” se siente como felicidad

Mucho de la frustración en el desarrollo web venía de decisiones repetitivas: dónde colocar archivos, cómo se mapean las URLs al código, cómo conectar con una base de datos o cómo nombrar cosas. Las convenciones de Rails reducen esa carga de decisiones.

Cuando el framework “sabe” que un modelo User se mapea a la tabla users, o que un controlador llamado OrdersController manejará páginas relacionadas con pedidos, pasas menos tiempo cableando y más tiempo construyendo. Esa simplicidad no es magia: es un acuerdo compartido codificado en el framework.

Una forma por defecto de construir aplicaciones web rápido

Rails popularizó la idea de que una app web debe tener un punto de partida opinado: routing, controllers, views, jobs en background, migraciones y una estructura de carpetas estándar. Los proyectos nuevos se parecen entre sí, lo que facilita copiar patrones, seguir tutoriales y reutilizar el conocimiento del equipo.

Ese “camino por defecto” también soporta iteración rápida: scaffolding, generators y herramientas integradas ayudan a convertir una idea en una funcionalidad funcionando con menos pasos.

Beneficios de legibilidad y onboarding (con una precaución)

Dado que las apps Rails tienden a seguir una estructura previsible, los compañeros suelen encontrar el archivo correcto rápido—even si no lo escribieron. Eso importa para el onboarding: la gente aprende las convenciones una vez y luego navega con confianza.

Las convenciones ayudan sobre todo cuando un equipo está de acuerdo con ellas. Si constantemente luchas contra el framework o mezclas patrones en conflicto, pierdes el mapa compartido que hace que Rails parezca simple en primer lugar.

Más allá de Rails: el ecosistema de frameworks Ruby

Rails es la estrella principal, pero el ecosistema Ruby siempre tuvo espacio para gustos distintos y equipos con necesidades diferentes. Esa variedad es parte de por qué Ruby siguió siendo agradable incluso cuando Rails no era la opción correcta.

Alternativas y complementos: elige tu nivel de “framework”

Si Rails parecía demasiado opinado o pesado para un servicio pequeño, los equipos a menudo recurrían a Sinatra: routing mínimo, endpoints rápidos y la estructura justa para mantenerse legible. Hanami tomó otra ruta: límites más explícitos, una separación de preocupaciones más limpia y una arquitectura que a algunos equipos les resultó más fácil de escalar sin tanta “magia” de Rails. También verás opciones como Roda para apps centradas en rendimiento y Grape para servicios orientados a API.

El punto clave: Ruby no imponía una única forma “correcta” de construir apps web. Podías adaptar el framework al problema, no al revés.

Frameworks más pequeños, distintos tamaños de equipo

Los frameworks pequeños soportaron un espectro de estilos de trabajo:

• desarrolladores en solitario que lanzan un prototipo rápido
• equipos pequeños que mantienen unos pocos endpoints
• organizaciones grandes que dividen sistemas en múltiples servicios con propiedad clara

Esa flexibilidad ayudó a que Ruby encajara tanto en startups como en equipos maduros sin requerir un reinicio total de cómo a la gente le gusta programar.

Gems compartidas y patrones comunes

Aunque los frameworks diferían, los equipos compartían una caja de herramientas común: Rack como base web, gems para autenticación, jobs en background y serialización, y una cultura de extraer piezas reutilizables. Bundler hizo que la gestión de dependencias se sintiera consistente entre proyectos, reduciendo la fricción al moverse entre codebases.

Qué significa “la forma Ruby” a través de frameworks

La “forma Ruby” no es “usa Rails”. Es valorar código legible, objetos pequeños y composables, valores por defecto útiles y un énfasis en hacer que la programación cotidiana sea satisfactoria—even cuando las elecciones de framework divergen.

Startups y el atractivo de iterar rápido con Ruby

Las startups suelen ganar (o perder) por la velocidad de aprendizaje: ¿puedes construir algo real, ponerlo frente a usuarios y ajustar antes de quedarte sin tiempo o dinero? Ruby—especialmente con Rails—encajó bien porque permitía a equipos pequeños convertir ideas en software funcionando sin un gran grupo de plataforma o una larga fase de configuración.

Por qué Ruby conectó con los MVPs

La sintaxis legible de Ruby y el enfoque “convención sobre configuración” de Rails redujeron el número de decisiones necesarias para empezar. Para equipos de producto iniciales, eso significó menos energía en cablear lo básico y más tiempo en partes visibles al usuario: onboarding, facturación, permisos, notificaciones y la iteración interminable alrededor del UX.

La iteración rápida también cambió las expectativas internas. Enviar cambios se convierte en un hábito diario, no en un evento trimestral. Cuando los cambios son baratos, los equipos prueban más ideas, miden antes y tratan el código como algo que se refina continuamente, no algo que se “termina”.

Adopción en el mundo real (contexto, no hype)

Ruby se ha usado en producción en empresas que valoran la iteración de producto y la entrega web. GitHub dependió de Rails durante años mientras crecía. Shopify construyó una gran plataforma de comercio con Ruby/Rails en su núcleo. Basecamp (el origen de Rails) lo usó para gestionar un negocio de producto con un equipo pequeño. Otros—como Airbnb en sus inicios—usaron Rails intensamente antes de mover partes del stack conforme cambiaban los requerimientos.

Dónde Ruby encaja mejor

Ruby destaca para equipos centrados en producto que construyen negocios web: marketplaces, herramientas SaaS, paneles administrativos y cualquier cosa donde la UI, el modelo de datos y el flujo cambien con frecuencia. Se trata menos del rendimiento bruto y más de facilitar el cambio—una ventaja que encaja perfectamente con la vida en una startup.

Cultura de equipo: la felicidad como estrategia de productividad

La felicidad del desarrollador no es un “lujo” opcional; es una estrategia de gestión con efectos medibles. Los equipos que se sienten bien en su día a día tienden a lanzar con más consistencia, discutir menos sobre trivialidades y quedarse más tiempo. Esa conexión importa porque contratar es caro, el tiempo de incorporación es real y la moral se filtra en la calidad del producto.

Contratación, retención y moral

Cuando los ingenieros dicen que disfrutan su trabajo, a menudo apuntan a cosas previsibles: menos sorpresas frustrantes, sensación de progreso y compañeros que respetan el tiempo. Una cultura que valora la felicidad atrae candidatos que cuidan la artesanía y reduce la rotación porque la gente no se siente quemada o atascada en incendios continuos.

La claridad multiplica la colaboración

El código legible es una herramienta social. Reduce la “energía de activación” para la revisión de código, centra las discusiones en la intención del producto en lugar de descifrar trucos ingeniosos y ayuda a los equipos a avanzar sin depender de héroes.

Por eso el énfasis de Ruby en la expresividad encaja bien con prácticas colaborativas: cuando el código es más fácil de entender, más personas pueden contribuir con confianza.

Pairing, mentoría y onboarding

El pair programming y la mentoría funcionan mejor cuando el artefacto compartido—el código—apoya la conversación. Nombres claros, patrones consistentes y tests sencillos facilitan que un nuevo compañero siga, haga las preguntas adecuadas y empiece a cambiar el código con seguridad.

El onboarding deja de ser memorizar conocimiento tribal y pasa a ser aprender las convenciones del equipo.

Evita la mitología

La felicidad no aparece automáticamente por escoger un lenguaje o framework. Los equipos todavía necesitan lo básico: propiedad clara, alcance razonable, normas de revisión de código, documentación viva y tiempo para pagar deuda técnica.

Piensa la “felicidad del desarrollador” como un resultado de buenas prácticas—Ruby puede mejorar la experiencia por defecto, pero la cultura convierte eso en productividad sostenida.

Expectativas de DX que Ruby ayudó a normalizar

Ruby no solo popularizó un lenguaje: definió un tono sobre cómo debería sentirse una “buena experiencia de desarrollador”. Muchas comodidades que hoy se dan por supuestas en plataformas modernas fueron normalizadas por Ruby y, en especial, por Rails.

Los valores por defecto son una característica

Rails dejó claro: los valores por defecto sensatos ahorran tiempo y reducen la fatiga de decisiones. Generadores, scaffolds y plantillas de aplicaciones permiten que los equipos empiecen a construir funciones reales rápidamente, con una estructura de proyecto familiar en distintas empresas.

Esa idea—los valores por defecto importan—aparece hoy en todo, desde starters de CLI hasta frameworks full-stack opinados. Incluso cuando los equipos rechazan el scaffolding, esperan que una herramienta ofrezca un camino claro, no un lienzo en blanco.

Errores, docs y ejemplos como parte del producto

La cultura Ruby trató el feedback hacia desarrolladores como parte de la calidad. Mensajes de error claros, trazas legibles y documentación con ejemplos se volvieron imprescindibles.

Eso generó una expectativa más amplia: si una librería es difícil de entender, está incompleta. Las buenas gems no solo funcionaban; te enseñaban a usarlas.

“Baterías incluidas” sin pesadez

Ruby fijó el listón para frameworks que se sienten completos desde el principio: routing, patrones ORM, migraciones, hooks de testing, jobs en background y entornos previsibles. La idea no era encerrarte: era evitar tener que montar lo básico desde cero.

Qué esperan hoy los equipos

A través de stacks, los desarrolladores esperan ahora:

• un “camino feliz” guiado para proyectos nuevos
• convenciones fuertes con salidas fáciles
• éxito en la primera ejecución vía plantillas y generators
• documentación que funcione como onboarding

Esas expectativas no empezaron con Ruby, pero Ruby las hizo más difíciles de ignorar.

Herramientas que suavizaron los flujos de trabajo en Ruby

La historia de “felicidad del desarrollador” de Ruby no es solo sintaxis: también son las herramientas diarias que hicieron los proyectos previsibles. La comunidad Ruby normalizó una idea simple: si la cadena de herramientas es calmada y consistente, los equipos avanzan más rápido con menos estrés.

RubyGems + Bundler: dependencias de confianza

RubyGems hizo compartir librerías sencillo, pero Bundler dio confianza a los equipos de que estaban ejecutando la misma app en todas partes. Un Gemfile describe de qué dependes, y el lockfile fija versiones exactas para que “funciona en mi máquina” ocurra con menos frecuencia.

Los flujos típicos eran:

bundle install
bundle exec ruby app.rb

Ese prefijo bundle exec puede parecer pequeño, pero es un marcador cultural: ejecuta todo dentro del entorno conocido y válido del proyecto.

Rake: tareas repetibles sin ceremonia

Rake convirtió tareas comunes en comandos nombrados y repetibles—configurar la base de datos, correr tests, generar código o arreglos de datos. En vez de conocimiento tribal (“ejecuta estos cinco comandos en este orden”), los proyectos ofrecen una tarea única fácil de documentar y difícil de estropear.

bundle exec rake db:setup
bundle exec rake test

IRB y Pry: explorar mientras construyes

Consolas interactivas como IRB—y luego Pry—fomentaron un bucle de feedback corto. Los equipos podían inspeccionar objetos, probar una consulta o validar un poco de lógica de negocio en segundos. Ese estilo de “tocar el sistema hasta que tenga sentido” redujo la barrera para depurar y aprender código desconocido.

Guía práctica: mantener la cadena de herramientas pequeña

Si quieres la suavidad al estilo Ruby en cualquier stack, toma prestado el principio:

• Estandariza un flujo de dependencias (y compromete el lockfile).
• Prefiere unos pocos comandos conocidos en vez de docenas de scripts ad hoc.
• Haz obvio el “camino feliz”: un paso de instalación, un paso para ejecutar, un paso para testear.

Las herramientas pequeñas y consistentes no solo ahorran minutos: reducen la incertidumbre, que suele ser el verdadero drenaje de los equipos.

Cultura de testing y el auge del QA amigable para desarrolladores

Ruby no inventó el testing, pero ayudó a que se sintiera como parte normal del desarrollo diario—algo de lo que los equipos hablaban temprano, no solo después de un bug en producción. Ese cambio importó porque enmarcó la calidad como soporte a la felicidad del desarrollador: menos regresiones sorpresivas, menos miedo al refactor y expectativas más claras sobre qué significa “terminado”.

RSpec y Minitest: tests como conversación por defecto

Dos herramientas se convirtieron en anclas culturales. RSpec popularizó especificaciones legibles y enfocadas en comportamiento (estilo “describe/it”) que facilitan comunicar la intención en una revisión de código. Minitest, más cercano a la librería estándar y más ligero, ofreció una opción sin ceremonia. Los equipos elegían según preferencia, pero el resultado clave fue el mismo: escribir tests dejó de ser una práctica de nicho y pasó a ser parte de cómo los equipos discuten diseño.

Herramientas que hicieron TDD accesible

La buena ergonomía bajó la barrera de entrada. Ejecutar un archivo, centrarse en un test, obtener mensajes de fallo claros e iterar rápido hizo que el TDD se sintiera menos como una disciplina que hay que “dominar” y más como un flujo de trabajo en el que puedes ir entrenándote.

Esto fue crucial en apps Rails, donde los bucles de feedback rápidos hicieron práctico escribir un test, hacerlo pasar y refactorizar sin romper comportamiento.

Por qué las startups se beneficiaron (y cuándo ser pragmático)

Para las startups, los tests ofrecían confianza mientras se movían rápido: refactors más seguros durante pivotes, menos tiempo volviendo a comprobar funciones antiguas y menos hotfixes nocturnos. Aun así, los equipos Ruby aprendieron una restricción sana: la profundidad de testing debe coincidir con el riesgo del producto—los flujos centrales y la lógica compleja merecen cobertura fuerte, mientras que detalles de UI de bajo impacto pueden merecer menos atención.

Escalando Ruby: realidades, compensaciones y patrones comunes

La reputación de Ruby de “no ser el runtime más rápido” está justificada—pero también es incompleta. La mayoría de equipos Ruby no ganan exprimendo microsegundos de cada línea; ganan manteniendo el sistema comprensible y luego dedicando esfuerzo de rendimiento donde importa.

La preocupación por el rendimiento, realísticamente

Ruby puede sentirse lento cuando estás limitado por CPU, procesando muchos datos en proceso o escalando consultas ineficientes. Para apps web típicas, sin embargo, el cuello de botella suele ser I/O: llamadas a BD, peticiones de red y servicios externos. Ese encuadre cambia la hoja de ruta.

Lo que los equipos realmente hacen para escalar

Los patrones comunes son sorprendentemente consistentes:

• Caching: caché de página/fragmentos, caching HTTP y caches por clave (Redis/Memcached) para evitar recomputar trabajo.
• Jobs en background: mover trabajo lento o con picos fuera del camino de la petición (emails, exportes, procesamiento de webhooks) para mantener la latencia visible estable.
• Disciplina en la base de datos: índices, revisión de consultas, evitar N+1 y tratar el esquema de BD como una característica de rendimiento, no como un pensamiento tardío.

Esto tiene menos que ver con “trucos de Ruby” y más con construir sistemas que se comporten de forma predecible.

Compensaciones y felicidad del desarrollador

Hay un ángulo claro de DX: Ruby facilita enviar funcionalidades, pero escalar añade piezas móviles—colas, caches, más observabilidad. La clave es añadir complejidad deliberadamente, manteniendo convenciones y herramientas (profilers, APM, análisis de consultas) cerca del flujo diario para que el trabajo de rendimiento no se convierta en tarea de un especialista exclusivo.

Cuándo los equipos consideran alternativas

Cambiar de stack suele volverse racional cuando aparecen señales repetibles: saturación de CPU sostenida, coste de infraestructura alto para un rendimiento modesto o requisitos del producto que demandan cargas intensivas en cómputo y baja latencia. Muchos equipos mantienen Ruby para la “app central” y externalizan puntos calientes a servicios especializados—ganando velocidad sin renunciar a la productividad que hizo valioso a Ruby.

Cómo Ruby influyó en la experiencia del desarrollador moderna en otros stacks

La contribución más duradera de Ruby no fue un truco de sintaxis: fue un conjunto de expectativas sobre cómo debería sentirse el desarrollo. Una vez que los equipos experimentaron un flujo optimizado para la comodidad y la velocidad humanas, fue más difícil aceptar plataformas que trataran a los desarrolladores como una consideración secundaria.

Cómo viajaron las ideas

Muchos de los valores por defecto de Ruby/Rails se convirtieron en patrones que otros ecosistemas luego adoptaron.

• Convención sobre configuración: Rails popularizó que los valores sensatos pueden sustituir una configuración interminable. Aún hoy ves frameworks que generan un proyecto funcional con estructura de directorios clara, nombres predecibles y funciones incluidas.
• Gestión de paquetes y disciplina de dependencias: Bundler hizo que la resolución de dependencias y las instalaciones reproducibles se sintieran normales. Hoy, lockfiles y entornos reproducibles son expectativas estándar en muchos lenguajes.
• Herramientas amigables: El énfasis de la comunidad Ruby en errores legibles, documentación accesible, generators y “un comando para empezar” sembró la mentalidad de que la herramienta es parte del producto, no una tarea secundaria.

Paralelismos en otros lados (sin reclamar causalidad directa)

Otros stacks llegaron a conclusiones similares por sus propias razones—bases de usuarios mayores, nuevos modelos de despliegue y competencia por talento. Aun así, los paralelismos son evidentes: herramientas de scaffolding, plantillas opinadas de proyectos, consolas interactivas y un foco más fuerte en el onboarding del desarrollador.

También ves esta presión aplicada a paradigmas de construcción más nuevos. Por ejemplo, herramientas de flujo asistido como Koder.ai toman el playbook de Rails en otra forma: un camino guiado que reduce la configuración y la fatiga de decisiones para que pases más tiempo validando ideas de producto y menos en ensamblar infraestructura.

DX como requisito de primera clase

Ruby ayudó a normalizar la idea de que la experiencia del desarrollador afecta resultados de negocio: iteración más rápida, menos problemas en el onboarding y bases de código más consistentes. Ese encuadre movió la DX de “agradable de tener” a algo que los líderes pueden justificar—al mismo nivel que rendimiento o fiabilidad.

Qué sugiere esto sobre plataformas futuras

Los ganadores futuros probablemente combinen capacidad técnica con ergonomía emocional: valores por defecto claros, modos de fallo útiles, documentación excelente y herramientas que hagan que el camino más simple sea también el mejor. Ruby no “ganó todo”, pero cambió lo que muchos equipos ahora se niegan a tolerar.

Conclusiones prácticas para equipos que quieran construir para la felicidad del desarrollador

La felicidad del desarrollador no es un extra que añades después: es un conjunto de decisiones que integras en cómo se hace el trabajo. El legado de Ruby recuerda que las pequeñas fricciones se acumulan y que los valores por defecto bien pensados pueden hacer a un equipo más rápido sin quemarlo.

Lista simple de DX (aplica a cualquier stack)

Empieza por cambios que reduzcan el “dolor de fondo”:

• Docs que respondan preguntas reales: un “getting started” corto, una página de “cómo desplegamos” y una sección de resolución basada en incidentes recientes.
• Valores por defecto sensatos: layout estándar del proyecto, un linter/formatter, un comando de tests, una forma de ejecutar la app localmente.
• Bucles de feedback rápidos: tests rápidos, salida CI clara y forma de reproducir fallos localmente.
• Bajar el coste del cambio: herramientas para refactor seguro, propiedad clara y PRs pequeños con tiempos de revisión previsibles.
• Hacer visible el éxito: plantillas para issues/PRs, ejemplos de buenos patrones y “recetas” internas ligeras.

Evalúa herramientas con la lente “felicidad + mantenibilidad”

Al elegir framework, librería o plataforma, haz dos preguntas:

• Felicidad: ¿reduce la carga cognitiva? ¿Los errores son comprensibles? ¿El “camino dorado” es fácil de seguir? ¿Ayuda a que los recién llegados sean productivos rápido?
• Mantenibilidad: ¿seguiría siendo legible en dos años? ¿Las actualizaciones son predecibles? ¿Hay una vía de escape cuando los valores por defecto fallan? ¿Podemos observar y depurar en producción?

Una regla práctica: si una herramienta hace las tareas fáciles más fáciles pero convierte las tareas difíciles en misterios, puede añadir estrés a largo plazo.

Esto también es útil para desarrollos asistidos por IA: una plataforma debe hacer obvio el camino feliz manteniendo al equipo en control. Por ejemplo, Koder.ai enfatiza un flujo guiado (modo planificación, snapshots, rollback y exportación de código fuente) para que la velocidad no implique sacrificar mantenibilidad.

Seguid aprendiendo (y compartid el lenguaje de la DX)

Si queréis ampliar, ved /blog/dx-basics y /blog/convention-over-configuration. Incluso si vuestro equipo no usa Ruby, las ideas subyacentes se traducen.

La alegría es una decisión de diseño, no una casualidad: tratad la felicidad del desarrollador como un requisito de producto para vuestra plataforma interna y normalmente obtendréis mejor moral y mejores resultados.