Hace tiempo se hizo famosa la teoría de la ventana rota. Básicamente, lo que dice es que si hay una ventana rota y no es reemplazada, la gente que pase caminando por ahí va a pensar que a nadie le importa y que no es responsabilidad de nadie. Rápidamente aparecerán más ventanas rotas, expandiendo la sensación de anarquía, enviando la señal de que nada de lo que pase tendrá importancia, de que colapsó el sistema. En una ciudad, problemas menores como graffitis, basura en las calles, etc. son equivalencias de la ventana rota, invitaciones a crímenes mayores.
Una forma de prevención, es resolver estos problemas cuando todavía son menores.
¿Qué relación tiene todo esto con el desarrollo de software?
La percepción de la calidad. ¿Cuántas veces por poner foco exclusivamente en los errores mayores no nos fijamos en detalles que hacen a la calidad que perciben los usuarios?
Algunos ejemplos:
• Tab Order (cómo va pasando el control entre los campos de una pantalla al presionar la tecla tab)
• Palabras con errores de tipeo o faltas ortográficas
• Campos sobre los que no controlamos el formato de ingreso
• Mensajes de error sin tratar, por ejemplo: mostrando la excepción que arrojó la base de datos sin explicar qué es lo que significa
¿Cuál es el resultado de todo esto?
Estamos dando la impresión de que estos temas (posiblemente otros más) no son importantes para nosotros, no nos preocupan, no nos interesan.
¿Cuál es la solución?
En primera instancia resolverlos. Si bien los errores deben ser tratados con prioridad, dejar errores que no tienen costo de reparación muestran que el control ha colapsado.
En segunda instancia, si no damos a basto con las correcciones por estar con bugs críticos, mostrarle al usuario a través de un issue tracker que los tenemos identificados, que los consideramos como errores que deben ser corregidos, y que están en nuestro roadmap.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment