subscripción
Ideas + Ingeniería del Software
¿Qué hacer cuando los usuarios/clientes se ponen nerviosos?
Febrero 20th, 2009 - [Enlace local]
Como dirían en El Hormiguero... "¡Los usuarios, ese gran desconocío''!"
Hoy se nos han puesto nerviosos los usuarios/clientes. Hacemos aplicaciones a medida, y hace un par de semanas tuvimos la última reunión (aún hay requisitos sin cerrar, pero bueno, tenemos claro que tenemos que aprender a convivir con eso). Nos han perido que quieren ver algo cuanto antes (obviamente cambiando la planificación acordada).
Ante una situación así se me ocurren tres alternativas:
a) Como no es lo pactado, nos ceñimos a lo hablado, así que dentro de mes y algo nos vemos. Hasta entonces, dejadnos tranquilos.
b) Ok, el cliente siempre tiene la razón, así que nos adaptamos. Cambiamos la duración del sprint, adelantando la demo, aunque reduciendo el número de historias de usuario que presentamos.
c) Nos mantenemos como estamos, pero, como el cliente siempre tiene la razón, os daremos versiones previas de prueba (abriendo acceso a alguno de nuestros servidores).
La a) es la típica en la programación por contrato, la ortodoxa, la que te enseñan en clase. Tiene sus ventajas y sus inconvenientes. Por un lado, sí, estás en tu derecho de "plantarte", ya que así está acordado. Pero por otro, no satisfaces la solicitud del cliente. Personalmente no me gusta. Predispones al usuario a tirar a la basura lo que le enseñes en la fecha acordada. Y, no lo olvidemos, en ese momento pueden tener razón (sí, señores, los desarrolladores también nos equivocamos).
La b) es la que inicialmente pensamos. No es demasiado mala, ya que no aumenta la "densidad de trabajo", y contenta a los usuarios. Pero presenta varios problemas. La duración del sprint no se debe cambiar, y mucho menos por gente no comprometida. Además, es tarea específica del Scrum Master evitar este tipo de situaciones. Y, dejando ya de lado Scrum, te permite menos margen de error. Aunque la "densidad de trabajo" no cambie, es más difícil cumplir el plazo.
La c) es la que finalmente se va a tomar. No sólo no rompe reglas de la metodología, sino que va a potenciar que el trabajo se haga como se debe. Ya habíamos quedado clara la "definición de hecho" y la integración contínua, así que en cualquier momento se podría desplegar el código del repositorio para probar. Y, además, permite satisfacer la necesidad del usuario (¡incluso mejor que con la opción b), ya que podrá ver más antes) e implicarle más. Tendremos feedback antes, minimizando el impacto del cambio de requisitos. Queda claro (tanto para el equipo como para el usuario) que la fecha de la demo es cuando debe estar el producto estable, que hasta entonces sólo estará viendo una versión en desarrollo.
En teoría todo pinta bien, ya veremos en la práctica :)
