Domanda:
Implementazione di bonus basati sulle prestazioni
aroth
2015-05-29 11:59:34 UTC
view on stackexchange narkive permalink

Sto cercando di creare una politica di compensazione incentrata sullo sviluppatore. Vale a dire che si concentra fortemente su trasparenza, flessibilità e correttezza. Molti aspetti sono influenzati dalla politica di Stack Exchange, descritta qui.

Tuttavia, mi sento un po 'perplesso su come includere al meglio i bonus basati sulle prestazioni nel modello . Ritengo che ciò sia essenzialmente necessario poiché tutti gli sviluppatori in una determinata posizione inizieranno con lo stesso stipendio base e poiché voglio 1) che ci sia un incentivo per incoraggiare le persone a fare qualche sforzo in più, apprendere nuove abilità, ecc. e 2) affinché gli sviluppatori con le migliori prestazioni siano in grado di guadagnare più degli sviluppatori con le prestazioni più basse quando c'è una differenza chiara e misurabile tra i due .

Quindi ci sono alcune domande pragmatiche, come:

  1. Qual è il limite appropriato per l'importo massimo del bonus? Attualmente sto pensando al 10%, ma penso che potrebbe essere troppo basso?
  2. Qual è un buon intervallo di tempo per condurre le revisioni delle prestazioni? Attualmente sto pensando a una cadenza annuale, ma forse trimestrale consente una maggiore flessibilità?

E poi ci sono più aree concettuali di preoccupazione, come qual è il modo migliore per fissare obiettivi di performance? Oppure, se gli obiettivi non sono definiti esplicitamente, quale diventa la metrica utilizzata per valutare le prestazioni?

Vorrei evitare di implementare sistemi che si basano molto sull'autovalutazione o sulla valutazione tra pari e altri meccanismi che potrebbero incoraggiare politiche aziendali inutili (o giochi di sistema).

Ho lavorato in aziende che hanno utilizzato MBO per questo, e suppongo che abbia funzionato abbastanza bene in termini di non creare politiche negative ed essere difficile da giocare. Tuttavia, era molto sovraccarico sia per i dipendenti che per i loro supervisori (che dovevano entrambi fare alcuni rapporti ogni trimestre per definire obiettivi, monitorare i progressi rispetto a essi e quindi rivedere i progressi alla fine). Esistono strategie simili in giro che sono più "leggere" di MBO in termini di costi generali?

Nota che è importante che l'implementazione del bonus si adatti perfettamente al resto della politica di compensazione. Vale a dire che deve essere incentrato sugli sviluppatori, trasparente ed equo. Quale approccio si adatta meglio a questi requisiti?

Come riferimento, puoi trovare la mia attuale bozza della politica completa qui.

Le tue due domande mi sembrano un po 'presto. Devi prima rispondere a come misurerai le prestazioni. Quando hai queste informazioni, inseriscile nella tua domanda come sfondo per queste domande.
I bonus non sono mai equi, non è possibile che siano giusti. Se usi una misura quantificabile, ricompensi le cose sbagliate perché le cose che contano davvero non sono facilmente quantificabili e così ricompensi le persone che scrivono più righe di codice vice quelle che risolvono i problemi difficili o che possono magicamente risolvere qualsiasi cosa. Ovunque io abbia mai lavorato che utilizza un sistema "equo" per distribuire aumenti di stipendio (che sono di gran lunga preferibili ai bonus) o bonus finisce per premiare i mediocri perché quello che fanno è più facile da misurare. Non essere quel capo. fidati e usa il tuo giudizio.
Collegamento obbligatorio a Joel on Software: http://www.joelonsoftware.com/articles/fog0000000070.html
Se ci fosse un modo anche semi-affidabile per farlo, ogni azienda lo farebbe. Il problema è che non esiste un modo affidabile per farlo. Ad esempio, le cui prestazioni erano più chiare e obiettive quando uno sviluppatore ha scritto 10.000 righe di codice ma poi è arrivato un altro sviluppatore e l'ha ridotto a sole 5.000 righe di codice molto più facile da capire? La prima persona ha fatto +10.000 SLOC di prestazioni. La seconda persona ha fatto -5.000 SLOC. Qualsiasi metrica oggettiva avrà difetti e scappatoie come questo.
Anche MBO non funziona. Gli obiettivi di una persona potrebbero essere chiari e ben definiti ma 2 mesi dopo tutto cambia, poi 2 mesi dopo cambia di nuovo. Sebbene tecnicamente fattibile, il problema è che il sovraccarico nel mantenere MBO rilevante è solitamente eclatante, almeno per gli artisti più ricercati perché tendono ad essere quelli che vengono spostati di più per combattere gli ultimi incendi.
Il bonus relativo alle prestazioni è una pessima cattiva idea ... punto. Promuove una malsana spinta alla consegna di un prodotto (con le buone o con le cattive). Questo tipo di approccio alla carota e al bastone è cosa del 19 ° secolo. Se vuoi una forza lavoro buona e stabile e un ambiente di lavoro sano, evitalo.
Tre risposte:
Joe Strazzere
2015-05-29 16:49:49 UTC
view on stackexchange narkive permalink

Qual è il limite appropriato all'importo massimo del bonus? Attualmente sto pensando al 10%, ma penso che potrebbe essere troppo basso?

Penso che l'intervallo dal 10% al 15% sia spesso sufficiente per cambiare il comportamento, che è ciò che tu sono dopo con i sistemi bonus.

In alcuni contesti, il 15% potrebbe non essere sufficiente. Ma per molte aziende statunitensi in questi giorni, in questa economia, sembra sufficiente. Non lo saprai con certezza fino a quando non avrai implementato il tuo sistema per alcuni anni e avrai analizzato il feedback / le metriche che stai acquisendo.

Qual è un buon intervallo di tempo per condurre la performance recensioni? Attualmente sto pensando a una cadenza annuale, ma forse trimestrale consente una maggiore flessibilità?

Consiglio che le revisioni formali del rendimento siano condotte annualmente, ammesso che sia necessario.

A meno che tu non abbia un sistema estremamente semplice da amministrare, trimestralmente è troppo frequente, comporta un sovraccarico eccessivo e non lascia che i progetti di più lunga durata abbiano alcun impatto.

Una nota di avvertimento. Prima di intraprendere l'implementazione di questi bonus dove prima non esistevano, suggerisco sempre caldamente alle persone di leggere e comprendere "Misurazione e gestione delle prestazioni nelle organizzazioni" di Robert D. Austin.

Austin sottolinea la disfunzione che potresti benissimo innescare, poiché le persone si sforzano di massimizzare i loro bonus, a scapito dell'azienda / sistema nel suo insieme.

Vorrei evitare di implementare sistemi che dipendono fortemente da se stessi - o valutazioni tra pari e altri meccanismi che potrebbero incoraggiare politiche aziendali inutili (o il gioco del sistema).

Non credo nei bonus basati sulle prestazioni per i lavoratori della conoscenza , anche se di solito ho lavorato in aziende in cui esistevano. Posso onestamente dire che non li ho mai visti raggiungere la "trasparenza, flessibilità e correttezza" che cercavi.

