Devo garantir ou adicionar uma cláusula de garantia ao meu contrato no caso de quebras de código ou anomalia ocorrer fora da mão do cliente ou ato de Deus?

Se sim, o que esse idioma deve dizer?

A menos que seu cliente exija algum tipo de garantia, não ofereça uma. Muitos clientes acabam usando-o para forçá-lo à servidão.

Mesmo que exijam um, consulte um advogado. Caso contrário, você está se preparando para uma catástrofe.

Devo garantir ou adicionar uma cláusula de garantia ao meu contrato no caso de quebras de código ou anomalia ocorrer fora da mão do cliente ou ato de Deus?

Não nunca

Se necessário, não aceite o trabalho. Esta é uma situação impossível. Não há fim para a lista de coisas que poderiam ser alteradas que causariam a interrupção ou não do código do seu código.

A menos que você goste de trabalhar de graça, siga em frente.

A maneira padrão de responder a isso é adicionar uma cláusula de suporte ou manutenção - "as primeiras 10 horas de trabalho incluídas gratuitamente, o restante disponível na seguinte taxa:".

Votei no "não faça" de Adam, mas oferecer essa garantia a um produto comercial de software pode receber muita atenção favorável dos clientes. Também mostraria que você tinha cojones enormes em comparação com o resto da indústria. :-)

Posso considerar oferecer uma garantia nas seguintes circunstâncias:

• É o meu produto, em vez de trabalhar para contratar alguém.
• Eu tinha controle sobre todo o processo de desenvolvimento e liberação de software, incluindo especificação, programação, teste e documentação.
• Especifiquei cuidadosamente na documentação as circunstâncias sob as quais o software poderia ser executado e ao qual a garantia se aplicaria. Por exemplo, requisitos de hardware, sem execução em emuladores de SO, etc.
• Limitei o período da garantia.
• Eu estava realmente confiante na qualidade do software

Nesse caso, posso oferecer uma garantia como: "Por um período de um ano a partir da data da compra, garantimos que, se o software não funcionar substancialmente conforme documentado no manual do usuário, iremos corrigi-lo e emitir uma licença gratuita. atualizar."

Isso não parece muito com uma garantia, mas é muito mais do que a maioria dos softwares comerciais, garante aos clientes que você corrigirá bugs, e a palavra "substancialmente" deixa espaço de manobra suficiente para que você não fique sem dinheiro.

Se for uma programação de contrato para outra pessoa, esqueça. Certa vez, entrei em uma situação semelhante a essa, portando um programa Windows para o Mac e perdi dezenas de milhares de dólares consertando "bugs" que eram realmente recursos ocultos na versão Windows que o cliente não mencionou antes de assinar o contrato. , mesmo que tivéssemos solicitado repetidamente especificações. Essa experiência foi uma das principais razões pelas quais parei de fazer contratos a preço fixo.

É comum dar uma garantia que inclua correções de erros por um período específico após o término do projeto (por exemplo, de 3 a 6 meses). Isso diz ao cliente que você está por trás do seu código e, francamente, você deve ter alguma responsabilidade com os problemas que você entrega com o seu código.

O que geralmente fazemos em nossos projetos é oferecer um SLA (contrato de nível de serviço) que define o que são bugs e o cronograma para corrigi-los de acordo com o nível de gravidade. Por exemplo, problemas críticos em um projeto ativo devem ser resolvidos (pelo menos tentados) dentro de 1 hora após o recebimento do relatório. Problemas visuais e pequenos erros devem ser resolvidos dentro de 48 horas.

É muito importante ter uma definição clara do que é um erro - já que os clientes geralmente tentam trabalhar em novos recursos como relatórios de erros (às vezes sem querer). Essas definições são sempre um tanto abertas à interpretação; portanto, você precisa atribuir um árbitro (geralmente uma autoridade na linguagem / plataforma de desenvolvimento) que pode arbitrar desacordos.

A redação do contrato teria que declarar coisas semelhantes à seguinte:

1. Você não pode estender este código
2. Você não pode fazer engenharia reversa deste código
3. Você não pode integrar esse código à sua estrutura (semelhante ao número 1, mas diferente no sentido de que se torna uma camada inteira de seus negócios)
4. Você não pode portar esse código para outros sistemas operacionais (janelas do IE para unix)

Apenas alguns em que eu conseguia pensar.