¿Qué hacer cuando los usuarios/clientes se ponen nerviosos?

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 :)

Posted by Juan Ignacio Sánchez Lara 15:52  

5 Comments:

  1. Joserra said...
    Hola,
    una pregunta, ¿de cuanto es la duración del sprint? ¿!de mes y medio!? ¿o me he perdido en la explicación?
    Nacho said...
    El sprint, tres semanas, aunque ha habido un pequeño desfase desde las conversaciones con los usuarios y el arranque en sí (había trabajo previo que hacer). Quizá en eso nos hemos salido de "la norma".
    AcP said...
    El problema que se te podría presentar con la "C" es que el usuario no entienda las sutilezas de ver un producto que está "en la cocina".

    Los usuarios tienden a confundir prioridad con severidad. Si ven algo que no va en una funcionalidad central (prioritario) se preocuparán mucho más que si ven, por ejemplo, un error (menor) de validación que ocurre en cada pantalla de la aplicación (severo).

    Pero si tienes su confianza esto puede explicarse con un poco de paciencia.
    jcesarperez said...
    Lo he vivido en mis carnes. En general el resultado suele ser positivo, sobretodo cuando ya conoces al interlocutor.

    Por mi experiencia la C creo que es demasiado optimista en el sentido que implica un esfuerzo extra (no presupuestado) en preparar la demo, tanto en QA (a nadie le gusta quedarse con cara de tonto delante del cliente y las pruebas a nivel de gui son siempre las más débiles) como en las horas de visita y pilotaje con el cliente (imagino que no querras dejarle solo delante de la app, al menos en las 1as revisiones).

    Pero la estrategia, sin duda, tiene sus ventajas, como bien citas. En especial si tu interlocutor con el cliente tiene nivel técnico y es comprensivo con los "fallitos".
    javi santana said...
    Es el caso típico de:

    1) cliente que no sabe de tecnología y de la dificultad que hay

    2) Acuerdos con el cliente poco claros.

    Mi opinión es optar por la 'b', reducir las cosas a implementar. Además, los sprints por qué tienen que ser intocables? no se supone que es ágil? Reduciendo entrará dentro de tu planificación y la persona verá las cosas "bien" acabadas, aunque no estén todas.

    Mi opinión de verdad es que estáis jodidos y os va a tocar hacer horas extras :)

Post a Comment