Optimización de reuniones de diseño tecnológico con plantillas de tickets estructuradas

Cuando conseguí mi trabajo en Wayfair en 2020, estaba entusiasmado por unirme a un equipo reducido y fragmentado que mantenía una herramienta B2B que generaba enormes cantidades de negocios. Venía de un puesto en el que había trabajado principalmente en un silo, por lo que estaba especialmente emocionado de volver a formar parte de un equipo de desarrollo. Sin embargo, descubrí muy rápidamente que gran parte del equipo tenía tanta experiencia en las herramientas que estábamos usando que tenían esta suposición predeterminada de que otros desarrolladores tenían la misma formación, experiencia y conocimiento que ellos. El problema principal era que las herramientas en las que estábamos trabajando eran internas y patentadas, por lo que muchos de los desarrolladores más nuevos no las conocían tan bien como los desarrolladores experimentados. Ahora bien, esto no es un problema en general. Sin embargo, se volvió muy problemático cuando los tickets de Jira se creaban, priorizaban, estimaban y asignaban con pocos detalles. Claro, el título explicaba el problema general, y el desarrollador experimentado que lo escribió probablemente sabía exactamente dónde empezar a buscar para hacer cambios, pero los que éramos más nuevos en las plataformas teníamos muy poco sobre lo que construir para comenzar. Esto provocó enormes agujeros en la eficiencia, ya que estábamos constantemente acosando a los desarrolladores con más experiencia para obtener más información.

Otra consecuencia de esta configuración era que nuestras reuniones de diseño técnico tendían a alargarse a medida que más y más de nosotros teníamos preguntas sobre los tickets que se presentaban para su estimación. Constantemente se iban dando detalles en las conversaciones, pero no se grababa nada. Estas reuniones se alargaban y, luego, volvían a surgir las mismas preguntas una vez que se asignaba el ticket (a menos que el asignado pudiera recordar mágicamente la conversación de semanas atrás en la que se habían hecho las preguntas inicialmente).

Este flujo de trabajo era increíblemente frustrante e ineficiente, pero hay esperanza. Poco tiempo después de que reconocimos este problema y lo analizamos, las reuniones comenzaron a fluir con más fluidez, a llevar menos tiempo y a tener más impacto. Los tickets estaban repletos de detalles y era fácil actuar sobre ellos, probarlos y completarlos. Así es como lo hicimos.

El problema: entradas no preparadas y reuniones prolongadas

Nuestras reuniones de diseño técnico solían verse frustradas por tickets que no contenían suficientes detalles. Los desarrolladores, diseñadores y otras partes interesadas dedicaban demasiado tiempo a buscar información adicional o a aclarar aspectos imprecisos de una tarea. Esto no solo alargaba nuestras reuniones, sino que también retrasaba el desarrollo, ya que los tickets asignados solían rebotar y requerían más aclaraciones antes de poder continuar con el trabajo.

Un gran ejemplo de esto podría ser un ticket informado por un desarrollador experimentado que simplemente decía "Necesitamos arreglar los precios de los SKU de pisos".

Está claro que, sin una cantidad suficiente de información de fondo, no hay absolutamente nada que puedas hacer cuando recibes este ticket. ¿Cuál es el problema con la fijación de precios en los SKU de venta al público? ¿Qué se espera que suceda? ¿Importa la cantidad de SKU en el carrito? Hay muchas preguntas abiertas y realmente no hay forma de comenzar a trabajar sin acudir a una reunión. Una mejor descripción del ticket podría ser:

“Los SKU de piso tienen precios a granel y nuestro sistema no maneja correctamente los cálculos de precio/cantidad cuando la cantidad en el carrito excede los umbrales de precios a granel”.

Ahora bien, todavía no hay suficientes detalles aquí, pero al menos explica el problema adecuadamente.

No voy a extenderme demasiado en el ejemplo, pero los desarrolladores tendrían que desarrollar todos estos detalles con preguntas, conversaciones y presentaciones repetidas hasta que tuviéramos suficientes detalles para estimar o trabajar en el ticket, según la tarea en curso. Esto provocó una gran pérdida de tiempo que nosotros, como desarrolladores, no pudimos recuperar.

La solución: implementar plantillas de tickets

Para resolver este problema, desarrollamos un conjunto de plantillas de tickets estructuradas y adaptadas al tipo de trabajo que se estaba realizando. Estas plantillas garantizaban que cada ticket (ya fuera un informe de error, un cambio de diseño, una solicitud de función o una tarea de optimización) contuviera toda la información necesaria antes de ser analizado o asignado. La regla era simple: si la plantilla no estaba completamente completa, el ticket no estaba listo para la reunión o para el desarrollo.

Informes de errores

Cambios de diseño

Solicitudes de funciones

Tareas de optimización

El impacto de las plantillas

Los resultados fueron inmediatos.

