Cerrar el ciclo de feedback desde el changelog

Un ciclo de feedback del cliente se cierra cuando a la persona que dio el feedback se le dice qué pasó con él. No cuando se archiva. No cuando se prioriza. Ni siquiera cuando se lanza. Cuando se le dice. La mayoría de los equipos hacen bien los primeros tres pasos y el último no lo hacen en absoluto, y luego se preguntan por qué la gente que envía feedback deja de enviarlo.

Este artículo trata de ese último paso, y de una afirmación concreta: el changelog es el lugar correcto para cerrar el ciclo, porque es el único artefacto que ya existe exactamente en el momento en que el ciclo se puede cerrar.

¿Qué es un ciclo de feedback del cliente?

Un ciclo de feedback del cliente es el camino desde que una usuaria te dice algo hasta que esa usuaria se entera de qué hiciste al respecto. Tiene cuatro pasos: recolectar el feedback, decidir qué hacer con él, lanzar el resultado, y avisarle a quien preguntó. El ciclo está abierto hasta que pasa el cuarto paso. Un equipo que recolecta feedback y lanza correcciones pero nunca avisa a nadie tiene una bandeja de entrada, no un ciclo.

La cuarta fila es de la que trata este artículo. Se rompe por una razón estructural, no cultural: para cuando una función se lanza, la petición que la causó vive en un sistema distinto de la cosa que se lanzó, y no es trabajo de nadie conectarlas. El ciclo empieza antes, con cómo se pide la petición desde el principio; cómo pedir feedback a los clientes cubre la redacción y el momento.

¿Por qué se quedan abiertos los ciclos de feedback?

Los ciclos de feedback se quedan abiertos porque la petición y el cambio lanzado viven en lugares distintos y el enlace entre ambos se hace a mano, si es que se hace. La petición está en una herramienta de feedback, una bandeja de soporte o una hoja de cálculo. El cambio está en un pull request. El anuncio está en un changelog o un correo. Tres sistemas, tres dueños, y el enlace del tercero de vuelta al primero es una persona que recuerda, meses después, quién preguntó.

Hay una segunda razón. El paso de avisar suele enmarcarse como una tarea de marketing (“anunciar la función”) en vez de una tarea de soporte (“responderle a la persona”). Los anuncios van a todos y no llegan a nadie en particular. La persona que pidió la función en marzo lee el anuncio en junio, si es que lo lee, como noticia, no como respuesta. El ciclo se cierra solo si el mensaje va dirigido a ella.

¿Por qué cerrar el ciclo desde el changelog?

Porque la entrada de changelog es el único artefacto que existe exactamente en el momento correcto, contiene exactamente las palabras correctas, y lo escribe exactamente la persona correcta. Existe cuando el cambio está en vivo y no antes. Dice qué cambió en los términos de la lectora, que es el mensaje que necesita quien preguntó. Y lo escribe alguien que acaba de leer el pull request, que es el único momento en que el enlace a la petición original sigue siendo visible.

Compara las alternativas. Cerrar el ciclo desde la herramienta de feedback significa que la herramienta de feedback tiene que saber cuándo se lanzó la función, lo que significa que alguien actualiza un estado a mano. Cerrarlo desde el pull request significa avisarle a la clienta al mergear, antes de que el cambio esté en vivo, una promesa rota con marca de tiempo en cuanto se retrasa el despliegue. Cerrarlo desde el anuncio de marketing significa esperar a que haya uno, y la mayoría de los cambios lanzados nunca tienen uno.

El changelog está en el medio: después del merge, en el momento del lanzamiento, con la redacción lista.

Cómo se cierra el ciclo, paso a paso

Este es el mecanismo que ejecutamos. Se describe aquí como especificación en vez de recorrido de producto, porque cada paso se puede hacer a mano o con otras herramientas; lo que importa es el orden.

1. El feedback se convierte en un issue en el repositorio que lo va a corregir. Un envío de widget se archiva como issue etiquetado de GitHub (feature-request o bug, una prioridad, y from-widget), con la dirección de correo de quien lo envió fuera del cuerpo del issue. El issue vive junto al código, para que el paso tres pueda encontrarlo. Un issue creado a mano, por ejemplo desde una plantilla de solicitud de función, queda fuera de este camino: el paso cinco no lo comenta, así que cierra ese ciclo tú mismo.
2. La corrección referencia el issue. El pull request dice Fixes #142, la propia palabra clave de cierre de GitHub. Nada nuevo que aprender, y es la misma frase que las desarrolladoras ya escriben.
3. La entrada de changelog se redacta a partir del pull request mergeado y lleva el enlace. Al mergear, se crea el borrador y #142 se lee del cuerpo del PR y se adjunta al borrador. El enlace se crea mientras sigue siendo barato, por una máquina, con datos que ya están ahí.
4. Una persona revisa la entrada. Redacción, audiencia, si debería publicarse siquiera. Un borrador descartado no cierra nada, lo cual es correcto: un refactor interno que casualmente referenció un issue no es noticia.
5. Al aprobarse, se avisa a quien preguntó. Se publica un comentario en el issue en que se convirtió su feedback, “Shipped —” seguido del título de la entrada y un enlace a la entrada publicada, y el widget le muestra a quien lo envió la misma entrada lanzada. Una vez, nunca dos, y solo después de que una persona haya publicado la entrada. La misma entrada sale por feed y widget a todos los que no preguntaron.

