Sembra un'idea terribile. Ecco alcune cose che accadranno, in aggiunta ai tuoi sviluppatori e tester che inizieranno a odiarsi a vicenda e te stesso per aver introdotto questo:

• Tutti si concentreranno sulla frutta a portata di mano . Ciò significa che il QA inizierà a segnalare tutti i tipi di cose che in realtà vanno bene, ma potrebbero essere interpretate come "buggy" nella speranza di essere pagati, mentre gli sviluppatori concentreranno tutto il loro lavoro sull'assicurarsi che non ci siano bug evidenti e molto meno sulla creazione certo che non ci sono bug strutturali complessi.
• Alcune persone si uniranno e uno sviluppatore introdurrà intenzionalmente un sacco di bug, quindi li invierà a un QA specifico per "trovarli", quindi dividerà i soldi.
• Alcuni dei tuoi dipendenti saranno insultati perché pensi che apprezzino il loro lavoro solo se ottengono un bonus per questo. Probabilmente lavoreranno meno duramente e produrranno più spazzatura per questo motivo.
• La comunicazione tra i membri del team si interromperà a causa dell'aumento dell'antagonismo. Ora è effettivamente un vantaggio per gli sviluppatori non aiutare il QA a svolgere meglio il proprio lavoro, perché qualsiasi bug che entra in produzione inosservato significa che vengono pagati di più
• Gli sviluppatori non si piaceranno a vicenda, perché ogni bug introdotto da uno sviluppatore costerà tutti loro denaro.

Questo è appena fuori dalla mia testa. Non cercare mai di motivare programmatori e QA con i soldi, risulta solo terribile. Il loro lavoro si basa su una motivazione intrinseca.

Inoltre, dai un'occhiata a questo TED-talk animato sulla spinta e la motivazione, poiché spiega molto meglio perché qualsiasi configurazione che coinvolge la motivazione di persone intelligenti con i soldi fallirà terribilmente:

https://www.youtube.com/watch?v=u6XAPnuFjJc

Ho letto un'idea per aumentare la produttività in un'azienda. È andata così:

Avere un certo fondo, sarà un bonus. Diciamo $ 100.000. Per ogni bug tangibile trovato, i tester vengono pagati $ 5 - $ 15. Tutto ciò che resta alla fine del mese / anno va agli sviluppatori.

Sembra un'idea abbastanza meravigliosa in teoria, anche se non sono sicuro di come funzionerà bene nella pratica . L'ovvia conseguenza di ciò è che promuove l'antagonismo tra sviluppatori e tester. Il bug business diventa un gioco a somma zero.

L'antagonismo è una brutta cosa? In che modo influirà sulla produttività e, soprattutto, sull'organizzazione? L'esperienza personale sarà molto apprezzata.

(Mi rabbrividisco quando leggo schemi "motivazionali" come questo.)

Forse l'autore di questa idea definisce la "produttività" in modo diverso di quanto farei.

