Severidad vs prioridad: por qué un bug crítico puede esperar

La severidad mide cuánto daño hace un defecto cuando ocurre. La prioridad mide qué tan pronto conviene arreglarlo. Son dos preguntas distintas: una la contesta el sistema (qué tan grave es el fallo técnico), la otra la contesta el negocio (qué tan urgente es repararlo). Confundirlas es la razón por la que tantos equipos arreglan cosas feas pero inofensivas antes que cosas discretas pero peligrosas.

La escena típica es esta. Un tester encuentra un botón que se pinta mal en una pantalla que casi nadie visita: es horrible, pero nadie se atasca por él. Al mismo tiempo hay un cálculo de impuestos que se equivoca por centavos en el checkout, algo que casi no se nota, pero que le cuesta dinero real a la empresa cada día. El primero grita más. El segundo hace más daño. Decidir cuál va primero es, exactamente, el trabajo de separar severidad de prioridad.

01 · las dos preguntasSeveridad es cuánto duele, prioridad es cuándo lo arreglas

El vocabulario estándar de testing las define por separado a propósito. La severidad es el grado de impacto que un defecto tiene sobre el desarrollo o la operación de un componente o sistema [1]. Es una propiedad casi objetiva del fallo: ¿tumba la aplicación, corrompe datos, o solo desalinea un ícono? La prioridad, en cambio, es el nivel de importancia de negocio asignado a resolverlo: qué tan arriba en la fila de arreglos lo pones [1].

La distinción importa porque las dos no se mueven juntas. Un defecto puede ser muy severo y de baja prioridad, o poco severo y de altísima prioridad. Esa independencia es justo lo que la vuelve útil: te obliga a pensar el impacto técnico y la urgencia comercial como dos ejes, no como uno solo.

Severidad la pone el sistema. Prioridad la pone el negocio. Cuando las mezclas, arreglas por volumen de queja, no por daño real.

Quién asigna cada una también difiere. La severidad la propone quien entiende el comportamiento técnico del defecto: el tester o el desarrollador que lo reproduce. La prioridad la decide quien entiende el costo de dejarlo suelto: el dueño de producto, el líder o el propio negocio. Cuando una sola persona fija las dos "a ojo", casi siempre colapsa ambas en un único número borroso, y ahí empieza el desorden.

02 · los cuatro cuadrantesPor qué un bug crítico a veces puede esperar

Como severidad y prioridad son ejes independientes, se cruzan en cuatro combinaciones. Cada una pide una decisión distinta, y las dos esquinas incómodas (alta-baja y baja-alta) son las que más se malinterpretan.

Alta severidad, alta prioridad. El caso fácil. La app se cae en el flujo de pago para todos los usuarios. Duele mucho y hay que arreglarlo ya. Nadie discute este cuadrante.

Alta severidad, baja prioridad. Aquí vive el "bug crítico que puede esperar". Imagina un fallo que corrompe los datos, pero solo se dispara en una versión del sistema operativo que usa el 0,1 % de tus usuarios, en una función que se lanza el mes que viene. Técnicamente es grave. Comercialmente, hoy, no urge: puedes programarlo sin pánico. Severidad alta, prioridad baja.

Baja severidad, alta prioridad. El espejo. Un error de ortografía en el nombre de tu empresa en la página de inicio, o el logo de un cliente clave mal puesto justo antes de una demo. El sistema funciona perfecto: severidad mínima. Pero la vergüenza o el riesgo comercial son enormes, así que se arregla en la próxima hora. Prioridad máxima.

Baja severidad, baja prioridad. El fondo de la fila. Un margen de dos píxeles en una pantalla interna que ven tres personas. Se anota, se agenda para algún día, y a veces nunca se toca. Y está bien que así sea.

03 · cómo decidirOrdenar con datos, no con quien grita más fuerte

El problema real no es entender la diferencia en teoría, es no aplicarla bajo presión. Cuando el reporte de un cliente ruidoso llega por un canal directo, tiende a saltarse la fila, aunque su defecto sea leve. Y cuando un fallo grave vive en un rincón que nadie reporta, se hunde en el backlog, aunque un día explote. Decidir "por quien grita más" es exactamente el sesgo que la matriz existe para corregir.

Para ordenar la prioridad con datos, en lugar de con volumen de queja, tres preguntas concretas ayudan casi siempre.

¿A cuánta gente afecta? Un fallo que toca a todos los usuarios pesa más que uno que toca a un caso muy raro, aun si el segundo es técnicamente más severo. El alcance mueve la prioridad hacia arriba.

¿Hay forma de esquivarlo? Si existe un rodeo sencillo (otro camino en la interfaz, un paso manual), la urgencia baja, aunque la severidad quede intacta. Un defecto sin escapatoria escala; uno con salida de emergencia puede esperar su turno.

¿Qué cuesta dejarlo suelto un día más? Dinero perdido, riesgo legal, reputación, un incumplimiento de contrato. Ese costo diario, no la fealdad del síntoma, es lo que debe empujar la prioridad. Un defecto que sangra plata cada hora sube aunque casi no se vea.

Un tablero maduro no pregunta "¿qué es lo más feo?". Pregunta "¿qué nos cuesta más dejar suelto hoy?".

En Qirava vemos el mismo patrón una y otra vez: los equipos que separan bien estos dos ejes discuten menos y entregan con la conciencia tranquila, porque su fila de arreglos es auditable. Cualquiera puede ver por qué un defecto va antes que otro, y esa razón no es "lo pidió alguien con voz fuerte", sino un dato: alcance, rodeo disponible, costo por día. La severidad se documenta, la prioridad se justifica, y la decisión deja de ser una pelea de opiniones.

Así que la próxima vez que alguien diga "es crítico, hay que arreglarlo ya", detente y separa las dos preguntas. ¿Es crítico porque duele mucho, o porque urge mucho? A veces son lo mismo. Muchas veces no. Y saber cuándo no lo son es la diferencia entre un equipo que apaga incendios pequeños y uno que protege la casa.