Il mio capo ha deciso di aggiungere un campo "persona da incolpare" a ogni segnalazione di bug. Come posso convincerlo che è una cattiva idea?

Dì loro che questo è solo un nome amatoriale per il campo Root Cause usato dai professionisti (quando il tracker di problemi non ha campo dedicato, si possono usare commenti per questo).

Cerca nel Web qualcosa di simile a analisi della causa root dei bug del software , ci sono molte risorse per giustificare questo ragionamento ^{1 , 2 , 3 , 4 , ...} .

...a root cause for a defect is not always a single developer (which is the main point of this field)...

Questo è esattamente il motivo per cui "root cause" è professionale mentre "person to bame" è amatoriale. La responsabilità personale è grande, ma ci sono casi in cui si limita a "uscire" dal team di sviluppo.

Dì al tuo capo quando è un singolo sviluppatore da incolpare, il campo radice causa coprirà sicuramente l'errore di codifica ( "fatto da Bob nel commit 1234, perso da Jim nella recensione 567" ). Il punto di usare il termine root cause è di coprire casi del genere, lungo con casi che escono dall'ambito del team di sviluppo.

^{Ad esempio, se il bug è stato causato da hardware difettoso (con la persona da incolpare di essere qualcuno al di fuori del team che lo ha acquistato e testato), il campo causa principale consente di coprire quello, mentre "singolo sviluppatore dare la colpa "sarebbe semplicemente interrompere il monitoraggio dei problemi flusso.}

^{Lo stesso vale per altri bug causati da qualcuno al di fuori del team di sviluppo: errori del tester, modifica dei requisiti e decisioni di gestione. Supponiamo che, se la direzione decide di saltare gli investimenti nell'hardware di disaster recovery, "incolpare un singolo sviluppatore" per un'interruzione dell'elettricità nel datacenter non avrebbe proprio senso.}

Un altro risultato probabile per una tale politica è che le persone non segnalano bug se pensano che possano essere la "persona da incolpare", quindi in realtà ridurrà il numero di bug segnalati dal team.

L'argomento principale che userei contro di esso è quello di chiedere quale problema sta cercando di risolvere. Ci sono quasi sicuramente modi migliori per risolvere lo stesso problema.

Per prima cosa, c'è sempre una sola persona da incolpare? Se c'è, stai facendo qualcos'altro che non va. Un buon processo richiede un pezzo di lavoro attraverso un analista, un programmatore, un revisore e un tester prima che arrivi alla produzione. Se non stai facendo tutte queste fasi, forse questa è la soluzione al problema che il tuo capo sta cercando di risolvere. Se sei allora quale è la colpa? Potrebbe non essere nessuno di loro, potrebbe essere un codice legacy da incolpare.

Non è utile avere persone che mordono e puntano le dita, cercando di evitare un segno nero che non andrà via una volta impostato. Non risolve nulla. Pochissime persone sono malintenzionalmente negligenti. Devi fare una corretta retrospettiva , vedere cosa è andato storto e cosa puoi fare per assicurarti non va di nuovo male.

Da ciò vedrai chiaramente se una persona è regolarmente in colpa e questo potrebbe essere un problema diverso da affrontare.

Il trucco per fermare un manager impostato sulla creazione di responsabilità è offrirlo gratuitamente , ma in un modo che ha davvero senso per te.

Ci sono almeno tre problemi con quel campo.

Il primo è che incolpare le persone non fa bene al morale. Ok. Ma forse non gli importa del morale e vuole licenziare i cattivi sviluppatori. Difficile da discutere.

Il secondo è che ottenere quel campo giusto sarà difficile e un tempo piuttosto lungo. È più complesso che scoprire chi ha scritto il codice errato. E qualsiasi informazione potenzialmente difficile da capire può essere insabbiata / tradita. Ma forse è pronto a pagare quel costo e controllare le informazioni. Bene.

La questione più fondamentale è che questo campo non sarà una buona metrica su cui agire. Certo, avrà una buona classifica del cui codice causa il maggior numero di difetti. Ma indovina chi sarà in cima a quella lista? Probabilmente il fondatore dell'azienda, o forse uno sviluppatore che ha un tasso di difetti molto basso ma è così produttivo che scrive una porzione sproporzionata del codice. Così finirà per licenziare il suo miglior sviluppatore, o farlo rallentare così tanto da non essere più il suo miglior sviluppatore. E il tipo che scrive una riga di codice al mese - preferibilmente i commenti - verrà probabilmente premiato per i suoi numeri di difetto basso.

Ancora un altro errore di metrica del software.

La causa principale di un difetto in campo non è mai una singola persona. Le persone perfettamente coscienziose faranno errori e un processo che si aspetta che siano infallibili è irragionevole. Se non si stanno verificando le modifiche ai sistemi di produzione prima della distribuzione, manualmente o tramite test automatici, i bug sono inevitabili.

Sbagliato:

Bob forget to check input and the program crashed dividing by zero.

A destra:

Code vulnerable to a divide by zero error was not detected before deployment. New test cases have been added to verify proper handling of invalid input. Code was corrected and all new test cases are passing.

Cambia "Persona da incolpare" in "Persona da elogiare"

La persona principale per risolvere i bug prende il loro nome.

Risposta semplice.

Il campo "Blame" sarà utilizzato solo per capri espiatori e fingerpoint, il morale precipiterà, la fiducia della squadra sarà distrutta e tutti cercheranno di trovare modi per dimostrare che qualcosa non è colpa loro invece di risolverlo. Le persone saranno anche più inclini a tacere sui bug invece di segnalarli, perché non vogliono che un collega si metta nei guai. È completamente controproducente.

Cosa è più importante, vittimizzare qualcuno per commettere un errore onesto o risolvere il problema il più rapidamente possibile?

Il tuo capo sembra pensare che gli insetti siano un segno di pigrizia o sciatteria. Loro non sono. Sono un dato di fatto. Quante patch Microsoft spinge in un anno?

Se sei pronto per una piccola disobbedienza civile, fai in modo che la squadra accetti di mettere un elenco di tutti gli sviluppatori in quel campo per ogni bug. Se non ti va, scrivi "I'm Spartacus!" anziché. Il punto, ovviamente, è che tu sei il responsabile di tutti i bug e non sei contento di dover indicare l'individuo che ha creato un bug.

Un'altra opzione: giocare insieme. Non fare nulla in particolare: basta fare un buon lavoro e compilare il campo il più accuratamente possibile per alcuni mesi. Quindi spiega al capo che assegnare la colpa a ciascun bug rende tutti i membri della squadra infelici e a disagio. Digli che tutti voi sentite che c'è poca correlazione tra bug creati e qualsiasi altra cosa (abilità, sforzo, sanità mentale). (Sarà d'aiuto se puoi eseguire alcuni numeri che mostrano che non c'è davvero una correlazione.)

Gandhian Civil Disobedience: metti il tuo nome su ogni campo (a meno che altri sviluppatori non facciano il passo e metti il loro nome per i loro bug) e accetti la colpa di ogni bug, che sia tuo o meno. Niente renderà quel campo o l'idea di incolpare qualcuno più inutile di questo. Se il tuo capo ti chiede perché è il tuo nome su ogni campo, allora puoi spiegare "perché non penso che lo sviluppo sia un gioco di biasimo, se hai veramente bisogno di persone da incolpare e crocifiggere, poi crocifigami per tutto e lascia che la mia squadra lavori pacificamente ".

Una volta un capo aveva implementato un sistema molto simile a questo, e sebbene non fosse una programmazione (era un progetto di stampa per un quotidiano) il concetto e la risposta appropriata sono gli stessi.

Quello che ha fatto è stato invece di aggiungere un campo "persona da incolpare" sui nostri documenti, dando a ciascuno dei designer una serie di adesivi colorati. Ogni designer ha ricevuto un adesivo colorato diverso ed è stato indicato che per qualsiasi disegno lavorato o anche toccato l'adesivo deve essere aggiunto al lavoro di quel progetto.

L'obiettivo dichiarato dal capo per "l'iniziativa sulle vignette" era quello di stabilire la fonte di tutti gli errori del nostro dipartimento (errori nelle pratiche burocratiche, disallineamenti, cattiva copia, essenzialmente l'equivalente nella stampa dei bug)

Ciò che abbiamo fatto è stato dare ad ognuno degli altri designer un quarto dei nostri adesivi in modo che ognuno di noi avesse tutti i colori, e invece di mettere solo il nostro colore su ogni disegno abbiamo messo tutti e quattro i colori dei designer.

Non scrivere semplicemente il tuo nome nella casella [Blame] - inserisci il nome di tutti quelli che fanno parte del team / progetto e assicurati che tutto il team faccia lo stesso.

Abbiamo lavorato insieme contro la sua cattiveria orwelliana e di conseguenza abbiamo finito per coglierci gli errori degli altri e parlarci a vicenda e alla fine abbiamo avuto una significativa riduzione degli errori. Era una manager di riserva, e invece di riconoscere che la sua iniziativa ha finito per unirci e aumentare la produttività, ha fatto tutto il male e ha sciolto il sistema di adesivi, dichiarandolo un fallimento e rimproverato formalmente a tutti noi.

Finirà col punire il suo programmatore più prolifico. Le probabilità sono, una o due persone potrebbero essere i migliori dipendenti che hanno lavorato alla maggior parte dei progetti. Se hai, in un dipartimento di 10 persone, un programmatore che è solo una fonte di output e ha scritto il 60% del codice dell'interfaccia, allora il 60% dei bug sarà nel suo codice.

Spiega che questo sistema potrebbe far sembrare che la persona che scrive più codice sia il peggiore programmatore e la persona che scrive il codice meno adatto è il miglior programmatore.

Questo suona molto quando Scott Adams ha sottolineato la saggezza fallita di un Bug Bounty quando il Boss dai capelli a punta in Dilbert. Wally ha annunciato che sarebbe andato a "scrivergli un nuovo Mini Van".

fumetto di Dilbert per il 13/11/1995 dall'archivio ufficiale dei fumetti di Dilbert.

Ricordo una volta quando Snow Skiing che qualcuno ha sottolineato che "non cadere" non era il segno di un buon sciatore, ma spesso il segno di uno che non provava nulla (o non sciava affatto).

I bug possono essere introdotti nel codice con una programmazione scadente e un design scarso; ma, possono anche venire come conseguenza della scrittura di un sacco di codice difficile. Dinging persone che producono il maggior numero di bug è probabile che Ding poveri sviluppatori siano altamente produttivi.

Sembra che il tuo capo possa essere frustrato dal numero di difetti. Le persone del tuo gruppo sono appassionate di qualità? Creare un campo "cosa" per la causa piuttosto che un campo "chi" potrebbe essere più produttivo. Es: Modifica dei requisiti, difetto di progettazione, difetto di implementazione, ecc. Anche questo non funzionerà a meno che non ci sia un gruppo in entrata per migliorare la qualità del prodotto.

Forse dovresti considerarlo come "Chi è nella posizione migliore per correggere l'errore?" Anche una parte di me si sente, l'hai rotto, lo aggiusti. Ci dovrebbe essere una certa responsabilità.

Non sono d'accordo con il mantenimento di una sorta di punteggio. Alcune persone creano più bug perché lavorano su parti più complesse del codice. Se le righe di codice non sono una metrica utile, dubito che i bug per linee di codice siano migliori. Il codice non verrà mai archiviato.

A un certo punto un manager dovrebbe sapere chi sta facendo il proprio lavoro e chi no, e chi lo fa meglio perché lo fa il resto della squadra.

È strano che nessuno ne abbia parlato prima: L'aggiunta di tale funzionalità al bug tracker stimolerebbe i dipendenti a provare a giocare al sistema .

Questo è un problema comune per approcci come quello che la domanda ha presentato, tra le altre idee simili (pagando per numero di linee di codice, pagando per numero di bug). Questo incoraggerà molti a concentrarsi sull'ottenere un buon punteggio, invece di risolvere i problemi relativi al software su cui stanno lavorando.

Ad esempio, provare a inviare una segnalazione di bug con una dicitura per ridurre la propria colpa e ficcarla su qualcun altro può portare gli sviluppatori a fraintendere la causa del problema (o il lavoro che viene dato a un altro sviluppatore che non conosce quella sezione di un codice buono come quello che ci lavorava di più e che era la causa principale del bug) portava a più tempo e sforzi per risolvere il problema.

La tua vera domanda era su come cambiare la cultura prima di lasciare la compagnia, convincendo il tuo capo che aggiungere una persona al campo della colpa per segnalazioni di bug è una cattiva idea. Ma ovviamente cambiare la cultura richiede che comprenda veramente perché questa è una cattiva idea.

Questo è un alto ordine. Oltre al problema di salvare la faccia dopo aver cambiato idea, c'è il problema di base che le persone che pensano alle soluzioni principalmente in termini di colpa individuale sono di solito piuttosto fissate in quella mentalità.

Hai chiesto di scrivere su questo argomento e vengono in mente Peopleware . È molto apprezzato e parla in termini generali su come gestire le persone che fanno lavori creativi in cui l'output è difficile da misurare. Il problema è che leggendo non sarà di grande aiuto, il tuo capo dovrebbe leggerlo e crederci almeno in parte.

Stranamente, dal momento che il problema qui riguarda più le persone che le segnalazioni di bug, molto probabilmente appartiene più a Workplace che ai programmatori. Ma il successo dei progetti software è solitamente piuttosto riconducibile all'interazione sociale umana, quindi le risposte reali spesso riguardano principalmente cose che trascendono il software.

La mia unica altra, semiseria, è di dire (o convincere un collaboratore a dire, visto che hai intenzione di andartene) che tu sei disposto ad assumerti la piena responsabilità per il successo del progetto e il tuo nome dovrebbe sempre andare sul campo, poiché anche se qualcun altro ha commesso l'errore direttamente, ti sei assunto la responsabilità di assicurarti che tutti i membri del team lavorino in modo soddisfacente.

Ovviamente è assurdo, come hai potuto mai fare un back up, ma alcune persone (specialmente le persone che hanno una grande colpa) mangiano davvero quella roba. Ronald Reagan era solito accettare pubblicamente la responsabilità personale ogni volta che un membro della sua amministrazione veniva coinvolto in uno scandalo (e ce ne sono stati parecchi) e in effetti ogni volta funzionava in modo abbastanza buono politicamente. La parte migliore per te è che la responsabilità generalmente non ha conseguenze effettive, pensano solo che sei un ragazzo in piedi per assumerti la responsabilità.

O forse non è così che andrà giù. Non ha alcun senso per me quindi è difficile per me prevedere quando funzionerà, ma ho visto che funziona quando sembrava che non ci fosse alcuna attività in tal senso (sul posto di lavoro, non solo sull'esempio di Reagan).

Le persone non vanno al lavoro intenzionate a commettere errori, e qualsiasi strategia messa in atto, per attribuire specificatamente la colpa a ciò che può o non può essere stato un errore umano è ridicola - per non dire estremamente poco professionale.

Per lo meno, una "parte responsabile" incaricata di prendere in carico e "risolvere" il problema, o elaborare un piano per tracciare e / o impedire che si verifichino eventi simili, sarebbe positivo. A volte la soluzione non è altro che una formazione aggiuntiva. Ho lavorato per un certo numero di aziende in cui faceva parte della descrizione del tuo lavoro, per ottenere una formazione "azienda pagata / orario aziendale". In un luogo è stato persino costruito un intero "centro di formazione", che il college locale "prende in prestito" a volte, per i loro corsi sulle tecnologie industriali.

Ho lavorato in un ambiente di produzione negli ultimi 20 anni, dove gli errori di programmazione non causano solo errori, distruggono fisicamente le cose e / o, peggio, fanno ferire le persone. Tuttavia, una costante in ogni settore manifatturiero che è strong, è che non c'è mai, in nessuna circostanza, qualcuno da incolpare. Perché è un difetto nel sistema, chiaro e semplice - non un difetto nelle persone. Osservala in questo modo - l'uso del correttore ortografico - uno strumento molto efficace, per coloro che sono meno fortunati nel campo del virtuosismo testuale, o forse solo quelli un po 'sopraffatti ... ma in nessun modo un metodo di biasimo o di responsabilità.

Un ambiente di lavoro, indipendentemente dal tipo, o per quale scopo serve, è un sistema. Un sistema composto da singoli componenti, che se correttamente "accordati", lavora in totale armonia - o una parvenza di tale tipo.

Lettura suggerita sulla parte del tuo capo: Le 7 abitudini di persone estremamente efficaci

Sembra che potrebbe usare un po 'di umiltà, se non un controllo di realtà. È parte della squadra, come tutti gli altri, e ha bisogno di rendersene conto - o semplicemente non funzionerà, e alla fine, terrà la borsa a prescindere.

Lettura e / o ricerca suggerite da parte tua:

Cerca in 5 perché analisi, analisi delle cause principali ... tutto ciò che ti mette in una posizione migliore per offrire una soluzione, non un problema . E il tuo disaccordo con il tuo capo, è solo questo, un problema, non una soluzione. Offrigli qualcosa di meglio, qualcosa che abbia senso, e sia anche pronto a permettergli di prendersi il merito dell'idea.

In questo momento non sembra che sia disposto a sistemare qualsiasi cosa, perché non ha una chiara comprensione di ciò che è rotto, se c'è qualcosa di rotto - oltre alla sua mentalità "I'm the boss" .

Buona fortuna! Spero tu riesca a superare questo, in un modo che è accettabile per tutti, specialmente in questi tempi.

EDIT: Personalmente, dalla mia esperienza personale ... "Vai avanti, dai la colpa a me, perché, abbastanza sicuro, lo aggiusterò, e in fondo alla strada, quando accadrà di nuovo, chi sarà lì per salvare la giornata? sì, hai indovinato ... io, con un gran sorriso oleoso. "

Per responsabilità non vorrei un campo person to blame , vorrei un campo Person who knows the code o un campo person who can fix , in modo che io sapessi dove inviare il ticket di supporto.

Ciò velocizzerebbe il processo risolvendo il bug stesso e dando responsabilità, un po 'come uccidere due piccioni con una fava. Lo consegnerei personalmente a lui e gli permetterò di decidere se ciò contribuirebbe ad aumentare il morale e la responsabilità senza far sentire nessuno come se fallisse. I test estremi non catturano tutti i bug, altrimenti non ci sarebbero segnalazioni di bug.

Digli che "la colpa" è negativa. Cambialo in "persona da aggiustare", ma almeno è inquadrato in maniera positiva, e lo stesso lavoro viene comunque fatto. Come possono le persone lavorare se vengono "incolpati" ?!

Se il mio capo avesse fatto ciò, sarebbe accaduto quanto segue, in questo preciso ordine:

1) Vorrei iniziare immediatamente a cercare un nuovo lavoro.

2) Ogni volta che viene segnalato un bug a una persona da incolpare, il nome del mio capo appare lì, e un commento sul motivo per cui una cattiva procedura nel team ne è responsabile. E CC quello al suo capo (preferibilmente in un lotto). Hai dei test unitari? In caso contrario, significa che il processo di sviluppo è rotto, quindi il bug. Disponi di test di integrazione automatici costanti con tutti i sistemi esterni? Quindi il processo di sviluppo è rotto, quindi il bug. Hai la capacità di rendere ogni ambiente identico nella produzione tramite script per non consentire l'errore umano? Quindi il processo di sviluppo è rotto, quindi il bug. Uno sviluppatore è terribile? Quindi il criterio di assunzione è cattivo quindi la colpa del boss. Tutti gli sviluppatori commettono errori stupidi a causa della mancanza di riposo perché lavorano 12 ore al giorno? Quindi il processo di sviluppo è rotto. Come puoi vedere il 100% dei bug è colpa del boss.

