¿Debo garantizar o agregar una cláusula de garantía a mi contrato en caso de que se rompa el código o se produzca una anomalía fuera de la mano del cliente o un acto de Dios?

Si es así, ¿qué debería decir ese idioma?

A menos que su cliente exija algún tipo de garantía, no ofrezca una. Muchos clientes terminarán usándolo para forzarlo a una servidumbre por contrato.

Incluso si exigen uno, consulte a un abogado. De lo contrario, te estás preparando para una catástrofe.

¿Debo garantizar o agregar una cláusula de garantía a mi contrato en caso de que se rompa el código o se produzca una anomalía fuera de la mano del cliente o un acto de Dios?

No nunca

Si es necesario, no aceptes el trabajo. Esta es una situación imposible. La lista de cosas que podrían modificarse no tiene fin y que podrían hacer que su código se rompa o no funcione.

A menos que te guste trabajar gratis, entonces adelante.

La forma estándar de responder a esto es agregar una cláusula de soporte o mantenimiento: "las primeras 10 horas de trabajo incluidas de forma gratuita, el resto disponible a la siguiente velocidad:".

Voté por el "no lo hagas" de Adam, pero ofrecer tal garantía para un producto de software comercial podría recibir mucha atención favorable de los clientes. También demostraría que tenía enormes cojones en comparación con el resto de la industria. :-)

Podría considerar ofrecer una garantía en las siguientes circunstancias:

• Es mi producto, a diferencia del trabajo por contrato para otra persona.
• Tenía control sobre todo el proceso de desarrollo y lanzamiento de software, incluidas las especificaciones, la programación, las pruebas y la documentación.
• Especifiqué cuidadosamente en la documentación las circunstancias bajo las cuales se podría ejecutar el software para el cual se aplicaría la garantía. Por ejemplo, requisitos de hardware, no ejecutarse bajo emuladores del sistema operativo, etc.
• Limité el período de la garantía.
• Estaba realmente seguro de la calidad del software

En ese caso, podría ofrecer una garantía algo así como: "Por un período de un año a partir de la fecha de compra, garantizamos que si el software no funciona sustancialmente como se documenta en el manual del usuario, lo arreglaremos y emitiremos un servicio gratuito actualizar."

Eso no suena como una gran garantía, pero es mucho más de lo que la mayoría del software comercial tiene, asegura a los clientes que corregirá errores, y la palabra "sustancialmente" deja suficiente margen de maniobra para que no se arruine.

Si se trata de programación por contrato para otra persona, olvídalo. Una vez me metí en una situación similar a esa, al portar un programa de Windows a la Mac, y perdí decenas de miles de dólares arreglando "errores" que en realidad eran funciones ocultas en la versión de Windows que el cliente convenientemente no mencionó antes de firmar el contrato. , a pesar de que repetidamente habíamos pedido especificaciones. Esa experiencia fue una de las principales razones por las que dejé de hacer contratos de precio fijo.

Es común dar una garantía que incluye correcciones de errores durante un período específico después del final del proyecto (por ejemplo, 3-6 meses). Esto le dice al cliente que respalda su código y, francamente, debe tener cierta responsabilidad ante los problemas que entrega con su código.

Lo que solemos hacer en nuestros proyectos es ofrecer un SLA (acuerdo de nivel de servicio) que defina qué errores son y el calendario para corregirlos de acuerdo con su nivel de gravedad. Por ejemplo, los problemas críticos en un proyecto en vivo deben resolverse (al menos intentarse) dentro de 1 hora de recibir el informe. Los problemas visuales y los errores menores deben resolverse dentro de las 48 horas.

Es muy importante tener una definición clara de qué es un error, ya que los clientes a menudo tratarán de trabajar en nuevas características como informes de errores (a veces sin intención). Esas definiciones siempre están algo abiertas a la interpretación, por lo que debe asignar un árbitro (generalmente una autoridad en el lenguaje / plataforma de desarrollo) que pueda arbitrar desacuerdos.

La redacción del contrato debería indicar cosas similares a las siguientes:

1. No puede extender este código
2. No puede aplicar ingeniería inversa a este código
3. No puede integrar este código en su marco de trabajo (similar al # 1, pero diferente en el sentido de que se convierte en una capa completa de su negocio)
4. No puede portar este código a otros sistemas operativos (ventanas de IE a Unix)

Solo algunas que se me ocurrieron.