In seguito a questa domanda , mi sono chiesto se la gente potrebbe essere in grado di suggerire alcuni esempi di ciò che potrebbe essere considerato un obiettivo "buono" in un ciclo di revisione periodica per un programmatore?
Definiamo SMART dalle definizioni più popolari nella voce di Wikipedia :
Mi sono reso conto che gli obiettivi SMART vengono utilizzati al meglio quando le persone hanno una deficienza che devono correggere e non sono così buone per i periodi in cui si desidera che le persone crescano o passino dal buono al grande. Ad esempio, se qualcuno non fa segnapunti e questo fa male alla società perché a volte devi ritardare la fatturazione, potresti avere un obiettivo intelligente come "nelle prossime 6 settimane, i fogli di lavoro di almeno 5 settimane saranno completati entro le 10:00 di il lunedì mattina successivo. " 6 settimane dopo hai un vero o falso; lo sviluppatore ce l'ha fatta o l'ha persa. O la nuova abitudine è a posto o si decide se si vuole ancora assumere qualcuno a cui non importa ritardare la fatturazione. Funziona anche per le persone che hanno altre cattive abitudini: "nelle prossime due settimane, almeno il 75% dei tuoi check-in avrà un commento di controllo che segue le linee guida per il check-in (link al documento interno)." Di nuovo hai un bel croccante fatto / non alla fine di quel breve periodo.
Dove trovo questi costrutti meno utili è quando il tempo si allunga, quando il risultato desiderato è sfocato (impara una lingua, sii più utile), o quando è ok se l'obiettivo non viene raggiunto (puoi valutare le certificazioni, ma se qualcuno fallisse il test probabilmente non avresti preso provvedimenti disciplinari). All'improvviso tutti i benefici dell'obiettivo intelligente svaniscono. Non cercare di usarli per qualcosa di diverso dalle azioni correttive, e sono facili da scrivere, aiutano lo sviluppatore a raggiungere il livello previsto e sono facili da testare quando il tempo è scaduto. Avere problemi con la scrittura significa che non sono lo strumento giusto per questo obiettivo.
Dato che sto per iniziare una conversazione sul mio obiettivo con l'obiettivo, ho pensato di aggiungere alcuni esempi simili a quelli che sto considerando di suggerire da solo:
Mi aspetto che il lavoro aggiuntivo si materializzi nei tempi che ho specificato (lo è sempre stato prima, dopo tutto) e che il lavoro potrebbe avere un effetto sull'aspetto "Tempestivo" in particolare. Questo non dovrebbe essere un problema: gli obiettivi dovrebbero essere rivisti regolarmente per assicurarsi che continuino a soddisfare il criterio "Achievable". Avrò bisogno di essere sicuro che tenga il mio manager al corrente su questo - a nessuno piacciono spiacevoli sorprese di fine anno ...
Se vendi software o un prodotto con software in esso ...
Aumenta le vendite n%.
Davvero.
Se il software non ha funzionato, non ne venderesti gran parte.
Se il software funzionasse DAVVERO BENE, venderesti lotti.
(Questo avrà i ragazzi del software che guardano i venditori come falchi assicurandosi di non far saltare il loro bonus sulle prestazioni.)
Se il tuo software è un sistema in-house:
riduci il costo del business n%.
Se i nuovi sistemi software impiegano 10 volte il costo della società. Se il nuovo sistema è veloce e previene errori, la società risparmia denaro.
Questo approccio sembra che si applichi ai venditori o forse al VP del processo di cambiamento aziendale, ma in realtà gli sviluppatori di software sono la prima linea per entrambi i tipi di processo.
La mia idea di fondo qui è quella di cercare di allineare esplicitamente la struttura dei dipendenti con il miglior risultato possibile per l'azienda.
Implementation of X module within
+-10% of the estimated time (40 hours) within 5% range of 10 defects/KLOC
È specifico - purché "Implementazione" abbia un significato accettato all'interno del team.
Di solito si riferisce a "Coding + Unit Testing"
È misurabile: puoi misurare i difetti, lo sforzo e il tempo
Raggiungibile - Finché la stima si basa su precedenti effettivi di moduli simili / giudizio di esperti, dovrebbe essere raggiungibile
Rilevante - Si tratta in particolare di un particolare modulo
Time Bound - Penso che potrebbe esserci una data di fine aggiunta per renderla esplicita.
Tuttavia, solitamente nei progetti in cui le persone svolgono più attività contemporaneamente su cose diverse, è molto più difficile da fare. Ma fino a quando le attività hanno la priorità correttamente, non dovrebbe essere davvero un problema che non ha una data di fine in esso
Leggi altre domande sui tag management project-management review