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 Descripción: Una descripción breve pero detallada del problema. Comportamiento esperado: Una explicación más detallada, incluidas capturas de pantalla o referencias de Figma, de cómo deberían funcionar las cosas. Comportamiento real: Una descripción detallada de lo que está sucediendo y en qué se diferencia del comportamiento esperado. Pasos para recrear: Pasos específicos y detallados sobre cómo recrear el problema. Esto debe abordarse de tal manera que alguien pueda abrir una nueva ventana de incógnito en la herramienta y recrear el problema sin desviarse de los pasos. (opcional) Notas del desarrollador: Esta es una sección opcional en la que podemos incluir sugerencias de enfoques si ya tenemos una buena idea de cómo debería ir esto o cómo debería desarrollarse. No queremos obligar a los desarrolladores a hacer las cosas de una determinada manera, pero cualquier orientación que se brinde aquí puede ayudar a acelerar la ejecución del ticket más adelante. (opcional pero preferido) Impactos externos: Aquí es donde mencionamos las fuentes externas que pueden afectar este trabajo. ¿Hay equipos que ya hayan creado una solución alternativa para un error en nuestra API y que deban recibir una notificación cuando lo solucionemos? ¿Este error depende de otros equipos, API o fuentes para obtener información que podría afectar el tiempo que lleva solucionarlo? (opcional) Impacto: ¿Tiene esto un impacto conocido y medible en el equipo o en la empresa? Esto no siempre se sabe ni es fácil de medir, por eso es un campo opcional, pero es importante saberlo para priorizarlo si existe. Cambios de diseño Descripción: Una descripción breve pero detallada del problema. Comportamiento esperado: Capturas de pantalla o enlaces de Figma para el comportamiento diseñado y esperado. Comportamiento real: Capturas de pantalla o videos que detallen lo que realmente está sucediendo, así como una descripción de lo que está sucediendo y cómo difiere del comportamiento esperado. (opcional) Pasos para recrear: Si se trata de un elemento de interfaz de usuario específico que solo aparece en situaciones particulares, necesitamos saber exactamente cómo/cuándo debería estar presente para saber cómo probar nuestros cambios. (opcional) Notas del desarrollador: Esta es una sección opcional en la que podemos incluir sugerencias de enfoques si ya tenemos una buena idea de cómo debería ir esto o cómo debería desarrollarse. No queremos obligar a los desarrolladores a hacer las cosas de una determinada manera, pero cualquier orientación que se brinde aquí puede ayudar a acelerar la ejecución del ticket más adelante. (opcional) Impacto: ¿Tiene esto un impacto conocido y medible en el equipo o en la empresa? Esto no siempre se sabe ni es fácil de medir, por eso es un campo opcional, pero es importante saberlo para priorizarlo si existe. Solicitudes de funciones Descripción: Una descripción detallada y completa de la función, cómo debería funcionar, cuáles son las entradas y salidas esperadas, etc. También deberíamos incluir cualquier razonamiento que tengamos sobre por qué se solicita esta función. Notas del desarrollador: El desarrollador debe utilizar esta sección para brindar orientación sobre los marcos y patrones conocidos que se deben utilizar para que se adapten al resto de nuestra base de código sin problemas. No queremos obligar a los desarrolladores a escribir el código de una determinada manera, pero cualquier orientación aquí hará que la ejecución del ticket sea más rápida y debería conducir a conversaciones de relaciones públicas más agilizadas. (opcional pero preferido) Maquetas: Si tenemos ejemplos de cargas útiles, capturas de pantalla o referencias de Figma que deberían guiar el desarrollo, todo esto debería incluirse aquí. (opcional pero preferido) Impactos externos: Aquí es donde mencionamos las fuentes externas que pueden afectar este trabajo. ¿Hay equipos que ya hayan creado una solución alternativa para una función faltante en nuestra API y que deban recibir una notificación cuando la agreguemos? ¿Esta función depende de otros equipos, API o fuentes para obtener información que podría afectar el tiempo que lleva crearla? (opcional) Impacto: ¿Tiene esto un impacto conocido y medible en el equipo o en la empresa? Esto no siempre se sabe ni es fácil de medir, por eso es un campo opcional, pero es importante saberlo para priorizarlo si existe. Tareas de optimización Descripción: Una descripción breve pero detallada del problema. Estado actual: Una explicación más detallada de cómo funciona actualmente el código y por qué es ineficiente. Estado preferido: Una descripción detallada de lo que pretendemos solucionar con esta optimización y qué objetivos estamos tratando de lograr. Notas del desarrollador: Esta es una guía del desarrollador que señala la necesidad de realizar optimizaciones. Debería indicar los archivos y las pruebas específicos que se deben editar, así como las secciones específicas que creemos que son un obstáculo para el rendimiento o que causan confusión. : Prueba Notas sobre cómo se puede validar o verificar esta optimización. No solo debemos comprobar que realmente obtuvimos algo de este proceso (y puede que sea algo de lo que podamos presumir), sino que también debemos verificar que los cambios no hayan afectado a ningún proceso externo conocido que dependiera del código modificado. Impactos externos: Aquí es donde mencionamos las fuentes externas que pueden afectar este trabajo. ¿Esta función depende de otros equipos, API o fuentes para obtener información que podría afectar el tiempo que lleva compilarla o probarla? Impacto: ¿Tiene esto un impacto conocido y medible en el equipo o en la empresa? No siempre se sabe ni es fácil medirlo, pero para justificar una refactorización u optimización necesitamos tener esta informació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. , 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 primer lugar 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. En segundo lugar, si 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. A continuación, , 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. Por último 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.
