Quindi ho appena iniziato a collaborare freelance sia nello sviluppo desktop / web che in questo cliente che ha già accettato il mio lavoro, e mi ha pagato continuando a tornare da me ogni volta che trova un bug ecc. E mi sono trovato a passare più tempo di quanto pensassi ripararli gratuitamente. Va bene, o dovrei iniziare a pagare una quota di supporto?
Qual è il modo migliore per gestire le correzioni su un lavoro apparentemente accettato e completato?
Una parte del contratto dovrebbe descrivere i test di accettazione, ovvero i test che il cliente farà e la tua applicazione deve passarli per il contratto da soddisfare. Tutto ciò che non è coperto da questi test è responsabilità del cliente. Tutto ciò che è coperto da loro è tuo.
Poiché non è possibile (soprattutto per un cliente non tecnico) prevedere tutti i possibili problemi, è necessario aggiungere al contatto una clausola che specifica un periodo, quando si correggeranno eventuali nuovi problemi come parte di un contratto. Successivamente, dovresti offrire solo assistenza a pagamento.
Dipende.
Nel primo caso dovresti pagare in quanto si può sostenere che il lavoro non è completo.
In seguito il cliente dovrebbe pagare per il supporto continuo.
Tuttavia, il problema è nel decidere dove si trova il confine e cosa costituisce un bug e quale è una nuova funzionalità. Avere requisiti e / o test di accettazione è molto importante per definirlo.
Hai davvero bisogno di mettere queste cose a posto prima di consegnare il lavoro, ma se non lo hai allora forse ora è il momento di dirlo - "Lo sosterrò gratuitamente per i prossimi N giorni / settimane, ma dopo di che abbiamo bisogno di discutere un contratto di supporto "(nota la mia enfasi su" noi ").
Detto questo, ci sono momenti in cui è necessario correggere un bug gratuitamente e prendere il colpo. Se non altro, costruisce la buona volontà.
Tutte le risposte sopra riportate sono buone. Tuttavia, aggiungerei alcuni punti elenco da considerare:
Il cliente è prezioso per te? A volte vale la pena spendere qualche yard per mantenere un cliente felice se ritieni che sia prezioso per te e ti porterà più lavoro in futuro . È necessario trovare un equilibrio tra l'essere severi e flessibili e questo può differire per ogni cliente. Inutile perdere il lavoro futuro solo perché sei irremovibile sul fatto che un bug facile da correggere non rientra nello scope. D'altra parte, non vuoi permettere al cliente di camminare su di te. È un delicato equilibrio!
Il bug è qualcosa che potrebbe facilmente essersi 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 Millennium bug ecc). Non ci si può ragionevolmente aspettare che un cliente rilevi questo durante i test, quindi l'onere è su di te per risolverlo.
Quando ero un freelance, il mio accordo base con il cliente definiva una condizione chiamata "accettazione", che era richiesta prima che io pubblicassi il progetto dal vivo. Al momento dell'accettazione, è iniziato un periodo di 30 giorni che ho chiamato "supporto attivo e funzionante". Dopo quel periodo di 30 giorni, i lavori in corso sul progetto sono stati fatturabili ogni ora.
Se hai un buon rapporto con questo cliente, abbi cuore con loro su quanto sia impraticabile per te la situazione attuale e proponi una tariffa oraria equa per manutenzione e supporto continui. A volte le persone pensano che acquistare un software personalizzato sia come comprare un sandwich o qualcosa del genere, come una volta che è stato realizzato. Non è così.
Generalmente puoi richiedere un supporto gratuito per un numero fisso di giorni dopo che hai consegnato l'applicazione. Sicuramente un supporto senza vita non è possibile / inaccettabile.
Assicurati che il bug generato sia un bug e non una modifica alla funzionalità esistente. Per qualsiasi cambio di funzione dovresti caricare.
Se lo ha testato e firmato, potresti obiettare che dovrebbe pagare.
Se sei orgoglioso e apprezzi il tuo lavoro, potresti obiettare che correggerai il codice. Impara dalle esperienze e crea un codice migliore la prossima volta, in modo più efficiente. Oppure fattore più profitto per coprire la risoluzione dei bug.
Se il programma fa qualcosa di indesiderabile o inaspettato dato gli input, allora è un bug e dovrebbe essere corretto.
Potresti aver preventivato la quota di supporto in anticipo per il lavoro di sviluppo iniziale.
Nel contratto, specifica una tariffa oraria e tieni traccia del tuo tempo. Quando dai al cliente il prezzo, specifica che si tratta di una stima e il risultato effettivo potrebbe essere inferiore o superiore.
Mantieni il cliente aggiornato sui progressi e quando inventa inevitabilmente dei suggerimenti, puoi semplicemente dirgli il tempo che ci vorrà (se il cambiamento è al di fuori delle specifiche originali) e lui può decidere se il cambiamento vale la pena . Pertanto verranno aggiunte solo modifiche importanti per lui.
Personalmente coprirò i bug accettabili vs inaccettabili (supporto pagato vs supporto gratuito) nel contratto, e in questo modo almeno avrai qualcosa da scrivere dall'inizio. Si chiederà indubbiamente perché si dovrebbe aver bisogno di quella clausola, quindi sii in anticipo e spiega che se viene fuori un nuovo aggiornamento del sistema operativo che rompe qualcosa, non è un supporto gratuito. Tuttavia, i bug nel codice in base alle specifiche originali sulle piattaforme specificate sarebbero coperti.
Tuttavia, dovrei menzionare che ho fatto solo il lavoro IT freelance piuttosto che la programmazione. Questo potrebbe spaventare i clienti, ma assicurati che il tuo lavoro si venda da solo, sia più professionale, estroverso e utile rispetto agli altri, ed essere disponibile con le tue ragioni per avere un contratto più stretto.
Inoltre, un client che non accetta quella clausola è molto probabilmente un cattivo cliente.
Leggi altre domande sui tag bug maintenance client-relations freelancing