Diverse organizzazioni che conosco utilizzano gli SMART obiettivi per i loro programmatori. SMART è un acronimo per Specific, Measurable, Achievable, Relevant e Time-Bound. Sono abbastanza comuni nelle grandi aziende.
La mia precedente esperienza con gli obiettivi SMART non è stata così positiva. Gli altri programmatori hanno trovato un modo efficace per misurare le prestazioni? Quali sono alcuni esempi di buoni obiettivi SMART per i programmatori (se presenti).
In una parola
No
Primo: non ho mai avuto i miei progetti abbastanza stabili da poter stabilire gli obiettivi SMART con qualsiasi significato. Il tempo varia tra quando i miei ruoli cambiano su un progetto e quando le recensioni perf sono fatte sono troppo fuori sincrono.
Secondo: misurare le prestazioni individuali è un ottimo modo per creare una mentalità "non il mio lavoro" e una competizione negativa tra individui e / o i vari sottogruppi di un'organizzazione. È molto semplice giocare al sistema e assicurarti di stare attento a te stesso e di non aiutare davvero l'intera squadra. Dovremmo incoraggiare le persone a essere giocatori di squadra, ma poi le nostre organizzazioni fanno esattamente l'opposto.
La maggior parte di questi sistemi è antitetica al team building. Mary Poppendieck ha fatto un lavoro molto migliore di articolare ciò che potrei mai fare in LeanEssays: Compensation del team .
Sue got a call from Janice in human resources. “Sue,” she said, “Great job your team did! And thanks for filling out all of those appraisal input forms. But really, you can’t give everyone a top rating. Your average rating should be ‘meets expectations’. You can only have one or two people who ‘far exceeded expectations’...”
... One of the greatest thought leaders of the 20th century, W Edwards Deming, wrote that un-measurable damage is created by ranking people, merit systems, and incentive pay. Deming believed that every business is a system and the performance of individuals is largely the result of the way the system operates. In his view, the system causes 80% of the problems in a business, and the system is management’s responsibility. He wrote that using exhortations and incentives to get individuals to solve management problems simply doesn’t work. Deming opposed ranking because it destroys pride in workmanship, and merit raises because they address the symptoms, rather than the causes, of problems.
...let’s take a deeper look into employee evaluation and reward systems, and explore what causes them to become dysfunctional...
Abbiamo utilizzato obiettivi SMART nella grande azienda in cui lavoro. Non hanno senso per la maggior parte.
Gli obiettivi vengono dal management e sono elevati e astratti. Relazionarli con progetti concreti e lo sviluppo è di solito uno scherzo. La maggior parte dei progetti che entrano nel gruppo provengono dall'azienda e soddisfano esigenze aziendali specifiche. Quindi codifica il progetto, lo metti in produzione e fai un lavoro fantastico come al solito. In che modo questo si collega a un obiettivo raggiunto da qualcuno nella direzione?
Facciamo molto meglio come gruppo quando arriviamo ai nostri obiettivi. A volte includono la formazione su un argomento specifico o l'implementazione di un nuovo cambio di processo, qualcosa che può essere effettivamente correlato a ciò che facciamo. Non sono ancora in relazione con l'operazione di codifica giorno per giorno, sono almeno cose che aiutano a spostare il gruppo in avanti nell'ambiente aziendale.
Modifica
Come Mnementh ha giustamente sottolineato, la mia risposta si basa sugli obiettivi SMART che non sono, beh, SMART. Vorrei aggiungere alla mia risposta che se sei un manager di programmatori e vuoi implementare obiettivi SMART, assicurati che siano SMART. Utilizzare l'esempio dei miei gestori come un modo per NON implementare gli obiettivi SMART. Se non gestisci programmatori e qualcuno ti dice che ora inizierai a utilizzare gli obiettivi SMART e loro finiscono come i nostri, allora capisci che hai delle persone nel top management a cui piacciono i buzz word e che puoi controllare fuori da una lista di cose che hanno implementato.
Ci sono molte ricerche per dimostrare che i programmatori faranno un ottimo lavoro a qualunque criterio venga loro presentato, al costo di altri possibili obiettivi.
Ciò significa che faranno bene a raggiungere obiettivi specifici e misurabili, e meno bene a tutto ciò che non è specificamente elencato. Ciò significa che devi essere estremamente attento a stabilire gli obiettivi.
Non vuoi impostare linee di codice come obiettivo. Fidati di me. L'impostazione dei bug risolti porta alla scrittura del codice buggy per cominciare. Chiedere correzioni di errori nel codice esistente porterà a definizioni molto liberali di "bug" (e forse "correzione"). (Inoltre, la parte "realizzabile" dipende da quanto buggy era il codice.) Chiedendo la completezza della funzionalità in un certo tempo, beh ....
Quello che vuoi che i tuoi programmatori facciano è scrivere cose utili in un ragionevole periodo di tempo con una buona qualità del codice, e migliorarlo e modificarlo mantenendo la qualità del codice. Non ho mai visto obiettivi specifici e misurabili che sarebbero stati buoni criteri me stesso.
Eseguiamo questo esercizio ogni anno. Il problema è che gli sviluppatori qui tendono ad avere pochissima autonomia su ciò che fanno (compiti determinati dal product manager). Siamo fortunati che, almeno sulla carta, abbiamo dedicato del tempo a perseguire i nostri obiettivi. Realisticamente, tuttavia, otteniamo molto meno di questo.
In tale contesto, ho trovato che l'impostazione degli obiettivi di autosviluppo funziona davvero bene. Ad esempio, due dei miei obiettivi dell'anno scorso erano:
Quindi, sì, ne ho tratto beneficio e mi sono divertito mentre lo facevo.
Onestamente, nella nostra azienda, penso che la mancanza di buoni obiettivi SMART per gli sviluppatori abbia più a che fare con l'avversione istintiva nei confronti delle aziende.
Sì, se impostato correttamente.
Se impostato correttamente, gli obiettivi possono migliorare sia la squadra che le singole persone. Dovrebbero essere allineati al lavoro e progettati per l'individuo.
Sono stato in posti in cui un intero team di DBA ha gli stessi obiettivi insignificanti, oltre che in mani di alto livello come "conforme agli KPI globali e regionali come stabilito dal comitato KPI". Che nessuno sa naturalmente ...
Poi di nuovo, sono stato in posti in cui il manager imposta obiettivi individuali con il pensiero in primo piano.
Modifica:
Ho letto l'articolo di Mary Poppendieck e non si tratta di SMART. "La Percezione di Impossibilità" fallisce "Achievable" per esempio.
Gli obiettivi dovrebbero essere stabiliti per l'individuo, per condividere le proprie forze, aiutare a correggere le debolezze, contribuire alla squadra. La misurazione è per l'individuo.
Non ci dovrebbe essere confronto di x vs y.
Gli obiettivi per xey dovrebbero essere commisurati al loro grado o posizione all'interno di un sistema: uno non fissa gli stessi obiettivi per senior e junior. È ingiusto.
Alcuni parametri di riferimento sono necessari per impostare bonus o payrises da un piatto limitato: dovremmo invece contare le linee di codice? Recensioni peer?
E mostrami alternative valide che non mi impongono di cambiare il mio ethos aziendale globale. Non ho alcuna critica a SMART: I do hanno critiche nei confronti dei pessimi manager ...
In quanto framework per le prestazioni, SMART è efficace solo quanto strettamente i tuoi obiettivi sono allineati con quelli dei tuoi manager. A volte i tuoi obiettivi SMART devono prima DUMB in giù, cioè. rendili:
Per quanto strano possa sembrare.
L'impostazione degli obiettivi di tipo SMART può essere utile in un contesto di programmazione ma deve essere eseguita in modo intelligente o, come indicato in altre risposte, è probabile che sia perdita di tempo (o peggio).
Per ottenere obiettivi utili, è utile concordare cosa significherà l'acronimo SMART: una ricerca rapida di Google trovato definizioni diverse :
Quindi, in primo luogo, entrambi i lati della negoziazione per la definizione degli obiettivi dovrebbero operare partendo da una comprensione comune del processo.
Successivamente, gli obiettivi generali per l'organizzazione, divisione, gruppo, squadra (o qualsiasi altra gerarchia è rilevante) devono essere spiegati e compresi. A quel punto dovrebbe essere possibile per l'individuo (IMO, gli obiettivi devono essere stabiliti a livello individuale per essere utile) per essere in grado di concordare un numero limitato di obiettivi che dovrebbero informare le attività di quella persona in futuro.
Se finisce lì, è sempre stato uno spreco di tempo per tutti. Gli obiettivi devono essere rivisti e adeguati periodicamente, laddove conseguiti, occorre prendere in considerazione l'eventuale necessità di fissare nuovi obiettivi, laddove non conseguiti, identificare le ragioni e, se necessario, adottare misure correttive.
Tutti gli interessati dovrebbero essere consapevoli che questo tipo di esercizio non vale la pena se non viene preso sul serio, o forse più algoritmicamente, il valore da estrarre è proporzionale allo sforzo messo in atto.
Potrebbe essere istruttivo vedere cosa pensano le persone potrebbero essere utili / utili obiettivi SMART. Ho posto una domanda qui ...
Il problema con gli obiettivi SMART è che devono scegliere ciò che è misurabile. Poiché ciò che è misurabile e ciò che è importante per il successo dell'organizzazione spesso non è la stessa cosa (e praticamente non lo sono mai nella programmazione), gli obiettivi SMART falliscono sempre nelle valutazioni delle prestazioni nella mia esperienza. E a volte le cose sembrano misurabili, ma non senza troppi sforzi (come l'obiettivo SMART, ho avuto una volta per rispondere a tutte le email entro 4 ore. Davvero chi vuole provare a leggere le migliaia di email che ricevo un anno, determinare se era informativo o aveva bisogno di una risposta e poi guardava le e-mail inviate per vedere se rispondevo e ascoltavo le registrazioni di tutte le telefonate per vedere se rispondevo, controlla il mio registro IM per vedere se ho risposto, ecc. che dire di quell'e-mail che mi è stata inviata sabato sera a mezzanotte ...)
Per tutte le persone che hanno risposto NO, i tuoi obiettivi non erano probabilmente SMART abbastanza.
Li ho usati e li trovo incredibilmente utili. Potresti provare qualcosa che funziona per noi:
Questo è estremamente potente, crea responsabilità per lo sviluppatore. Le persone che vogliono trovare scuse pollo fuori dopo 6 mesi o giù di lì.
P.S: Riesco a capire che le persone stanno votando la risposta, ma per favore lascia un commento pertinente, altrimenti imparerò qualcosa che non so: -)
SMART è un acronimo per ricordare alcuni criteri per obiettivi migliori. Quindi, introducendo SMART significa che la tua gestione deve fare meglio seguendo questo principio. Senza la gestione SMART si fisserebbero gli obiettivi in ogni caso, ma sarebbero più probabilmente troppo difficili.
Quindi, per i programmatori non dovrebbero esserci cambiamenti, la gestione deve cambiare stile per implementare SMART. E se fanno bene, il tuo lavoro di programmatore può diventare più semplice, perché la direzione del progetto è più chiara, i tempi sono impostati e così via.
Se la gestione non lo fa correttamente, non cambierà molto.
Leggi altre domande sui tag management metrics