Aislar y proteger al equipo del cliente

Interesantísimo tema que se planteó hace unos días en LinkedIn en el que yo defendía que el equipo de desarrollo tiene que estar aislado del cliente. Pero… Agile fomenta la interacción con el cliente ¿NOOOO? Sí, pero no.

Situemos el debate: alguien pide consejo y orientación para implantar Scrum y yo le sugiero algunas cosas, entre las que cito evitar que el cliente tenga contacto con el equipo de desarrollo. En seguida saltó alguien asegurando que no tenía ni idea de lo que decía, porque Agile fomenta la interactividad con el cliente. ¿A que sí? ¿A que el manifesto Agile dice eso? Bueno, PUES NO.

Recordemos lo que dice el manifiesto, resumido en el tema que nos interesa:

A través de este trabajo hemos aprendido a valorar:
Colaboración con el cliente sobre negociación contractual
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Este es un fallo que me encuentro muy a menudo en la implantación de Scrum: alguien que se ha leído el manifiesto y lo interpreta de una forma radical para defender su manía. El mejor ejemplo es el que tenemos entre manos: el manifiesto nunca dice que haya que desterrar la negociación, sólo dice que es mejor colaborar que negociar contratos. Lo cual tiene toda la lógica del mundo: ningún acuerdo te va a librar de perder el cliente si te emperras en entregar un producto que no le resuelve el problema, aunque sea lo que se puso en las especificaciones. El desafío es evitar que el cliente introduzca el caos absoluto en el desarrollo. Vamos por tanto a revisar lo que quiere decir «aislar y proteger al equipo».

Uno de los problemas habituales en los proyectos de software es que las especificaciones cambian continuamente. Esta realidad tiene muchas causas. Algunas son legítimas, como el hecho de que la tecnología avanza a gran velocidad y que continuamente se producen novedades. Es normal, por tanto, que en un proyecto que dure varios meses o un par de años haya requisitos que cambien desde el momento en que se formulan al princio, hasta el momento en que se implementan unos meses más tarde. Hasta aquí, todo normal.

Pero también hay causas ilegítimas, como que el cliente no tiene ni idea de lo que quiere y pide lo primero que se le pasa por la cabeza o, como también es habitual, traslada la responsabilidad de definir el producto a la empresa de desarrollo. Es el típico «bueno, lo normal, tú sabrás decirme qué es lo que debe tener un portal de comercio electrónico». Lo que pasa es que al cabo de cuatro o cinco semanas se entrega la primera parte y lo que encuentra no es lo que pensaba. Ahí ya no se acuerda de que se desentendió por completo del problema y exige revisiones que pretende que se anoten como «correcciones», como si el software tuviera fallos.

El escenario anterior es habitual y todos lo hemos vivido, pero puede empeorar por algunas causas adicionales, como pueden ser debilidad de la empresa, riesgo de perder al cliente o falta de práctica en la negociación. Un Jefe de proyecto o un comercial débiles o con pocas tablas pueden ceder de forma exagerada en las condiciones de trabajo y llegar al punto de prometer lo más perjudicial: «bueno, no te preocupes que ahora definimos una cosa así genérica, pero luego hablas con los chicos y ellos seguro que hacen lo que necesites». ¡Horror!

Vemos así que el contacto del cliente con el equipo no suele aparecer como un medio de colaboración, sino como una consecuencia de la incapacidad de la empresa para negociar, de mantener una disciplina con el cliente o de hacer una toma de requisitos efectiva. Esto no solo perjudica al equipo, que ve aumentada su carga de trabajo, sino a la propia empresa, que ve cómo empeoran sus márgenes, su ambiente, su gestión de entregas y alguna cosa más.

Cuando se introduce Scrum una de las prácticas más importantes es la apertura del Sprint, en la que se negocia y concreta el alcance de ese ciclo de desarrollo. El propietario (product owner) fija unos objetivos y necesidades y el equipo valora la capacidad de producción en el periodo fijado para adquirir un compromiso de entrega: si me das tantos días, puedo hacer hasta aquí.

Si a mitad del Sprint permitimos que el cliente tenga contacto con el equipo, lo más normal es que utilice esa facultad para introducir cambios en los requisitos, añadir peticiones e incluso alterar por completo las prioridades con la célebre frase «es que esto es súper-urgente». Liberado de la presencia de un Jefe de proyecto, el cliente puede ejercer una presión enorme sobre el trabajo.

El objetivo de Scrum, en línea con la filosofía Agile, es eliminar las barreras en la comprensión del problema. Si se ha fijado un requisito, por ejemplo un formulario de registro, pueden surgir dudas sobre un campo, sobre el número de detalles, sobre la presentación de un dato. Es muy provechoso que equipo y cliente puedan tener un canal para resolver esas dudas, de forma que cuando se hace la demostración al cierre del Sprint el producto entregado se ajuste al máximo a lo que realmente quería.

El problema es que esta relación ideal debe construirse sobre la experiencia, el respeto y la disciplina. Es difícil que el cliente acepte al principio las limitaciones del Sprint y que los programadores puedan resistirse a una imposición formulada con la amenaza de que «haces esto porque yo soy el que paga», secundado por un comercial que recuerde que «haz esto, porque este es el que paga».

Por este motivo, durante una primera fase de implantación es conveniente que el propietario sea una persona interna en la empresa, algo muy parecido a un Jefe de proyecto, en el sentido de que sirve de integrador de comunicaciones entre el exterior y el interior, que tome los requisitos de fuera y los presente y negocie dentro. Es en este sentido, y no en la negación de un contacto positivo con el cliente, en el que mi recomendación es «aislar y proteger» al equipo de las injerencias externas.

Cuando el cliente empiece a ver las ventajas de recibir versiones funcionales cada pocas semanas, cuando vea que esperar al siguiente inicio de Sprint es una oportunidad de revisar propuestas y confirmar peticiones con un poco más de reflexión, será el momento de ir abriendo la puerta y permitir una comunicación cada vez más fluida hasta alcanzar ese ideal expresado en el manifiesto Agile.

Puede que nunca se consiga o puede que se alcance en menos de un mes. Ahí está la habilidad del Director de operaciones y del Scrum Monster para evaluar la situación y avanzar en la dirección correcta.

Dejar una contestacion

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *