¿Y si el cliente quiere testear la apliación mientras se desarrolla?
En un proyecto surgió que el cliente estaba dispuesto a ir probando la aplicación mientras se iba desarrollando. En principio me pareció genial, porque se trataba de un programa complejo con muchas funcionalidades y sería una manera de ir validando el desarrollo. Por otro lado, un cliente suele ser un buen localizador de bugs.
La conclusión a la que he llegado es que no se puede aplicar a cualquier programa ni sobretodo, a cualquier cliente. Los que no desarrollan software, pueden no entender los pasos que se están dando al realizar la aplicación y llegar a entorpecernos involuntariamente.
Estos son los problemas con los que me he encontrado:
- El cliente no entiende que cuando hay algoritmos complejos, lo importante primero es validarlos y al final ya se comprobará que el usuario final entre los datos correctamente, se cambiará el aspecto de la interfaz, etc. Es decir, él debe vigilar que los datos que entra tengan sentido. Pueden empezar a llegar correos y llamadas sobre problemas en la interfaz o en que “me deja entrar un fecha incorrecta”.
- El cliente ve el armazón de la aplicación y se aventura a probar funcionalidades no terminadas todavía en vez de la pactada: correos y llamadas diciendo que la otra parte no funciona o que si ya se ha tenido en cuenta tal o tal aspecto cuando no es el momento de tratarlo.
- El cliente no entiende bien su rol, cree que es parte del equipo de desarrollo y puede llegar a enviar mails y llamadas a cualquier hora por cada fallo que crea haber encontrado, en vez de una lista por correo electrónico con todos los problemas tal y como se pactó.
- El cliente ve una aplicación que parece terminada y ya desea enseñarla a sus clientes, superiores, etc. Pero te pide que le acabes tal aspecto de la interfaz o tal funcionalidad (que todavía no toca) porque causará mejor impresión. Esto supone una gran pérdida de tiempo y en ocasiones trabajar dos veces.
Por lo tanto, aunque no sea culpa de él, ya que quizás le hemos asignado un papel que no le correspondía, nos hace perder mucho tiempo respondiendo llamadas, correos, dando explicaciones y desactivando opciones del menú que no debería probar.
Respondiendo a la pregunta del título, diría que vale, pero si conocemos bien al cliente y estamos seguros de que no entorpecerá el desarrollo de la aplicación.
Actualización: A raíz de un pequeño debate en plurk, aclaro que en ningún caso estos “tests del cliente” vienen a sustituir a los tests programados por el equipo de desarrollo.
pentacour @ Octubre 29, 2008
Pues… en mi anterior empresa el cliente siempre o casi siempre iba viendo las cosas según se iban haciendo, y es lo peor de lo peor, creo que una gran parte de culpa de que la empresa sea tan caótica. Soy partidario de que solo vea una serie de hitos pre-establecidos con fases ya establecidas, también.
Te añado al blogroll y al reader, que no te tenía
Es que al principio me pareció buena idea porque además, era una manera de que fuese validando la aplicación por las características del proyecto. No es un proyecto típico y creí poder ahorrarme cambios grandes sobre la marcha. Comercialmente también lo tienes más tranquilo porque va “viendo cosas”. Pero no. Si no tiene muy claro su papel, mejor como dices: hitos ya pactados y ya está.
Por otro lado, ya tenía fichado tu blog. Abriré un apartado de blogroll que no tengo
Bueno, no te lo había dicho para eso, solo para que lo supieras
Mi experiencia es que, si el cliente va viendo, solo va a querer cambio sobre cambio sobre cambio. Un coñazo, si el jefe se deja, como era mi caso.
Es que claro, al final se busca tener un cliente contento y si han de haber cambios, que se puedan absorber de manera poco traumática. Para ello hemos empezado a utilizar scrum. Además, como este proyecto en concreto era nuevo y el cliente tenía algunas lagunas, me pareció buena idea que fuese viendo más proceso del que le debería tocar.
El problema es saber cuando decirle al cliente “hasta aquí”