Todo gestor de incidencias acaba teniendo campos personalizados, y todo equipo que los recibe pasa por el mismo ciclo: un arrebato de entusiasmo, once campos nuevos y, seis semanas después, un formulario donde nueve de ellos están vacíos en cada ticket.
El problema no son los campos personalizados. Es que «¿sería útil saber esto?» es la pregunta equivocada antes de crear uno. Casi todo sería útil saberlo.
La prueba que conviene aplicar
Antes de añadir un campo, pregúntate: ¿qué decisión cambia por él?
No «qué nos diría», sino qué harías distinto. Si la respuesta sincera es «podríamos verlo», ese campo estará vacío dentro de un mes, porque nadie rellena un campo que no cambia nada.
Dos ejemplos de la misma información que pasa y no pasa la prueba:
Versión afectada, en un equipo que publica cada semana y mantiene dos versiones: pasa. Decide si un bug necesita un backport.
Versión afectada, en una app web con despliegue continuo: no pasa. Todo el mundo está en la misma versión. Es un campo que registra la fecha en un formato peor.
El campo es idéntico. La decisión no.
La segunda prueba: ¿quién lo rellena?
Un campo que rellena quien hace el triaje es realista. En cambio, un campo que pide información que solo tiene quien reportó el bug, o que solo tiene un ingeniero después de investigar, se salta durante el triaje y nadie vuelve a él.
Si un campo solo se puede responder tarde, no es un campo de triaje, y ponerlo junto a la prioridad hace que frene cada pasada de triaje sin dejar de estar vacío.
Campos que se pagan solos
Nivel de cliente (selección). Si la urgencia de un bug depende de verdad de a quién le ocurrió, este es el campo que más cambia el orden del triaje. Pasa la prueba de la decisión sin problemas.
¿Regresión? (casilla). Un solo bit que se rellena en el triaje y divide el backlog en «esto lo rompimos nosotros» y «esto nunca estuvo bien». Son dos colas distintas con dos urgencias distintas.
PR vinculado (URL). No sirve para hacer seguimiento, sino para quien reabre el bug dentro de cuatro meses y quiere saber qué se intentó ya.
Revisor o responsable de QA (miembro). Solo si una segunda persona de verdad tiene que dar el visto bueno. Si «asignado» es el único rol que existe en tu equipo, este campo siempre será igual a la persona asignada.
Campos que conviene evitar
Cualquier cosa que se pueda calcular. Días abierta, número de reportes, tiene adjuntos: el tracker ya lo sabe, y una copia mantenida a mano se queda desactualizada la primera vez que alguien se olvida.
Un segundo estado. Bloqueada, Falta información, Esperando al cliente como campo junto a la columna del tablero significa que el estado real de la tarea vive en dos sitios que no van a coincidir. Si es un estado, es una columna, y si no quieres una columna para él, probablemente tampoco quieras ese estado.
Texto libre donde toca una selección. Un campo de texto llamado Componente acumulará checkout, Checkout, check-out y chkout, y entonces ya no se puede filtrar ni contar. Si quieres agrupar por él, tiene que ser una lista fija.
Cualquier cosa que añadas porque una persona lo pidió una vez. Los campos son baratos de crear y socialmente caros de quitar. El listón debería estar más alto que «alguien lo mencionó».
Elegir bien el tipo del campo
Los tipos no son decoración. Deciden qué le podrás preguntar al tablero después.
Tipo | Úsalo cuando | Sirve para |
|---|---|---|
Selección | Hay un conjunto fijo de opciones | Filtrar y agrupar limpiamente |
Selección múltiple | Son varias de un conjunto fijo | Preguntar «afecta a iOS o Android» |
Número | Es una cantidad real | Filtrar por rango |
Fecha | Es un momento en el tiempo | Filtrar por rango |
Casilla | Es un bit | Dividir el tablero en dos |
Texto / URL | Es cualquier otra cosa | Solo buscar subcadenas |
El error principal es recurrir al texto porque es lo más rápido de configurar. El texto es el tipo que eliges cuando ya has aceptado que nunca vas a filtrar por ese campo.
En BugDump, el tipo de una propiedad no se puede cambiar después de crearla, porque los valores ya guardados tienen la forma de ese tipo. Así que los treinta segundos que dedicas a elegir valen la pena.
Menos campos, pero rellenos
Lo que hace útil un tablero no es cuánto puede registrar. Es que lo que registra sea fiable.
Tres campos rellenos en todas las tareas valen más que once rellenos cada uno en un tercio. Un campo a medio rellenar es peor que ningún campo: parece un dato, así que la gente filtra por él, y el filtro excluye en silencio todas las tareas en las que alguien tenía prisa.
Un hábito práctico: al cabo de un mes, mira con qué frecuencia se rellena cada campo personalizado. Lo que esté por debajo de la mitad, más o menos, tiene un mal nombre, está mal colocado o responde a una pregunta que nadie se hace. Bórralo. En BugDump, eliminar una propiedad la quita junto con sus valores pero deja intactas las tareas, así que podar no cuesta nada más que la decisión.
Cómo funciona en BugDump
Las propiedades personalizadas están en la página Propiedades del proyecto, junto a las cinco integradas (estado, asignado, prioridad, etiquetas y fecha límite), que usan el mismo mecanismo y se editan de la misma forma.
Hay ocho tipos (texto, número, fecha, casilla, URL, selección, selección múltiple y miembro), y cada uno tiene en el tablero el control de filtro que le corresponde: casillas para las selecciones, un rango para números y fechas, un campo de «contiene» para el texto. Los filtros se combinan con AND y viven en la URL, así que un tablero filtrado es un enlace.
También llegan a tu agente de IA. El servidor MCP devuelve cada propiedad con sus opciones, y list_tasks acepta filtros por propiedad, así que «tareas abiertas donde Nivel de cliente es Enterprise» es una sola llamada y no un traerlo-todo-y-revisar.
Las propiedades personalizadas están en Pro y Ultra; las cinco integradas, incluida la lista editable de prioridades, están en todos los planes.
Te puede interesar
Niveles de prioridad de bugs: por qué cuatro opciones fijas nunca encajan — por qué la lista de prioridades debería decidirla tu equipo y no el tracker.
Métricas de bugs que de verdad importan — qué números dicen algo sobre tus bugs y cuáles solo llenan un dashboard.
Notificaciones en un bug tracker: quién debe enterarse de un cambio — cómo un campo de miembro decide quién recibe los avisos de una tarea.