Devo pagare i miei sviluppatori per correzioni di bug per un progetto o lavoro ancora in corso? [duplicare]

I difetti sono un risultato atteso del processo di sviluppo del software. Per un contratto di tempo e materiali, mi aspetterei che gli sviluppatori ti caricino per il tempo che dedicano alla correzione dei bug. Questa è una parte normale del lavoro di uno sviluppatore. Per un contratto di offerta fisso, mi aspetterei che gli sviluppatori mangiano il costo dei difetti e consegnano il sistema privo di bug (o il più vicino ad esso come afferma il contratto) per quel costo fisso. Per una situazione in cui li stai impiegando più direttamente come imprenditori o come dipendenti, allora rientrerebbe nello stesso tempo e nel ragionamento dei materiali: è una parte del lavoro, quindi dovrebbero essere pagati per questo.

Per essere sincero, questa domanda implica un enorme livello di ignoranza sul processo di sviluppo del software . Potrebbe essere opportuno rimuovere il tuo sito web aziendale dal tuo profilo [soprattutto dal momento che non esiste] e leggere un libro sulla gestione dei progetti di sviluppo software.

Per rispondere alla tua domanda specifica, come altri hanno affermato, se vuoi il codice privo di bug e il bug-fixing gratuito, devi specificare i test di accettazione per i deliverable e negoziare i contratti a offerta fissa con gli sviluppatori. Se assumi persone per dedicarti a un progetto senza prove di accettazione chiaramente definite, hai accidentalmente accettato di pagarle per il loro tempo, non i loro risultati. Quindi sì, dovresti pagare i tuoi sviluppatori per correggere i bug. Li hai anche pagati per scrivere gli errori. E se il tuo progetto non ha test di accettazione, probabilmente continuerai a pagarli per scrivere e correggere i bug fino a quando non accidentalmente finiscono il progetto, o esaurisce i soldi, o il cliente lo annulla. Nessuno dei quali rifletterà bene sulla tua organizzazione.

Quali sono i termini del contratto? Hai specificato di avere una fase di test di accettazione utente? Hai effettuato i pagamenti in base alla liquidazione dell'UAT?

I moduli / unità / sono stati accettati dalla tua organizzazione? Nota che c'è una differenza tra ricevuto e accettato. Ricevuto significa che hai ricevuto il codice e sta entrando nel test di accettazione dell'utente. Accettato significa che ha superato l'UAT.

Se il bug viene trovato dopo UAT, generalmente sei tenuto a pagare la correzione. Se viene rilevato durante UAT, non hai ancora ricevuto il codice di lavoro, quindi il traguardo del pagamento non è stato raggiunto.

Se non hai inserito alcun tipo di clausola di accettazione nel contratto, probabilmente dovrai pagare per correggere i bug.

Sto editorializzando qui - se sei in una condizione in cui non disponi di mezzi per far rispettare il codice di ricezione che funziona come previsto, quindi disattivi il contratto ora. L'azienda esterna è tenuta a fornire solo ciò che è nei termini del contratto. Se il contratto non specifica cosa sia "funzionale", allora sei praticamente in balia di ciò che viene consegnato per il contenuto finale.

Modifica aggiuntiva n. 1: Se si è in un contratto "Tempo e materiali" per il lavoro di sviluppo, non vi è alcuna differenza funzionale tra il pagamento per loro di codificare una nuova funzione o il pagamento per correggere i bug nelle nuove funzioni. Pensalo in questo modo: solo perché ti hanno dato un'anteprima di una funzione non significa che la funzione sia stata effettivamente consegnata. Quindi, anche se potresti aver trovato difetti nell'anteprima della funzione, significa che non sono ancora completi con lo sviluppo. Quello che vedi come correzioni di bug è in realtà il loro continuo perfezionamento della funzione.

Modifica aggiuntiva n. 2: Vorrei incoraggiare il controllo per vedere se ti sei spostato formalmente dal contratto a prezzo fisso all'approccio progetto-log / per-l'ora (alias T & M). In generale, ho mai consigliato a nessuno dei miei clienti di accettare un contratto T & M quando si tratta di nuovi sviluppi. Ci sono semplicemente troppe variabili in gioco per rendere un contratto T & M un rischio accettabile.

