Garantía de satisfacción

19-10-2007 Luis Artola

Ésta es una duda que siempre tengo cada vez que hago un presupuesto. ¿Cuál debe ser el periodo de garantía de satisfacción que le ponga al cliente? Esto es: ¿cuánto tiempo debo dejar desde que termino el desarrollo de la aplicación hasta que admito correcciones y feedback por parte del cliente? ¿A partir de cuando considero que puedo cobrarle por un cambio no especificado?

Es un tema realmente complejo. En un escenario de constante cambio como es el del desarrollo de software, uno no puede atenerse a lo especificado originalmente en un análisis de hace seis meses, sería poco realista… pero por otro lado no debe permitir cambios constantes en los requisitos por parte de un cliente veleta. Por supuesto podemos aplicar todos los mecanismos propios de los métodos ágiles para ver lo menos vulnerable posible a los cambios pero, aún y todo, tienen su coste y su riesgo.

¿Y si uno pone una funcionalidad en producción pero el cliente no hace ningún esfuerzo por probarla, la prueba pasados dos años desde que se programó y te pide que la corrija porque tiene un fallo? ¿Debemos aceptarlo?

Éste es un post lleno de preguntas y sin ninguna respuesta. A ver quién se anima.  ;-)

5 Comentarios

  • 1. JoseLuisGV  |  October 19th, 2007 at 12:52 pm

    Pues tal como comento en un post de temática MUY parecida de Enero de este año (”Requerimientos y especificaciones: gestión de expectativas“), mi opinión es:

    “Si los requerimientos iniciales han sido obtenidos siguiendo unas normas básicas, con la conformidad del cliente, son estos requerimientos los que deben marcar las expectativas y el marco del proyecto, y por tanto, todo aquello que se salga de estos requerimientos mutuamente acordados, deberán ser abordados en un nuevo proyecto o en una ampliación del mismo.”

    Y por ende, si algo “falla” estando dentro del desarrollo original, CREO que debería ser resuelta aun a pesar de ser descubierto años después de la implantación. Todos sabemos que puede haber partes del desarrollo o circuitos del mismo que ni siquiera se prueben NUNCA.

    Un saludo.

  • 2. Ricardo J. Mamaní  |  October 19th, 2007 at 2:03 pm

    Creo que hay dos instancias bien definidas:

    - Por un lado al finalizar un desarrollo, el cliente debe comprometerse a realizar las pruebas pertinentes (firmar la aceptación del desarrollo) para dar conformidad al desarrollo y por ende liberar el último pago. Con esto el cliente nos dice “el software esta funcionando de acuerdo a lo especificado”.

    - No obstante es posible que se encuentren fallos una vez firmada la aceptación por parte del cliente, con lo cuel entra en vigencia el período de garantía que debe figurar en el contrato firmado entre el cliente y la empresa desarrolladora. Dependiendo del cliente y el importe facturado el producto tendrá mayor o menor garantía. Por ejemplo seis meses. Teniendo en cuenta siempre que deberían ser fallos de los requisitos pre-establecidos y no nuevas funcionalidades, estas deberían tratarse en un proyecto aparte.

    Saludos.

  • 3. danJ  |  October 19th, 2007 at 8:45 pm

    Claro, como los comenta Ricardo todo eso es muy importante a la hora de hacer el contrato, este debe ser específico que modulos, pantallas y funcionalidades incluye, el tiempo de la garantía, que tambíen debe haber un acuerdo entre ambas partes (empresa-cliente), debe de especificarse tambien que el cliente esta obligado a probar la funcionalidad y si pasando el periodo de garantía sale algún detalle que en su tiempo fué obligacion del cliente reportarlo, claro que tiene un costo.

    Saludos

  • 4. Héctor  |  January 23rd, 2008 at 6:12 am

    mm de acuerdo con lo anterior; sólo quisiera agregar, un amigo arquitecto, me contaba que le siguen pagando por una obra, aún después de terminada… me pregunto ¿qué pasaría si a los desarrolladores, nos siguieran pagando mensualmente por la creación artística a la cual hemos dado vida? con la consiguiente extensión de la garantía, claro…

  • 5. norbert  |  November 27th, 2008 at 11:43 pm

    Las preguntas que haces en el post se resuelven, en buena medida, con un contrato bien redactado.
    El mismo debe incluir no sólo los detalles del desarrollo, lo que se espera y objetivos que permitan cuantificar resultados sino también posibles vías de escape o alternativas por si las cosas no salen como se esperan.
    Considero que el principal problema entre informáticos y “el resto” se basa en conflictos de entendimiento. Digamos, del diferente sentido con que se entiende el mismo punto. Deberíamos por partir de la base de qué se entiende por “cliente satisfecho” (un concepto con sabor ambigüo) y proponer pautas facilmente cuantificables.

Comenta el articulo:

Requerido

Requerido,