En el vasto e interconectado mundo del software moderno, donde un solo clic puede desencadenar una cascada de acciones a través de sistemas bancarios, de viajes y de comunicación, la cuestión de la calidad no se trata simplemente de encontrar errores. Se trata de comprender qué significan esos errores cuando se dejan sin reparar. Todas las grandes organizaciones de software mantienen una larga lista de problemas conocidos, a menudo llamados defectos o errores, que son registrados, categorizados y asignados a equipos para su reparación. Durante décadas, el método estándar para gestionar estas listas ha dependido de dos etiquetas simples: la severidad, que describe qué tan grave parece el problema, y la prioridad, que dicta qué tan rápido debe repararse. Este sistema funciona bien para organizar el trabajo, pero a menudo falla al intentar responder la pregunta más crítica que enfrenta una empresa antes de lanzar una nueva actualización: ¿es seguro lanzar este software al público con estos problemas específicos aún presentes? La dificultad radica en el hecho de que un problema que parece menor en una pantalla puede causar un fallo silencioso y catastrófico en el mundo real, mientras que un error evidente podría ser fácilmente sorteado por un operador humano. Cuando la trayectoria de un único cliente atraviesa docenas de sistemas informáticos diferentes, el riesgo de un problema no resuelto ya no es solo un problema técnico; se convierte en una decisión organizacional compleja sobre quién tiene permitido aceptar ese riesgo y bajo qué condiciones.

Un investigador llamado Jesmith Lopes investigó este exacto dilema dentro de una enorme empresa de telecomunicaciones en los Estados Unidos, un entorno donde ocurren miles de cambios de software cada año. La organización ya poseía herramientas sofisticadas para rastrear cada uno de los defectos, pero luchaban por traducir esos registros en decisiones claras y consistentes sobre la preparación para el lanzamiento. El estudio, que se basa en los registros internos de la empresa y en las experiencias de sus profesionales, revela que la brecha entre el rastreo de un problema y la gobernanza del riesgo que este plantea es donde muchas grandes organizaciones tropiezan. El investigador descubrió que tratar los defectos no resueltos como simples elementos de trabajo para ser cerrados es insuficiente. En su lugar, estos problemas deben tratarse como unidades de riesgo operativo que requieren un proceso de gobernanza específico. Este proceso implica mirar más allá de la etiqueta inicial de severidad para plantearse una serie de preguntas más profundas: ¿Quién se ve realmente afectado? ¿Existe una forma fiable de solucionar el problema si ocurre? ¿Puede detectarse el fallo rápidamente, o se ocultará y causará daños en etapas posteriores? Y lo más importante, ¿quién tiene la autoridad para decidir que el riesgo es lo suficientemente aceptable como para proceder con el lanzamiento?

Para abordar esto, el estudio propone un marco estructurado llamado Marco de Riesgo Operativo de Defectos (Defect Operational Risk Framework). Este enfoque complementa el sistema de seguimiento tradicional con una nueva capa de toma de decisiones que evalúa los defectos no resueltos a través de ocho dimensiones específicas. Estas incluyen el impacto en el cliente, la criticidad de la transacción involucrada, la efectividad de cualquier alternativa disponible, la probabilidad de que el problema ocurra en condiciones del mundo real y la capacidad de detectar el fallo una vez que el software esté en funcionamiento. También considera cuánto tiempo ha estado abierto el defecto, si ha ocurrido anteriormente y si las personas responsables de solucionarlo, coordinar la solución y aceptar el riesgo están claramente identificadas. Al aplicar estas preguntas, la organización pudo pasar de una vaga sensación de preocupación por los defectos abiertos a una comprensión precisa del riesgo residual. El marco distingue entre tres niveles de preocupación: problemas normales que pueden ser manejados por equipos de ingeniería estándar, problemas elevados que requieren una revisión entre equipos y una mitigación documentada, y problemas críticos que exigen una decisión explícita de un propietario de riesgo designado antes de que cualquier lanzamiento pueda proceder.