L'obiettivo della maggior parte delle aziende produttrici di software è fare soldi e forse massimizzare la quantità di denaro che guadagnano. L'obiettivo di un sistema di bug bounty è meno chiaro e certamente non ha nulla a che fare con la produttività. Si spenderebbe molto tempo cercando di ottenere denaro bonus e poco tempo sarebbe speso cercando di spedire il software (che è il modo in cui l'azienda guadagna).

Immagina che un'azienda abbia uno sviluppatore e un tester .

Se tu fossi lo sviluppatore, la tua strategia ottimale sarebbe quella di trattenere tutto il software dal tester fino a quando non ci fossero più bug rimasti o fino a quando non ci fosse tempo nella pianificazione per il tester di trovarne .

Ho lavorato per un'azienda che premiava gli sviluppatori con elogi, piuttosto che denaro, e questa era esattamente la strategia utilizzata da uno sviluppatore. Le build venivano rilasciate al QA ogni 2 settimane. E ogni altro venerdì, abbiamo avuto una riunione del team completo in cui è stato annunciato il conteggio dei bug nella build corrente. Se uno sviluppatore avesse mai avuto zero bug, sarebbe stato scelto e lodato per aver svolto un ottimo lavoro.

Uno sviluppatore ha deciso di giocare con il sistema. Avrebbe tenuto la build (sempre con scuse ragionevoli) fino a poco prima della riunione settimanale. Ha quindi rilasciato la build, il rapporto sul conteggio dei bug è stato eseguito e "magicamente" ha avuto un conteggio dei bug pari a zero giusto in tempo per la riunione.

Sebbene fosse una brava sviluppatrice, il suo codice non era nessuno meglio della maggior parte degli altri. La sua abilità consisteva nel manipolare il sistema a suo vantaggio.

Attualmente lavoro in un negozio che punisce gli sviluppatori per il numero di bug attribuiti al loro lavoro durante un progetto. Ci si aspetta che "migliorino" il numero dei bug rispetto all'anno precedente. Questo fa parte dei loro MBO e parte di ciò che va al pagamento del bonus annuale.

Non sorprende che abbiano impiegato molto tempo per produrre la prima build verificabile per il QA. E hanno chiesto al QA di dedicare molto tempo ai test nell'ambiente di sviluppo (dove non è possibile scrivere rapporti sui bug). Hanno avuto tutte le possibilità di produrre meno bug nel sistema di segnalazione, e quindi di massimizzare il loro bonus.

Il Product Manager ha persino deciso di cambiare molte segnalazioni di bug in "richieste di miglioramento" in modo da non influire MBO per sviluppatori. La sua argomentazione era "beh, gli sviluppatori non hanno sviluppato completamente quella funzione, quindi la miglioreranno quando avranno tempo".

Se venissi pagato "dal bug" potrei trovare un sacco di bug abbastanza facilmente, non importa quanto sia bravo lo sviluppatore. (Faccio questo lavoro da quasi 30 anni). Inizialmente mi concentravo sul frutto a bassa pendenza e saltavo tutto ciò che richiedeva tempo. Le mie segnalazioni di bug sarebbero minime e non molto utili, praticamente tutto ciò che è necessario per inserire la segnalazione di bug nel sistema e ottenere i soldi.

Il risultato sarebbe un sacco di segnalazioni di bug superficiali che erano "solo abbastanza tangibili" e il software sarebbe inevitabilmente lasciato con alcuni bug critici importanti. Non riesco a immaginare che il sistema venga mai spedito.

Gli sviluppatori concentrerebbero tutto il loro tempo e la loro attenzione sul nuovo codice. Non ci sarebbe assolutamente alcun vantaggio finanziario nella correzione di eventuali bug già trovati. E sarebbero incentivati ​​a produrre pubblicazioni minuscole e insignificanti. Se producono una versione contenente solo una singola riga di codice perfetto, ottengono un bonus di $ 100k! Perché aggiungere funzionalità complicate?

Entrambi i team discutono con veemenza su ogni segnalazione di bug e se si tratta veramente di un bug "tangibile" o meno. (Questo è un termine carino e sfocato. Mi piacerebbe sentire un team che cerca di definirlo concretamente). Questo tipo di argomenti non pone le basi per qualcosa che chiamerei produttività.

E né i tester né gli sviluppatori spenderebbero tempo su nient'altro. Nessuna riunione, nessuna documentazione, nessun supporto clienti, nessun aiuto agli altri, nessuna preparazione per la spedizione. Ehi, se fosse importante, ci sarebbe stato denaro contante, giusto?

E quest'ultima parte è significativa. Per i lavoratori della conoscenza, spesso attribuire bonus in denaro a compiti che ritengono intrinsecamente importanti è un grande disincentivo. Se desideri una maggiore comprensione dei tipi di disfunzioni che possono derivare da questi tipi di sistemi di incentivi, ti consiglio vivamente di leggere Misurazione e gestione delle prestazioni nelle organizzazioni di Robert D. Austin.

In breve, questa è un'idea terribile.

La maggior parte delle buone società di software riconoscono la follia di un tale piano e cercano di stare alla larga da questo tipo di sistema. La maggior parte delle aziende di software comprende che il rilascio di software senza bug non è un obiettivo realistico e che è più importante rilasciare il software in modo tempestivo.

Questo ha tanto senso quanto avere l'equipaggio di una nave diviso in squadre, quelli che fanno propulsione e quelli che navigano, gareggiano in una gara, sulla stessa nave.

Mi rifiuto di avere una relazione antagonista con i miei tester. Li apprezzo. Mi rendono un programmatore migliore.

Rispetto anche la creatività che il loro lavoro richiede loro. Ecco perché penso che i soldi siano la motivazione sbagliata qui. Studi hanno dimostrato che, a meno che un lavoro non sia praticamente insensato, gli incentivi in ​​denaro in realtà, in modo misurabile, rallentano le persone.

Il lavoro creativo non è motivato al meglio dal denaro. Le sue migliori motivazioni sono:

autonomia - il desiderio di dirigere la nostra vita
padronanza - la voglia di migliorare, o sviluppare abilità
e scopo - la necessità di fare cosa facciamo per ragioni più importanti di noi

Esatto, le scelte, le opportunità di miglioramento e il lavoro di squadra funzionerebbero meglio del denaro.

Il controllo di qualità è un lavoro creativo. Il compito è proprio quello di pensare a ciò che gli sviluppatori non hanno pensato di. Questo è il motivo per cui il controllo qualità dovrebbe automatizzare. Una volta pensato un test, non dovrebbe essere "eseguito" ancora e ancora come uno spettacolo di Broadway. Dovrebbe essere automatizzato in modo che il QA possa smettere di pensarci e pensare al prossimo test. Il QA dovrebbe essere compilato con i tuoi sviluppatori più talentuosi. Perché stanno cercando di pensare all'altro tuo team di sviluppatori.

Alcuni non la pensano così. Alcuni pensano di QA come discarica per gli sviluppatori meno dotati. Se lo hai fatto, le tue priorità sono al contrario. Sfida i tuoi migliori sviluppatori a modernizzare i tuoi test e assicurati che le persone sappiano che il controllo qualità è dove dai il meglio.

Se quei soldi ti stanno ancora facendo un buco in tasca, usali per la formazione o, se necessario, licenziamento packages.

Qui non facciamo un lavoro insensato.

Avere un certo fondo, sarà un bonus. Diciamo $ 100.000. Per ogni bug tangibile trovato, i tester vengono pagati $ 5 - $ 15. Tutto ciò che resta alla fine del mese / anno va agli sviluppatori.

È orribile. Per tutti i motivi nelle altre risposte e per il fatto che non supera questo semplice test:

• E se tutti i tuoi dipendenti fossero fantastici e non venissero trovati bug?

  La produzione funziona perfettamente e tutto il denaro andrà al DEVS

• E se tutti i tuoi dipendenti facessero schifo?

  La produzione è appena bruciata il terreno a causa dei bug, ma hey, chi se ne frega, i soldi andranno al DEVS.

Anche se i soldi fossero una motivazione in la nostra attività, sarebbe orribilmente sbagliato.

Prendi i soldi e assumi qualcuno che sia davvero bravo a scrivere specifiche e pianificare progetti con scadenze gestibili. Sia DEV che QA saranno molto più felici di quanto i soldi potrebbero mai far loro.

Può essere apocrifo, ma mi è stato fornito un esempio simile negli anni '80 quando coprivo la "Legge delle conseguenze indesiderate" come parte di un corso BPR.

L'esempio riguardava una linea di produzione in fabbrica il reparto di controllo qualità era incentivato dal numero di scarti che producevano. Il reparto di produzione è stato ugualmente incentivato in base al numero di scarti che producevano.

L'effetto netto è stato che il controllo di qualità ha rifiutato più prodotti rispetto al passato e la produzione ha impiegato più tempo per produrre articoli "perfetti", quindi la produzione complessiva è diminuita mentre i costi sono aumentati per effetto degli incentivi. La qualità non è stata influenzata.

Funziona male. Non l'ho visto con sviluppatori e tester. Ma il dipartimento di giustizia in Nuova Zelanda a un certo punto ha premiato i guardiani della detenzione periodica per ogni detenuto che hanno violato. È passata da una violazione in una brutta settimana, ad alcuni detenuti che subiscono 6 violazioni in un giorno e finiscono in prigione per questo. Alla fine un guardiano si è fatto male.

Dubito che sarebbe andato così lontano poiché non è la stessa quantità e le persone meno volatili (penso), ma genera cattivo sangue tra i gruppi che sono già in disaccordo a causa ai loro ruoli.

Altre risposte hanno già sufficientemente affermato che la tua idea è cattiva TM. Quindi non lo ripeterò ulteriormente e menzionerò invece cosa dovresti cambiare per migliorare l'idea.

Stai cercando di allegare denaro a quello che alla fine è il numero su un foglio. Quel numero non creerà denaro. A peggiorare le cose, il numero che vuoi usare è per lo più casuale: un prodotto che non ha mai avuto bug all'improvviso ne ha 50, tutti errori di battitura nella documentazione. Un bug che altera il colore di evidenziazione di 200 elementi diventa 200 bug. Non appena chiedi ad alcune persone di aumentare magicamente il numero, quel numero è un numero immaginario completamente inutile. E per di più sprecherai decine di migliaia di dollari di stipendio con riunioni assolutamente inutili in cui le persone discutono cosa è e cosa non è un bug.

Se desideri allegare bonus o altri premi ai numeri su carta, questi numeri devono essere collegati direttamente al denaro effettivo guadagnato dalla società: un esempio comune è il bonus collegato al profitto in una società commerciale.

Come suggerito nei commenti "cupcake" sotto la tua domanda, alcune forme di ludicizzazione possono funzionare. Che ne dici di assegnare un trofeo per il "Miglior insetto" trovato durante un certo periodo, assegnato dai voti di entrambe le squadre insieme ?

In un ambiente di sviluppo sano c'è un "timore reverenziale" condiviso 'tra tester e sviluppatori su persone (di solito i tester) che trovano quei fastidiosi bug che possono essere riprodotti solo in determinate condizioni, su quel bug intermittente che ti ha tormentato per mesi, su qualcosa di molto semplice che uno sviluppatore ha trascurato, ecc. ^*

Il trofeo dovrebbe essere qualcosa di molto semplice, perché non riguarda il suo valore intrinseco: un piccolo segno, un cupcake, una tavoletta di cioccolato.

^{* L'ultimo esempio non riguarda la ricerca di un bug, ma la causa di un bug. In quel caso il premio significa scherzo amichevole. Hai bisogno di una cultura in cui i tuoi colleghi riconoscano che tutti commettono errori.}

Penso che il risultato sarebbe dannoso. È sia contro le pratiche di buon senso sia di sviluppo che di test.
Zero bug trovati non significa che il software sia buono. Potrebbe essere troppo complesso da testare o QA potrebbe saltare alcuni test.Anche zero bug trovati, processo di test completo e la grande qualità del codice non significa che il prodotto sia buono. Se i requisiti fossero incasinati, il software può essere terribile per il client.

Giocare contro quel sistema potrebbe essere estremamente facile.
Per sviluppatori: build recenti. Per tester: concentrazione su bug banali.
Con le build più recenti, il test iniziale è impossibile. Poco tempo per i test e la gratificazione per il numero di bug? I tester si concentrano su bug banali, come etichette con errori di ortografia o alcuni casi non critici.
Se vuoi sapere se il prodotto è buono, chiedi al tuo cliente.

Per farla breve. Sviluppatori e tester stanno lavorando sulla stessa barca: la tua azienda.

È facile criticare lo sviluppatore per un bug che producono, ma è difficile premiarlo per bug che non hanno prodotto.

Se il bug è arrivato alla build finale e il cliente lo ha segnalato, chi era la colpa? Sviluppatore per aver scritto il bug o tester per non averlo rilevato?

Questo causa la tensione tra sviluppatori e tester per impostazione predefinita. La tua idea mette una tensione aggiuntiva tra i due. Davvero non lo vuoi.

Se hai uno spazio di lavoro amichevole e vuoi ricompensare la cattura di bug dividere il budget a tutti in modo equo, fai un elenco di sviluppatori e per ogni bug lo sviluppatore pagherà $ 1 banca. Organizza la festa di Natale e usa la banca per premiare tutta la squadra. Assicurati che sia più divertente della ricompensa / punizione e che nessuno lo prenda (troppo) sul serio. Premia sia il "peggiore" che il "migliore" tra sviluppatori e tester.

Onestamente, l'incentivo nel migliore dei casi sembra inutile e nel peggiore dei casi dannoso. Se hai un team addetto al controllo qualità, hai già messo da parte dei fondi per trovare i bug in quanto ciò costituirà una parte importante della descrizione del loro lavoro. Non ci sarà molto antagonismo aggiunto tra i due poiché ci sarà di più verso la politica stessa. Se sei davvero preoccupato per il problema così tanto da buttare soldi ai tuoi attuali dipendenti con vincoli allegate, sarebbe meglio assumere qualcuno dove ne hai bisogno in QA o sviluppo.

Dove questo potrebbe davvero andare sbagliato è dal lato degli sviluppatori è che vedrai un calo dei rilasci per paura che vengano pagati meno a causa di nuovi bug e dal lato del controllo qualità potresti vedere fasi di revisione molto più lunghe a causa dei tester che vogliono una paga extra. Non sto dicendo che accadrà , ma solo che è una possibilità.

Nessuno vuole bug nel loro prodotto finale, ma succederà. In qualità di manager ci sono modi molto migliori per assicurarsi che esistano meno bug nel codice, ad esempio avere obiettivi e orari realistici e consentire la facilitazione per uno sviluppo migliore come le revisioni del codice.