¿Qué es la Developer Experience? Y por qué te debería importar incluso si no eres una persona desarrolladora

Imaginemos que necesitas cumplir la osada tarea de bañar a un elefante, pero todos los ítems necesarios para la tarea están en una cabaña a 5 kilómetros de distancia. Tendrás que entrar a un vehículo, separar los ítems necesarios y llevarlos al lugar de la tarea. Si, por alguna razón, olvidas algún ítem, tendrás que regresar, duplicando tu tiempo inicial. Luego de que, finalmente, hayas bañado al elefante (una tarea para nada fácil, dado el tamaño del animal), tendrás que llevar de regreso todos los ítems que usaste. Esas idas y vueltas y posibles percances aumentarán la complejidad de la tarea, que ya no es fácil. Básicamente, tardarías un día entero en cumplir tus quehaceres y la menor falla costaría mucho tiempo.

Bueno, seguramente tu experiencia bañando elefantes no está siendo buena. Hasta que, un día, alguien decide construir una cabaña cerca de donde está el elefante, y mover hasta allí todos los ítems necesarios para el baño. ¡A partir de este momento, tu vida cambia! Ahora, todo está cerca y la tarea fluye con facilidad, tu esfuerzo cognitivo disminuye drásticamente y puedes enfocarte más en la tarea en sí, que es el baño. Por eso, desarrollas nuevas técnicas para bañar elefantes, y te vuelves cada vez mejor en esto. El costo general también disminuye para ti, porque un vehículo para ir y volver con ítems de baño ya no es necesario. Con el tiempo extra, pasas a mantener un control de los ítems más usados en el baño y ahora los compras en grandes cantidades, optimizando aún más los costos. Lo que antes te llevaba todo un día, de forma trabajosa y costosa, ahora te lleva menos de la mitad de un día y ocurre de manera fluida y más especializada.

Si reemplazas el elefante por un sistema complejo, y el baño por la tarea de desarrollar y mantener el sistema, estarás viendo exactamente la importancia de una buena Developer Experience: es decir, cómo la organización externa, los procesos, las herramientas y todo el entorno están influenciados -positiva o negativamente- por la concepción técnica de tu producto y, consecuentemente, en sus resultados. Analizaremos, entonces, los pormenores de todo esto.

La Developer Experience es una capa de análisis que busca ofrecer el mejor ambiente, condiciones y herramientas para que las personas desarrolladoras tengan una experiencia fluida, natural y sin grandes esfuerzos en el proceso de la concepción, mantenimiento, depuración e integración de softwares, para alcanzar así mejores resultados en menos tiempo. La DevEx (a veces, también escrita como DX) abarcará todo lo que influencia en el flujo práctico del desarrollo, y cómo eso está ayudando o dificultando las metas de la empresa o de los integradores de un determinado producto. La DX puede aparecer en algunos contextos diferentes, siendo los más comunes:

El contexto interno de la empresa. Básicamente, las personas desarrolladoras que son empleadas o prestadoras de servicios están experimentando el día a día de trabajo, y cómo esa experiencia está afectando el desarrollo del producto y, en consecuencia, las metas y los resultados.

El contexto externo de la empresa. Este es el caso de las empresas que ofrecen productos a otros desarrolladores como: herramientas, integraciones, paquetes open source y servicios en general. La DX, aquí, hace referencia a cómo la persona desarrolladora, en tanto consumidora, se relaciona con el producto. Esa DX también afecta las metas y los resultados, una vez que más personas integradoras utilizan tu producto de manera más fácil y se convierten en factores de éxito para tu negocio.

Es importante considerar que a una buena Developer Experience la construyen todos los agentes de su flujo de desarrollo y que puede representar un cambio lento y gradual de pensamiento y de cultura de una empresa. No hay una respuesta exacta a cómo tener una buena DX, porque cada producto es único y cada contexto es único. De todas formas, existen algunos puntos específicos que puedes probar para definir start points:

Procesos: asegúrate de que las fases, procesos y prioridades de tu sector de desarrollo estén bien definidas, tengan sentido y se hayan comprendido en todo el equipo.

Documentación: asegúrate de que las demandas generadas por las personas desarrolladoras estén bien documentadas y que esa documentación sea de fácil acceso. Este punto es especialmente importante si ofreces productos de integración a la comunidad, softwares de open source, APIs públicas y afines: es necesario que las personas usuarias de tus productos e integraciones tengan a su disposición una excelente documentación.

Comunicación: asegúrate de que la comunicación sea fácil y fluida en los equipos de desarrollo, y también entre otros equipos. En casos de Outer Source, verifica que sea sencillo reportar un problema, aclarar dudas o acercarse al producto. A nivel equipo: asegúrate de que tus metas se hayan definido bien, y que estén bien comunicadas y reflejadas en tu proceso organizacional.

Cultura: asegúrate de que la cultura de tu equipo y de la empresa en sí ofrecen un grado de confort y tranquilidad necesarios para un buen trabajo. Que no haya ninguna hostilidad, competencias innecesarias, fricciones sociales, incertidumbres, etc.

