El Importante Papel del Cliente en un Proyecto Ágil de Software

Siempre se ha dicho que la participación del cliente es clave en el desarrollo de un proyecto. Lo sabemos y confirmamos por nuestra propia experiencia. Incluso el manifiesto ágil lo recoge en uno de sus cuatro valores principales, e incluso va un poco más allá: “colaboración con el cliente por encima de la negociación contractual”.

Y si vamos a dos de sus doce principios:

• Nuestra mayor prioridad es satisfacer al cliente, mediante la entrega temprana y continua de software con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio, para proporcionar ventaja competitiva al cliente.

Todos tenemos en mente a algún cliente con el que nos ha tocado tratar, o que nos ha hecho pensar qué tipo de cliente somos o hemos sido. Seguro que algunos nos acordamos del típico cliente impertinente, que incluso en ocasiones podría parecer, por cuestiones incomprensiblemente extrañas, ajeno al proyecto o interesado en que ni siquiera éste saliera adelante. Por el contrario, otras veces “disfrutamos” de un cliente inquieto, que está literalmente encima de nosotros y nos dificulta, lentifica o pervierte nuestra cadencia de trabajo. ¿Quién no ha afirmado en alguna ocasión eso de…? “Si el cliente no nos molestara tanto, le podríamos entregar su trabajo antes”.

Probablemente la mayoría se inclinaría por un cliente que se mueva entre estos dos extremos, como seres humanos que somos cuando tenemos una cosa pensamos en la otra y viceversa. Efectivamente, el cliente ideal debería estar pendiente del proyecto pero, asimismo, ser muy consciente del marco ágil en el que se encuentra. Y por consiguiente, respetar la metodología de principio a fin, que se dice muy fácil, pero es lo realmente complicado en una adopción Agile.

Aunque en ocasiones no lo parezca, el hecho de que el cliente intervenga aparentemente cuando le viene en gana, no es siempre su culpa. Dicho de otro modo, tenemos mucho qué hacer para educar, preferentemente evitar o minimizar este ruido por su parte. que no estamos hablando únicamente del antes mencionado impertinente. Imaginemos que tenemos un cliente educado, empático, inteligente, pero al que simplemente no le hemos explicado nuestro marco de trabajo, no conoce nuestra filosofía ágil; incluso ni siquiera las características del equipo. En este caso, bastante más común de lo deseable, estaríamos ante el típico cliente que quiere resultados y valor, como es lo normal, pero que no le importa nada más. Bueno, eso no es definitivo, pero es preferible que nos conozcamos todos, como un equipo al completo y juguemos cada uno nuestro papel como tal.

Por ejemplo, supongamos que tenemos un proyecto con un cliente externo, que se comunica con el equipo interno de una organización por medio del Product Owner. -Nótese esta aclaración porque podría haber casos donde el propio cliente interno desempeña la labor de Product Owner-. Como bien hemos mencionado antes, el cliente es una pieza fundamental en el transcurso y futuro de nuestro proyecto. Así que tenemos que ayudarle a ser ágil, hacerle sentirse ágil. Debemos educarle desde el comienzo del proyecto, desde el origen del mismo donde es clave su negociación con el Product Owner, en esa captura de requisitos, en esa construcción del Product Roadmap o en esa definición del Release Planning.

Vayamos a un escenario más concreto. Si estuviéramos utilizando Scrum o XP para un proyecto de software, el cliente ya debería tener claro antes del comienzo de la primera iteración que:

• Para cualquier cuestión, debe dirigirse al Product Owner y no al equipo de desarrollo.
• Debe conocer y asumir que sus solicitudes de cambio y nuevas peticiones se aceptan, pero se ejecutarán en próximas iteraciones, nunca en el transcurso de la presente y siempre teniendo en cuenta la prioridad del Product Backlog.
• Debe revisar continuamente, tener claras estas prioridades del proyecto y comunicarlo al Product Owner, para que éste pueda ordenar el Backlog, que el equipo irá trabajando y finalmente entregando en forma de valor.
• Será en la Demo o Review, una vez terminada la iteración, cuando podrá participar, dar su opinión y solicitar sus nuevas peticiones, que el Product Owner traducirá en forma de historias de usuario priorizadas para siguientes iteraciones.

En general, debe conocer y creer en el funcionamiento del equipo, su velocidad, y lo que es más importante, y repetimos, respetar la metodología.

Y permítanme otro pequeño inciso sobre este “respetar la metodología” puesto que aquí radica la verdadera dificultad. Este puede ser otro ejemplo en el que se afirma: “Sí, claro que somos ágiles” o “Estamos usando Scrum, XP, Kanban…” pero no es nada más que un intento que no se está llevando (correctamente) a cabo. Si el cliente no entiende, no quiere, no cree o no hace uso de la metodología ágil, entendiendo sus valores y principios y llevándola a cabo, estamos en uno de esos escenarios en el que nos planteamos: “¿Pero realmente somos ágiles?” o algo así como “Pues yo hago Scrum y no funciona”. Por descontado que Scrum, no es sólo poner papelitos en la pared. Ser ágil no significa únicamente celebrar diariamente las reuniones stand up y poco más. De hecho, es completamente imposible aplicar Agile con un cliente que no está verdaderamente comprometido, sin que participe en el proceso como se le debe exigir.

También es necesario tener en cuenta el tipo de cliente como profesional con el que estamos tratando: más o menos técnico, más cercano o más distante, más o menos paciente. No tiene nada que ver un experto tecnológicamente hablando, con un gestor financiero o un comercial.

En cualquier caso, lo realmente importante es conocerlo y hablar en su mismo idioma, y no me refiero precisamente al lenguaje.

Este compromiso, negociación y trato prácticamente diario con nuestro cliente, dista mucho del que tiene lugar en el tradicional Waterfall, donde nos basamos en las fechas y en nuestros diagramas a largo plazo, cuyo cumplimiento de hitos es realmente complicado en el tiempo, sobre todo en el cambiante mundo del software. En Agile estamos potenciando esta relación entre el cliente y equipo, haciéndola más cercana y humana. Es por ello, por lo que hacemos especial énfasis en su fortalecimiento. Y aquí podríamos volver a pensar en el manifiesto ágil y sus cuatro valores. Incluso sería preferible que esta relación fuese más allá de lo profesional, conociendo así los gustos del cliente; hasta aficiones y forma de afrontar la vida, los problemas, etc.

Sin embargo, sucede a menudo que lo vemos como un enemigo, y nada más lejos de la realidad, tener al cliente como amigo es una garantía de éxito. Entrar en disputas, discusiones y demás problemas nos lleva precisamente a desperdicio, desconfianza o falta de concentración y esto no hace sino crear precedente en el futuro. Todos debemos remar en la misma dirección, aplicando ineludiblemente la teoría y, como tal, debemos mimar el trato, no sólo con el equipo, sino empezando por el cliente; pensando también en los usuarios de nuestro producto y, en general, en todos los interesados de nuestro proyecto.

Como conclusión, espero humildemente haber hecho reflexionar a más de uno sobre los clientes que conoce, tiene o ha tenido y cómo se ha comportado o tratado con ellos. Del mismo modo, a mis queridos clientes, siempre ansiados al principio y algo más cuestionados después y, por supuesto, a toda la comunidad ágil a la que me enorgullezco de pertenecer.