Come nota a margine: ogni buon manager di sviluppo è a conoscenza di ciò che ho scritto sopra. E le strategie Agile hanno lo scopo di indicare al boss o ai suoi supperitori perché dev sta rallentando: guarda, stiamo spendendo il 50% del nostro tempo per correggere i bug. Osserviamo le strategie per ridurle in modo che possiamo dedicare il 40% del tempo a correggere i bug, e quindi rivisitare questo problema portandolo al 30%. ecc.

Sfortunatamente sembra che tu non abbia un buon manager a causa del campo. Quindi suggerisco di fare (1) e non di portarlo al manager (eccetto il tuo colloquio di uscita)

Sembra che il tuo capo non abbia una profonda conoscenza del software e forse nemmeno lui lo intende. Quindi ha una lingua diversa, una cultura diversa.

Smettere un lavoro per un problema come questo, prima ancora di provare a fare un passo avanti per una soluzione è solo essere un quitter. Smettere è smettere. Non smettere fino a quando non ti farà sicuro che non ti capirai mai. Per essere sicuri, dovresti prima provare.

Dato che non conosce la nostra lingua, ed è il capo, il primo passo qui sarebbe cercare di parlargli nella sua lingua. Cosa intendo con il linguaggio? Pensiamo insieme:

Noi persone del software, la maggior parte di noi ama il lavoro che facciamo, abbiamo una profonda connessione con quello che stiamo facendo. Altrimenti non funziona e non si può continuare a lungo in questo business senza amarlo o essere completi ... si riempiono gli spazi vuoti ...

