Por Qué Existen los Tickets

El conocimiento del equipo almacenado solo en las cabezas es conocimiento del equipo con un único punto de falla. Un ingeniero que "simplemente sabe" cómo funciona el pipeline de deploy, qué variables de entorno se requieren, o por qué el servicio de autenticación tiene esa lógica de reintento extraña está cargando memoria institucional a la que el resto del equipo no puede acceder, buscar o verificar.

Los tickets externalizan ese conocimiento en un sistema compartido y buscable. Cuando un ingeniero crea un ticket para una pieza de trabajo, no solo está haciendo seguimiento de una tarea — está registrando que el trabajo existe, qué requiere y por qué importa. Seis meses después, cuando alguien pregunta "¿alguna vez arreglamos la condición de carrera en el flujo de pagos?", la respuesta es una consulta de búsqueda, no un mensaje de Slack a alguien que puede haber dejado la empresa.

La alternativa — mantener el trabajo en cabezas, hilos de Slack y notas adhesivas — funciona para un equipo de 3 personas en una habitación con memoria perfecta. Se rompe en el momento en que alguien se va de vacaciones, cambia de proyecto o renuncia. Cada pieza de conocimiento almacenada exclusivamente en la cabeza de una persona es un riesgo de factor bus que el equipo está eligiendo cargar. Los tickets no eliminan la necesidad de conversación, pero le dan a esas conversaciones un artefacto duradero que sobrevive a las personas que las tuvieron.

Cada decisión no trivial en una base de código eventualmente se cuestiona. "¿Por qué agregamos este endpoint?" "¿Quién decidió eliminar el soporte para IE?" "¿Cuándo cambió la lógica de precios?" Sin tickets, responder estas preguntas requiere arqueología — excavar en Slack, contactar a antiguos compañeros de equipo, leer diffs de commits y adivinar la intención.

Los tickets crean un rastro de decisiones. Cada ticket registra quién solicitó el trabajo, cuándo se priorizó, cuáles eran los criterios de aceptación y — a través de PRs y commits vinculados — exactamente qué código cambió para cumplirlo. Esto no es trabajo burocrático; es la diferencia entre "creo que cambiamos eso en marzo" y "aquí está el ticket, el PR y la discusión de revisión".

La trazabilidad también importa para cumplimiento y respuesta a incidentes. Cuando surge un bug de producción, la pregunta "¿qué cambió recientemente?" debería tomar segundos, no horas. Un equipo con buena higiene de tickets puede rastrear desde un deploy hasta un merge, desde un merge hasta un PR, desde un PR hasta un ticket, y desde un ticket hasta la solicitud original. Un equipo sin esto está leyendo git log y adivinando.

Los tickets son la capa de coordinación para equipos que no pueden estar en la misma habitación al mismo tiempo. En un equipo co-ubicado de tres, puedes coordinar girando tu silla. En un equipo distribuido de ocho a través de tres zonas horarias, "solo hablen entre ustedes" no es una estrategia de coordinación — es un deseo.

Un sistema de tickets le da a cada pieza de trabajo una URL estable, un estado y un responsable. Un ingeniero en Londres puede tomar un ticket, ver qué se espera, revisar los criterios de aceptación y comenzar a trabajar — sin esperar a que el ingeniero en San Francisco que lo creó se despierte. El ticket es el punto de transferencia asíncrona.

Esto escala hacia abajo tan bien como hacia arriba. Incluso un equipo co-ubicado se beneficia de la coordinación asíncrona cuando las personas están en reuniones, enfermas o en trabajo de concentración profunda. El ticket siempre está disponible. La persona que lo escribió no.