El orden del paso cinco es todo el diseño. Avisarle a quien preguntó al mergear sería más temprano y más fácil, y sería incorrecto aproximadamente tan a menudo como se retrasan los despliegues. Un feature flag rompe incluso este orden, porque aprobado y publicado puede pasar mientras la función sigue siendo invisible para la cuenta de quien la pidió; feature flags y solicitudes de funciones cubre la verificación extra que este paso necesita en cuanto hay un flag de por medio.

¿Cómo se ve un ciclo cerrado para la clienta?

Se ve como una respuesta. La clienta envió una petición a través de un widget, y un día el widget la muestra como lanzada, con enlace a una entrada que la describe en sus términos; en GitHub, el issue recibe la misma noticia como comentario. No se suscribió a un boletín, no revisó una roadmap, no buscó en el changelog. Le avisaron.

Esa es la experiencia que provoca el siguiente pedazo de feedback. La gente le envía feedback a productos que responden. La página de ejemplos de changelog incluye entradas de equipos cuyos usuarios visiblemente siguen volviendo con peticiones, y el hilo común no es la herramienta; es que las entradas se leen como respuestas.

¿Cómo se mide un ciclo de feedback?

Mide la fracción de cambios lanzados que avisaron al menos a quien preguntó, y el tiempo desde el lanzamiento hasta el aviso. Dos números, ambos fáciles una vez que el enlace existe e imposibles antes.

• Tasa de cierre: de las entradas de changelog publicadas este mes, cuántas enlazaron al menos una petición, y de esas, cuántas avisaron a quien preguntó. Si el segundo número es mucho más bajo que el primero, las notificaciones están fallando; si el primero es bajo, las peticiones no se están referenciando desde los pull requests, y la corrección es una frase en la plantilla de PR.
• Tiempo de lanzamiento a aviso: cuánto pasa entre que la entrada sale en vivo y se avisa a quien preguntó. Con el mecanismo de arriba son segundos. A mano son típicamente semanas, o nunca, y “nunca” es el número que importa.

No midas el ciclo por el volumen de feedback recolectado. Recolectar es el paso fácil, y un equipo que lo mide lo va a optimizar, lo cual produce más ciclos abiertos.

¿Dónde encaja la roadmap?

Una roadmap pública es una forma de cerrar el ciclo temprano: le dice a quien preguntó que su petición fue escuchada, antes de que se lance. Es útil, y no sustituye el último paso. “Planeado” es una promesa sobre el futuro; “Lanzado” es un hecho sobre el presente. Ejecuta la roadmap pública a partir de los mismos issues, con una etiqueta por columna, para que la misma petición se mueva de planeada a lanzada sin volver a introducirse en ningún sitio. El paso a lanzada es un cambio de etiqueta (roadmap:shipped) que nadie hace por ti cuando se aprueba la entrada, así que hazlo en la misma revisión.

FAQ

¿Cuáles son los cuatro pasos de un ciclo de feedback del cliente? Recolectar, decidir, lanzar, avisar. El ciclo está abierto hasta que pasa el cuarto paso. La mayoría de los marcos añaden pasos de análisis y priorización en el medio; son refinamientos de “decidir”, y ninguno cierra nada.

¿Debería avisarse a los clientes cuando se rechaza una petición? Sí, y es el mensaje más descuidado del ciclo. Un claro “no vamos a hacer esto, y aquí está por qué” termina la espera. El silencio deja el ciclo abierto para siempre y a la clienta comprobando.

¿En qué se diferencia cerrar el ciclo de anunciar una función? Un anuncio va a todos. Cerrar el ciclo es una respuesta a la gente que preguntó, por el canal por el que preguntó. Haz ambas cosas; son mensajes distintos para lectoras distintas.

¿Y si quien preguntó no está en GitHub? La mayoría no lo está, y no pasa nada. El widget les sigue mostrando el estado de lo que enviaron, incluida la entrada lanzada y su enlace, así que no necesitan nada más allá de la página desde la que escribieron. El comentario en el issue es para las personas que pueden ver el repositorio.

¿Este ciclo funciona en GitLab o Bitbucket en vez de GitHub? El widget y el changelog sí. El comentario automático del paso cinco todavía no. Un equipo en GitLab o Bitbucket sigue recibiendo cada envío, sigue archivándolo como issue, y sigue mostrándole a quien preguntó un estado en el widget, pero cerrar ese ciclo concreto de vuelta sobre el propio issue es un paso que hay que hacer a mano hasta que exista esa integración.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Ejemplos de changelog