¡Ajá 😏! Así que quieres que tu aplicación, página o servicio tenga la mejor experiencia del usuario (UX) para conseguir una percepción positiva, mejor conversión y eficiencia. Pues para crear ese valor, hay que desarrollarlo y ahí entra la importancia de conocer, entender y cuidar la experiencia de desarrollo (DX) 👩💻👨💻 en tu organización.
Entregar valor al usuario, hacerlo rápido y de la mejor manera posible 📜. Ese es el mantra de muchas empresas y organizaciones. A veces el foco es total y se busca ser eficaz pero... ya sabéis, eficaz !== eficiente. Así que para lo segundo, en ocasiones, sólo se trata de seguir frameworks ágiles. SCRUM, XP, Kanban... ¿Es eso suficiente? Lo cierto es que no. Y más conforme los equipos de desarrollo crecen en las organizaciones. Por eso es importante conocer, entender, cuidar y mejorar la Experiencia de Desarrollo.
¿Qué es la Developer Experience (DX)? 👩💻👨💻
Es la experiencia que disfrutan (o padecen 😜) los equipos de desarrollo a la hora de crear, mantener, usar o iterar los productos o servicios que una empresa u organización ofrece. Aunque esta experiencia también puede ser externa, por ejemplo de desarrolladores u otras empresas que usan nuestros servicios a través de APIs o SDKs, en este artículo vamos a centrarnos en la experiencia de desarrollo dentro de la propia empresa.
Los retos de la Developer Experience
Hay muchos retos a superar y preguntas que hacernos al hablar de la experiencia de desarrollo. Por ejemplo. ¿Es fácil desplegar a producción para entregar el valor al usuario? ¿La calidad del código es lo suficientemente buena para mantenerlo e iterarlo? ¿Tiene el equipo de desarrollo la información suficiente para hacer su trabajo? ¿Los procesos y herramientas que usan son las adecuadas? ¿Son los equipos realmente autónomos o tienen muchas dependencias?
Me ha gustado en este aspecto el tweet de Marta Manso que habla de cosas que afectan a la velocidad del equipo ⚡. No es el mismo enfoque (daría para otro artículo explicar por qué me gusta más enfocarlo desde el prisma de desarrolladores/equipos contentos en lugar de por qué van lentos) pero creo que hay retos compartidos y se entiende perfectamente 👍.
A cada reto que nos enfrentamos a la hora de hablar de Developer Experience tenemos diferentes prácticas que podemos seguir para mejorar y se puede dividir en cuatro grandes pilares: herramientas 🛠, procesos 🖇, cultura 🧠 y arquitectura 🏗.
Pongamos, por ejemplo, que tenemos un código de mala calidad. Deberemos revisar los diferentes pilares para encontrar y solucionar los problemas que estén provocando esto para poder mejorar la experiencia de desarrollo:
- Herramientas 🛠: El equipo tiene las herramientas necesarias para escribir el mejor código posible. El equipo no usa linters para evitar y/o solucionar errores de forma automática. El equipo no cuenta con herramientas para conocer la cobertura del código. Cada desarrollador usa sus propias herramientas...
- Procesos 🖇: El equipo no usa pair-programming, revisiones de código y/o pull requests. Existe revisión de código pero no es eficaz porque nadie le da importancia. Los tests no forman parte del desarrollo del software. Las tareas son demasiado grandes y hay muy poco tiempo para implementarlas...
- Cultura en el equipo y la empresa 🧠: El equipo no está motivado y por eso no le importa el código que produce. La empresa no ofrece una buena conciliación familiar. No hay conocimientos suficientes en el equipo para mantener unas buenas prácticas. La empresa sólo se enfoca al corto plazo. Nunca hay tiempo para afrontar la deuda técnica...
- A nivel de arquitectura 🏗: La arquitectura no escala y/o no encaja con los requerimientos del proyecto. La arquitectura no ofrece buenas formas de solucionar las tareas. La arquitectura no está definida y cada equipo o persona dedica su tarea a cambiarla o modificarla libremente...
Esto es solo un ejemplo de cómo podemos, tras detectar un reto para nuestra experiencia de desarrollo, preguntarnos a diferentes niveles de la organización cómo podemos afrontarlo y, entonces, sacar acciones para solucionarlo.
Es importante evitar decisiones precipitadas o soluciones irreflexivas. Por ejemplo, en el caso anterior del código de mala calidad, dar por sentado que simplemente por pasar a Typescript lo vayamos a solucionar. ¿Sabe todo el equipo de desarrollo Typescript? ¿Puede crear un silo de conocimiento en la organización? ¿Realmente es lo que necesitamos para acabar con el problema y mejor la experiencia que tenemos a la hora de desarrollar?
¿Por qué importa? 🤔
Simplemente, es insostenible en el tiempo dar la mejor experiencia al usuario mientras mantienes una deficiente experiencia de desarrollo. Fíjate que hablo de insostenible en el tiempo pero no imposible de realizar 😮. Y esto es porque sí es posible dar una buena experiencia de usuario pese a que tu experiencia de desarrollo no sea la adecuada. Al final, entregarás la funcionalidad pero no podrás mantener ese ritmo o calidad con el tiempo (o al menos no sin que tenga un coste de algún tipo). Podrías ser eficaz ✅ pero no eficiente 🚀.
Ejemplos hay muchos. ¿Hasta cuándo se puede mantener un código horrible donde vas haciendo ñapa sobre ñapa porque hay que entregar funcionalidades? Llegado un punto habrá que parar o será inviable continuar. ¿Nunca hay tiempo para mejorar el sistema de despliegue a producción para automatizarlo y sigue siendo manual y tarda la vida? Pues todo ese tiempo perdido está restando, no sólo ventaja competitiva, si no moral en el equipo de desarrollo 📉.
Y es que, además, casi siempre la inversión de tiempo en mejorar la experiencia de desarrollo es recompensada con más tiempo disponible en el futuro ⏳.
Pero ni siquiera es importante la velocidad. Nuestra organización está formada por personas 🧍♂️🧍♀️. De la misma forma que queremos ofrecer la mejor experiencia para nuestros usuarios también deberíamos querer cuidar la experiencia que tienen todos nuestros empleados. Y en ese grupo de empleados, también, los equipos de desarrollo.
Al final se debe alimentar un círculo exitoso: para ofrecer la mejor experiencia de usuario necesitas atraer, desarrollar y retener el mejor talento y, para conseguir eso, la propia experiencia de desarrollo tiene que ser la mejor posible para ofrecer la mejor experiencia de usuario 🔄.
A veces una prueba de fuego 🔥 para saber si la experiencia de desarrollo es buena viene con el onboarding de un nuevo colega al equipo. ¿Hay que explicarle muchísimas cosas de cómo funcionan y cómo se deben hacer las cosas? ¿No lleva código a producción después de mucho tiempo por dificultades o complejidades? ¿Hay que controlarle para que "no la lié"? ¿Tiene que hacer muchas preguntas porque no hay documentación? 💡
¿Qué puedo hacer para mejorar la Experiencia de Desarrollo?
A nivel personal debemos abogar por mejorar aquellos áreas en las que creemos existe mejora. La comunicación y dar feedback sincero, honesto y desde la empatía. Es normal que otros perfiles de la organización no entiendan las ventajas que puede ofrecer mejorar la DX. Hay que saber transmitir los beneficios también para el resto. Si no encuentras el apoyo en la empresa, encuentra alianzas con tus colegas para presentar mejores planes que finalmente calen.
¿Y qué puede hacer la propia empresa u organización? 👇
La DX para derribar silos de conocimiento 🔨: herramientas internas y equipos cross
Cuidar la DX es algo que debe estar en la mentalidad de la empresa. A veces, si tu organización es suficientemente grande, puede ser interesante crear un equipo cross que se dedique completamente a este cometido y que sus clientes (partes interesadas) sean los propios desarrolladores de la empresa. De esta forma puedes evitar que ciertas herramientas y decisiones sean tomadas en silos de conocimiento.
Por ejemplo, pongamos que una empresa tiene diferentes equipos y que todos suben estáticos a un S3 de Amazon ☁️. Ante esa necesidad, en lugar de que cada equipo busque e implemente una solución distinta, el equipo cross puede priorizarlo y ofrecer la misma solución para todos los equipos, documentarla y mantenerla. A veces incluso el equipo puede adoptar una solución ya existente de un equipo y, simplemente, servir de catalizador para que otros equipos usen la misma solución.
Al final lo importante es que es interesante tener y mantener ciertas herramientas internas para automatizar procesos, que tengan una buena documentación, sean fáciles de mantener, evitar que los desarrolladores tengan que enfrentarse constantemente a los mismos problemas y prevenir que se formen silos de conocimiento de forma que soluciones o conocimiento no fluye al resto de la organización o para futuras necesidades.
Abraza el código abierto 🤗
Otra estrategia muy interesante es ofrecer bibliotecas y herramientas de código abierto aunque sean pensadas para consumo interno en la compañía. ¿Por qué? Porque al abrir tu trabajo al mundo, automáticamente, cambias la mentalidad de lo que estás ofreciendo. Esto hará que estas herramientas tengas que proporcionarlas con una buena documentación y ofrezcan la suficiente abstracción de tu necesidad específica para ser reusada por otras personas (y por tu propia organización). Dicho de otra forma: priorizarás la experiencia de desarrollo 🕺.
Además, si tu repositorio suscita el suficiente interés, podrás disfrutar de la comunidad para mejorar y evolucionar ese código y que, además, es una buena forma de atraer talento 🧲. Win-win.
Aunque esta estrategia pueda sonar extravagante, en realidad, ocurre más frecuentemente de lo que uno puede pensar. Uno de los objetivos de Facebook a la hora de publicar React era asegurarse que el proyecto podría escalar y ser usado por diferentes productos dentro de la misma organización y no sólo en Facebook.com. Otras empresas como Airbnb tienen diferentes proyectos de código abierto, como Lottie, de forma que sus equipos de iOS, Android y React Native pueden usar las animaciones de After Effects independientemente del equipo. También en mi empresa seguimos este principio ofreciendo toda nuestra arquitectura como software a base de paquetes independientes.
La Experiencia de Desarrollo como negocio... 💸
Para entender del todo hasta qué punto la DX es importante, podemos echar una ojeada rápida al mercado para ver cómo van apareciendo nuevas compañías cuya estrategia principal ha girado en ofrecer la mejor experiencia de desarrollo posible. Uno de los casos más famosos es Vercel ▲ (antes llamada ZEIT).
Vercel ofrece una plataforma en la que desplegar aplicaciones web de una forma sencilla, rápida y, para proyectos pequeños, de forma gratuita. Además en su ecosistema cuenta con Next.js, un framework de React que se está convirtiendo en el standard a la hora de afrontar grandes proyectos con la librería de React ⚛️.
El lema del a empresa reza así: "Vercel combina la mejor experiencia de desarrollo con un foco obsesivo en el rendimiento para el usuario final. Nuestra plataforma habilita a los equipos de frontend a hacer su mejor trabajo.".
Hoy Vercel cuenta con más de 12 millones de usuarios y levantó en abril de 2020 una ronda de inversión de 21 millones de euros (apoyada por personalidades como Nat FriedMan (CEO de Github) o Jordan Walke (creador de React)).
Pero... ☝️
... yo trabajo en un equipo pequeño y no hace falta.
Siempre hace falta. Hasta cuando uno trabaja solo 🤷.
...no tengo tiempo de dedicarme a estas cosas.
Pues ya pagarás el precio 💰.
...no soy capaz de llevar este tipo de cambios a mi empresa u organización.
Puede no ser fácil, es verdad. Pero no desfallezcas. Encuentra alianzas, documenta bien los cambios, beneficios e insiste. Ser capaz de llevar y liderar este tipo de cambios son los que marcan la diferencia 🏁.
...nunca se priorizan tareas para arreglar X.
A veces es posible que trabajes en sprints y que el foco absoluto sea sólo y exclusivamente trabajar en el producto. Si tienes más colegas en el equipo, habla con ellos para empujar el cambio. Un Product Owner puede hablar por lo que necesita el cliente... y un buen Product Owner deja que el equipo del que forma parte priorice lo que necesite para hacer mejor su trabajo 😏.
...no me gusta que se haga X o se use Y por mejorar la DX.
A la hora de trabajar la DX se pueden crean decisiones o herramientas reusables por distintos departamentos o equipos para que, precisamente, los desarrolladores puedan enfocarse en otras cosas más importantes. A veces, esas mejoras pueden venir a costa de llegar a acuerdos y dejar de lado opiniones personales individuales 💁♀️.
¡No descuides más tu DX! 👨💻👩💻
Espero con este artículo haberte convencido para que pongas foco y recursos en mejorar la experiencia de desarrollo en tu empresa u organización. Cuando nuestro equipo de desarrollo es feliz y tiene procesos que le ayudan a su experiencia para ser más eficiente, esto se traduce en una mejor entrega de valor y calidad al usuario final.
Si te interesa descubrir más sobre este tema, te recomiendo mucho la página de developerexperience.io que recoge multitud de artículos y recursos relacionados sobre la experiencia de desarrollo y su impacto en las empresas.
También te invito a mi canal de Youtube 📹 y a mi podcast 🎙️, donde hablo sobre desarrollo web y comparto todo tipo de recursos.
Y si quieres hablar conmigo sobre la experiencia de desarrollo o quieres que te ayude al respecto, siempre puedes encontrarme en Twitter o en mi blog. ¡Muchas gracias por leerme!