- Va muy lenta
- Ciertas partes no funcionan
- Hay casos de prueba que funcionan y otros no
- Etc...
provocará rechazo por parte del usuario final. Por ejemplo, un equipo desarrolla una aplicación web para que los usuarios puedan darse de alta en un censo de un pueblo. La aplicación es simple y compleja. Simple porque de cara al usuario es solo un formulario de 10 campos que se rellenan y se pulsa un botón de enviar. Compleja porque en core usa tecnologias que hacen mas facil la navegación, se conecta con un web services que verifica la firma, hace una validacion con 2 bases de datos, optimiza busquedas para validacion de .... y mas cosas. Todo esto último se ha conseguido pero el dia de probar en producción se produce el gran problema, el responsable del cliente dice que toda (no solo la interfaz) es un desastre porque hay un campo donde no se pueden poner mayusculas.
Si llevas tiempo en el desarrollo de software te sonará seguro:"Esta aplicación en una mierda porque no deja poner mayusculas en este campo" y el programador piensa: " pero si eso es una tonteria, lo del web services era lo complejo".
Como evitar esto? Es una tonteria o es algo que puede hacer fracasar un proyecto?
En estos casos, todo el mundo tiene razon y todo el mundo esta equivocado.
Si llevas tiempo en el desarrollo de software te sonará seguro:"Esta aplicación en una mierda porque no deja poner mayusculas en este campo" y el programador piensa: " pero si eso es una tonteria, lo del web services era lo complejo".
Como evitar esto? Es una tonteria o es algo que puede hacer fracasar un proyecto?
En estos casos, todo el mundo tiene razon y todo el mundo esta equivocado.
- La interfaz al usuario hay que probarla hasta mas no poder. Es importante eliminar cualquier fallo en el que el usuario pueda decir:"esto es de sentido común".
- Si el principal objetivo de un programador es la interfaz entonces las partes mas complicadas no estarán implementadas y si que la aplicación no valdrá para nada.
La mejor opción es poner una capa intermedia entre el desarrollo y el cliente:
- Un departamento de pruebas.
- Comerciales que deduzcan de forma lo mas exacta posible que es lo que quiere el cliente.
- Etc...
En cualquier caso, suponer que es lo "de sentido común" (o básico) para el cliente es un error. Los clientes suelen saber lo que quieren durante la marcha. Cuando ven algo sabe si les gusta o no. Lo mejor es planificar el desarrollo para que los cambios en la interfaz te afecten lo menos posible.
No hay comentarios:
Publicar un comentario