Devo garantire o aggiungere una clausola di garanzia al mio contratto nelle interruzioni del codice evento o un'anomalia si verifica al di fuori della mano del cliente o di un atto di Dio?
Se sì, cosa dovrebbe dire quel linguaggio?
Devo garantire o aggiungere una clausola di garanzia al mio contratto nelle interruzioni del codice evento o un'anomalia si verifica al di fuori della mano del cliente o di un atto di Dio?
Se sì, cosa dovrebbe dire quel linguaggio?
A meno che il tuo cliente non richieda una sorta di garanzia o garanzia, non andare ad offrirne uno. Molti clienti finiranno per usarlo per costringerti alla servitù a contratto.
Anche se ne richiedono uno, consultare un avvocato. Altrimenti, ti stai preparando per la catastrofe.
Should I guarantee or add a warranty clause to my contract in the event code breaks or an anomaly occurs outside the client's hand or act of God?
Se richiesto, non accettare il lavoro. Questa è una situazione impossibile. Non c'è fine alla lista di cose che potrebbero essere cambiate che potrebbero causare la rottura o il mancato funzionamento del tuo codice.
A meno che non ti piaccia lavorare gratis, vai avanti.
Il modo standard per rispondere a questo è aggiungere una clausola di supporto o manutenzione - "le prime 10 ore di lavoro incluse gratuitamente, il resto disponibile alla seguente tariffa:".
Ho upvoted Adam's "do not do it", ma offrire una tale garanzia per un prodotto software commerciale potrebbe ottenere molta attenzione favorevole da parte dei clienti. Mostrerebbe anche che hai avuto enormi cojones rispetto al resto del settore. : -)
Potrei considerare di offrire una garanzia nelle seguenti circostanze:
In tal caso, potrei offrire una garanzia come "Per un periodo di un anno dalla data di acquisto, garantiamo che se il software non funziona in modo sostanziale come documentato nel manuale dell'utente, lo ripareremo e emettere un aggiornamento gratuito. "
Questa non sembra una gran parte della garanzia, ma è molto più di quanto la maggior parte dei software commerciali abbia, rassicura i clienti che correggi i bug e la parola "sostanzialmente" lascia abbastanza spazio di manovra da non andare in rovina .
Se è la programmazione del contratto per qualcun altro, dimenticala. Una volta mi sono imbattuto in una situazione simile a quella, portando un programma Windows sul Mac, e ho perso decine di migliaia di dollari risolvendo "bug" che in realtà erano funzionalità nascoste nella versione di Windows che il client non riusciva a menzionare prima di firmare il contratto , anche se abbiamo chiesto più volte le specifiche. Quell'esperienza è stata una delle principali ragioni per cui ho smesso di fare contratti a prezzo fisso.
È comune fornire una garanzia che includa correzioni di bug per un periodo specifico dopo la fine del progetto (per esempio 3-6 mesi). Questo dice al cliente che stai dietro il tuo codice e, francamente, dovresti avere una certa responsabilità per i problemi che fornisci con il tuo codice.
Quello che facciamo di solito nei nostri progetti è offrire uno SLA (accordo sul livello di servizio) che definisce quali sono i bug e il calendario per risolverli in base al loro livello di gravità. Ad esempio, i problemi critici su un progetto dal vivo dovrebbero essere risolti (almeno tentati) entro 1 ora dalla ricezione del report. Problemi visivi e bug minori dovrebbero essere risolti entro 48 ore.
È molto importante avere una chiara definizione di cosa sia un bug - dato che i clienti cercheranno spesso di lavorare su nuove funzionalità come segnalazioni di bug (a volte involontariamente). Queste definizioni sono sempre in qualche modo aperte all'interpretazione, quindi è necessario assegnare un arbitro (di solito un'autorità nella lingua / piattaforma di sviluppo) in grado di arbitrare i disaccordi.
La formulazione del contratto dovrebbe indicare cose simili alle seguenti:
Solo alcuni a cui potrei pensare.
Leggi altre domande sui tag code-quality freelancing negotiation