Lo Que los Tickets No Hacen Bien

Los tickets rastrean trabajo. Son terribles para almacenar conocimiento. Un ticket que dice "migrar el servicio de autenticación al nuevo formato de token" captura qué debe suceder y por qué, pero la decisión arquitectónica resultante, la especificación del formato de token y la estrategia de migración no pertenecen al ticket. Pertenecen a documentación que sobrevive al ciclo de vida del ticket.

El modo de falla es familiar: un equipo usa tickets como su base de conocimiento, y seis meses después, encontrar la decisión de migración de autenticación requiere buscar entre 2,000 tickets cerrados con palabras clave que coinciden con docenas de resultados no relacionados. La decisión está ahí en algún lugar, enterrada en una descripción, un comentario o un archivo adjunto, pero no es localizable en un tiempo razonable.

Los tickets son efímeros por diseño. Representan una unidad de trabajo con un inicio, un final y un estado. Las decisiones de arquitectura, contratos de API, procedimientos de runbook y guías de incorporación son conocimiento persistente que necesita un hogar persistente: un wiki, un directorio /docs en el repositorio, un archivo ADR (Architecture Decision Record). El ticket puede enlazar al documento. El documento no debería vivir dentro del ticket.

Un hilo de 30 comentarios en un ticket es una conversación que debería haber ocurrido en otro lugar. Los tickets son herramientas de coordinación: responden "¿qué debe suceder?" y "¿está hecho?" No son el medio adecuado para debates de diseño, negociaciones de requisitos o sesiones de resolución de problemas.

Cuando un ticket se convierte en un hilo de chat, tres cosas salen mal. Primero, la relación señal-ruido cae: los requisitos reales están enterrados entre actualizaciones de estado, preguntas tangenciales y pings de "¿alguna actualización sobre esto?" Segundo, la conversación no es visible para personas que no están siguiendo ese ticket: una decisión de diseño tomada en un comentario de ticket no aparece en el canal de Slack del equipo, notas de reunión o documentación. Tercero, los metadatos del ticket (estado, asignado, fecha de vencimiento) se desconectan de la realidad de un alcance que aún está evolucionando.

La discusión pertenece a herramientas de discusión: hilos de Slack con un resumen publicado de vuelta al ticket, documentos de diseño enlazados desde el ticket, o una llamada de 15 minutos con notas capturadas en la descripción. El ticket es la página de inicio de una pieza de trabajo, no la transcripción de cada conversación sobre ella.

Un backlog no es un estacionamiento para ideas, pero la mayoría de los equipos lo tratan como tal. Cada solicitud de función, error menor, "sería bueno tener" y "probablemente deberíamos hacer esto algún día" obtiene un ticket, y ese ticket permanece sin tocar durante meses. El backlog crece. Nadie lo poda. Eventualmente tienes 800 tickets y ninguna forma de distinguir los 30 que importan de los 770 que no.

Los backlogs obsoletos conllevan costos reales. Los ingenieros pierden tiempo desplazándose por tickets muertos en la planificación de sprint. Los nuevos miembros del equipo no pueden distinguir qué tickets son actuales y cuáles son fósiles de dos pivotes de producto atrás. Las búsquedas devuelven ruido. El backlog se convierte en un monumento que induce culpa al trabajo que el equipo nunca hará, y cada vistazo a él socava la confianza en el proceso de planificación.

La higiene del backlog es una disciplina, no una limpieza única. Una cadencia saludable: una vez al mes, revisar cada ticket con más de 90 días de antigüedad. Si no ha sido priorizado en tres meses, o no es lo suficientemente importante para hacerlo o no está lo suficientemente bien definido para estimarlo. Ciérralo. Si importa, volverá, y cuando lo haga, volverá con contexto fresco y prioridades actuales.

El instinto es mantener los tickets abiertos "por si acaso". Ese instinto está equivocado. Un ticket cerrado no está eliminado: es buscable, enlazable y reaperturible. Cerrarlo solo significa que el equipo es honesto sobre lo que realmente está en el alcance. Un backlog de 50 tickets que refleja prioridades reales es infinitamente más útil que un backlog de 800 tickets que refleja cada idea que alguien tuvo alguna vez.