Come quantificare il lavoro svolto da uno sviluppatore / programmatore? [duplicare]

Non puoi misurare e non puoi quantificare. Dare queste idee dall'inizio. Peopleware fornisce informazioni dettagliate su come alcune persone offrono valore semplicemente facendo da catalizzatori per il resto della squadra. Queste persone non devono essere licenziate perché non producono linee di codice. Allo stesso modo, abbiamo lavorato tutti con sviluppatori che sfornano il lavoro ma sono così distruttivi per la squadra (attraverso l'atteggiamento o la negligenza) che la squadra sta meglio senza di loro.

Tu puoi quantificare il valore di un team, in base a quale funzionalità fornisce al business e a cosa l'azienda guadagna da esso. Ma questo dovrebbe essere fatto solo a livello di squadra.

Puoi anche confrontare il valore dello sviluppatore all'interno di un team. Ma non necessariamente nel modo in cui stai pensando. È tutta una questione di peer-review attraverso la creazione di opportunità di feedback regolari.

Inizia con riunioni stand-up ogni giorno. Uno sviluppatore dovrebbe sempre essere in grado di giustificare ad altri sviluppatori ciò che stavano facendo il giorno precedente. Per essere chiari, le riunioni stand-up non sono progettate per giustificare l'esistenza di uno sviluppatore. E se gli incontri si sentissero così, smetteranno di funzionare. Ma una riunione stand-up è uno strumento di feedback regolare e quindi, per sua natura, ti darà immediatamente suggerimenti sugli sviluppatori di problemi.

