Los derechos del cliente

Hoy vamos con algo ligero y no por ello menos importante: los derechos del cliente. Y no penséis que vamos a revisar leyes y decretos, ni mucho menos.

Hablamos de fomentar una relación profesional de respeto y confianza, basada en unas normas conocidas y simples que permitan a nuestros clientes seguir trabajando recursivamente con nosotros en proyecto tras proyecto. Empecemos.

#1: Fijar los objetivos del proyecto, y que éstos se sigan.

Desde luego, el cliente tiene derecho a establecer qué hay que hacer (requisitos), pero no sólo eso. También tiene el derecho de establecer los objetivos generales del proyecto, la visión del mismo que hay que cumplir y que debe terminar no sólo con un software que funciona, sino además, con unos objetivos corporativos satisfechos.

#2: Conocer cuánto tiempo va a costar hacer el software, y cuánto dinero me va a costar.

Aquí ya lo siento por los talibanes del agilismo. Pero es uno de los puntos que hay que respetar del cliente: tiene este derecho inalienable.
Por supuesto, si el cliente nos permite hacer el desarrollo mediante sprints, usando métodos ágiles, y  está dispuesto a no saber cuándo estará terminado ni el precio final...estupendo. La gente se entiende hablando.
También hay que decir, que ser ágiles o usar metodologías ágiles, no tiene que estar forzosamente relacionado con una fecha de entrega fija y precio fijo.

#3: Decidir qué funcionalidades se incluyen, y cuáles se quedan fuera del software.

Aquí las técnicas ágiles pueden ayudar: entregas frecuentes, identificación de funcionalidades prioritarias...etc. Lo que hay que tener claro, es que la última palabra, la tiene el cliente. Es nuestro problema si nosotros hubiéramos preferido dejar esa otra funcionalidad fuera de esta versión...

#4: Poder hacer razonables cambios en el software durante su construcción, y conocer sus costes antes de llevarlos a cabo.

De nuevo, las metodologías ágiles nos pueden permitir asumir los cambios de forma práctica. Pero un buen procedimiento de control de cambios no está de más. No sólo eso, sino que al cliente hay que aclararle cuánto le va a costar de más (o de menos, no seamos ladrones, que también existe esa posibilidad) el añadir o quitar cosas, el hacer cambios durante la construcción. Por supuesto, también hay que aclararle al cliente el impacto en la fecha de entrega (que puede adelantarse o retrasarse).

#5: Conocer el estado del desarrollo de forma clara y concisa.

El cliente tiene derecho a estar informado claramente del estado: funcionalidades en cartera (backlog en terminología ágil), en desarrollo, desarrolladas, etc.

#6: Ser avisado regularmente de los riesgos que afecten al coste, la calidad o la fecha de entrega, y ser informado de qué opciones hay para evitar o resolver los problemas anticipadamente.

Esta es una de las partes más flojas que he observado durante mis muchos años en el mundo del desarrollo de software. Se suele hacer una gestión pésima de riesgos y problemas. En muchas ocasiones limitada a mostrar obstáculos obvios e inmediatos, y cuando hay problemas o riesgos inminentes, las opciones y planes de contingencia son desproporcionadamente pobres y carentes de credibilidad.

#7: Tener acceso a los entregables durante todo el proyecto.

Para terminar, el cliente debe tener acceso a los entregables. Y sí, me refiero a la documentación, a esos documentos que tanto nos cuesta realizar y que para el cliente son la prueba de que sabemos trabajar, y de que el estado de nuestro trabajo da credibilidad de que somos capaces de terminar.
Además, esa documentación deberá ser altamente práctica y muy ágil, para facilitar el cambio y servir a otros grupos de trabajo: proveedores que se integran con nosotros y que han de ver en esos documentos una información mínima pero suficiente, personal de mantenimiento, de sistemas (que deberán tener claro cómo instalar, desinstalar, etc.).

¿Y tú, estás de acuerdo con estos puntos? ¿Añadirías alguno o quitarías alguno? Gracias por vuestros comentarios.


¡Ah! y en el próximo artículo, veremos los derechos del equipo de desarrollo (aquí hay pan para todos). Un cordial saludo.

Fuente: Adaptación libre de: Software Project Survival Guide (Steve McConnell, Microsoft Press)