Dover fissare obiettivi per gli sviluppatori, anche se gli obiettivi non funzionano [chiuso]

È generalmente accettato che la definizione di obiettivi misurabili per gli sviluppatori di software non funzioni , poiché un'eccessiva focalizzazione sugli obiettivi può portare a comportamenti contrari agli obiettivi organizzativi (la cosiddetta " disfunzione della misurazione ").

Tuttavia, nella mia azienda, siamo tenuti a fissare obiettivi per tutto il personale e siamo incoraggiati dalle Risorse umane a renderli SMART . In passato, i miei colleghi manager di primo livello (team lead) e io abbiamo provato una serie di approcci:

1. Stabilire obiettivi misurabili aggiuntivi rispetto al normale lavoro, come "Fare formazione sulla tecnologia X", "Creare documentazione per un pezzo di codice Y che nessuno capisce" e così via. Quando si tratta della valutazione annuale delle prestazioni, valutare gli sviluppatori non in base agli obiettivi scritti, ma piuttosto in base alla mia opinione sul valore incommensurabile del loro normale lavoro, poiché questo è in realtà ciò che interessa all'azienda.
2. Impostare obiettivi molto specifici come "giorni di lavoro svolto come registrato dal sistema di gestione delle attività", "numero di bug introdotti", "numero di produzione emessa causata". Ciò ha portato a stime gonfiate e classificazione errata dei bug, al fine di ottenere "punteggi" migliori. È interessante notare che anche a quegli sviluppatori che hanno ottenuto punteggi alti su questo sistema non è piaciuto, poiché la fiducia intrinseca all'interno del team è stata danneggiata e non hanno sempre sentito di meritare la loro posizione elevata.
3. Stabilisci obiettivi vaghi che sono varianti di "Fai bene il tuo lavoro normale". Quando si tratta della valutazione annuale, la loro valutazione riflette la performance rispetto agli obiettivi, ma gli obiettivi stessi non sono misurabili o realizzabili, il che è disapprovato.

Nessuno di questi è l'ideale. Se ti sei trovato in una situazione simile in cui devi creare obiettivi significativi e misurabili per gli sviluppatori di software nonostante le prove contro la loro efficacia, quale approccio ha funzionato meglio per te?

Domande correlate che ho scoperto che non affrontano lo stesso punto:

• Quali sono alcuni buoni obiettivi di prestazioni per un ingegnere del software?
• Definizione degli obiettivi di rendimento per gli sviluppatori
• Quali sono gli indicatori di prestazione adatti per i programmatori?
• Qual è una tecnica di misurazione della produttività equa per i programmatori?
• Ho bisogno di alcuni "Obiettivi" di carriera per il prossimo anno

Aggiornamento (18 novembre 2009): ci sono 10 voti positivi per la mia domanda e le risposte con il punteggio più alto hanno solo 4 voti positivi (incluso uno ciascuno da me). Penso che questo ci dica qualcosa: forse che Joel e gli altri hanno ragione, e che la saggezza combinata di stackoverflow non può trovare alcun obiettivo convincente e misurabile per gli sviluppatori che non potrebbero essere giocati senza influenzare negativamente il vero valore (non misurabile) del loro lavoro. Grazie per aver provato però!

quale approccio ha funzionato meglio per te?

Un solo obiettivo: superare un'ispezione del codice / revisione tra pari, con me come revisore, senza che io trovi alcun bug o abbia altre critiche, che ti chiede di rifare qualcosa.

Appunti:

• Non stavo misurando la capacità dei nuovi assunti di finire rapidamente e non li incoraggiavo a: volevo che le persone imparassero a finire bene (perché se non è finito bene, allora non è finito)
• Le persone hanno imparato quello che cercavo in una revisione del codice: quindi è un'opportunità di apprendimento e una misura di controllo della qualità, e non solo un obiettivo di gestione
• I miei commenti avrebbero due categorie:
  1. Questo è un bug: devi risolverlo prima di fare il check-in
  2. Come suggerimento, avrei fatto questo e quest'altro
