Para empezar a hablar de la experiencia del desarrollador, y por extensi\u00f3n de la experiencia de los ingenieros de software y de todas las personas implicadas en el ciclo de vida del desarrollo de software, voy a empezar por hablar de lo que no es:<\/p>\n\n\n\n
- \n
- Noches sin dormir por un problema urgente sin tener los medios para conocer con certeza qu\u00e9 est\u00e1 pasando en producci\u00f3n.<\/li>\n\n\n\n
- Tiempos de espera por peticiones de permisos de acceso o aprobaciones para hacer incluso la m\u00e1s trivial de las tareas.<\/li>\n\n\n\n
- Requerimientos que no est\u00e1n claros al estar muy separado el negocio de los equipos de desarrollo, lo que ocasiona retrabajo continuo y muchos apuros para llegar a fechas de entrega comprometidas por alguien no implicado en el desarrollo.<\/li>\n\n\n\n
- Aplicaciones que cuesta much\u00edsimo poner en producci\u00f3n porque no se tienen claros los criterios que hay que seguir o no hay transparencia sobre c\u00f3mo van a estar, o ya est\u00e1n, configurados los entornos.<\/li>\n<\/ul>\n\n\n\n
Al final, todas estas situaciones generan frustraci\u00f3n en los equipos. No son tan productivos en su d\u00eda a d\u00eda como podr\u00edan ser. Est\u00e1n \u00abatrapados\u00bb.<\/p>\n\n\n\n
Y ah\u00ed es donde entra la experiencia del desarrollador.<\/p>\n\n\n\n
Queremos proporcionar a nuestros equipos de desarrollo de una experiencia fabulosa cada d\u00eda: que se sientan productivos, que realicen sus tareas con gran calidad, que las interacciones entre roles sean armoniosas. En definitiva: que cada persona se dedique a hacer aquello para lo que est\u00e1 mejor preparada, en lugar de \u00abpelear contra molinos de viento\u00bb.<\/p>\n\n\n\n
Y eliminar, por tanto, todo aquello que causa retrasos, ineficiencias, y frustraci\u00f3n.<\/p>\n\n\n\n
Podemos ver la experiencia del desarrollador como un an\u00e1logo a la experiencia de usuario o a la experiencia del cliente.<\/p>\n\n\n\n
Cuando hablamos de experiencia del cliente, muchos visualizareis una tienda fant\u00e1stica \u2014esa tienda de referencia de una gran marca\u2014 donde cada segundo desde que un cliente potencial entra por la puerta hasta que finaliza su visita est\u00e9 debidamente estudiada y planificada para generar satisfacci\u00f3n y vinculaci\u00f3n a la marca.<\/p>\n\n\n\n
Cuando hablamos de la experiencia de usuario, hablamos de dotar a las personas que est\u00e1n usando una aplicaci\u00f3n \u2014ya sea web o sea m\u00f3vil, ya sea para el p\u00fablico general o sea una aplicaci\u00f3n interna de la empresa\u2014, con una interfaz intuitiva, f\u00e1cil de utilizar, que no les frustre, que no les requiera estar todo el tiempo navegando \u00abde aqu\u00ed para all\u00e1\u00bb para tareas sencillas, sino que sea todo claro, preciso y r\u00e1pido.<\/p>\n\n\n\n
Siguiendo esa analog\u00eda, la experiencia del desarrollador busca dise\u00f1ar e implantar acciones para que el d\u00eda a d\u00eda de los equipos de ingenier\u00eda sea fant\u00e1stico<\/strong>. Se pone a los ingenieros en el centro como actores principales y de gran valor para la organizaci\u00f3n. Se cuida de sus necesidades y se prima que sean felices y se sientan valorados, como camino para alcanzar la excelencia mediante la productividad y la calidad.<\/p>\n\n\n\n
Por qu\u00e9 son necesarias las estrategias de DevEx<\/h1>\n\n\n\n
Suena bien, \u00bfverdad? Tan bien que podr\u00edamos pensar que es algo que nos acompa\u00f1a ya en nuestro d\u00eda a d\u00eda. Pero no es as\u00ed y debemos trabajar para cambiarlo.<\/p>\n\n\n\n
Si nos fijamos a nuestro alrededor, la verdad es que las organizaciones no lo ponen f\u00e1cil a desarrolladores, ingenieros de plataformas e infraestructuras, analistas de datos o de seguridad, expertos en calidad y expertos en el negocio que participan en el desarrollo de soluciones:<\/p>\n\n\n\n
- \n
- Existen grandes puntos de dolor desde que un proyecto o producto empieza a tomar forma hasta su fin de vida. Esos puntos de dolor se extienden a cada persona que empieza a trabajar en un equipo, y los puntos de dolor acompa\u00f1an a las personas en su d\u00eda a d\u00eda mientras pertenecen a ese equipo.<\/li>\n\n\n\n
- Hablamos de limitaciones y procesos tediosos, por ejemplo, para conseguir acceso a un repositorio de c\u00f3digo, a una herramienta de gesti\u00f3n de proyectos, a un escritorio remoto, a un entorno de desarrollo o prueba, o conseguir una licencia para una herramienta necesaria.<\/li>\n\n\n\n
- Hablamos de poca claridad o acceso limitado al conocimiento de la organizaci\u00f3n y la documentaci\u00f3n que se necesita para conocer la tarea a realizar y poder completarla.<\/li>\n\n\n\n
- Hablamos de indefinici\u00f3n o poca claridad en prescripciones de arquitectura: blueprints <\/em>de soluciones, arquetipos de componentes y artefactos, herramientas recomendadas, est\u00e1ndares y buenas pr\u00e1cticas.<\/li>\n\n\n\n
- Hablamos de la seguridad por oscuridad, donde objetivos, pol\u00edticas y procesos de cumplimiento no son ampliamente conocidos, ocasionando retrabajo y retrasos, e incluso en ciertos casos exponiendo a la organizaci\u00f3n a riesgos adicionales cuando los equipos o individuos \u00abse buscan la vida\u00bb.<\/li>\n\n\n\n
- Hablamos de carencias en las campa\u00f1as de concienciaci\u00f3n sobre la seguridad f\u00edsica y de la informaci\u00f3n, limitadas en su alcance y desconectadas de escenarios del mundo real.<\/li>\n\n\n\n
- Y, por supuesto, mucho, much\u00edsimo, trabajo manual, de bajo valor, sin capacidades de autoservicio para fomentar la autonom\u00eda de los equipos y la sensaci\u00f3n de estar siempre dependiendo de otros.<\/li>\n<\/ul>\n\n\n\n
Imaginad cualquiera de vuestros clientes con cientos, incluso miles de desarrolladores. Imaginad si pudi\u00e9ramos eliminar tareas innecesarias que supongan tan solo una hora de trabajo a la semana por cada persona. Una peque\u00f1a mejora como esa tendr\u00eda un efecto multiplicador impresionante: miles de horas semanales que se podr\u00edan dedicar a mejorar la calidad de los productos, a entregar con predictibilidad en los plazos acordados (o mejorarlos), o resultar en esfuerzos ahorrados si ya se cumplen el resto de los objetivos.<\/p>\n\n\n\n
Se busca mucho la productividad de los desarrolladores, pero no siempre de la manera adecuada. No es raro hablar con equipos de desarrollo que se sienten presionados, con actores externos al equipo continuamente \u00abencima de ellos\u00bb para que sean m\u00e1s productivos y entreguen en plazo \u00abcomo sea\u00bb. Pero solo con presionar y desear algo, no tiene por qu\u00e9 suceder.<\/p>\n\n\n\n
Y es que pocas veces se hace el estudio de qu\u00e9 causa que los equipos de desarrollo no sean tan productivos como la organizaci\u00f3n desear\u00eda y se toman las acciones necesarias. No desear, sino actuar:<\/p>\n\n\n\n
- \n
- \u00bfLes estamos dotando de las herramientas necesarias?<\/li>\n\n\n\n
- \u00bfEstablecemos procesos excesivamente complejos, con muchos puntos de aprobaci\u00f3n que interrumpen el flujo de trabajo?<\/li>\n\n\n\n
- \u00bfSe trasladan los retrasos causados por la incertidumbre en el trabajo a realizar hacia el equipo de desarrollo, o se producen continuos cambios en el alcance esperado sin que se modifiquen los hitos de entrega?<\/li>\n\n\n\n
- \u00bfSe producen pausas esperando a que algo suceda porque parte del flujo de trabajo depende de otro departamento, de otro grupo, o de otro equipo? Por ejemplo, porque no haya comunicaci\u00f3n fluida entre equipos y sus necesidades y dependencias no son conocidas, o se depende de un equipo externo que se convierte en cuello de botella, etc.<\/li>\n\n\n\n
- \u00bfHay suficiente automatizaci\u00f3n para que tareas cotidianas y sencillas no necesiten de intervenci\u00f3n humana?<\/li>\n\n\n\n
- \u00bfEstablecemos silos organizativos con objetivos contradictorios que generan fricci\u00f3n entre los distintos roles?<\/li>\n\n\n\n
- \u00bfResulta f\u00e1cil a las personas que incorporamos a los equipos tener acceso al conocimiento y herramientas que necesitan para hacer su trabajo de forma productiva?<\/li>\n<\/ul>\n\n\n\n
Solamente cuando en una organizaci\u00f3n nos detengamos a hacer esas preguntas, analizando la cadena de valor desde que una idea surge en el negocio hasta que esa idea llega a producci\u00f3n, y descubriendo c\u00f3mo el feedback<\/em> de los usuarios finales se emplea en mejorar continuamente, podremos identificar los puntos de dolor y actuar para mejorar la experiencia de los equipos de desarrollo, y con estos actos ayudar a que la organizaci\u00f3n est\u00e9 equipada para cumplir sus objetivos.<\/p>\n\n\n\n
Ser\u00eda maravilloso que nuestro d\u00eda a d\u00eda fuera radicalmente diferente.<\/p>\n\n\n\n
Por qu\u00e9 es ahora el momento de DevEx<\/h1>\n\n\n\n
Me dir\u00e9is: \u00abVale, todo esto es muy bonito. Pero \u00bfpor qu\u00e9 precisamente ahora?\u00bb<\/p>\n\n\n\n
Son muchos los retos de las organizaciones: incrementar beneficios, liderar en sus respectivos mercados, reinventarse para crecer y aspirar a ser los mejores. En un mundo donde todo negocio es un negocio tecnol\u00f3gico, los ingenieros de software, as\u00ed como el resto de los perfiles que desarrollan y operan los sistemas tecnol\u00f3gicos se convierten en empleados clave de la organizaci\u00f3n. Tanto por su relevancia como por lo significativo en tama\u00f1o frente al resto de empleados de la organizaci\u00f3n.<\/p>\n\n\n\n
Un banco puede tener los mejores productos financieros del mercado, pero si no puede ponerlos al \u00abalcance de los dedos\u00bb de sus clientes lo tendr\u00e1 muy dif\u00edcil para prosperar. Una aseguradora puede tener la mejor red de asistencia a sus clientes, pero si \u00e9stos lo tienen dif\u00edcil para ponerse en contacto con quien puede ayudarles, no conseguir\u00e1 sus objetivos de retenci\u00f3n.<\/p>\n\n\n\n
Adicionalmente, experimentamos un crecimiento en la complejidad de los sistemas tecnol\u00f3gicos, tanto en su dise\u00f1o como construcci\u00f3n y entrega del software, as\u00ed como su operaci\u00f3n y evoluci\u00f3n posterior.<\/p>\n\n\n\n
Necesitamos arquitecturas de sistemas m\u00e1s elaboradas, m\u00e1s distribuidas, con mejores capacidades y mucho m\u00e1s robustas para dar la funcionalidad que se requiere en el mundo digital. Y esa complejidad, si se traslada directamente a los equipos de desarrollo o de operaciones, puede causar sobrecarga y cuellos de botella en ellos, adem\u00e1s de la propia presi\u00f3n cognitiva que supone tener que \u00absaber de todo\u00bb o entrar en una din\u00e1mica donde \u00abtodo es urgente\u00bb.<\/p>\n\n\n\n
Finalmente, es tambi\u00e9n el momento de priorizar la experiencia del desarrollador porque nuestras fuerzas de trabajo son mucho m\u00e1s l\u00edquidas de lo que eran hace 5 o 10 a\u00f1os. Es muy com\u00fan ver equipos que cambian en tama\u00f1o, en roles y responsabilidades, con skills<\/em> t\u00e9cnicos que evolucionan con el ciclo de vida de los productos. Equipos que se reorganizan o que cambian completamente de \u00e1rea de negocio.<\/p>\n\n\n\n
Por tanto, es fundamental el invertir en experiencias \u00f3ptimas para las personas: tanto cuando aterrizan en el equipo y deben ponerse en marcha r\u00e1pidamente, como durante su d\u00eda a d\u00eda a partir de ese momento. No basta con asumir una curva de aprendizaje larga y tediosa porque \u00absolo pasa una vez en la vida\u00bb. Cada d\u00eda puede ser el primer d\u00eda de alguien en el equipo, cada d\u00eda puede ser el primer d\u00eda que te enfrentes a una tarea nueva, y ese d\u00eda debe ser fabuloso. No basta con \u00abresolver\u00bb el d\u00eda uno si luego cada d\u00eda est\u00e1 salpicado de ineficiencias, fricciones, e incluso, miserias.<\/p>\n\n\n\n
C\u00f3mo empezar a adoptar DevEx<\/h1>\n\n\n\n
De todo lo anterior ya se puede deducir que la DevEx no es algo \u00absolamente\u00bb de los ingenieros de software ni \u00absolamente\u00bb un problema de herramientas. Adoptar DevEx es un esfuerzo que embarca a toda la organizaci\u00f3n. La estrategia surgir\u00e1 por tanto de la intersecci\u00f3n de tres pilares de su arquitectura empresarial:<\/p>\n\n\n\n
- \n
- Primero, la estrategia de talento y cultura.<\/li>\n\n\n\n
- Segundo, el enfoque metodol\u00f3gico y las formas de trabajo.<\/li>\n\n\n\n
- Tercero, la ingenier\u00eda de software y sus pr\u00e1cticas.<\/li>\n<\/ul>\n\n\n\n
Y, en el centro de todos ellos, una estrategia orientada a plataformas.<\/p>\n\n\n\n
A continuaci\u00f3n, voy a describir con m\u00e1s detalle los aspectos que en mi experiencia son m\u00e1s relevantes a la hora de plantear un enfoque de DevEx en cualquier organizaci\u00f3n.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2025\/03\/devops-3-img-1-estrategia-devex-1024x975.png\")
<\/figure>\n\n\n\nDevEx en la intersecci\u00f3n de la estrategia de talento, las formas de trabajo, y las pr\u00e1cticas de ingenier\u00eda de software<\/em><\/p>\n\n\n\n
El cambio cultural y la carrera interna de ingenier\u00eda de software<\/h1>\n\n\n\n
Empiezo por el cambio cultural ya que puede ser el m\u00e1s importante para potenciar la DevEx. Si no est\u00e1 presente dif\u00edcilmente todo lo dem\u00e1s tenga el impacto deseado. Adem\u00e1s, es normalmente el m\u00e1s dif\u00edcil de articular y afinar a la realidad de cada empresa y grupo de profesionales.<\/p>\n\n\n\n
No es f\u00e1cil construir una marca atractiva para los ingenieros de software, no solamente ser una marca reconocida dentro del mundo de los negocios, sino tambi\u00e9n como un lugar donde desarrollar una carrera tecnol\u00f3gica.<\/p>\n\n\n\n
El reto no es sencillo y tiene m\u00faltiples aspectos complementarios:<\/p>\n\n\n\n
- \n
- Crear modelos de carrera espec\u00edficos para los perfiles de ingenier\u00eda de software que sean atractivos y que se alineen a las expectativas de ese colectivo, alineadas a la presi\u00f3n que marca el mercado de talento.<\/li>\n\n\n\n
- Promover un entorno de seguridad psicol\u00f3gica donde todo el mundo se sienta libre de opinar y de hablar, de disentir y donde todos reconozcamos que en la diversidad radica nuestra fuerza, pues para prosperar, mejorar y crecer todas las voces son bienvenidas.<\/li>\n\n\n\n
- Promover tambi\u00e9n una cultura de la autorreflexi\u00f3n, que apuesta por la mejora continua con decisiones orientadas al dato: medir, formular hip\u00f3tesis en base a esas mediciones, poner en marcha acciones y medir nuevamente el impacto de esas acciones para potenciarlas o descartarlas.<\/li>\n\n\n\n
- Crear y facilitar el espacio y el tiempo para la innovaci\u00f3n y el pensamiento sobre el futuro, analizar las tendencias tecnol\u00f3gicas y ver c\u00f3mo nos pueden ayudar (y, por tanto, fomentar su adopci\u00f3n) o nos amenazan (y nos preparamos para ello).<\/li>\n<\/ul>\n\n\n\n
En definitiva, una estrategia que potencie lo que se conoce, dentro de la tipolog\u00eda de organizaciones de Westrum, como una organizaci\u00f3n de tipo generativo<\/strong>.<\/p>\n\n\n\n
Una consecuencia de este tipo de cambio cultural es que se destierran comportamientos no deseados como la \u00abcolampetici\u00f3n\u00bb: en un entorno empresarial donde la colaboraci\u00f3n entre departamentos, equipos y roles, es fundamental para que los negocios prosperen, no hay cabida para la competici\u00f3n interna poco saludable, incluso t\u00f3xica, donde se antepongan objetivos personales o partidistas a los del conjunto de la organizaci\u00f3n.<\/p>\n\n\n\n
Como esta no es mi \u00e1rea de conocimiento no voy a atreverme a profundizar, pero si te interesa el tema hay muchas fuentes solventes en las que inspirarse. Sin ir m\u00e1s lejos, en Codemotion Madrid los \u00faltimos a\u00f1os hemos tenido oportunidad de disfrutar de contenido excelente sobre las carreras de ingenier\u00eda de software y el cambio cultural y organizativo tan necesario en muchas empresas.<\/p>\n\n\n\n
Fomento de la colaboraci\u00f3n<\/h1>\n\n\n\n
El enfoque que la organizaci\u00f3n da para fomentar y potenciar la colaboraci\u00f3n y la distribuci\u00f3n del conocimiento entre departamentos, equipos o roles es de crucial importancia.<\/p>\n\n\n\n
Una de las estrategias habituales es la creaci\u00f3n de comunidades de pr\u00e1ctica<\/strong>. Una comunidad de pr\u00e1ctica es un grupo con una autonom\u00eda relativamente alta dentro de la organizaci\u00f3n que tiene la responsabilidad de conectar a las personas de una cierta tecnolog\u00eda, rol o \u00e1rea de negocio para hacer cosas como, entre otras:<\/p>\n\n\n\n
- \n
- Fomentar que compartan el conocimiento por m\u00faltiples canales: wikis<\/em>, charlas y talleres internos, hackathon<\/em>, participaci\u00f3n en eventos externos.<\/li>\n\n\n\n
- Participar activamente en la construcci\u00f3n y evoluci\u00f3n de productos y servicios internos con modelos inner source<\/em> (p.ej. contribuci\u00f3n al portal interno del desarrollador, contribuci\u00f3n a la documentaci\u00f3n de uso de una librer\u00eda compartida).<\/li>\n\n\n\n
- Prescribir arquetipos de soluciones, est\u00e1ndares y buenas pr\u00e1cticas.<\/li>\n\n\n\n
- Dise\u00f1ar los curr\u00edculums formativos.<\/li>\n<\/ul>\n\n\n\n
La gamificaci\u00f3n es una herramienta muy \u00fatil para fomentar la participaci\u00f3n en comunidades de pr\u00e1ctica. Ya que no siempre es posible establecer un modelo 80%-20% para compaginar trabajo en proyectos con trabajo para la comunidad se torna necesario idear otras formas de compensar a las personas por su esfuerzo, ya sea mediante beneficios adicionales, bonos de fin de a\u00f1o, asistencia a eventos con gastos pagados, u otras v\u00edas.<\/p>\n\n\n\n
Las formas son m\u00faltiples y muy variadas pero lo fundamental a nivel de estrategia es entender que todo esfuerzo debe tener su recompensa. Eso puede ser la diferencia entre desear que algo pase y tomar las acciones necesarias para que realmente pase.<\/p>\n\n\n\n
Cuando los miembros de una comunidad participan en las actividades de esta los beneficios son m\u00faltiples. Por supuesto, el valor intr\u00ednseco de lo que se produce. Tambi\u00e9n se consigue que el conocimiento fluya con naturalidad y las personas se sienten mucho m\u00e1s inclinadas a colaborar de forma espont\u00e1nea (frente al hacerlo \u00abobligado porque me lo ha dicho mi jefe\u00bb). Adicionalmente, la adherencia a procesos y est\u00e1ndares es mucho mayor ya que la gente se sienten parte de ello y no como algo impuesto desde \u00abla torre de marfil\u00bb. Nos bebemos nuestro propio vino porque pensamos que es el mejor.<\/p>\n\n\n\n
Otra estrategia habitual consiste en la creaci\u00f3n de equipos especializados con la funci\u00f3n de relaci\u00f3n con los desarrolladores<\/strong> (developer relations<\/em> o developer advocates<\/em>). Este rol, cuando se proyecta hacia dentro de la organizaci\u00f3n, busca trabajar con los equipos de desarrollo para entender sus necesidades y dificultades, y ayudar a que los productos y servicios internos se construyan para que la vida de los ingenieros de software sea tan f\u00e1cil como sea posible. Estos equipos deben tener una interesante combinaci\u00f3n de perfil desarrollador, calidad, datos, sistemas, formaci\u00f3n y elaboraci\u00f3n de documentaci\u00f3n t\u00e9cnica, aunque no necesariamente contenidos todos ellos en el cuerpo de una sola persona.<\/p>\n\n\n\n
Formaci\u00f3n continua<\/h1>\n\n\n\n
Las estrategias que buscan impulsar la formaci\u00f3n continua tambi\u00e9n tienen un impacto muy positivo en la experiencia del desarrollador.<\/p>\n\n\n\n
Las personas se sienten valoradas cuando su organizaci\u00f3n se preocupa por que est\u00e9n constantemente ampliando su conocimiento, generalmente hacia tecnolog\u00edas nuevas y emergentes, pero tambi\u00e9n potenciando los soft skills<\/em>.<\/p>\n\n\n\n
Una estrategia de formaci\u00f3n continua se complementa muy bien con el impacto que tienen las comunidades de pr\u00e1ctica. Si la comunidad vela por identificar o desarrollar contenido formativo relevante para ellos mismos, la organizaci\u00f3n puede y debe aportar no solo una visi\u00f3n estrat\u00e9gica y de m\u00e1s largo plazo, sino aportar los recursos necesarios para que se lleve a cabo.<\/p>\n\n\n\n
Puede parecer de Perogrullo, pero no lo es; un buen programa de formaci\u00f3n continua requiere de inversi\u00f3n con visi\u00f3n. Por fortuna, existen muchas opciones de formaci\u00f3n con precios ajustados y escalables. Desde portales de formaci\u00f3n online que dan acceso a cientos de cursos de especializaci\u00f3n (muy recomendables especialmente los que dan acceso a entornos de laboratorio a modo de playground<\/em>), a acuerdos con proveedores de servicios para acceder con descuento a sus programas de certificaci\u00f3n (p.ej. programas de colaboraci\u00f3n para partners<\/em>).<\/p>\n\n\n\n
De un modo u otro, estos programas deben ser priorizados ya que la alternativa no es solo personal descontento sino una p\u00e9rdida de valor intr\u00ednseco de las personas que no estar\u00edan tan preparadas para afrontar retos cercanos.<\/p>\n\n\n\n
Quer\u00eda hacer menci\u00f3n especial en este apartado al impacto positivo que la inteligencia artificial generativa va a tener en nuestro enfoque de aprendizaje. Podemos argumentar largo y tendido sobre su impacto en las tareas cotidianas de los ingenieros de software (eso da para otra serie de art\u00edculos) pero s\u00ed que vemos con mucha claridad su impacto positivo en las curvas de aprendizaje. Ya sea para aprender un nuevo lenguaje o tecnolog\u00eda, o tan solo la pizca de conocimiento que falte para una tarea espec\u00edfica.<\/p>\n\n\n\n
Contando con que ya se cuenten con conocimientos s\u00f3lidos de las bases de la ingenier\u00eda del software, cambia el enfoque de aprendizaje. No hace tanto tiempo que aprend\u00edamos un nuevo lenguaje o framework<\/em> con un libro, un manual, o un cursillo en CD. Los tutoriales online<\/em> nos abrieron la puerta a m\u00e1s conocimiento y en muchas m\u00e1s \u00e1reas, pero no cambiaba la manera fundamental en que aprend\u00edamos: leyendo (mucho) y practicando (lo que se pod\u00eda).<\/p>\n\n\n\n
La irrupci\u00f3n de la IA generativa s\u00ed que cambia y se reinventa la aproximaci\u00f3n al aprendizaje. Podemos aligerar el proceso sin depender fuertemente de libros, tutoriales o cursos, y comenzar pidiendo ayuda y gu\u00eda acerca de lo que queremos hacer. Yo mismo lo he experimentado directamente. Ten\u00eda que crear un automatismo con un lenguaje de programaci\u00f3n con el que no hab\u00eda trabajado antes ni tampoco conoc\u00eda la librer\u00eda con la que deb\u00eda automatizar el proceso. Con un asistente de codificaci\u00f3n pude tener r\u00e1pidamente una visi\u00f3n general de c\u00f3mo se pod\u00eda hacer la tarea, una gu\u00eda paso a paso de lo que deb\u00eda hacer para empezar, y una vez metido en faena, sugerencias sobre bloques de c\u00f3digo o de configuraci\u00f3n hasta completar mi tarea.<\/p>\n\n\n\n
Pero ojo, no tienes por qu\u00e9 creerme; pru\u00e9balo. Cualquier tarea que tengas pendiente y que requiera aprender algo previamente, ya sea mucho o poco, intenta abordarla con la ayudad de un asistente de IA. Creo que te sorprender\u00e1 positivamente.<\/p>\n\n\n\n
DevOps<\/h1>\n\n\n\n
Puesto que uno de los elementos que m\u00e1s influye significativamente en la experiencia del desarrollador es la fricci\u00f3n entre roles y la automatizaci\u00f3n de tareas (especialmente si son tediosas, repetitivas) no es de extra\u00f1ar que DevOps sea una estrategia que se deje ver en el contexto de DevEx. Seguro que \u00ablo esperabais\u00bb puesto que esta es una serie de art\u00edculos sobre nuestro entendimiento presente de los principios y pr\u00e1cticas DevOps. No voy a repetirme aqu\u00ed, por tanto, sobre qu\u00e9 es DevOps, pero s\u00ed que voy a establecer los aspectos m\u00e1s importantes de esa conexi\u00f3n.<\/p>\n\n\n\n
Fricci\u00f3n\u2026 roces, conflicto, falta de colaboraci\u00f3n. De eso DevOps \u00absabe\u00bb bastante. Dejando las pr\u00e1cticas de automatizaci\u00f3n aparte, que ya introduje en el segundo art\u00edculo de la serie, DevOps es sobre todo una propuesta para trabajar de manera diferente, donde se potencia la colaboraci\u00f3n y compartir objetivos entre equipos.<\/p>\n\n\n\n
Por tanto, la conexi\u00f3n es directa: las organizaciones que adoptan DevOps como marco de trabajo sobre el que se apoyan las interacciones de los grupos de desarrollo y operaciones consiguen mejorar la experiencia del desarrollador. Al derribarse el imaginario \u00abmuro de la confusi\u00f3n\u00bb se tienen din\u00e1micas fluidas entre todos los miembros de un equipo que funciona bajo principios DevOps. Recordad que DevOps es algo que lo hacemos todos, o no lo hacemos ninguno; no es un silo diferente sobre el que volcar todas las tareas que otros equipos no quieran o no sepan hacer.<\/p>\n\n\n\n
Las ceremonias del d\u00eda a d\u00eda permiten repartir las tareas seg\u00fan la especialidad y conocimiento de cada miembro del equipo \u2014ya sea desarrollador frontend<\/em>, experto en datos, ingeniero de plataformas o infraestructura, etc. \u2014, se anticipan dependencias y bloqueos, se discuten las opciones para resolver retos, o se acuerda c\u00f3mo abordar cuestiones de cumplimiento de pol\u00edticas. Sin sorpresas inesperadas. Sin broncas porque las cosas ya no se quedan en \u00abtierra de nadie\u00bb, ni se ignoran ni se despachan inmisericordemente a otros equipos.<\/p>\n\n\n\n
En resumen: la empat\u00eda que se genera en un ambiente de alta colaboraci\u00f3n reduce o elimina la fricci\u00f3n entre roles con un impacto directo en el bienestar de las personas y la productividad de los equipos.<\/p>\n\n\n\n
Lo anterior se amplifica cuando se avanza en la automatizaci\u00f3n de las tareas tediosas y repetitivas. Cuando los miembros del equipo sienten que su tiempo, que es valioso, se emplea en tareas no triviales (de valor a\u00f1adido) donde poner de manifiesto su especializaci\u00f3n tecnol\u00f3gica y su capacidad en resoluci\u00f3n de problemas, su autoestima aumenta y su impacto a los objetivos de la organizaci\u00f3n tambi\u00e9n.<\/p>\n\n\n\n
En resumen: la automatizaci\u00f3n de tareas repetitivas tiene tambi\u00e9n un impacto directo en el bienestar de las personas y la productividad de los equipos.<\/p>\n\n\n\n
Portal interno del desarrollador<\/h1>\n\n\n\n
Un elemento central sobre el que orbita una estrategia de DevEx es el portal interno del desarrollador<\/strong>. Sobre la base s\u00f3lida que nos dan los elementos descritos anteriormente toca centrarse en la experiencia nuclear del desarrollador. De manera an\u00e1loga a otros enfoques de experiencia, trazamos los recorridos del desarrollador (developer journeys<\/em>) y los utilizamos para dise\u00f1ar una experiencia \u00fanica en su doble acepci\u00f3n: \u00fanica porque es un reflejo de las necesidades y expectativas de los desarrolladores de manera diferenciada al resto de roles de la organizaci\u00f3n, y \u00fanica como reflejo de su alta calidad e impacto en la satisfacci\u00f3n.<\/p>\n\n\n\n
Imaginemos el primer d\u00eda de un desarrollador en un nuevo equipo. Bastante sobrecogedor por la cantidad de informaci\u00f3n que se espera que conozcan y la dificultad para obtenerla. Muchas veces, por no decir casi todas, se recurre al conocimiento tribal. Trocitos de informaci\u00f3n que va circulando conforme hace falta, perseguir a compa\u00f1eros de equipo o esperar a que alguien est\u00e9 disponible un par de horas para que te haga una sesi\u00f3n r\u00e1pida de bienvenida. Es lo normal: pasan d\u00edas o incluso semanas hasta poder completar la primera tarea asignada, y mucho m\u00e1s hasta ser completamente productivos ya integrados en el nuevo equipo. Obviamente, no estamos aun en Matrix<\/em> y no podemos aprender kungf\u00fa en un minuto, sin embargo, una buena implementaci\u00f3n de los recorridos del desarrollador ayuda a mejorar la experiencia de aterrizaje a un nuevo equipo.<\/p>\n\n\n\n
Un portal interno del desarrollador t\u00edpico proporciona acceso r\u00e1pido a muchas de estas necesidades:<\/p>\n\n\n\n
- \n
- \u00bfD\u00f3nde est\u00e1 el c\u00f3digo fuente de la aplicaci\u00f3n en la que se supone que tengo que trabajar?<\/li>\n\n\n\n
- \u00bfQu\u00e9 entornos tengo disponibles para probar mis cambios?<\/li>\n\n\n\n
- \u00bfQu\u00e9 procedimientos de validaci\u00f3n, como chequeos de c\u00f3digo o pruebas, tengo a mi disposici\u00f3n?<\/li>\n\n\n\n
- \u00bfC\u00f3mo puedo saber qu\u00e9 tareas tengo asignadas y c\u00f3mo puedo informar del tiempo que necesito para terminarlas?<\/li>\n\n\n\n
- \u00bfC\u00f3mo puedo avisar a mis compa\u00f1eros o a otros equipos de una dependencia que podr\u00eda bloquearme en una tarea?<\/li>\n\n\n\n
- \u00bfD\u00f3nde est\u00e1 la documentaci\u00f3n funcional o t\u00e9cnica que necesito para entender mis tareas y c\u00f3mo realizarlas?<\/li>\n\n\n\n
- \u00bfHay componentes reutilizables, como arquetipos, librer\u00edas, APIs de negocio, que me puedan ayudar a completar mi tarea en menos tiempo y con m\u00e1s calidad?<\/li>\n<\/ul>\n\n\n\n
Cada una de estas preguntas, y muchas otras, forman parte del developer journey<\/em>, como si de historias de usuario en una soluci\u00f3n de negocio se tratara.<\/p>\n\n\n\n
Su implementaci\u00f3n dentro del portal permite a los desarrolladores tener toda la informaci\u00f3n que necesitan para hacer su trabajo, cada tarea conectada con las recomendaciones de arquitectura, buenas pr\u00e1cticas o ejemplos que ayuden a completarla a tiempo y con calidad.<\/p>\n\n\n\n
El uso de la palabra portal no es casual: es un enfoque visual, basado en roles y responsabilidades, cuadros de mando especializados para que cada rol dentro del equipo vea prioritariamente lo que m\u00e1s le puede interesar, y personalizables para dar cabida a usos variados, no previstos, o simplemente preferencias personales.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2025\/03\/devops-3-img-2-portal-desa-1024x632.png\")
<\/figure>\n\n\n\nEjemplo de una parte del cuadro de mando de bienvenida de un portal interno del desarrollador construido con Port (getport.io).<\/em><\/p>\n\n\n\n
Un portal interno del desarrollador tambi\u00e9n puede ser una extensi\u00f3n de la estrategia de puesto de trabajo en las organizaciones. Siendo breves: no basta con proporcionar a los desarrolladores con un ordenador corporativo con el software base necesario seg\u00fan las pol\u00edticas de la organizaci\u00f3n; ni siquiera una versi\u00f3n del puesto de trabajo espec\u00edfica para los desarrolladores es suficiente. \u00ab\u00bfDesarrolladores de qu\u00e9?\u00bb Seg\u00fan el rol o la tecnolog\u00eda, incluso en funci\u00f3n del proyecto, las herramientas cambian. No hay una talla \u00fanica que pueda acomodar a todos y tampoco es una opci\u00f3n tener un puesto de trabajo con todo el software relevante para alg\u00fan miembro de la organizaci\u00f3n.<\/p>\n\n\n\n
El enfoque cambia. La organizaci\u00f3n construye un cat\u00e1logo de aplicaciones y servicios aceptables con la colaboraci\u00f3n estrecha de las comunidades de pr\u00e1ctica, de manera que los intereses de todos est\u00e9n representados. Sobre ese cat\u00e1logo se construye un mercado (marketplace<\/em>) digital <\/strong>donde los miembros de los equipos puedan acceder y elegir qu\u00e9 necesitan y poder instalarlos a golpe de click<\/em> en su ordenador.<\/p>\n\n\n\n
Como un app store,<\/em> pero para las necesidades de los desarrolladores.<\/p>\n\n\n\n
Un portal interno del desarrollador no se queda en facilitar el acceso al conocimiento o a la instalaci\u00f3n de aplicaciones. Un cat\u00e1logo bien construido aportar\u00e1 tambi\u00e9n acceso f\u00e1cil a servicios relacionados con los entornos donde se validan y ejecutan las soluciones. Ya sean entornos cloud<\/em>, on-premise<\/em> o software como servicio, desde un portal interno se debe facilitar el acceso a cada uno de ellos, simplificar la creaci\u00f3n de nuevos entornos o el despliegue de nuevos componentes en un entorno existente, as\u00ed como controlar todo el ciclo de vida de las soluciones de negocio. Desde una base de datos a un servicio de mensajer\u00eda distribuida. Desde crear un nuevo repositorio de c\u00f3digo a solicitar un espacio colaborativo para trabajar en equipo. Desde desplegar un MVP en un entorno de desarrollo a realizar un pase a producci\u00f3n de una soluci\u00f3n compleja sin interrupci\u00f3n para el negocio.<\/p>\n\n\n\n
Es un enfoque basado fuertemente en el autoservicio y la automatizaci\u00f3n<\/strong> para conseguir que los equipos sean lo m\u00e1s independientes posibles del resto de equipos. Cuanto m\u00e1s rico el cat\u00e1logo a disposici\u00f3n de los equipos, menor ser\u00e1 la dependencia y la fricci\u00f3n. La organizaci\u00f3n gana en agilidad por su capacidad para adaptarse a nuevas necesidades y gana en la observabilidad de los usos de recursos tecnol\u00f3gicos necesarios para sus soluciones.<\/p>\n\n\n\n
Ingenier\u00eda de Plataformas<\/h1>\n\n\n\n
Si justo acabo de hablar de autoservicio y automatizaci\u00f3n como claves, y claramente un portal interno del desarrollador nos da la frontal con capacidades de autoservicio, \u00bfcu\u00e1l es la mejor manera de enfocar la estrategia de automatizaci\u00f3n?<\/p>\n\n\n\n
Opciones hay numerosas, cada una con sus pros y contras, pero la que en mi experiencia m\u00e1s beneficios aporta a medio y largo plazo por su capacidad para escalar es la ingenier\u00eda de plataformas<\/strong>.<\/p>\n\n\n\n
Lo primero que debemos tener claro es que la ingenier\u00eda de plataformas es un espacio mucho m\u00e1s amplio de lo que es DevEx o DevOps.<\/p>\n\n\n\n
El primer principio base de toda plataforma es abstraer la complejidad<\/strong> de los elementos necesarios para una soluci\u00f3n o grupo de soluciones comunes. En lugar de reinventar la rueda con cada necesidad, se identifican los elementos comunes, se prescriben blueprints<\/em> de referencia que luego se puedan implementar en m\u00faltiples ocasiones. Esos elementos de referencia, a modo de bloques de construcci\u00f3n de un juego de LEGO, se abstraen bajo una interfaz de servicios con APIs f\u00e1ciles de usar, para que sea muy sencillo implementarlos de manera repetida por distintas soluciones, as\u00ed como integrarlas con elementos externos a la plataforma.<\/p>\n\n\n\n
El segundo principio base en la ingenier\u00eda de plataformas, que complementa al anterior, es el balance entre estandarizaci\u00f3n y autonom\u00eda<\/strong>. Cuando se limita la capacidad de innovar, cuando se ponen impedimentos a equipos y desarrolladores que necesiten piezas diferentes, se genera fricci\u00f3n y resentimiento entre equipos y la gente se \u00abbusca la vida\u00bb aprovechando las rendijas del sistema y ocasionando la aparici\u00f3n de plataformas en la sombra. La clave por tanto es dise\u00f1ar componentes y servicios reutilizables que sean modulares, abiertos a la composici\u00f3n, que realmente los equipos puedan usarlos en una variedad de escenarios, sobre todo en escenarios que no estaban pensados de antemano. Se deben definir l\u00edneas rojas que act\u00faen como guardarra\u00edles para la organizaci\u00f3n en su conjunto, as\u00ed como para los equipos, pero sin restringir demasiado hasta el punto de estrangular. Seguro que hab\u00e9is o\u00eddo en alguna ocasi\u00f3n que \u00abel control mata a la innovaci\u00f3n\u00bb. Pues una buena estrategia de plataformas debe dar a la organizaci\u00f3n del control justo y necesario, pero ni una pizca m\u00e1s. Habilitar innovaci\u00f3n con seguridad y tranquilidad mientras se promueven pr\u00e1cticas sostenibles en el tiempo. No aspirar a crear soluciones universales que no resuelvan ning\u00fan problema. As\u00ed dicho parece f\u00e1cil, pero no lo es.<\/p>\n\n\n\n
Plataformas hay muchas y variadas por su funci\u00f3n o momento del ciclo de vida en que se utilizan.<\/p>\n\n\n\n
Tenemos plataformas orientadas al tiempo de desarrollo, e.g.:<\/p>\n\n\n\n
- \n
- Plataforma de ciclo de vida de las aplicaciones.<\/li>\n\n\n\n
- Plataforma de gesti\u00f3n de la configuraci\u00f3n.<\/li>\n\n\n\n
- Plataforma de CI\/CD.<\/li>\n\n\n\n
- Portal interno del desarrollador.<\/li>\n<\/ul>\n\n\n\n
Tambi\u00e9n las plataformas para el tiempo de ejecuci\u00f3n, e.g.:<\/p>\n\n\n\n
- \n
- Plataforma de contenedores.<\/li>\n\n\n\n
- Plataforma de observabilidad.<\/li>\n\n\n\n
- Plataforma de datos.<\/li>\n\n\n\n
- Plataforma de mensajer\u00eda distribuida.<\/li>\n\n\n\n
- Plataforma de integraci\u00f3n.<\/li>\n<\/ul>\n\n\n\n
La ingenier\u00eda de plataformas tambi\u00e9n aplica a las plataformas verticales por dominio de negocio, tambi\u00e9n llamadas a veces plataformas empresariales. Es decir, plataformas como las que ofrecen SAP, Salesforce, Oracle, Microsoft, ServiceNow y muchas otras compa\u00f1\u00edas. Y, tambi\u00e9n, a las plataformas de negocio que nuestros clientes implementan a medida. Plataformas de comercio electr\u00f3nico, plataformas de seguros, plataformas de banca online, plataformas de gesti\u00f3n de las cadenas de suministro, etc.<\/p>\n\n\n\n
Todas ellas tienen impacto en la DevEx a lo largo del ciclo de vida de aplicaciones, servicios y productos. Unas nos van a facilitar crear y llevar el cambio hasta los usuarios, otras son la base s\u00f3lida sobre las que ejecutar las cargas de trabajo con fiabilidad, disponibilidad y observabilidad, ya sean productivas o no productivas.<\/p>\n\n\n\n
Tomemos como ejemplo una plataforma orientada al desarrollo. \u00bfQu\u00e9 tipo de funcionalidades nos permite abstraer y podemos integrar con un portal interno del desarrollador? Por ejemplo:<\/p>\n\n\n\n
- \n
- Solicitar la creaci\u00f3n de un nuevo espacio de trabajo para un proyecto.<\/li>\n\n\n\n
- Solicitar la creaci\u00f3n de uno o varios repositorios de c\u00f3digo.<\/li>\n\n\n\n
- Crear un repositorio de c\u00f3digo a partir de un arquetipo de componente disponible (p.ej. un microfrontend<\/em> con Angular o un microservicio<\/em> con Spring Boot).<\/li>\n\n\n\n
- Gestionar los permisos para acceder al proyecto y al c\u00f3digo con distintos roles: responsable, desarrollador, colaborador, etc.<\/li>\n\n\n\n
- Solicitar la creaci\u00f3n de un entorno cloud<\/em> para usarlo como entorno de prueba.<\/li>\n\n\n\n
- Solicitar la creaci\u00f3n de entornos productivos con estrategias de resiliencia dentro de cat\u00e1logo (redundancia, escalabilidad, regi\u00f3n \u00fanica o multirregi\u00f3n, etc.).<\/li>\n\n\n\n
- Definir una estrategia de entrega que involucre distintos componentes, aprobaciones, paralelizaci\u00f3n de tareas, o puntos de control.<\/li>\n<\/ul>\n\n\n\n
Y muchas, muchas m\u00e1s capacidades.<\/p>\n\n\n\n
Combinando una estrategia de plataformas s\u00f3lida, con automatizaci\u00f3n basada en APIs, y la integraci\u00f3n de esas APIs con el portal interno del desarrollador, se consigue materializar el impacto positivo en la DevEx que tanto desean las organizaciones.<\/p>\n\n\n\n
Conclusi\u00f3n: Los beneficios de DevEx<\/h1>\n\n\n\n
La adopci\u00f3n de una estrategia que redunda en la experiencia del desarrollador aporta a las organizaciones beneficios m\u00faltiples.<\/p>\n\n\n\n
Para empezar, tiene un impacto positivo en la agilidad de negocio de la organizaci\u00f3n, permitiendo mejorar el tiempo a mercado de nuevas soluciones o evoluciones de soluciones existentes.<\/p>\n\n\n\n
Ayuda a conseguir que el momento de arrancar una nueva soluci\u00f3n o proyecto o el momento de dar la bienvenida a nuevas personas al equipo sean experiencias fabulosas, f\u00e1ciles, sin traumas.<\/p>\n\n\n\n
Cada tarea que se automatiza y cada flujo de trabajo que se optimiza conlleva ahorros a la organizaci\u00f3n por la mejora en productividad. Ser\u00e1n capaces de hacer m\u00e1s con los recursos disponibles, y cuando ya cumplan sus objetivos, optimizar el coste total de propiedad.<\/p>\n\n\n\n
Contar con plataformas de ingenier\u00eda robustas, fiables y operables, impacta positivamente en la DevEx durante todo el ciclo de vida de las soluciones, ya sea en actividades de mantenimiento, correctivos, soporte a usuarios, parcheos<\/em>, o actualizaciones de infraestructura y componentes de las plataformas. Adem\u00e1s, consigue mejorar la experiencia de los usuarios: funciona bien, en cualquier momento y desde cualquier lugar.<\/p>\n\n\n\n
Todo lo anterior se aplicar\u00e1 con flexibilidad para ajustarse a necesidades espec\u00edficas de ciertas soluciones o equipos. Por muy completos que sean los cat\u00e1logos de arquetipos o de servicios de plataforma siempre debe existir la opci\u00f3n de salirse del camino trazado. De lo contrario se limitan las opciones que nos brinda la tecnolog\u00eda y se podr\u00eda perder una ventaja competitiva. Habr\u00e1 l\u00edneas rojas en la organizaci\u00f3n, p.ej. relacionadas con el cumplimiento de las pol\u00edticas de seguridad, pero fuera de esas l\u00edneas no deber\u00eda haber nada prohibido.<\/p>\n\n\n\n
Finalmente, se mejora la moral y la retenci\u00f3n de los empleados que sentir\u00e1n una mayor vinculaci\u00f3n con su organizaci\u00f3n, una mayor implicaci\u00f3n con los objetivos del negocio al entender las razones por las que su trabajo es necesario, as\u00ed como el valor a\u00f1adido que representa su participaci\u00f3n en el equipo.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2025\/03\/devops-3-img-3-beneficios-devex-1024x793.png\")
<\/figure>\n\n\n\nLos beneficios de DevEx<\/em><\/p>\n\n\n\n
En definitiva, felicidad y fabulosidad<\/em><\/strong> en los equipos de desarrollo.<\/p>\n\n\n\n
En el pr\u00f3ximo art\u00edculo de la serie continuar\u00e9 profundizando en conceptos claves de nuestro entendimiento de DevOps y conectando totalmente con lo reci\u00e9n visto hablar\u00e9 en detalle de la ingenier\u00eda de plataformas (platform engineering)<\/em> desde la perspectiva de su impacto tan positivo en la adopci\u00f3n de principios y pr\u00e1cticas DevOps.<\/p>\n\n\n\n
Sobre el autor<\/h1>\n\n\n\n
Jorge Hidalgo<\/a> es director de ingenier\u00eda de software en Accenture, responsable de DevOps en Accenture Iberia y de la unidad de Arquitectura y Plataformas Cloud y DevOps en Accenture EMEA South Advanced Technology Center, y es tambi\u00e9n responsable globalmente en Accenture de la comunidad de pr\u00e1ctica Java. Jorge es un Java Champion desde 2023.<\/p>\n\n\n\n
Jorge cuenta con m\u00e1s de 25 a\u00f1os de experiencia en la industria, principalmente con tecnolog\u00edas Java, web, cloud, DevOps, agilidad y ciberseguridad. Adem\u00e1s de desarrollar su actividad profesional con clientes, es una figura activa en las comunidades tecnol\u00f3gicas, tanto como ponente en numerosos eventos locales e internacionales, como liderando la actividad de comunidades como M\u00e1laga JUG, M\u00e1laga Scala Developers y Boquer\u00f3nSec, as\u00ed como colaborando en la organizaci\u00f3n de eventos como OpenSouthCode o Codemotion.<\/p>\n\n\n\n
https:\/\/deors.wordpress.com<\/a><\/p>\n\n\n\n
https:\/\/www.linkedin.com\/in\/deors<\/a><\/p>\n\n\n\n
https:\/\/deors.bsky.social<\/a><\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
- Participar activamente en la construcci\u00f3n y evoluci\u00f3n de productos y servicios internos con modelos inner source<\/em> (p.ej. contribuci\u00f3n al portal interno del desarrollador, contribuci\u00f3n a la documentaci\u00f3n de uso de una librer\u00eda compartida).<\/li>\n\n\n\n
- Fomentar que compartan el conocimiento por m\u00faltiples canales: wikis<\/em>, charlas y talleres internos, hackathon<\/em>, participaci\u00f3n en eventos externos.<\/li>\n\n\n\n