Tuttavia, vede le cose in modo molto diverso. Con ogni segnalazione di bug, mentre la maggior parte di noi si entusiasma di far funzionare meglio la cosa (no, anche se a volte è davvero molto stressante, amiamo i problemi, ammettiamolo!), La vede come un fallimento, una misura dell'essere senza esito. La prima cosa che dovrebbe capire è che i bug sono buoni. Bugs fa sì che i clienti amino la compagnia. (Ora questa è la sua lingua) Quando un cliente segnala un bug o quando ne troviamo uno, dopo che è stato risolto, è molto meglio della situazione che non è mai successo. I bug creano la fedeltà dei clienti (sono serio!), I bug creano un'ottima scusa per la comunicazione tra il consumatore e il produttore del software.

Per "aumentare il profitto dei bug" dovresti offrire una segnalazione dei bug ancora più aperta. Con ogni bug report e la sua soluzione rapida, pulita, buona, i clienti sentono e vedono che "wow, questi ragazzi sono fantastici! Funzionano davvero duramente." Guarda queste cose che stanno risolvendo. Non eravamo nemmeno consapevoli che il software fosse così complesso cosa!" blah blah e blah ...

Fai la tua mossa, parla nella sua lingua. I bug sono grandi per un'azienda di software, non un problema. Ci fanno vivere.

