Si diriges una organización de ingeniería, conoces el coste que nunca aparece en un informe: las horas que un desarrollador pierde levantando un entorno, adivinando cómo se compila el proyecto o esperando dos días por una revisión. Por separado cada una parece inofensiva; en todo un equipo, la fricción del trabajo diario es uno de los costes más caros y menos medidos que soporta una empresa tecnológica. Una buena developer experience (DevEx) es, sencillamente, el trabajo de eliminar esa fricción.
Por nuestra experiencia, la DevEx rara vez es un problema de talento. Más a menudo es una cuestión de herramientas, entornos y estándares que nadie trató nunca como un producto. Nosotros lo enfocamos al revés: tratamos la plataforma interna y el proceso como un producto cuyo usuario es el ingeniero. Y aunque no tengas un equipo de plataforma en casa, cubrimos esos roles con competencias de DevOps y platform engineering.
¿Por qué la developer experience marca la velocidad de entrega y la retención?
La razón es directa: un ingeniero productivo dedica la mayor parte de su tiempo a resolver el problema de negocio, no a pelearse con las herramientas. Cuando el camino de la idea a producción es corto y previsible, el equipo entrega más rápido, sin heroicidades; cuando está lleno de obstáculos, el ritmo cae y tu mejor gente empieza a mirar alrededor.
La retención es aquí la parte infravalorada. Un desarrollador con experiencia rara vez se va por una sola cosa, pero las pequeñas frustraciones se acumulan: una build inestable, un entorno que solo «funciona en mi máquina», una revisión que no termina nunca. Una buena DevEx no es, por tanto, solo una palanca de productividad; es un argumento real para retener a las personas más caras de reemplazar.
¿Qué son el platform engineering y una plataforma interna para desarrolladores?
El platform engineering es la disciplina que coge las partes repetitivas y tediosas del trabajo de un ingeniero y las convierte en capacidades listas y de autoservicio. El resultado es una plataforma interna para desarrolladores (IDP): una capa que permite a un desarrollador levantar un nuevo servicio, entorno o pipeline sin abrir un ticket a otro equipo. No se trata de comprar una herramienta, sino de montar una experiencia coherente con piezas que normalmente ya tienes:
- golden paths, los caminos recomendados y ya asfaltados para construir y desplegar servicios,
- un catálogo de servicios y plantillas, para que un proyecto nuevo arranque con valores por defecto sensatos,
- autoservicio para entornos, secretos y recursos, sin intermediarios manuales,
- una capa de observabilidad conectada por defecto, no pegada al final.
Una buena plataforma es fina donde los equipos necesitan libertad y opinada donde un estándar ahorra tiempo a todo el mundo.
¿Qué herramientas de desarrollo y capacidades de autoservicio dan más retorno?
El retorno más rápido viene de aquello que un ingeniero hace muchas veces por semana. Por eso empezamos por las capacidades de autoservicio que sacan al equipo de la cola de tickets de otro:
- levantar servicios y entornos bajo demanda a partir de plantillas predefinidas,
- pipelines CI/CD por defecto, en vez de configurarlos desde cero en cada repositorio,
- gestión de secretos y accesos que sea segura pero no obligue a pedir cada clave,
- una vista única del estado de los servicios (logs, métricas, despliegues) en un solo sitio.
Lo que cuenta no es el número de herramientas, sino atarlas en un conjunto comprensible. Hemos visto a muchos más equipos sufrir por una maraña de herramientas inconsistentes que por falta de ellas, así que antes de añadir nada miramos qué se puede simplificar y unificar.
¿Cómo acortan la documentación y las rutas de onboarding el tiempo hasta el primer commit?
El onboarding es la prueba más despiadada de la developer experience. Si una persona recién incorporada necesita una semana para compilar el proyecto y llegar a producción, es señal de que todo el equipo sufre esa fricción, solo que se ha acostumbrado. Por eso tratamos el tiempo hasta el primer commit con sentido como una métrica, no como folclore.
Preferimos documentación que viva cerca del código: un README que de verdad permita compilar el proyecto, golden paths documentados y listas de onboarding que mantienen al día quienes acaban de pasar por él. En vez de un documento gigante que nadie lee, diseñamos rutas cortas y orientadas a tareas: «cómo ejecutarlo en local», «cómo desplegar», «cómo añadir un servicio nuevo».
¿Cómo es un aprovisionamiento sensato de entornos para los equipos?
Los entornos son el punto donde más a menudo se rompe la DevEx. El clásico problema de «en mi máquina funciona» viene de entornos montados a mano, desviados y imposibles de reproducir. Lo atacamos desde el ángulo de la repetibilidad.
En la práctica eso significa infraestructura como código (Terraform, Helm) y contenerización, de modo que un entorno se pueda recrear con un único comando y no desde la memoria de una persona. Añadimos entornos efímeros por pull request y paridad entre local, pruebas y producción, para que las sorpresas no esperen al despliegue. El resultado es prosaico pero medible: menos tiempo en «por qué no arranca esto» y más en trabajo de verdad.
¿Cómo moldean la developer experience los estándares de código y la práctica de revisión?
A veces se confunden los estándares con burocracia, cuando son justo lo contrario: un estándar bien elegido significa menos decisiones y menos discusiones en la revisión. Cuando el formateo, el linting, las convenciones y las puertas de calidad están automatizados, la revisión deja de ser una pelea sobre estilo y empieza a tratar de lo que importa: la lógica y el riesgo.
La propia revisión es una pieza de DevEx que se olvida con facilidad. Una pull request colgada dos días no es solo un retraso; es un flujo roto y una frustración creciente para quien la escribió. Por eso la tratamos como un asunto humano y de proceso a la vez:
- cambios pequeños y revisables en vez de mega-PR inmanejables,
- expectativas claras sobre el tiempo de respuesta en la revisión,
- automatizar lo que se pueda automatizar (lint, pruebas, escaneos), para que las personas miren el significado,
- una cultura de feedback en la que la revisión enseña en vez de bloquear.
¿Cómo se mide la developer experience para no ir a ciegas?
Sin medición, la DevEx se convierte en opiniones. Preferimos anclarla en señales que combinan datos duros con lo que los ingenieros sienten de verdad. Miramos métricas de flujo en la línea de DORA (frecuencia de despliegue, lead time del commit a producción, tasa de fallos por cambio, tiempo de restauración) y, junto a ellas, usamos encuestas ligeras al estilo DevEx/SPACE, porque parte de la fricción solo se ve desde dentro.
Lo importante es no convertir las métricas en otra fuente de presión. Los números deben señalar cuellos de botella, no calificar a las personas, y decirte dónde golpear primero y si el arreglo funcionó.
¿Qué competencias de DevOps y platform engineering aportamos?
Aquí está el quid: no necesitas un equipo de plataforma ya montado en casa para elevar la developer experience. Aunque no hayamos construido tu plataforma concreta, tenemos gente que hace estas cosas en proyectos de software a medida y en nuestra práctica DevOps. Entre otros, cubrimos roles como:
- un ingeniero de plataforma / DevOps que construye autoservicio, CI/CD e infraestructura como código,
- un SRE responsable de la observabilidad, la fiabilidad y unos error budgets sensatos,
- un arquitecto que ordena los golden paths, los estándares y los límites de propiedad,
- un desarrollador backend / sénior que lleva las prácticas de calidad y revisión al propio equipo de producto.
Formamos el equipo alrededor del hueco concreto y verificamos las competencias antes de empezar, no «por si acaso». Entregamos a las personas que lo hacen, no un deck sobre cómo debería hacerse.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con experiencia real en DevOps, platform engineering y proyectos de software a medida. En vez de empezar por las herramientas, empezamos por dónde pierde tiempo tu equipo, y solo después decidimos qué simplificar, automatizar o estandarizar:
- entramos en el proceso existente en lugar de imponer una plantilla prefabricada desde fuera,
- atamos herramientas, entornos y estándares en una experiencia coherente y de autoservicio,
- trabajamos en una zona horaria cercana, así que entramos en tu ritmo de revisiones y reuniones sin una larga puesta en marcha,
- verificamos las competencias antes de empezar y ajustamos el rol a la necesidad real.
Lo más habitual es que lo entreguemos como refuerzo de equipo o equipo dedicado, porque la DevEx es trabajo continuo, no un despliegue único con fecha de fin.
¿Por dónde empezar a mejorar la developer experience?
Empieza por medir la fricción más dolorosa: el onboarding, el tiempo de espera en revisión o la preparación de entornos. Una sola cosa contable te da una línea base y un objetivo, en vez de generalidades sobre «la cultura de ingeniería». Después cierra un golden path de principio a fin, y solo desde ahí extiende la plataforma a más equipos.
Si estás valorando si esto es trabajo para una contratación fija, para refuerzo de equipo o para un equipo dedicado, explicamos las diferencias en nuestro artículo sobre modelos de colaboración en TI.
¿Quieres mejorar de verdad la developer experience: herramientas, entornos y estándares? Hablemos - ajustamos las competencias y el enfoque a tu equipo.