Autonomía: asegúrate de que cada agente tenga la mayor autonomía sobre su flujo de trabajo. Por ejemplo: las personas desarrolladoras deben tener acceso a herramientas adecuadas, bases de código, accesos privilegiados, buen hardware para trabajar y afines. Gestionar herramientas e infraestructura tampoco debe ser un problema a nivel técnico. Ofréceles autonomía.

Escucha a tu equipo: Haz reuniones constantes para medir la temperatura del equipo. Verifica los dolores y extrae oportunidades de lo que se hable.

Una buena DX se transforma en beneficios para toda la empresa, por ejemplo:

1. Buen ambiente y rutina previsible: Una mejor rutina para las personas desarrolladoras genera un esfuerzo cognitivo más liviano y un ambiente psicológicamente saludable, lo que se convierte en una mejor performance. Puedes descubrir más detalles sobre eso en este post: [How psychological safety affects employee productivity] (https://www.ragan.com/how-psychological-safety-affects-employee-productivity)

2. Economía de tiempo: En un ambiente amigable y adecuado, las tareas y demandas fluirán en un proceso mucho más ágil. Las fricciones como, por ejemplo, configuraciones de ambiente lentas y confusas, pequeños descubrimientos constantes que traban las tareas, ambientes inciertos, falta de documentación constante, comunicación incierta y lenta contribuyen mucho a un flujo más lento y frágil, transformando tareas simples en demandas complejas y agotadoras, lo que se convierte en pérdida de tiempo. Una buena DX ayuda a disminuir drásticamente este problema.

3. Optimización de Costos: Una buena DX también ayuda a optimizar costos, aprovechar las horas de cada persona desarrolladora, lo que se refleja en los demás puestos del equipo, menos optimizaciones en infraestructura, retrabajo y horas de planificación incierta. Una mala DX, generalmente, lleva a más horas aplicadas en la depuración y desarrollo de soluciones inciertas, más reuniones, desperdicio de recursos, infraestructura inadecuada, bugs frecuentes, etc. Todo eso significa más costos.

4. Más Innovación: Una buena experiencia reduce el costo cognitivo de los problemas triviales a niveles más bajos, posibilitando que la persona desarrolladora explore las mejores maneras de ejecutar las tareas, generando la mejor performance y, por momentos, innovación. Una mala experiencia de desarrollo hace que parte del esfuerzo cognitivo se aplique en mantener lo que ya existe sin romper nada mientras no se apliquen cambios en el software.

5. Multiplicación: Todos los puntos anteriores hacen al producto más previsible y comprensible, por lo que el intercambio de información entre personas desarrolladoras o de un equipo a otro se vuelve más rápido y claro. Esto ayuda a la multiplicación de conocimiento con respecto al producto.

Todos estos puntos hacen a un producto más saludable, a una cultura más saludable, a costos menores y a un ambiente de trabajo más leve y asertivo.

• Change Failure Rate (CFR): ¿Cuántos incidentes críticos afectaron a tus deploys? Roll backs, bugs críticos, problemas de infraestrutura, errores de release, etc. Empieza a observar este número por unos meses, define un valor aceptable y trabaja con tu DX para reducirlo siempre.

• Change Scope Rate (CSR): ¿Cuántas veces los planes o definiciones de una tarea cambian a mitad del camino? Eso, generalmente, genera retrabajo, pérdida de tiempo y una mala DX. Lo ideal es que ese número esté por debajo de un cuarto del número total de iniciativas.

• Time to Start (TS): Una vez que se defina conceptualmente una nueva demanda, ¿cuánto tiempo tarda en salir de la planificación y entrar a el proceso de desarrollo? Esa métrica puede cruzarse con la CFR para insights interesantes, por ejemplo: si tu TS está baja (rápida) pero la CFR está alta, puede indicar debilidad en las definiciones, tu equipo puede estar recibiendo poco contexto sobre las demandas, etc.

• Mean Time To Recovery (MTTR): ¿Cuánto tiempo tarda la demora en recuperarse? Considera que aquí no se trata del tiempo en arreglar el problema, sino en remover el síntoma del flujo de producción. Lo ideal es que una falla pueda aislarse en horas, o menos.

Alcanzar metas de manera asertiva y rápida es un factor importante y, a veces, decisivo en el desarrollo y mantenimiento de productos innovadores. Uno de los pilares para posibilitarlo es que la experiencia de la persona desarrolladora, a la hora de lidiar con la cultura interna, herramientas, análisis y comunicación, sea fluida y clara. Eso se convertirá en beneficios para todos los puestos de trabajo: desde el técnico, la gestión, hasta la persona usuaria final, convirtiéndose en una mejor reputación para el producto, optimización de costos y buen ambiente de trabajo.

En cuanto a la pregunta inicial, la del título del post, podemos decir: La Developer Experience está relacionada con la manera en que todos los aspectos alrededor del proceso de desarrollo de un producto afectan a los resultados, y con cómo optimizar esos aspectos para obtener buenos resultados. Y ese es, en sí, un excelente motivo para preocuparse con la DX de tu empresa: obtener buenos resultados.