Per l'etica del team, l'efficienza o qualsiasi tipo di conversazione che potresti fare potrebbe funzionare nel modo opposto che intendevi. Se vuoi smettere, penserà "aha, la mia soluzione ha iniziato a funzionare fin dal primo giorno! I link errati hanno già iniziato a cadere da soli prima che vengano scoperti!" Crede nella sua idea di trovare i cattivi ragazzi in compagnia ed è molto difficile convincerlo del contrario. Soprattutto quando potresti essere uno di quei ragazzacci!

Quindi concentrati sul suo vero problema: Bugs. Dimostragli che i bug possono essere molto utili. Senza problemi, una relazione è noiosa. Tutto ciò che non ti uccide ti rende più strong. Ogni bug è una grande opportunità che puoi utilizzare per aumentare la felicità del cliente.

Questa è solo una cosa che puoi dire. Pensa alle sue preoccupazioni e troverai molti altri articoli da aggiungere alla tua lista. The GOLDEN KEY è di offrire una cosa alternativa invece di combattere con la sua idea!

Se stai facendo Agile, sembra che tu sia dal commento caratteristiche / storie . La persona da incolpare sarebbe la persona che controlla il QA che ha lasciato scivolare il bug, oppure il proprietario del prodotto / cliente che ha accettato la funzionalità / storia completa del bug in esso contenuto.