• Dopo un po ', le mie revisioni del codice di una persona smetterebbero di trovare elementi "da correggere" (a quel punto non avrei più bisogno di rivedere il loro lavoro).

Personalmente cerco di fissare due tipi di obiettivi:

• Obiettivi incentrati sul business (ecco perché, dopotutto, veniamo pagati). Ad esempio, "completare il progetto X entro il 1 giugno 2009"). Questi obiettivi sono spesso condivisi tra diversi membri del team (e loro ne sono consapevoli). Il team può superare l'obiettivo portando il progetto in anticipo o superando la funzionalità richiesta. Gli individui possono superare l'obiettivo producendo più funzionalità, avendo meno bug contro di loro o istruendo e supportando altri membri del team.

• Obiettivi di crescita personale, ad esempio il completamento di un progetto che coinvolge una tecnologia che lo sviluppatore desidera aggiungere al proprio set di competenze, comprendere meglio il dominio dell'utente, acquisire esperienza di leadership ecc.

Penso che sia importante che:

• Gli obiettivi sono SMART
• Gli obiettivi sono allineati alle esigenze dell'azienda
• Includete il "lavoro normale" negli obiettivi, infatti questi sono gli obiettivi più importanti!
• Il dipendente ha qualche opportunità di superare gli obiettivi che ti sei prefissato

Infine, starei lontano dalle metriche del software come obiettivi: sono troppo facili da giocare e probabilmente non ti daranno ciò di cui hai bisogno. Userei solo una metrica in cui voglio istruire qualcuno dentro o fuori un particolare comportamento.

Tutto questo si riduce al fatto che la "gestione di primo livello" e la maggior parte dei dirigenti non conosce i propri dipendenti. Invece di far parte della pianificazione e dello sviluppo quotidiano, vengono fuori cose come SMART. Se i manager trascorressero più tempo con i ragazzi che fanno il lavoro effettivo, niente di tutto ciò sarebbe necessario.

Personalmente, preferisco lavorare in un ambiente agile dove è ovvio chi degli sviluppatori si comporta in termini di produttività e consapevolezza della qualità. Un vero approccio agile richiede che nel processo siano inclusi non solo sviluppatori, ma anche designer, tester, clienti e product manager. Questo porta naturalmente a una migliore comprensione dal punto di vista dei manager.

Obiettivi misurabili che ho visto finora:

• Supera un esame di certificazione
• Ricerca la tecnologia X e tieni una presentazione al riguardo
• Numero di modifiche che interrompono la build impegnate
• Numero di articoli wiki scritti sulla gestione della conoscenza interna

Che ne dici di chiedere direttamente ai tuoi sviluppatori se hanno alcune idee per lo sviluppo personale che potrebbero essere utilizzate per obiettivi?

Dover fissare obiettivi per gli sviluppatori, anche se non funzionano

Se i tuoi sviluppatori non funzionano, forse alcuni obiettivi sono proprio ciò di cui hanno bisogno per dare loro un incentivo? ;-)

"Assicurati che almeno l'n% del tuo codice sia testato da uno unit test appropriato" Utilizza uno strumento di copertura per dimostrarlo e chiedi a qualcun altro di verificarne la qualità.

Penso che avere obiettivi molto specifici in anticipo, cioè SMART (forse lavoriamo nello stesso posto in realtà), sembra una buona idea in pratica ma non è molto pratico per la maggior parte delle squadre.

Il problema è che i nostri obiettivi incrementali cambiano. Il business cambia e come sviluppatori dobbiamo reagire e reagire adeguatamente e in un lasso di tempo ragionevole.

Considera la possibilità di stabilire obiettivi che siano legati allo scopo del tuo team o gruppo nell'organizzazione. La tua squadra non sarebbe finanziata se non servisse a uno scopo: uno scopo macro. Avere obiettivi collettivi che esistono in tutto il tuo team e che sono in linea con il business. Dare responsabilità alle persone e ritenerle responsabili. Celebrate i loro successi e fallimenti (se a volte non falliamo probabilmente non ci stiamo provando ed è quello che volete dalle persone). HTH

