El efecto final de satisfacción de cliente no se improvisa, hay que sembrarlo y trabajarlo continuamente. Cuando decimos que “la calidad se planifica”, esto tiene que ver con que hay que imaginar los criterios de aceptación, idear los procesos de aseguramiento y control de calidad que hacen más probable que dichos criterios de aceptación se cumplan.
Sin embargo, es muy frecuente que los clientes no nos firmen los requisitos. ¿Qué podemos hacer entonces para gestionar las expectativas del cliente?
Imaginemos que dirigimos un proyecto de desarrollo de software. Recopilamos requisitos el primer mes. Trabajamos en nuestras instalaciones durante 6 meses, terminamos y entregamos. Hemos sido muy eficientes, pero ¿habremos sido igual de eficaces?
El cliente verá el producto por vez primera el mes 7. No coincidirá con su idea inicial. Nos rechaza la funcionalidad al 80%. Las sucesivas iteraciones de prueba y reparación del software no lograrán niveles aceptables de calidad percibida. El día de la puesta en producción, será imposible reducir los defectos a un nivel aceptable por el cliente.
Si pudiéramos medir el riesgo del proyecto, acumulamos mucha exposición hasta la entrega. En la fase de pruebas no es posible reducir eficazmente el nivel de riesgo. Por otra parte, hasta que se produce la entrega, la calidad percibida es cero. Cuando se ve el producto, comienza a subir la percepción de calidad, pero no hasta superar los criterios de aceptación.
Imaginemos ahora que practicamos un modelo de ciclo de vida iterativo-incremental. Observemos cómo mejoramos la gestión de expectativas del cliente.
En cada iteración construimos algo que se puede probar, reparar y enseñar al cliente. La calidad percibida va aumentando desde el principio, y los niveles de riesgo se mantienen controlados.
En la 5ª iteración, hacemos una entrega formal, una parte del sistema que ya pueden usar. En la figura puede observarse que hay previstas tres entregas más, y finalmente, la 5ª y última entrega servirá para cerrar el proyecto.
Cada vez que entregamos, el cliente va modelando su propia imagen del producto. Es muy probable que reformule algunos requisitos, que nos diga “eso está bien, pero…” y a continuación una serie de elementos que quiere cambiar. Cuando en la siguiente entrega entreguemos lo que ha pedido, esto no lo va a discutir. Discutirá otras cosas, cada vez menos.
En proyectos con mucha incertidumbre, es eficaz gestionar la calidad con iteraciones incrementales.
Si el cliente nos ha dicho 20 veces “Sí, pero…” la última vez no nos va a decir “NO”
En un esquema de despliegue iterativo-incremental, se ordenan las entregas: primero lo más importante, o más complejo, o de más riesgo, o de más valor. Se deja para el final la funcionalidad secundaria. De esta manera, si el proyecto se cancela, o se adelanta la fecha límite, pueden entregarse partes con valor para el cliente.
Desde las primeras entregas (subsistemas finales o prototipos) los usuarios dan su realimentación positiva o negativa. Poco a poco, el sistema se va pareciendo por aproximaciones sucesivas, a lo que realmente necesitan. El valor del desarrollo se aprecia continuamente.
Estas iteraciones harán que el proyecto sea la solución a lo que requiere el cliente.
ResponderEliminarNo obstante, estas iteraciones no son un sobrecoste?
Es decir, normalmente, en proyectos de software, se realizan unas pruebas para verificar el buen funcionamiento de la aplicación (preferiblemente con cliente) una vez desarrollada. Si en oferta ya se tienen en cuenta estas iteraciones (como debe ser), no seremos de partida más caros que la competencia?
Buen punto, David. A mi juicio, la mejor propuesta es la que mejor argumenta el plan del proyecto (que todavía no será definitivo porque debe perfeccionarse con el cliente, después de la adjudicación, ver el post http://goo.gl/0KyjQ)
ResponderEliminarSi el cliente está familiarizado con el coste de la calidad, preferirá un enfoque iterativo (algo más coste de conformidad, a cambio de mucho menos coste de no conformidad).