Tales from the Scrum: el cliente en las trincheras

Cuando no seguimos metodologías ágiles, esperamos que la especificación del sistema surja de conversaciones y análisis iniciales, trabajamos por unos meses, y luego entregramos algo al cliente. Por lo que ha pasado en muchos casos, esto es el camino a entregar algo que no es lo que necesita o espera el cliente. El resultado está ejemplificado en esta imagen:

(La primera vez que la ví, estaba publicada en una revista de los 50, referida a la ingeniería en general, no al desarrollo de software).

¿Cómo consigue Scrum (y metodologías ágiles en general) luchar con este síndrome de entregar cualquier cosa? Involucrando al cliente desde el principio del desarrollo, no sólo a través del product owner, que es el principal contacto del equipo con el cliente, sino también entregando al final de cada sprint una aplicación andando, que puede ser probada por los interesados, y de esta manera ir consiguiendo retroalimentación del cliente final, para que no pase lo del dibujo de arriba.

Al ir avanzando iterativamente, y viendo cómo la aplicación es tomada por el cliente, podemos ir refinando nuestra puntería, para llegar a algo que realmente sirve y tenga valor para el cliente final. Destaco “cliente” en vez de “usuario”: en mi jerga, cliente es alguien para el que el sistema tiene valor de negocio, mientras que usuario es quien lo usa. Este último puede no estar tan interesado en el valor de negocio, sino en que su trabajo sea fácil. El cliente es más importante: es alguien que usa el sistema, pero con interés personal en que todo tenga valor de negocio, y no sea una aplicación cualquier más.

También hay que interactuar con varios clientes, no siempre con uno solo. En la aplicación en desarrollo, pueden haber varias personas que ameriten ser clientes involucrados en lo que vamos entregando. Como ejemplo, el lunes pasado, en nuestro equipo, entrevistamos a un cliente, muy interesado en el resultado final de lo que estamos desarrollando. Es un cliente interesado en que el sistema sea algo mejor de lo que tiene ahora, y brindó su tiempo para explicarnos temas y detalles. Fue muy interesante la reunión: es un cliente de las trincheras, que está en el día a día de lo que debe hacer el sistema. Y fue interesante, porque hasta ese momento habíamos tenido algunas reuniones, pero con clientes que estaban algo alejados del trabajo de línea. Y a partir de la reunión, conseguimos ver más claro una parte del dominio del sistema, que nos aclara realmente cuál es el trabajo al que debemos ayudar con la aplicación.

Fue también importante, conseguir en esa reunión, una forma de seguir en contacto con este cliente en concreto. Una reunión no termina ahí. La relación con el cliente debe seguir a lo largo del tiempo, y no terminar en notas de una reunión. Una de las ideas que quiero implementar, en este caso, es tener un servidor de prueba accesible para esta persona y su grupo, para que vayan probando lo que estamos construyendo, como ya estamos haciendo con otras partes y otros clientes finales. Un pequeño detalle: durante la reunión se tomaron notas, directamente, en notebooks, para no tener que pasar después de papel a formato electrónico. Las notas se enviaron a la lista de correo del proyecto, para que todos las tengamos disponibles, hayamos estado o no en la reunión.

Pero es importante ir entregando, incrementalmente, interactuando con el cliente de la trinchera.

No es cuestión de caer un lunes, dentro de seis meses, e instalar la hamaca del árbol, que el cliente no esperaba ni necesitaba.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>