Rápidamente nos dimos cuenta de que podíamos resolver aproximadamente tres veces más tickets en una sola reunión de diseño técnico de una hora de duración que antes. Además, las discusiones que teníamos en estas reuniones eran más beneficiosas e impactantes. Nos tomábamos el tiempo para señalar casos extremos, equipos afectados y posibles obstáculos o cuellos de botella en el proceso, preparando a los desarrolladores para el trabajo en lugar de pasar todo nuestro tiempo tratando de captar más detalles. También nos obligamos a seguir un patrón en el que registrábamos todos estos comentarios en el ticket, ya sea en la descripción o en los comentarios. Las plantillas eran un recordatorio constante de que estos detalles eran importantes y que debían estar presentes y ser fáciles de encontrar. En cierto modo, estas plantillas volvieron a entrenar nuestros cerebros para adoptar un enfoque de documentación ante estos tickets, asegurando que quienquiera que tomara el ticket, ya sea un desarrollador junior o un ingeniero experimentado, tuviera suficiente información para escribir un código de alta calidad.

Luego, notamos que nuestros ciclos de desarrollo eran más concisos, nuestras estimaciones eran más precisas y estábamos alcanzando esa codiciada marca de finalización del 100 % en los sprints con mucha más frecuencia que nunca antes. Pudimos completar nuestro tablero casi de manera constante. No solo es importante para la empresa porque recibían actualizaciones cuando les dijimos que las recibirían, sino que también fue un gran refuerzo de confianza para el equipo, ya que constantemente se colocan en una posición de éxito. Nuestras partes interesadas vieron nuestra eficiencia y rendimiento mejorados y ganaron una mayor confianza en nuestro equipo y nuestro proceso. También notaron que nuestro código era de mayor calidad, ya que pudimos dedicar más tiempo a concentrarnos en el problema real en cuestión.

Sabíamos desde el principio que esto mejoraría nuestras vidas como desarrolladores, pero no nos habíamos dado cuenta del impacto positivo que tendría también en nuestros socios comerciales.

Conclusiones clave para otros equipos

Si siente que su equipo está constantemente agobiado por la falta de información, podría valer la pena investigar si la creación de plantillas de tickets estructuradas podría funcionar para usted. Es importante señalar que esto requiere tiempo adicional del desarrollador para desarrollar los tickets con suficiente detalle para tomar medidas. Creo que este es un costo justificado y genera un gran ahorro de costos a largo plazo, ya que mejora enormemente sus flujos de trabajo, pero es importante señalar que estos cambios no ocurren de manera gratuita. Alguien tiene que dedicar tiempo a investigar y redactar un ticket de alta calidad y es probable que esa persona sea su equipo de desarrollo.

Dicho esto, es fácil ver lo importante que puede ser esta victoria para un equipo. Para empezar, recomendaría seguir algunos pasos breves.

En primer lugar , evalúa si realmente tienes un problema. A veces, uno o dos desarrolladores tienen problemas con la documentación o la transferencia de conocimientos, pero eso no es indicativo de un problema a gran escala con tus tickets. Tal vez otras cosas, como una mejor integración o documentación, podrían resolver algunos de esos problemas.

En segundo lugar, si descubre que se trata de un problema generalizado que necesita una solución, el siguiente paso es categorizar qué tipo de tickets recibe normalmente y qué tipo de información se requiere en cada uno. Los candidatos obvios son los errores y las características, sin embargo, según la naturaleza del negocio de su empresa, tal vez tenga otros tipos de tickets que fluyen constantemente a través de su sistema y tienen diferentes necesidades. Tal vez su equipo gestione un flujo de trabajo ETL y necesite saber qué entradas/salidas se ven afectadas por los tickets relacionados con eso. Tal vez su equipo tenga un SDK y los tickets relacionados con él deban manejarse de manera especial/prioritaria y deban incluir qué funciones comerciales podrían verse afectadas por un cambio. Conozca a su equipo y sus requisitos para poder determinar exactamente qué tipos de plantillas se requieren.

A continuación, una vez que tengas toda esta información, ponla por escrito en algún lugar compartido al que todos tengan acceso. Quizás se trate de un documento compartido, o una página wiki que el equipo administre y acceda a ella, o quizás incluso puedas crear plantillas en el propio Jira, obligando a la gente a usarlas. Independientemente de cuál sea tu enfoque, necesitas conseguir la aceptación del equipo y de los desarrolladores, lo que significa que deben poder verla. Este es uno de los pasos más importantes porque este proceso no avanzará a menos que tengas la aceptación del 100 % de todos los que escribirán tickets. Presenta estas plantillas a tu equipo, recopila comentarios, explica cómo crees que este nuevo proceso te afectará a ti y a las partes interesadas. Asegúrate de que todos los miembros del equipo se sientan cómodos con el nuevo proceso.

Por último , debes hacer cumplir estos cambios. Los tickets presentados sin suficientes detalles deben ser rechazados inmediatamente sin discusión. Es importante ser estricto con el seguimiento de las pautas de la plantilla o la gente siempre encontrará razones para evadirla. "Este problema es demasiado crítico, no tengo tiempo para escribirlo" es una queja común que recibimos. Sin embargo, si eres estricto con la necesidad de una plantilla y trabajas con personas que están tratando de evadirla, eventualmente los convencerás.

En Wayfair, hemos visto mejoras importantes en los procesos y la moral de nuestro equipo al implementar los pequeños cambios que se mencionan arriba. Espero que esto también ayude a tu equipo.