Chi dovrebbe pagare per correzioni / bug? [chiuso]

Quindi ho appena iniziato a lavorare come freelance sia nello sviluppo desktop / web che in questo client che ha già accettato il mio lavoro e che mi ha pagato continua a tornare da me ogni volta che trova un bug ecc. E mi sono ritrovato a passare più tempo di quanto pensassi di risolverli gratuito. Va bene, o dovrei iniziare ad addebitare una commissione di supporto?

Qual è il modo migliore per affrontare le correzioni su un lavoro apparentemente accettato e completato?

Parte del contratto deve descrivere i test di accettazione, ad esempio i test che il cliente eseguirà e l'applicazione dovrà superarli per l'adempimento del contratto. Qualunque cosa non coperta da questi test è a carico del cliente. Qualunque cosa coperta da loro è tua.

Poiché non è possibile (soprattutto per un cliente non tecnico) prevedere tutti i possibili problemi, è necessario aggiungere al contatto una clausola che specifichi un periodo, quando si risolveranno eventuali nuovi problemi come parte di un contratto. Successivamente, dovresti offrire solo assistenza a pagamento.

Dipende.

In primo luogo dovresti pagare in quanto si può sostenere che il lavoro non è completo.

Successivamente il cliente dovrebbe pagare per il supporto continuo.

Tuttavia, il problema è decidere dove si trova il confine e cosa costituisce un bug e qual è una nuova funzionalità. Avere requisiti e / o test di accettazione può fare molto per definirlo.

Hai davvero bisogno di ottenere queste cose a posto prima di consegnare il lavoro, ma se non avete allora forse è giunto il momento così dire - "Io sostengo questo gratuitamente per i prossimi N giorni / settimane, ma dopo che abbiamo necessità di discutere un contratto di sostegno "(notare la mia enfasi sul" noi ").

Detto questo, ci sono momenti in cui dovrai correggere un bug gratuitamente e prendere il colpo. Se non altro costruisce buona volontà.

Tutte le risposte fornite sopra sono buone. Tuttavia, aggiungerei alcuni punti elenco da considerare:

• Il cliente è prezioso per te? A volte vale la pena fare qualche metro in più per rendere felice un cliente se ritieni che sia prezioso per te e ti porterà più lavoro in futuro. Devi trovare un equilibrio tra l'essere rigoroso e flessibile e questo può differire per ogni cliente. Inutile perdere il lavoro futuro solo perché sei fermamente convinto che un bug facile da risolvere esca dall'ambito di applicazione. D'altra parte, non vuoi lasciare che il cliente cammini su di te. È un delicato equilibrio!

• Il bug è qualcosa che poteva facilmente essere perso nei test degli utenti? Ad esempio, prendi un bug relativo alla data che entra in gioco solo quando viene inserito un determinato anno (pensa al bug del Millennio ecc.). Un cliente non poteva ragionevolmente aspettarsi di individuarlo durante il test, quindi spetta a te risolverlo.

Quando lavoravo come freelance, il mio accordo di base con i clienti definiva una condizione chiamata "accettazione", che era richiesta prima di rendere pubblico il progetto. Al momento dell'accettazione, è iniziato un periodo di 30 giorni che ho chiamato "supporto operativo". Dopo quel periodo di 30 giorni, i lavori in corso sul progetto erano fatturabili ogni ora.

Se hai un buon rapporto con questo cliente, abbi un cuore a cuore con loro su quanto sia inattuabile la situazione attuale per te e proponi una tariffa oraria adeguata per la manutenzione e il supporto continui. Le persone a volte pensano che acquistare software personalizzato sia come comprare un sandwich o qualcosa del genere, come una volta che è stato realizzato, è fatto. Non è proprio così.

In genere puoi richiedere un supporto gratuito per un numero fisso di giorni dopo la consegna della domanda. Certamente un supporto gratuito a vita non è possibile / inaccettabile.

Assicurarsi che il bug sollevato sia un ERRORE e non una modifica alla funzione esistente. Per qualsiasi modifica delle funzionalità è necessario addebitare.

Se lo provasse e lo firmasse, si potrebbe sostenere che dovrebbe pagare.

Se sei orgoglioso e apprezzi il tuo lavoro, potresti sostenere che risolveresti il ​​codice. Impara dalle esperienze e costruisci codice migliore la prossima volta, in modo più efficiente. O fattore in più profitto per coprire la correzione di bug.

Se il programma fa qualcosa di indesiderato o imprevisto dati gli input, allora è un bug e dovrebbe essere corretto.

Avresti potuto preventivare preventivamente la commissione di supporto come extra per il lavoro di sviluppo iniziale.

Nel contratto, specifica una tariffa oraria e tieni traccia del tuo tempo. Quando dai il prezzo al tuo cliente, specifica che si tratta di una stima e che il risultato effettivo potrebbe essere inferiore o superiore.

Tieni aggiornato il cliente sullo stato di avanzamento e quando inevitabilmente ti dà suggerimenti, puoi semplicemente dirgli il tempo che ci vorrà (se la modifica è al di fuori delle specifiche originali) e può decidere se la modifica vale la pena. Pertanto verranno aggiunti solo i cambiamenti importanti per lui.

Coprerei personalmente i bug accettabili vs inaccettabili (supporto pagato vs supporto gratuito) nel contratto, e in questo modo almeno avrai qualcosa per iscritto fin dall'inizio. Si chiederà senza dubbio perché dovresti aver bisogno di quella clausola, quindi sii sincero e spiega che se esce un nuovo aggiornamento del sistema operativo che rompe qualcosa, questo non è supporto gratuito. Tuttavia, verrebbero coperti i bug nel codice in base alle specifiche originali sulle piattaforme specificate.

Tuttavia, dovrei menzionare che ho svolto solo attività di IT freelance piuttosto che di programmazione. Questo potrebbe spaventare i clienti, ma assicurati solo che il tuo lavoro si venda da solo, sia più professionale, estroverso e utile degli altri, e sia disponibile con le tue ragioni per avere un contratto più rigoroso.

Inoltre, un cliente che non accetta questa clausola è molto probabilmente un cattivo cliente.