Ho fatto il tipografo nel corso della giornata, ecco la mia versione.

This is like blaming a typesetter for misspellings and other things that a proofreader should have found but missed. The typesetter made the misspelling, but the proofreader missed it, so it is the proofreader to blame for the mistake making to print, not the person that made the error in the first place.

In un ambiente Agile è responsabilità del personale di controllo qualità rilevare errori (bug) ed è responsabilità del proprietario del prodotto non accettare le cose che non sono corrette. Si tratta di due livelli di lettori di prove che dovrebbero isolare gli sviluppatori dalle cose che vengono rilasciate, che è l'unico modo in cui qualsiasi cosa dovrebbe essere classificata come un bug in un ambiente Agile.

Penso che il tuo manager stia cercando di risolvere un problema con la soluzione sbagliata. Penso che forse c'è un problema che vengono rilasciati troppi bug e il tuo manager vuole che gli sviluppatori assumano più responsabilità e responsabilità nei confronti del codice che scrivono.

L'utilizzo dello sviluppo basato su test e l'impostazione di un server di integrazione continuo (come Jenkins ) aiuterà a risolvere questo problema, senza introdurre il " scaricabarile". Un server di integrazione continua è importante per questo perché quando qualcuno commette un codice che "interrompe la build", una e-mail viene inviata al team che mostra la persona da incolpare. Poiché questo codice non è stato rilasciato in un ambiente di produzione, questo tipo di colpa è più proattivo e incoraggiante (e divertente!).

Il risultato è che gli sviluppatori avranno più proprietà, si sentiranno più sicuri e ci saranno meno errori nel codice di produzione.

Fai notare che se l'errore di una singola persona causa la fine di un bug in produzione, allora c'è qualcosa di sbagliato nella tua metodologia, o nel tuo modo complessivo di sviluppare software. Fai notare che impedire agli insetti di arrivare alla produzione è responsabilità dell'intero team.

Usando uno di questi due argomenti, vedi se riesci a convincere il tuo capo che avere il campo "chi dare la colpa" come un campo di selezione singola sarebbe fuorviante; e quindi, è necessario assicurarsi che il campo "chi dare la colpa" sia un campo di selezione multipla. Una volta raggiunto questo, assicurati che per ogni bug, il nome di tutti sia sul campo. Il tuo capo alla fine vedrà che qualsiasi segnalazione sul campo è inutile.

Per dare qualche credito al capo, il concetto di "assegnazione della colpa" è già covato in strumenti come SVN e l'uso appropriato dei dati può essere costruttivo per gli sviluppatori in "scoprire chi parlare" durante il debug, ad esempio: link

Anche se sono d'accordo con la risposta di gnat sopra che un campo Root Cause è una buona cosa, questa non è la stessa informazione e "denormalizza" il campo per assegnare a volte il nome dello sviluppatore precedente ) per la fonte interessata, e a volte hanno una descrizione tecnica (ad es. "non ha scalato fino a 10000 utenti") infangheranno solo le acque. Sostengo che mantenere un campo Root Cause chiaramente una descrizione tecnica (ad esempio, anche in caso di errore chiaro del programmatore, è necessario catturare dettagli come "IndexOutOfRange Exception when fooData = 999"). feedback utili quando vengono esaminati in massa e consentono di intraprendere alcune azioni correttive per risolvere intere classi di problemi con modifiche architetturali o strutturali (ad esempio, miglioramento delle classi contenitore personalizzate, gestione delle eccezioni di livello superiore)