Secondo me, tutti i sistemi di bonus basati sulle prestazioni possono essere e saranno "giocati" e portare ad almeno un certo livello di disfunzione. Personalmente mi sono imbattuto in molti scenari in cui sono stato costretto a scegliere tra quale fosse la cosa "giusta" da fare in una particolare situazione (ovvero, la cosa migliore per l'azienda e / o il cliente) e quale fosse la cosa che avrebbe fornito il bonus più alto per me. Odio essere messo in quella posizione ed essere costretto a scegliere.

Credo che i bravi manager nei dipartimenti di knowledge worker sappiano quali membri dei loro team hanno i migliori risultati e sono perfettamente in grado di premiare quei membri in modo appropriato . Non penso che prendere la decisione dalle loro mani funzioni davvero, non importa quanto cerchi di trovare le "metriche perfette" su cui si basano i bonus.

[Nota: poiché indichi che sei il capo dello sviluppo software e dell'IT, potresti essere saggio consultare le risorse umane prima di procedere con il tuo piano. Quando diversi reparti all'interno di un'azienda hanno obiettivi / misurazioni / sistemi di bonus molto diversi, può esserci una grande disconnessione tra i gruppi e può generare molti attriti e disfunzioni. In molte aziende non saresti libero di implementare un tale sistema di bonus senza previa approvazione delle risorse umane.]

Ottimi punti e riferimenti.
Azzeccato. I manager dovrebbero essere pagati di più per usare il loro giudizio e i sistemi oggettivi premiano quasi sempre i mediocri (perché fanno meglio con le cose facili da misurare) o le persone che giocano con il sistema. Qualsiasi manager che non sa chi sono le sue persone migliori senza un sistema non presta attenzione durante l'anno.
Quindi il sottotesto nei commenti (e certamente anche, [qui] (http://www.joelonsoftware.com/articles/fog0000000070.html)) sembra essere che potrebbe essere meglio non preoccuparsi affatto dell'idea bonus? È una possibilità. E per aggiungere un po 'più di dettagli, non esiste un dipartimento delle risorse umane; questa è una piccola azienda che sta per iniziare la sua prima corsa alle assunzioni. Quindi qualunque cosa venga stabilita è probabile che stabilisca il tono della cultura dell'organizzazione per gli anni a venire, da qui l'importanza di farlo bene.
Le piccole aziende di @aroth: hanno un vantaggio in quanto è MOLTO più facile cambiare le cose quando diventa evidente che non funziona. Se questo è il tuo primo ciclo di assunzioni, sospetto che cambierai molte cose nei prossimi 2 anni.
Kate Gregory
2015-06-30 18:17:48 UTC
view on stackexchange narkive permalink

Ecco il problema di avere un sistema, soprattutto un sistema trasparente e aperto, per i bonus: sarà giocato . Le persone non possono resistere a lavorare secondo le metriche e prendere decisioni che portano loro più denaro personale, indipendentemente dall'impatto sull'azienda. Più grandi sono i bonus, più forte è l'incentivo a fare la cosa sbagliata a volte. Le aziende generalmente rispondono rendendo il sistema più complicato, il che disconnetterà ulteriormente "l'impegno per aiutare l'azienda" dal "tentativo di guadagnare un grande bonus" e introdurrà anche un elemento avversario nel sistema.

Ecco qui il problema di avere bonus che sono del tutto soggettivi, soprattutto se gli importi non sono di dominio pubblico: molte persone penseranno che la gestione sia ingiusta e che dia soldi alle persone che preferiscono. Questo può portare al malcontento e persino alla perdita delle persone migliori (che troveranno più facile trovare altri lavori.)

In breve, quasi certamente non puoi motivare gli sviluppatori a fare la cosa giusta offrendo loro denaro extra fallo.

Nella mia azienda siamo abbastanza piccoli da prendere una decisione e darla alle persone come un vero vantaggio: abbiamo avuto un buon anno quest'anno, hai aiutato molto, ecco qualche extra soldi per te. Non credo che nessuno ci abbia mai fatto affidamento, abbia preventivato il budget o sarebbe stato pazzo se non l'avessero capito. Se sei troppo grande per farlo e non lavori in un settore che ha una "cultura dei bonus", starei completamente lontano dai bonus e darei aumenti basati sulle prestazioni, che sono ben compresi e possono essere compensati da "la tua assunzione di rischi ci costa denaro" in un modo che raramente i sistemi di bonus possono fare.

keshlam
2015-06-30 18:40:48 UTC
view on stackexchange narkive permalink

Credevo fermamente nei premi basati sulle prestazioni. Dopo averli visti malfunzionamenti drasticamente più volte nella mia carriera, non posso più dire che, almeno a un livello superiore a quello più locale e con un manager che sia abbastanza attivo coinvolto nel lavoro del proprio dipartimento che conosce la risposta senza bisogno di metriche giocabili / non funzionanti / semplicemente stupide.

Se non sai come si posizionano i tuoi dipendenti e non puoi ricompensarlo equamente, senza formalismo non fai il tuo lavoro di manager. Se non riesci a giustificare le tue classifiche al resto del dipartimento, idem.

Il confronto tra i reparti perde progressivamente sempre più informazioni man mano che sale la catena e diventa ingiusto, specialmente per coloro che odiano vantarsi e quindi non si auto-commercializzano in modo altrettanto efficace ... e / o che lavorano per manager che non hanno le capacità o l'inclinazione a difendere i propri dipendenti.

È una buona teoria. Semplicemente non funziona per nessuna delle organizzazioni più piccole o per quelle come la produzione in cui ci sono davvero metriche concrete incontestabili per la produttività. E anche lì che non riesce a riconoscere quelli che rendono più facile il lavoro di tutti gli altri.

Alternativa forse poco pratica: se vuoi riconoscere / assegnare bonus, potresti farlo per risultati particolari quando qualcuno va significativamente al di sopra e al di là cosa ci si aspetta al loro livello. Ricorda di adattarlo al loro titolo / grado di paga / gruppo / come lo chiama la tua azienda, in modo che anche le persone meno esperte vengano riconosciute quando hanno fatto del bene. Se qualcuno li riceve spesso, è tempo di aumentare la paga base e le aspettative di base. Non so se funziona davvero, ma è un'idea.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...