In un mondo di prezzi fissi, sono tenuti a risolvere tutti i problemi che impediscono di fornire la funzione specificata dal contratto. Quindi correzioni di bug dovrebbero essere sulla loro monetina, non il tuo.

In un mondo T & M, non esiste una soluzione di bug. È solo un ulteriore miglioramento del codice che è stato generato in quel momento.

(Editoriale # 2) Se le cose vanno male, non aver paura di abbandonare un cattivo contratto. Paga la sanzione di fuga e sii fatto con esso. È molto facile entrare in una situazione in cui i buoni soldi vengono gettati dopo male. Stop al cattivo processo di sviluppo; rielaborare la richiesta di offerta e specificare cosa è effettivamente richiesto; inchiostro un nuovo contratto. È il modo migliore per assicurarti che otterrai ciò di cui hai effettivamente bisogno e risparmierai un sacco di mal di testa nel lavorare con un cattivo contratto.

(Non sono un avvocato)

Dipende - cosa hai scritto in un contratto con loro? Se si tratta di dipendenti stipendiati, sei responsabile di pagarli a prescindere da cosa.

Come altri hanno risposto: dovresti pagare qualunque sia il tuo contratto che dice che hai accettato di pagare.

Sembra che tu possa ora avere problemi con il tuo contratto e senti che sei stato portato a fare un giro. Se non sei soddisfatto del tuo team di sviluppo, è tua responsabilità comunicarlo a loro in modo chiaro e amichevole, in modo che il problema possa essere risolto e il lavoro possa continuare. Non sembra che tu abbia un problema particolare con la squadra o il lavoro che viene fornito, ma piuttosto la fatturazione. Fai una telefonata amichevole o un incontro faccia a faccia e chiedi loro. La mia esperienza è stata che questo risolverà la maggior parte dei problemi abbastanza bene.

Se ciò non funziona per te, allora esiste un gruppo di great risposte a questa domanda già.

Potrebbe dipendere dalla natura dei bug. Se i bug impediscono il loro lavoro su altre funzionalità (ad esempio, se Screen 1 non riesce a renderizzare a causa di un bug vecchio , come possono aggiungere 2 nuovi pulsanti ad esso?), Allora potrebbe essere più economico per far sì che correggano il bug e facciano il loro nuovo lavoro correttamente piuttosto che il codice attorno al bug. In futuro, probabilmente starai meglio a definire questo tipo di situazione in modo più chiaro nel contratto iniziale.

Direi che le specifiche non erano chiaramente definite, o hanno fatto saltare le loro stime (che non dovresti pagare per).

Quando cerchi un preventivo, devi definire chiaramente quale sia la funzionalità da fornire e fornire loro (il negozio di sviluppo) una chiara definizione di come il prodotto dovrebbe funzionare e come sarà testato per verificare che funzioni. Il loro compito è di stimare e consegnare con precisione.

Se il prodotto non funziona come previsto (non supera i test che hai fornito, ad esempio un utente inserisce il nome utente e la password, fa clic su login e viene reindirizzato alla loro homepage), non è colpa tua.

Tuttavia, se non hai definito cosa dovrebbe accadere se inseriscono l'errato uname / pword e la pagina genera un errore, POTREBBE avere spazio per dire "Beh, non hai detto che dovevamo convalidare il nome utente e la password" così assicurati di scrivere ciò che ti aspetti che ogni "scenario di prova" abbia come risultato ..

1. definisce chiaramente cosa vuoi
2. definisci chiaramente come verificherai che funzioni nel modo desiderato
3. al momento della consegna utilizzare il test concordato per convalidarlo funziona come previsto

non fornire abbastanza informazioni in anticipo finirà per costarti ..

Non è possibile assumere i programmatori per scrivere codice perfetto:

1. Correggere bug nel normale progetto software richiede almeno 1/3 di tutto il tempo impiegato. In fase di mantenimento, più di 1/3.
2. Anche dopo aver speso grandi quantità di tempo e denaro per correggere i bug, la NASA ha comunque perso navette spaziali a causa di problemi software. Penso che finirai per esaurire i soldi molto prima che tu abbia la stessa qualità.
3. L'esternalizzazione della responsabilità di correggere i bug di fornitori esterni è sicuramente un buon modo per far fallire il tuo progetto.