Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor

0

El primero de los doce principios del manifiesto para el desarrollo ágil de software. Comparados con los enunciados de valores, que ya hemos repasado algunos en este blog, los principios tienen muchas menos intenciones. Son más claros en su definición. Por lo que poco extra sacaremos de ellos. Aún así, algo sacaremos.

Este principio tiene cuatro conceptos integrados en una sola frase:

  • La prioridad es satisfacer al cliente. (Nuestra mayor prioridad es satisfacer al cliente)
  • Cuanto antes se entregue, mejor. (mediante la entrega temprana)
  • La entrega debe ser continua. (y continua)
  • Lo que cuenta es el software con valor. (de software con valor)

La prioridad es la satisfacción del cliente

Uno de los pilares que debe regir en el equipo es la satisfacción del cliente. Aquí cliente se dice en sentido amplio. Puede ser la empresa que nos ha contratado para hacer el desarrollo (cliente externo). Puede ser el departamento de nuestra misma empresa que nos ha solicitado el desarrollo (cliente interno). Puede representar a los usuarios. Puede representar a los directivos.

Yo, sinceramente, lo cambiaría por la satisfacción de los interesados. Pero tampoco está tan mal usar el concepto de cliente, siempre que lo entendamos en el sentido amplio.

Lo que viene a decir este principio es que debemos conseguir esta satisfacción por encima de todas las cosas. Y esto a veces puede implicar hacer cosas que no es lo que desearíamos, como dar un curso, o ayudar a hacer un power point. Un cliente contento es indicador de que estamos haciendo un buen trabajo.

Cuando el cliente se queja de que no entregamos a tiempo, de que no cumplimos sus expectativas, de que no resolvemos las incidencias, es que tenemos un cliente insatisfecho y algo hacemos mal.

Cuanto antes se entregue, mejor

Este es otro de los pilares del desarrollo ágil. Es mejor entregar la funcionalidad A hoy y la B mañana, que un paquete con A y B mañana. Hay muchas ventajas en la entrega temprana, pero por desatacar unas pocas:

  • Cuantos antes esté funcionando, antes entregará valor. Entregando una parte antes, maximizamos el valor entregado.
  • Cuando antes se ponga en marcha, antes se detectarán los defectos y los posibles cambios a realizar. El coste de los cambios, tanto en dinero como en tiempo para tener la funcionalidad definitiva se reduce.
  • Convence y alinea a interesados. Aumenta su implicación en el desarrollo que estamos haciendo.

Resumiendo entregamos más valor, reducimos coste y riesgos y aumentamos la implicación y satisfacción de interesados.

Parece un buen camino para satisfacer al cliente, ¿no?

La entrega debe ser continua

El entregar cada cierto tiempo algo, mantiene viva la llama. En el punto anterior ya vimos que una entrega temprana aporta valor. El ir entregando de forma continua tiene también ventajas:

  • Permite a los usuarios ir recibiendo paulatinamente las mejoras, lo que ayuda a entenderlas y a adaptarse a ellas.
  • Reduce riesgos, ya que cada vez se analiza una nueva parte.
  • Psicológicamente mantiene satisfechos a nuestros clientes.

Es como cuando sale una nueva versión de tu lenguaje o IDE favorito. De golpe hay varios cambios, y tardas un tiempo hasta que los revisas todos. En el tiempo entre versiones parece que está parado ese producto. Imagina que cada poco tiempo, aparece un nuevo cambio. Podrías dedicarte a ese cambio en ese momento, en vez de tener que lidiar con una veintena de ellos a la vez. Así el feedback es más inmediato. Y la sensación de producto vivo es mucho mayor.

Hay valor intrínseco en mantener una entrega continua, pero además aumenta la satisfacción o imagen que tiene nuestro cliente sobre nuestro trabajo.

Lo que cuenta es el software con valor

Ya lo comentamos cuando repasamos el enunciado «Sofware funcionando frente a documentación extensiva«. Lo importante es el software funcionando, y el software funcionando es el que está aportando valor. En este principio lo matizamos y dejamos más claro si cabe.

Para un que un software tenga valor debe:

  • Ser lo que el cliente necesita. Lo que realmente le aporte utilidad y usa (valor).
  • No debe fallar. Eso le resta valor.
  • Debe ser usable. Por mucho «valor» que se espere que aporte una funcionalidad, si luego nadie la usa, no sirve de nada.
  • Debe estar en producción. No vale con acabar y demo, debe estar disponible para usarse.

Conclusiones

El principio lo deja bastante claro. La prioridad es la satisfacción del cliente. Para conseguirlo la mejor manera es haciendo entregas en producción de software que sea realmente útil, no falle y se utilice. Y estas entregas deben producirse de forma continua, sin grandes lapsos de tiempo entre ellas; de forma que las funcionalidades se pongan a disposición de los usuarios lo antes posible.

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios