Educando a un cliente.

Aquí os dejo un post que escribí y llegó a la fase final de un concurso de redacción de posts en nubelo.

¿A qué viene el concepto de “Análisis” en tu presupuesto?

Ésta suele ser una de las primeras preguntas que me suele hacer un cliente cuando le preparo un presupuesto. Cualquiera que haya estudiado algún curso o asignatura de programación, sabe que la primera fase de un proyecto debe ser el análisis. Nuestro error como profesionales suele llegar cuando damos por sentado que el cliente también lo sabe. Nuestra misión debe consistir en educar a nuestros clientes, haciéndoles comprender que un buen análisis requiere un tiempo. Dicho tiempo nos permitirá analizar, estructurar y preparar el proyecto para que su desarrollo sea más rápido y consistente. Evidentemente, ese tiempo se debe cuantificar dentro del periodo de desarrollo del proyecto y por lo tanto se debe facturar como parte de él.

¿Y el concepto de “Pruebas y corrección de errores”?

Cuando he conseguido hacer comprender al cliente la primera pregunta, siempre realizan la segunda. En cualquier proyecto de desarrollo de software, aunque utilicemos Desarrollo Orientado a Pruebas e Integración Continua, siempre, siempre, siempre hay errores. Para detectarlos hay que realizar pruebas. Una vez detectados hay que corregirlos. Una vez corregidos hay que volver a realizar pruebas. Todo esto significa tiempo, y como bien sabéis, tiempo significa dinero que se debe facturar. Tengo compañeros que optan por omitir este concepto en el presupuesto y lo camuflan dentro del tiempo de desarrollo. Yo soy de la opinión, de que intentar explicar estos conceptos al cliente les ayuda a tener una visión global de nuestro trabajo.

¿Me puedes añadir esto?

Típica pregunta/petición que suele realizar un cliente cuando el estado del desarrollo es avanzado o está terminado. La respuesta siempre debe ser la misma, “Claro, te lo presupuesto y si estás conforme lo hago”. Tras esta respuesta debéis estar preparados para una mala cara e intentad explicar la situación al cliente. Yo siempre pongo un ejemplo, “Imagina que vas a un bar y pides una tostada con tomate. Una vez que el camarero te la ha servido, le pides que le añada unas lonchitas de jamón”. Evidentemente el precio ya no es el mismo. Es exactamente lo que sucede con un proyecto de desarrollo de software. Para evitar estas situaciones siempre es aconsejable hacer un documento funcional con los requerimientos de nuestro cliente y firmarlo cuando se apruebe el presupuesto.

Si conseguimos educar a nuestros clientes para que comprendan nuestro trabajo, nuestra relación con ellos siempre podrá ser estable y duradera. Sin embargo, cuando no lo hacemos, los problemas con ellos se suelen enquistar y las relaciones laborales siempre terminan rompiéndose.