KPI per programmatori [duplicato]

Considera la seguente verità: otterrai esattamente ciò che misurerai e monitorerai. Con questo in mente:

Cose terribili su misura

Linee di codice - Il codice elegante ha una natura concisa. Le linee di codice incoraggiano il bloat, il copia e incolla o, ancora peggio, il codice per motivi di codice.

Time-to-solution: il codice fatto rapidamente contiene molti bug.

Correzioni di bug - Questo va con "time to solution". Non premiare i programmatori per la scrittura di codice slopping, e soprattutto non li premiare per aver risolto i problemi che hanno causato in primo luogo!

Che cosa, IMHO, dovresti misurare

Impact. L'unica cosa che conta è ciò che i tuoi sviluppatori fanno . Hai scritto uno strumento che migliora l'efficienza del 10%? Che dire dell'automazione di un'attività che richiedeva 3 ore? Che dire del refactoring di quella libreria gnarly, quindi ora è più facile da usare per tutti gli addetti al team?

Dovresti misurare cosa è stato scritto dopo il codice e quanto è prezioso il contributo per gli obiettivi della tua azienda / azienda. Nota che è possibile avere un impatto negativo.

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks..

(Robert C Martin, Pulisci codice - libro che si apre con l'immagine sopra)

Supponendo che tu abbia ingaggiato qualcuno intelligente, dovrebbero fare le cose. Oltre a ciò, quando misuri i dipendenti (soprattutto i programmatori), ottieni esattamente ciò che misuri.

In breve, controlla che i progetti vengano eseguiti all'interno degli standard del team.

Che ne pensi dell'efficienza (lavoro svolto / ora) ?. Questo può essere misurato con la tecnica pomodoro . Dai un'occhiata a questa presentazione .

Una volta che stai monitorando le tue stime pomodoro e le effettive pomodoros per attività, puoi misurare il fattore di realtà, che questo strumento chiama pomodairo fa per te. Questo fattore di realtà può riassumere quanto sono buone le tue stime e quanto sei efficiente; per valutare l'efficienza, mi limiterei a non più di 2 attività pomodoro.

Trovo l'obiettivo di pomodoros (su base individuale) perché ognuno indica una quantità fissa di lavoro focalizzato e sono una buona misura per migliorare, che IMHO è il vero scopo di qualsiasi metrica di questi tipi che conta.

L'abbiamo appena esaminato durante il mio lavoro. Cercando di capire quali dovrebbero essere i nostri KPI e quindi quali sarebbero stati i nostri KPI (dal momento che risultavano difficili da misurare).

L'indicatore KPI dovrebbe essere una misura per risolvere i requisiti aziendali in modo tempestivo. Se qualcuno conosce un buon modo per misurare questo fammi sapere. :)

Abbiamo terminato di decidere di utilizzare # delle funzionalità implementate. I nostri clienti effettuano l'accesso su tutte le funzionalità che l'utente ha di fronte e hanno una priorità pubblica (quindi le persone possono lottare per ottenere il loro primo posto). Abbiamo pensato che sarebbe stato un modo semplice per misurare se stiamo andando bene. Vedremo .....

Non ci sono quasi metriche aziendali che puoi utilizzare. Devi trattare il programmatore come un matematico o uno scienziato. L'unica cosa che viene misurata è l'impatto o il potenziale impatto delle idee / codice. Contenderesti il numero di righe in una prova scritta da un matematico?

Anche se si utilizza una misurazione, il programmatore verrà trattato come un problema di ottimizzazione a seconda che determini le proprie retribuzioni. Un altro punto è che la produttività del programmatore varia di giorno in giorno, alcuni giorni ci sono un sacco di righe di codice scritte, altre volte non si pensa a nuove idee di progettazione, ecc.

Quali sono alcuni degli indicatori di prestazioni chiave per un dirigente o un manager? Forse dovresti provare a utilizzarli per i programmatori dato che ci occupiamo anche di idee e pensieri.

Per un programmatore industriale, $ / hr salvato (o guadagnato) è, a mio parere, l'unica metrica aziendale significativa.

I tipi di software sono noti per avere una mentalità da gioco (giochi per computer, penna e carta, puzzle, ecc.). Non comportamento incentivo non allineato con le esigenze aziendali.

Ad esempio, se consideri kLOC / week come indicatore chiave, osserverai che per la stessa funzione, stai ricevendo molti più kLOC.

Esempio:

int foo() {
   return blah;
}

Può essere trasformato in:

int
foo()
{
   return 
      blah;
}

Per la stessa funzione. Questo è un aumento 2x LOC. Se classifichi la mia produttività principalmente in base a LOC, è meglio credere che valuterò se voglio ottenere quel bonus / promozione basato sulla produttività.

Direi che è necessario allineare le metriche dalle business unit alla programmazione. I programmatori non lo vogliono perché sentono che la business unit fallirà e non sembreranno buoni.

La mia risposta è: Dude - o Dudette - lavora con i tuoi utenti aziendali e crea strumenti fantastici per loro che li renderanno estremamente produttivi e il loro successo sarà il tuo successo.