Abbiamo una serie di metriche raccolte mentre i programmatori lavorano, come ad esempio:

• Numero di SLOC modificato / aggiunto
• Numero di errori / bug iniettati in varie fasi del processo (durante peer review, post peer review, post release)
• Richieste di modifica soddisfatte / rifiutate
• Documenti formali (descrizioni della versione del software, documenti di progettazione, ecc.)

Tutti questi sono elementi tangibili che trovo utili nelle presentazioni per la gestione e la garanzia della qualità del software. Ma non li ho mai trovati così utili nelle valutazioni effettive delle prestazioni delle persone, che è il punto sottolineato da molti dei link che hai elencato. Ho scoperto che i punti di Joel qui sono validi: le metriche non promuovono mai una buona atmosfera di squadra.

Sfortunatamente, viviamo tutti in un mondo in cui le metriche sono richieste da altri (gestione, garanzia di qualità, appaltatori esterni, ecc.). Ho scoperto che è necessario un atto di bilanciamento - fornire quelle metriche, ma anche fornire prove di intangibili - intangibile è ciò che ogni programmatore ha realizzato che non è necessariamente tracciato. Ad esempio, ho avuto un programmatore che ha trascorso molto tempo a indagare sul codice legacy che nessun altro voleva toccare. Anche se i suoi parametri erano bassi per quel periodo di tempo, quello sforzo è stato inestimabile.

L'unico modo che ho trovato per includere queste cose è stato quello di spingere per la creazione di una categoria immateriale aggiuntiva e dargli uguale peso con le altre metriche. Di solito questo è sufficiente per far oscillare la bilancia per un particolare programmatore.

Uno dei problemi sembrerebbe essere che, come divisione / dipartimento, le organizzazioni IT non hanno obiettivi strategici misurabili. Se lo facessero, sarebbe più facile fissare gli obiettivi per gli individui.

Ad esempio, se ci fosse un'iniziativa dipartimentale per ridurre il numero di ticket problematici sollevati, è possibile impostare obiettivi individuali in base al numero di ticket relativi al software di cui si occupano.

Poiché lo sviluppo del software è ampiamente collaborativo, avrebbe più senso fissare obiettivi a livello di team e quindi valutare le persone in base al loro contributo al team.

Un obiettivo che mi piace è:

Richiedi N recensioni positive sul tuo coinvolgimento in un progetto dal cliente del progetto.

Questo aiuta in quanto è sempre bene avere un feedback positivo scritto dai clienti (interni o esterni). Non è difficile da ottenere, è rilevante ed è un segno di spunta facile, ma non privo di significato.

Determinare come allineare lo sviluppo personale con i progetti in corso è un punto chiave in questo credo. Fare in modo che gli sviluppatori si analizzino per trovare i punti deboli insieme al feedback sugli altri può essere un modo per trovare ciò che può essere migliorato e quindi trovare un modo per misurarlo. Ad esempio, potrei scoprire di documentare raramente gli elementi completati e quindi sui miei obiettivi per l'anno posso affermare che voglio migliorarlo e che la quantità di documentazione che produco può essere una misura di ciò. Potrebbe funzionare o potrebbe ritorcersi contro a seconda di come lo seguo davvero. Da un lato ci possono essere valide preoccupazioni per questo, essendo come migliorare il mio lavoro e fare quello che può essere visto come il modo corretto, mentre una visione passiva aggressiva o infantile sarebbe quella di produrre una montagna di documentazione se non lo è.

La definizione di uno sviluppatore efficace è un altro elemento di questo. È la persona che risolve meglio i bug? Il nuovo funziona più velocemente? Il nuovo lavoro è completo di test e documentazione anche se non viene eseguito rapidamente? Cosa stai definendo efficace poiché la risposta standard "dipende" dovrebbe essere chiarita qui.