Detto questo, l'aggiunta di un campo Person To Blame può chiaramente inviare un messaggio e un messaggio distruttivo a un team di software che la gestione vuole individuare e punire i singoli sviluppatori che interrompono il codice più spesso. Sospetto che il manager creda che questo esame pubblico farà sì che gli sviluppatori siano più attenti e autoregolamentati per evitare di ottenere il loro nome su questo "muro della vergogna", e non capisce perché gli sviluppatori si sentano minacciati da questo, specialmente se viene aggiunto genericamente a ogni segnalazione di bug.

I problemi con l'aggiunta di questo come un campo bug / potenziale metrica sono facili da iniziare a enumerare:

1. I bug sono altamente variabili in difficoltà da risolvere e una semplice statistica di conteggio degli errori / sviluppatore non riflette questo.
2. Gli sviluppatori hanno capacità molto variabili "" "" "" "" "" "
3. Molti sistemi software hanno componenti che necessitano di refactoring, tuttavia il refactoring dei componenti legacy (in particolare se la base legacy non dispone di funzionalità di test unità limitate) introdurrà inizialmente bug. Gli sviluppatori sono probabilmente scoraggiati da questa "buona" attività, se c'è uno stigma / paura associato alla generazione di nuovi bug (anche se questi sono banali da risolvere e il risultato finale è un notevole miglioramento nel sistema.)
4. I tester possono archiviare un numero altamente variabile di bug relativi allo stesso problema, con conseguente conteggio / sviluppatore di bug altamente distorto, a meno che non venga eseguita un'analisi più dettagliata.