La investigación destaca una distinción crucial entre la propiedad técnica y la propiedad del riesgo. En muchas grandes empresas, un equipo puede ser responsable de escribir el código para corregir un error, pero no tiene la autoridad para decidir si el software puede lanzarse sin esa corrección. Por el contrario, un líder de negocios puede tener la autoridad para aceptar el riesgo de un lanzamiento, pero carece del conocimiento técnico para comprender las implicaciones. El modelo de gobernanza propuesto separa estos roles, asegurando que un propietario técnico diagnostique y repare el código, un propietario de coordinación mantenga el proceso en marcha a través de diferentes equipos, y un propietario de riesgo tome la decisión final sobre si el peligro restante es aceptable. Esta separación evita el escenario común donde un defecto permanece sin resolver porque nadie sabe quién es el responsable último de la decisión. El estudio también redefine cómo se escalan los problemas. En lugar de simplemente convocar más reuniones para aumentar la visibilidad, la escalada se convierte en un mecanismo para forzar una decisión específica, como acelerar una reparación, aprobar una alternativa, eliminar una funcionalidad del lanzamiento o retrasar el lanzamiento por completo.

El valor práctico de este enfoque fue demostrado a través de los registros de rendimiento de la empresa de telecomunicaciones. Durante el período en que estas prácticas de gobernanza estructurada maduraron, la organización vio mejoras significativas en su estabilidad operativa. Los informes indicaron que el número de defectos que se filtraron al entorno de producción real disminuyó de 83 a 20. El volumen de tickets de soporte relacionados con problemas de producción cayó de 71 a 31, y el número de defectos críticos o bloqueadores disminuyó aproximadamente un 82 por ciento. El equipo también logró resolver más de 4,500 problemas en su sistema de seguimiento y gestionó más de 42,000 tickets de soporte con alta calidad, todo ello manteniendo un estricto cumplimiento de los acuerdos de nivel de servicio. Estas cifras sugieren que el modelo de gobernanza no solo creó más papeleo, sino que cambió fundamentalmente la forma en que la organización entendía y gestionaba el riesgo de lanzar software. Los datos respaldan la idea de que, cuando una organización trata los defectos no resueltos como decisiones de riesgo explícitas en lugar de solo tickets abiertos, puede lograr un mayor nivel de fiabilidad sin necesidad de eliminar cada uno de los errores antes del lanzamiento.

El estudio ilustra este cambio con dos escenarios contrastantes. En un caso, un defecto parecía ser moderado porque no impedía el funcionamiento de la interfaz principal de usuario. Sin embargo, el proceso de gobernanza reveló que el error causaba fallos silenciosos en segundo plano, afectando transacciones críticas y creando una carga oculta para los equipos de soporte. Debido a que el fallo era difícil de detectar y no tenía una alternativa fiable, el riesgo se elevó, requiriendo una decisión específica para sea o bien repararlo, añadir monitoreo o aceptar formalmente el riesgo antes de lanzar. En un segundo caso, un defecto fue inicialmente marcado como de alta severidad porque rompía visiblemente una transacción. No obstante, la revisión de gobernanza encontró que el problema era fácil de detectar, tenía una alternativa manual fiable y afectaba a un número manejable de usuarios. En este caso, el riesgo se consideró aceptable para el lanzamiento, siempre que la alternativa estuviera en marcha y el propietario del riesgo aprobara la decisión. Estos ejemplos muestran que la etiqueta de severidad por sí sola suele ser un mal predictor del peligro en el mundo real; el verdadero riesgo depende del contexto del fallo y de la capacidad de la organización para gestionarlo.

En última instancia, el artículo argumenta que la gestión de defectos en la entrega de software a gran escala no es solo un flujo de trabajo técnico, sino un problema de gobernanza. Las herramientas pueden registrar la existencia de un error, pero no pueden resolver automáticamente la ambigüedad de si ese error es seguro para dejarlo en el sistema. La solución reside en crear una capa de decisión disciplinada que obligue a las organizaciones a enfrentar la realidad de sus problemas no resueltos. Al clasificar explícitamente el riesgo, asignar una propiedad clara y requerir decisiones documentadas para cada defecto no resuelto, las empresas pueden transformar su proceso de lanzamiento de una apuesta en una decisión calculada. La investigación sugiere que este enfoque es particularmente vital para las grandes empresas donde los sistemas son complejos e interconectados, y donde el costo de un fallo se extiende mucho más allá de una sola aplicación. Si bien el estudio no pretende haber resuelto por completo el problema de los defectos de software, proporciona un método probado y repetible para gobernar el riesgo que permanece, convirtiendo la incertidumbre de la preparación para el lanzamiento en un proceso claro y manejable.