Imagina la escena: vas conduciendo por una carretera infinita a máxima velocidad. El indicador de la gasolina lleva desde hace varios kilómetros atrás avisando, pero no puedes parar a repostar. Tienes que llegar cuanto antes a tu destino y no hay tiempo para otro asunto. El final: tarde o temprano te quedarás sin combustible, el motor se romperá y tendrás que abandonar ese coche.
Esta analogía podría servir para ilustrar la apisonadora del día a día de muchas startups, solo centradas en sacar nuevas funcionalidades a cualquier coste. Sin dedicar tiempo y pararse a preguntar a sus desarrolladores de software lo que necesitan para trabajar más eficientemente o qué partes técnicamente les producen mayores de dolores de cabeza.
Aquí hablamos de algo muy amplio, ya que pueden ser desde herramientas software que no tienen, hardware o el propio codebase, la deuda técnica, librerías obsoletas que nunca sacamos tiempo para actualizar. Es decir, cosas que pasamos por alto sin prestar atención. Aquí incluimos procesos de testing, procesos de QA, integración continua y release para conseguir una build, la documentación, el proceso de onboarding de los nuevos miembros o la forma de comunicación con el resto del equipo de producto (diseñadores, Product Manager o Engineering Managers).
¿En qué puntos técnicos debemos mejorar? Obviamente esto no es un KPI sin más, sino que necesitamos un contexto para ayudar a priorizar mejor un roadmap.
¿Cuáles son los puntos que están causando problemas de su trabajo diario? ¿En qué puntos técnicos debemos mejorar? Obviamente esto no es un KPI sin más, sino que necesitamos un contexto para ayudar a priorizar mejor un roadmap. La solución podría ser preguntar a los desarrolladores del equipo qué opinan. Aquí surge la idea de la Developer Survey, no confundir sin más con un indicador de la felicidad de los desarrolladores, engloba muchas más cosas.
Creando una encuesta para ver qué opinan los desarrolladores
En el día a día, en las propias weekly del equipo, las retrospectivas o los 1:1 aparecen temas interesantes para mejorar la productividad y “la felicidad del equipo”. Pero aun así, sigue siendo difícil tener algo específico que nos ayude a tomar decisiones, acometer action point y priorizar ciertas tareas técnicas por encima de las feature que el producto demanda.
Tener un equipo centrado en el tooling, la arquitectura y que vaya más allá de las propias features de producto ayuda bastante. Llamémosle equipo de Core, Tooling, Staff o Platform, depende de la compañía.
A la hora de crear un roadmap puramente técnico necesitamos priorizar un gran número de tareas que irán surgiendo y afectará a distintas áreas. Esto solo se podría conseguir teniendo unos indicadores concretos que identifiquen el problema, el objetivo a solucionar y las acciones a aplicar.
Para ello, un punto de partida es crear esa encuesta dirigida a los desarrolladores del equipo sobre distintas facetas. Tanto de producto como sobre asuntos técnicos y de la salud del proyecto. Esto último es fundamental para anticiparnos a problemas futuros que el día a día frenético oculta.
Lo primero que deberíamos hacer es dividir los temas que nos interesan. El Joel Test es un buen punto de partida. Aquí viene un ejemplo más amplio que nos podría servir de guía:
- El entorno de desarrollo. Herramientas necesarias, documentación de onboarding al equipo, documentación de procesos internos, etc.
- Codebase: grado de satisfacción con el código actual, posibles refactors, partes de la arquitectura que deberíamos mejorar, cómo afecta el código legacy para entregar nuevas funcionalidades, errores comunes, etc.
- Code Review: proceso de revisión de código, Pull Request, calidad del código entregado.
- Testing: entorno de ejecución local y en CI, tipos de test usados (UI o Unit)
- Entorno de pruebas: entornos de pre producción, staging, entornos locales de ejecución.
- CI: uso de la integración continua, grado de las satisfacción de la infraestructura
- Proceso de release: principales cuellos de botella, facilidad para hacer builds, despliegue a los usuarios finales
- Documentación: grado de satisfacción general, temas que deberíamos documentar.
- Feedback del equipo: grado de felicidad, coordinación, satisfacción del trabajo hecho.
- Trabajo en remoto: herramientas de comunicación, coordinación, sincronización, meetings, etc.
- Futuros desarrollos: nuevos framework, mejoras en la arquitectura, futuras pruebas de concepto, priorización de las áreas de investigación y desarrollo.
Este listado de temas cubre un amplio abanico de asuntos que nos interesa evaluar dentro del equipo. Saber cuál es la salud de cada uno de ellos y detectar lo que no estamos haciendo bien y reforzar lo positivo.
Después de tener ese listado de temas a evaluar, similar al descrito arriba, lo interesante es empezar a formular las preguntas necesarias. Os comparto una plantillas en markdown con algunas de las preguntas que hemos ido a haciendo con el tiempo en el equipo de desarrollo.
¿Preguntas de valoración o preguntas de texto libre?
Después de tener el listado de temas, lo ideal es usar una combinación de preguntas en las que podamos calcular una valoración y otro conjunto de preguntas de texto libre para que los desarrolladores puedan complementar sus valoraciones, además de dar ideas explayándose todo lo que quieran.
Para los valores numéricos podemos usar una escala NPS (0-10) o Likert (1-5). Por la naturaleza de las preguntas que tenemos en la encuesta, nos decantamos por este último modelo.
Likert es una escala psicométrica comúnmente utilizada en cuestionarios y es la escala de uso más amplio en encuestas de investigación. El formato típico de elementos con 5 niveles serían: totalmente satisfecho, satisfecho, neutral, insatisfecho o totalmente satisfecho.
Con esta plantilla podéis jugar con un conjunto de combinaciones: satisfacción, acuerdo, relevancia, frecuencia o importancia. De hecho, será con este tipo de valoraciones con la que intentaremos intercalar las preguntas a los ingenieros para tener una foto más amplia.
Recomendaciones a la hora de rellenar la encuesta
Vamos a ir preparando el camino.
Porcentaje de encuestas rellenadas. Todo depende del tamaño del equipo. Obviamente para un equipo de 4-6 personas podríamos decidir que todo el mundo debería completarla, es una obligación. En equipos más grandes de 20-50 personas, quizás no sea posible que todo el mundo lo rellene, aunque un 80% sería adecuado para no dejar escapar ningún punto de vista.
Tiempo para completar la encuesta. Da tiempo a tu equipo para hacerlo. Suelen ser preguntas largas, por lo tanto, mínimo una semana para que el equipo pueda ir rellenándola con calma. Tienen que estar avisados.
Define cómo debe ser el formato de las respuestas esperado. Fija ciertas recomendaciones antes de completar las preguntas de texto libre. Explica al equipo que algunas preguntas requieren redactar o un análisis con antelación. No valen las respuestas: “Ahora mismo no se me ocurre nada”, “No tengo nada en mente”, etc. Esta encuesta no es una encuesta rápida que te hacen al salir del supermercado.
Deja claro que la encuesta tiene un objetivo y un plan posterior. Esto es importante, ya que sino el equipo podría estar desanimado y no verá ninguna utilidad en la encuesta. Explica el plan que tienes cuando obtengas los resultados de la encuesta y cómo se crearán los action points necesarios.
¿Qué cosas queremos averiguar con la encuesta?
Lo más obvio, los problemas que tiene el equipo. Los temas más conflictivos en lo que probablemente recibiremos puntuaciones más bajas: documentación, comunicación entre teams, falta de conocimiento en el uso de herramientas o impedimentos para hacer de una forma más eficiente el trabajo.
También, deberíamos obtener ideas de nuevas tareas que hacer: refactors de las piezas más conflictivas, herramientas para automatizar ciertos aspectos más ásperos, futuras ideas de investigación o pruebas de concepto, etc. Y sin olvidarnos de la adopción de nuevas tecnologías, ya sean lenguajes, framework, librerías o paradigmas que mantengan la motivación del equipo y veamos que son necesarias.
Con todos esos temas nuestro objetivo será construir un plan de acción, ya sea priorizando esos asuntos en el roadmap. Dando un peso mayor a esas tareas técnicas que hasta ahora estaban quedando ocultas por el día a día de las features de producto.
Para ello después de recopilar los resultados, siéntate con el equipo para acordar los action point. Si puedes fija algunos action point ligados a ciertas valoraciones para poder validar que hemos conseguido el objetivo. Por ejemplo: aumentar el grado de satisfacción de la documentación que tiene el equipo o la sensación de velocidad a la hora de revisar PRs. Puede que estas sean las más fáciles, pero son un buen punto de partida.
En resumen: crea tu primera encuesta de desarrolladores y observa los resultados, algunos puede que te sorprendan
Como hemos comentado anteriormente, no hay que olvidar las otras vías para obtener feedback de los desarrolladores (1:1, weeklies, PR, etc..), pero las encuestas nos permite documentar y crear unos indicadores de la satisfacción del equipo fácilmente. Con estas “developer surveys” tendremos una excelente foto general de la marcha del equipo y nos servirán de motivación para ayudarle a crecer.
Puedes lanzarte creando una encuesta sencilla con un par de temas que preocupan a los desarrolladores. Lo fundamental es que después de analizar y recopilar los datos tengas un plan de acción. Empresas como Linkedin o Shopify basan su estrategia de tooling en las encuestas de anuales o semestrales de Developer Survey.
Puedes usar la plantilla que comentaba más arriba para crear tu primera encuesta. Elige las preguntas que mejor se adapten a tu equipo o dale una vuelta.
Elige algún servicio de encuesta que te permita crear un formulario online vistoso y fácil de rellenar, por ejemplo, Google Forms o Typeform que ya cuenta con ciertas plantillas permitiendo exportar los resultados y resumirlos de forma sencilla.
Y por supuesto, la encuesta de desarrolladores también puede ser usada para mejorarla así misma en sucesivas iteraciones, así que reserva algunas preguntas para consultar feedback sobre el propio cuestionario.
Foto Glenn Carstens-Peters on Unsplash
This article was also published in English Ask the Developers What Headaches Really They are Facing
Deja un comentario