Questa è solo la punta dell'iceberg. Combinateli con il dito puntato su chi si aspettava quale comportamento dell'API, risultati attesi errati nei test e problemi "precedenti nella catena" con requisiti errati / mancanti, e dovrebbe essere ovvio che una metrica come questa è condannata come senza valore (a meno che l'obiettivo è danneggiare il morale e causare un esodo di massa.)

Tornando al punto di vista del boss, va bene che lui / lei voglia scoprire se ci sono sviluppatori che interrompono il codice ripetutamente e provare a fare qualcosa (si spera costruttivo) a riguardo. Cercare di ottenere queste informazioni aggiungendo un campo alle segnalazioni di bug non fornirà informazioni significative per i motivi sopra elencati. Secondo la mia esperienza, questa informazione può essere appresa collegandosi al team, partecipando alla maggior parte delle riunioni del team, integrando (accuratamente) le informazioni apprese in riunioni individuali occasionali con i membri del team e familiarizzando con i sottosistemi in il codice (anche se non possono leggere il codice.)

Lascia perdere. Il tuo capo scoprirà da solo che causa un problema, se lo fa.

Sia chiaro, hai un'opinione e anche lui. È il tuo manager e la sua opinione è quella che vince.

Sì, puoi andare in guerra per questo problema, ma ne vale davvero la pena? Dubito che duri più di 3 mesi prima che cada in disuso.

Ma il sabotaggio attivo di questo o il suo urlare sfruttano solo il capitale politico che viene salvato meglio per chiedere quel tempo extra, il prossimo rialzo, la promozione o quando verrà presa una decisione progettuale davvero critica.

In quel momento, quando conta davvero, non vuoi che il capo ricordi che tu eri la persona che ha attivamente sabotato la sua idea di "persona da incolpare".

Rispetta l'ufficio anche se non rispetti la decisione.

Salva lo stress e la tabella che martellano per decisioni che saranno molto più durature.

Spiega al tuo capo che lo sviluppo in una squadra richiede abilità sociali. Potrebbe anche annuire.

Ma il problema è che questo è qualcosa di estremamente negativo per gli sviluppatori. Aggiungere strumenti che suggeriscono di incolpare è più importante di un'adeguata analisi dei problemi è controproducente.

Invece hai bisogno di incentivi per migliorare le abilità sociali e l'infrastruttura di comunicazione che devi supportare. Ad esempio, valuta positivamente: nomina una persona responsabile di un ticket, che si occupa di esso.

Inizia anche con le revisioni del codice in modo da poter imparare l'una dall'altra. Che in seguito accusa le accuse.

Mandagli una email con questa domanda SO. Se è aperto alla ragione, i commenti qui forniranno controlli di sanità per il suo ragionamento. Se non è ragionevole, è improbabile che lo convinca con ragioni che hanno un senso. Inoltre, sarà in grado di leggere le ragioni al di fuori di una conversazione (che a volte può essere più convincente a causa della motivazione rimossa per "avere ragione" nel calore di una conversazione).

Potresti anche provare a girarlo. Il campo potrebbe essere "possibili passi per evitare che si verifichi un errore simile" o qualcosa di più breve in tal senso. Quindi potresti mettere insieme le soluzioni e votare su quali implementare per migliorare il tuo ambiente di lavoro. Forse un approccio orientato alla soluzione è più produttivo e probabilmente meglio accolto (a patto che ci sia un reale follow-up sulla rivisitazione dei suggerimenti).

Vedo due possibilità qui: vuole essere in grado di punire le persone che commettono errori, o semplicemente non ci ha pensato fino in fondo. Fategli sapere che la percezione di tutti sarà che intende punire coloro che commettono errori. Chiedigli se questa è la cultura che vuole incoraggiare.

il mio capo ha deciso che aggiungere un campo "Person To Blame" al nostro modello di tracciamento dei bug aumenterà la responsabilità

Nella mia esperienza, quando la direzione vuole "rendere le persone più responsabili", ciò che intendono è che vogliono essere in grado di esigere la punizione per il fallimento. Che si tratti di licenziare i musicisti poveri o semplicemente lasciarli ammorbidire nella revisione annuale delle retribuzioni ("Scusa, Bob, hai avuto 17 bug segnalati come tua colpa, e questo è oltre il limite di 15"), è una punizione.

Probabilmente dirà "Oh, no, non lo vogliamo", quindi chiedigli come saranno utilizzati i dati. Ricordagli che non aggiungi punti dati a un database a meno che non lo userai. Vuole o selezionare su un determinato criterio ("Mostrami tutti i bug aperti nel sottosistema del creatore del report"), in modo che tu possa lavorare sulle cose o essere in grado di ottenere dati aggregati ("Quale sottosistema ha avuto il maggior numero di bug "), in modo da poter eseguire analisi post-mortem. Prevede una sorta di tote board of failure in cui le persone possono essere umiliate pubblicamente?

Quindi, quale intende? Vuole essere in grado di dire "Mostrami tutti i bug che sono colpa di Bob?" Perché? O vuole essere in grado di dire "Mostrami chi è la colpa per la maggior parte del tempo?" Perché? Il primo non è significativo, e il secondo è solo punitivo. Oppure la terza opzione è che non ha una vera ragione.

Ammetto che c'è la possibilità che lui possa cercare quei programmatori del team che hanno bisogno di aiuto per migliorare le loro capacità. In tal caso, esistono modi migliori per acquisire queste informazioni che non creano una cultura di puntamento del dito.

Credo che l'aspetto chiave da osservare qui è quanto sia aperta la comunicazione nella squadra verso il "capo" e viceversa. Puntare il dito non è mai un bene, tuttavia, dal punto di vista gestionale, se uno dei tuoi sviluppatori cade nello stesso problema più volte, potrebbe essere il momento di intervenire e cercare di aiutarlo a superare questo problema ripetitivo (ad esempio, John non sta testando correttamente il codice: 3 bug di produzione negli ultimi 3 mesi, diamo una lista di controllo in modo che si ricordi come dovrebbe essere il suo codice e come dovrebbe testarlo).

Da un punto di vista dello sviluppo, la "colpa" è già incorporata in uno strumento mainstream come SVN, quindi non vedo alcun danno nell'andare "John, per favore aggiusta quel pezzo di merda che hai scritto" e mettendo un nome accanto ad esso. JIRA incorpora anche il nome di una persona quando scrivi un bug (tuttavia il campo non è pensato per la persona che ne è responsabile, è piuttosto così che qualcuno lo aggiusta).

Ecco però la cosa, come molti hanno già detto in precedenza, se si verifica un errore, è una responsabilità condivisa: dallo sviluppatore, ai tester, al controllo qualità, ai manager. Se il tuo capo a un certo punto gestisce un cliente arrabbiato al telefono con cose come " mi dispiace tanto, John non l'ha mai testato correttamente ", quindi sicuramente sarei alla ricerca di un altro lavoro. Un buon capo dovrebbe andare "ci penseremo noi". Nessun nome, nessun dito, solo soluzioni.

Ancora una volta, credo che sia tutto basato sulla comunicazione. Forse l'unica cosa che il tuo capo vuole fare è vedere chi ha problemi nella squadra di sviluppo, o che tipo di problemi ha la squadra (forse per le sessioni di allenamento?), Ma non penso che scoprirai esattamente cosa c'è dietro il suo team decisione (o meglio, noi poster / lettori) a meno che non parli con il tuo capo e tutta la tua squadra.