Cioè, a volte un rapporto stand-up sarà "Non ho ottenuto nulla perché ..." ma va bene, purché non lo sia tutti i giorni (anche se se lo è ogni giorno, vuoi considerare che gestione fallita prima di decidere che si tratta di un errore individuale.

Successivamente, inizia a fare riunioni 1-a-1 . Regolarmente, in modo affidabile, off-site e anonimo. Imparerai rapidamente se un individuo è un drenaggio della squadra o se un altro individuo è un vantaggio consistente.

Infine, esegui periodicamente 360 recensioni . Non commettere errori, questi sono difficili da ottenere. Deve essere anonimo e visto come anonimo; idealmente collazionata da una terza parte indipendente. Ma se lo fai bene, questo è quando inizierai a vedere un effettivo valore numerico di uno sviluppatore rispetto all'altro. E, forse più importante, del tuo valore come manager.

Lo misuri spendendo le ore necessarie per gestire il progetto.

Se aspetti fino a quando tutto è stato detto e fatto, non hai modo di estrarre statistiche dal prodotto finale. Non puoi nemmeno guardare gli artefatti del processo e misurare automaticamente i livelli di contribuzione senza ricorrere alle statistiche ingenue.

Man mano che i progressi vengono fatti durante il progetto, determini mentalmente chi sono i contributori forti e deboli. Regoli i loro carichi di lavoro per abbinare le loro abilità, punti di forza e punti deboli. Entro la fine del progetto avrai una buona idea delle classifiche relative di ciascuna parte del team di progetto in relazione al tuo progetto.

Tutte le misure che proponi sono ingenue e cattive, tuttavia alcune sono molto, molto peggio di altre.

In particolare, i primi tre sono pessimi, anzi, banalmente sovvertiti. Solo l'ultimo - funzionalità implementate - dovrebbe anche essere considerato in una decisione aziendale.

Ovviamente questa misura vive e muore per il modo in cui la "misura della funzionalità" viene mappata al valore commerciale effettivo. Questo è un grave problema, ma è uno che devi risolvere comunque! Qualcuno, da qualche parte, deve fare delle stime sul costo e il beneficio di una determinata funzione, storia, punto di funzione, qualunque cosa tu lo chiami, perché questo è l'unico modo ragionevole per decidere quale di loro fare e in quale ordine. Qualunque misura tu usi per prendere queste decisioni dovrebbe anche essere usata per valutare il valore aggiunto al business da parte di quelli che li implementano.

Lo scopo degli sviluppatori non è quello di "scrivere codice". Lo scopo di QUALSIASI ingegnere, che si tratti di ingegnere informatico, ingegnere civile o di qualsiasi altro problema, SOLVE PROBLEMI.

Pertanto, è possibile giudicare uno sviluppatore sul proprio lavoro, ma non in nessuno dei modi elencati (una specie di ...).

Il numero 4 è sulla strada giusta, ma non del tutto completo. Giudica gli sviluppatori su quanto bene:

1. Interagisci con i loro utenti aziendali / membri del team (se sei un'azienda abbastanza grande da avere un BA, quindi sostituisci gli utenti aziendali con quelli di BA)
2. Risolvi i problemi presentati a loro. Prendono una quantità eccessiva di tempo rispetto ad altri sviluppatori per risolvere problemi simili?
3. Estratto complesso di problemi fino a parti più piccole di lavoro e creazione di sub-attività significative, e quindi esecuzione su quelle sottoattività.
4. Aggiungi valore al business.

Come puoi vedere, non è facilmente quantificabile. Proprio come molte altre professioni, si tratta di concetti molto più nebulosi di "quanto codice scrivono".

Il conteggio delle chiamate confermate è la misura che utilizzo. Trovo che sia ragionevolmente affidabile. C'è una grande differenza tra un ragazzo che sta commettendo 15.000 linee all'anno e un altro che sta commettendo 3.000 linee l'anno, e un altro che sta commettendo 60.000 linee all'anno. Nel giorno in cui ho scritto un sacco di codice ho raggiunto il limite di circa 50.000 linee all'anno. I migliori programmatori che ho avuto esperienza personale fanno circa 200.000 linee all'anno. I ragazzi che lo fanno, i veri bruciatori, devono essere molto a testa bassa e sono difficili da trovare. Un ragazzo che conoscevo che era quel livello ora è un VP e guadagna $ 500.000 all'anno.

Devi anche tener conto degli spazi bianchi. Ci sono alcuni ragazzi che mettono ogni coppia su una propria linea, quindi devi moltiplicare per 0,8 per regolare tutto lo spazio bianco. In generale, però, è solo un tweaking. Di solito i bravi programmatori producono doppio o triplo o quadruplo quello che fanno i deboli, quindi gli spazi bianchi non contano molto sul lungo periodo.

Il primo anno in cui ho lavorato a tempo pieno come programmatore ho scritto un'applicazione MS Access DB. Mi ci è voluto tutto l'anno per scriverlo. Dopo che il tutto è stato scritto e completamente debugato e funzionante, ho fatto un conteggio delle righe. Erano 400 linee di codice. Al giorno d'oggi, potrei scrivere la stessa applicazione in un solo giorno. Ti dà un'idea della differenza di abilità. Al giorno d'oggi, se faccio tutto, come il Goole Code Jam o qualcosa che posso scrivere su 1000 linee di lavoro / debug al giorno, quindi in teoria potrei fare 250.000 righe all'anno se non avessi fatto altro che programmare. Ovviamente, passo tutto il mio tempo andando alle riunioni, scrivendo specifiche, vincendo nuovi affari e rispondendo a domande su SO, quindi faccio molto meno di quello.

A causa di quest'ultimo fattore, devi valutare ciò che la persona sta effettivamente facendo. Li hai spesi settimane a scrivere specifiche o file di aiuto? Questo colpirà il conteggio delle righe. Stanno parlando con i clienti o facendo offerte per affari. Idem. Il conteggio delle righe è principalmente una misura accurata per i ragazzi che codificano rigorosamente.

Si noti che è necessario tenere conto della fase in cui si trova il progetto. Se il progetto è nuovo, il conteggio delle righe sarà molto più alto di un vecchio progetto che viene sottoposto a debug. Inoltre, poiché i progetti diventano grandi e pelosi, il numero di linee diminuisce leggermente.

Troverai alcuni "manglers" là fuori che hanno l'idea che misurare con il numero di commit incoraggerà le persone a commettere il codice spazzatura, ma in pratica non è quello che succede. Chiunque commetta un sacco di spazzatura finisce con lo sprecare un sacco di tempo per il debug, quindi non guadagna nulla commettendo cose inutili. In generale, più un programmatore è produttivo, maggiore è la qualità del codice e, in effetti, deve essere. Se stai scrivendo 1000 righe al giorno, è meglio che tu stia bene o passerai molto tempo a fare il debug.

------ Postscript

Penso che sia piuttosto comico che la risposta numero uno dica che non c'è modo di quantificare la capacità di programmazione / produttività e quindi raccomanda di avere un sacco di incontri. LOL. La ciliegina sulla torta è che il ragazzo è di Londra, l'epicentro del mondo del programma per gli incontri.

Credo che dovrei modificare la mia risposta in qualche modo. Supponevo che quello che stavi cercando di fare fosse scrivere programmi per computer funzionanti. Se lavori per una grande, ricca società con diritto, dove l'obiettivo è di massimizzare l'occupazione, rendere il tuo governo felice, essere verde e avere un ambiente di lavoro salubre in cui tutti sono socievoli e gentili con tutti, quindi con tutti i mezzi hanno un sacco di incontri, questo è il segreto del successo. Misurare le persone è un male, potrebbe farle sentire inferiori, non può averlo.