Qué se puede aprender de los Bugs?

(Berlín, Memorial a los judíos asesinados en Europa) – Hace unas semanas, cuando visité el Memorial, el sentimiento de soledad y la falta de dirección me invadió. Creo que esta fue la principal conquista del arquitecto (Peter Eisenman) … traer este sentimiento a los visitantes. Exactamente en la posición en que tomé la foto, me pregunté «qué aprendimos con este horror?». Inspirada por los principios de aprendizaje continuo para la mejora continua, me gustaría hacer la misma pregunta pero aplicada a errores y alteraciones de requisitos o Change requirements (CR): ¿qué podemos aprender de errores? Podemos considerarlos como oportunidades de mejora.

Los bugs realcan siempre alguna vulnerabilidad en la planificación e implementación del producto, desde las fases iniciales de los requisitos. Pero si los bugs llegan hasta el usuario / usuario final, bloqueando el mejor desempeño y percepción del producto, las razones para ello deben ser analizadas y el hecho debe ser considerado como oportunidades de mejora.

Bugs salen extremadamente caros, desde los costos para corregirlos hasta el riesgo de decepción y pérdida de clientes. Sobre este tema mucho se ha escrito, recomiendo particularmente el resumen efectuado en el post: el costo financiero de los bugs de software

Los requisitos mal documentados o incompletos, también originan interpretaciones erróneas sobre las funcionalidades deseadas. Es por eso que las funciones de ingeniero de requisitos, analista de negocios e ingenieros de Experiencia del usuario (UX) son tan importantes cuando se introducen desde la fase de exploración del proyecto. Las técnicas de prototipado rápidas (interactivas o basadas en papel) pueden ser muy útiles para crear una comprensión común antes de iniciar la fase de programación.

Se pueden verificar también ineficiencias o errores en el diseño de la solución o arquitectura, siendo que en estas situaciones bugs o ineficiencias serán detectados después de la implementación del producto, ya con él contexto real de utilización.

Otra situación de riesgo ocurre cuando el diseño o la arquitectura de la solución son hechos o aprobados por personas no cualificadas para ello. Por desgracia, muchas veces, especialmente en las grandes organizaciones, qué arquitectura e importantes decisiones en el diseño de soluciones se toman, no por personal cualificado, sino por niveles jerárquicos superiores, sin llamar a estos expertos a contribuir.

Me gustaría compartir con ustedes algunas notas personales, donde describo, cómo empecé a diseñar un plan para balizar calidad, definiendo herramientas con claros objetivos de prueba y aceptación de los requisitos desde la fase inicial del proyecto.

Qué podemos aprender de Bugs?

Debemos reforzar la calidad, la cobertura y la automatización de pruebas, con vistas a una práctica continua de pruebas, reforzada por la introducción en varios niveles de automatización.




Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.