En el desarrollo de aplicaciones, no todos los errores se crean de la misma manera y no todos los errores de tu aplicación merecen la misma dedicación. Sí, tu aplicación se bloquea, pero si sólo ocurre cuando alguien hace click en el botón de leer más bajo la biografía del desarrollador de la aplicación, pregúntate: ¿es realmente tan importante? O, a la inversa, ¿qué pasa con esa coma que flota en la segunda línea de la pantalla de bienvenida? ¿Garantiza eso una corrección de errores de última hora justo antes de enviarla a Apple?
Este es un momento clave para cuestionar la prioridad de los fallos frente a su gravedad y reconocer los contrastes entre ambos. Saber en qué centrar el esfuerzo de tu equipo de desarrollo, ante el constante aluvión de fallos, de forma que se minimice el riesgo y se maximice la entrega, es una habilidad esencial si estás tratando de entregar una pieza de software, ya sea una aplicación, una web o cualquier otro. Es especialmente importante reconocer la diferencia entre la gravedad y la prioridad de un fallo para evitar el desperdicio de los recursos de tu equipo.
En Juice Studio, hemos desarrollado más de 100 aplicaciones y durante ese tiempo hemos desarrollado un proceso de triaje de errores que vemos cada error a través de un prisma de prioridad para clasificar un error y su importancia. El campo de prioridad que utilizamos en una incidencia responde a la importancia de arreglar este fallo para el calendario de lanzamiento. ¿Liberarías el producto incluso con este fallo? ¿O se trata más bien de algo agradable de tener, pero no crucial? En Juice Studio, utilizamos una escala de priorización de errores P0-P1-P2, en la que un error P0 (Bloqueador) es un obstáculo que debe solucionarse antes de lanzar la siguiente versión. Los P1 (críticos) son importantes, pero no son algo por lo que pararíamos un lanzamiento, mientras que los P2 (medios, bajos) representan prácticamente cualquier cosa que sólo se arreglará cuando nuestro equipo de desarrollo haya resuelto todos los fallos P0 y P1.
Al abordar la cuestión de la prioridad frente a la gravedad, es importante tener en cuenta que la prioridad de un fallo no debe confundirse con su gravedad, que existe como una dimensión completamente diferente. En Juice Studio, utilizamos un campo llamado «Severidad» para representar una evaluación (en cierto modo) objetiva del impacto de un fallo en la funcionalidad del sistema. Desde crítico, que representa caídas o cuelgues importantes, hasta problemas funcionales menores o defectos puramente estéticos. Mientras que un ingeniero de control de calidad clasifica la gravedad de un fallo en el momento de su creación, es el director de proyecto quien asigna la prioridad en el momento de la selección, basándose en su conocimiento de los requisitos del producto y del negocio del cliente.
Algo que es de gravedad crítica no significa necesariamente que sea un P0. ¿Ese error de bloqueo en la pantalla de tu biografía? Acéptalo, a nadie le importa leerlo y pocos harán click en el botón, así que no es algo que deba ser un P0. Mientras tanto, una coma mal colocada puede parecer nada digno de atención emergente, pero ¿qué pasa si se repone por completo la declaración de tu marca? Eso es lo más estético que puede ser un error, pero es algo que podría justificar una etiqueta P0 dadas las implicaciones para el negocio. Es importante no confundir la gravedad del fallo con la prioridad del mismo, y no dejar que el impacto de un fallo confunda tu juicio sobre su importancia relativa.
La clasificación eficaz de los fallos es un factor esencial de higiene y éxito para cualquier persona que gestione una publicación de software, y reconocer la diferencia entre la gravedad y la prioridad de un fallo es crucial. Saber ver un fallo y asignarle una prioridad es el primer paso de un proceso de triaje eficaz. Aunque conocer la gravedad de un fallo es un dato importante que hay que sopesar, nunca debe ser el único factor decisivo para organizar la prioridad de los fallos. Nuestra experiencia en el desarrollo nos permite encontrar y aplastar los fallos como si fuéramos exterminadores digitales.
