Come valutare la produttività degli sviluppatori (o, più in generale, dei dipendenti)
Valutare la produttività dei dipendenti di un’azienda è un lavoro complesso. Nella letteratura scientifica non esistono regole, leggi o studi a riguardo della valutazione dei dipendenti e spesso le aziende usano metriche vetuste o inadeguate.
Alcune aziende usano le “righe di codice” al mese: quante righe di codice vengono prodotte in un mese da uno sviluppatore. I livelli di riferimento cambiano a seconda se si usa un linguaggio ad oggetti, che permette di scrivere codice più velocemente, oppure linguaggi a basso livello, dove bisogna essere attenti a ogni punto e virgola e scrivere tanto codice per realizzare meno funzioni.
Ma questa metrica non è adeguata perchè a uno sviluppatore più bravo può essere chiesto di lavorare su una parte difficile del sistema, mentre a uno “medio-scarso” viene richiesto di implementare qualche funzione più semplice. Lo sviluppatore bravo allora produrrà meno codice, ma sarà un codice di buona qualità e ci avrà messo un intervallo di tempo pari ad X; lo sviluppatore meno bravo avrà prodotto più codice nello stesso intervallo X di tempo, ma potrebbe contenere più errori o essere più semplice da realizzare.. Se si tenesse conto solo di questo, lo sviluppatore scarso avrà prodotto più linee di codice, e ciò non è desiderabile. Bisogna incentivare chi è bravo e chi si assume la responsabilità di parti difficili del sistema!
Ad ogni modo, un sistema software non è fatto solo di codice. Spesso bisogna produrre quantità industriali di documentazione, e a seconda di se seguiamo lo standard o meno, potrebbero essere tanti documenti (Requirements Analisys Document, System Design Document, Object Design Document, Test Plan, Test Case Specification, Test Incident Report, Test Execution Report, Test Summary Report, Javadoc o commenti al codice!). Non credo che in Italia si facciano tutti questi step … l’industria IT italiana usa una gestione molto casereccia, da puteia, IMHO.
Per questo, valutare la produttività o comunque dare una valutazione agli sviluppatori deve essere qualcosa di globale. Io ora vi darò una “ricetta” utilizzata in un progetto terminato poco fa; non è affatto perfetta e probabilmente ha bisogno dei vostri commenti per migliorare ancora e diventare un giudizio sensato.
Innanzitutto bisogna distinguere due tipi di valutazione: la valutazione personale, che comprende attributi tipo attenzione ai meeting, ritardo nel consegnare il lavoro, ritardo nel presentarsi al lavoro, entusiasmo, autonomia nel completare il lavoro e saper prendere decisioni corrette, e altre variabili che magari dipendono dal vostro posto di lavoro; e la valutazione tramite “metriche”, ossia tramite valori ricavabili dai dati a disposizione. Entreremo nel dettaglio di queste due valutazioni tra un secondo; prima ricordatevi alcune vere regole alla base di tutto:
- un buon manager sa essere obiettivo quando valuta, quindi lo fa al netto di simpatie/antipatie, opinioni sportive, razziali, sessuali, etc.
- Qualsiasi metrica voi vogliate misurare, se vi restituisce qualcosa che secondo voi è fuori dalla realtà, probabilmente è una metrica sbagliata.
Un commento sulla regola 2. Molto spesso noi raccogliamo metriche e poi dobbiamo combinarle con formule o altre cose per ottenere un numero “magico” che mette su una scala graduata tutti gli sviluppatori. Può accadere che alcune persone avranno una valutazione più alta di altri e voi manager sapete che la realtà è ben diversa. Che fare? Probabilmente avete sbagliato metrica, quindi conviene capire come mai sono usciti valori sbagliati e raccoglierne altri oppure combinarli in maniera da farli risultare più corrispondenti alla realtà.
Torniamo alle due metriche principali e cerchiamo di capire come usarle.
Valutazione personale
Questo tipo di valutazione è soggettiva, e viene fatta dal manager ad ogni meeting, sulla base del feedback che riceve dal team. La cosa migliore da fare è di creare una tabella per ogni meeting, che conterrà sulle righe tutti i team member, e sulle colonne i fattori che volete misurare: puntualità, attenzione, entusiasmo, etc etc. Queste servono ai manager per rendersi conto anche del modo in cui hanno lavorato settimana dopo settimana tutti i team member.
Alcuni consigli: usate una scala da 1 a 5 (o da 1 a 7); conviene prendere scale che siano dispari per poter rappresentare anche un valore medio. Si suppone che lavoriate tramite “meeting”, quindi ogni settimana farete un meeting in cui revisionerete il lavoro svolto e asssegnerete nuovi task. Se è così, avendo questa tabella aggiornata per ogni meeting, alla fine potrete fare delle medie e ricavare una sorta di scala graduata per ogni valore.
Valutazione tramite metriche
La valutazione tramite metriche serve a colmare quello che non fa la valutazione personale, ossia prende dei dati analitici dal progetto in corso e li analizza con tecniche anche statistiche se ce n’è bisogno.
Nel progetto a cui ho partecipato, le metriche che abbiamo preso in considerazione erano, per ogni documento creato:
- un fattore di qualità del documento creato, da 0 a 1
- un fattore di difficoltà, da 0 a 1
- una metrica se l’artefatto è stato completato in tempo, magari con 1 se l’artefatto è stato completato in tempo e con valori minori se l’artefatto ha subito ritardi.
Uso la parola “artefatto” intendendo pezzi di documento, classi, pagine web, package, etc. La granularità la decidete voi, a seconda di quanto / cosa volete valutare.
Potete creare delle metriche anche per il codice, e ricavare questi valori. Purtroppo l’assegnazione di questi valori avverrà sulla base della vostra esperienza, quindi assegnerete 1 se l’artefatto vi sembrerà di buona qualità e 0 viceversa; se non avete molta esperienza dovrete farvi prima un’idea della situazione per saper giudicare.
Sommando questi numeri per ogni artefatto, otterete una valutazione dei vostri TM (team member) che sono abbastanza sorprendenti. Per questo, vi dico, forse non è la migliore formula possibile. Potreste provare a misurare il numero totale di artefatti consegnati, il numero di artefatti che hanno subito ritardo per ogni membro, e tutta un’altra serie di metriche che, se serve allo scopo, fate bene a mettere. E’ inutile riempire il database di numeri che non sapete interpretare; meglio pochi numeri ma che rappresentano il lavoro svolto dai membri.
Queste sono le parole di un professore che mi ha risposto sull’argomento:
La valutazione e’ estremamente soggettiva per quanto riguarda il comportamento delle persone, ma e’ basata comunque sulla propria esperienza e se vogliamo e’ oggettiva rispetto al punto di vista di chi valuta. In ogni caso, dei criteri bisogna averli fissati e dei pesi dati ai vari criteri bisogna averli definiti.
La produttivita’ non puo’ esserela panacea: serve solo a confrontare il lavoro
svolto da persone che hanno lavorato lo stesso tempo per vedere chi e stato piu’ bravo (di per se’ non puo’ essere l’unico criterio).Detto questo, l’esperienza mi dice che le persone in un progetto sono diverse e contribuiscono in maniera diversa, per cui e’ necessario differenziarle nella
valutazione (al di la’ dell’impegno profuso).
Questa risposta evidenzia un’opinione riguardo all’impegno che hanno profuso i diversi membri. Nel caso del nostro progetto, i ragazzi avevano lavorato pressappoco tutti lo stesso monte-ore, e mi sembrava poco saggio assegnare solo 2 punti su 4 disponibili per persone che si sono impegnate così tanto. Però un manager non deve livellare verso l’alto per amicarsi i membri, perchè così si fa nemici i Top manager. E non è buono per la carriera. Per fortuna questo era un progetto universitario e tante cose abbiamo potuto sbagliarle; nella vita reale le cose non si possono fare così.
Sia chiaro, mi rendo conto che il lavoro in azienda è del tutto diverso rispetto a quello fatto all’università, ed è bene evidenziarne le differenze.. Io magari mi sono allargato nei voti universitari non perchè volevamo davvero amicarci il prof, ma perchè davvero ero convinto che bene o male valessero tutti quel voto. Purtroppo i voti non li decido io (altrimenti avrei messo 30 a tutti…)
Questa piccola lezione di management spero possa essere utile a chi ha bisogno di delucidazioni.. La mia conoscenza finisce qui e per valutare le persone c’è bisogno di esperienza e metodo. Sicuramente ho scritto qualche imprecisione o qualche invenzione ma vi prego di non prendere per oro colato questo articolo: fareste bene a valutare i vostri dipendenti secondo i parametri che realmente sono necessari per la loro (e vostra) crescita professionale.
Vi lascio con l’ultima regola del management:
non importa quanti linguaggi di programmazione conosci, da quanto tempo lavori in azienda o qual è il tuo voto di laurea. L’unica cosa davvero importante è se sei capace di prenderti delle responsabilità (anche di un team) e di saperle onorare con l’impegno. Chi fa carriera non è il più bravo ma il più capace a rispettare e far rispettare tempi, costi, e qualità.
ultimi shock