Come strutturare i bonus per gli sviluppatori di software? [duplicare]

In primo luogo, guarda questo .

Quindi, pensa a come puoi creare una struttura bonus basata sui risultati della ricerca in quella clip. :)

Versione TL; DW : le strutture tradizionali di ricompensa di carote e bastoncini funzionano solo su manodopera puramente meccanica. Non funzionano per i knowledge worker. In realtà tutto ciò che puoi fare per motivare i knowledge worker è dare loro un lavoro interessante e autonomia.

IME e amp; HO, i bonus fanno più male che bene. Non esiste un modo semplice per misurare oggettivamente le prestazioni, quindi spesso si riduce a come si va d'accordo con la persona che prende la decisione. Può diventare molto dividente e ferire davvero l'org.

Un metodo molto migliore è quello di pagare tutti abbastanza bene da non aver bisogno di preoccuparsi dei soldi e quindi soddisfare le loro altre esigenze: lavoro interessante, autodeterminazione e un buon ambiente di lavoro. L'occasionale regalo di tipo "thank-you" può funzionare se fatto bene: tutti noi (indipendentemente dalla retribuzione e dalle prestazioni) abbiamo ottenuto iPad per Natale.

So che tutto sembra molto socialista, ma allevare la concorrenza tra pari può solo distrarli da ciò che effettivamente vuoi che si concentri su di loro.

Le strutture bonus tendono a funzionare meglio quando vengono applicate all'intero gruppo, non ai singoli. Altrimenti, invece di incoraggiare la cooperazione, incoraggi la concorrenza e gli sviluppatori non lavoreranno insieme per creare il miglior software possibile.

Detto questo, hai bisogno di qualcosa per le persone che superano la chiamata del dovere, e un modo per prevenire gli scansafatiche, che sono ricompensati per essere in un gruppo altrimenti ben funzionante.

Gli incentivi non monetari (come i giorni di riposo extra, i pranzi di catering, le gite giornaliere o altre attività speciali) possono spesso essere più efficaci della retribuzione incentivante.

Gli incentivi devono essere considerati attentamente, per evitare conseguenze indesiderate. Vedi link

1. Milestones del prodotto: il metodo semplice per misurare il successo di un team di prodotto.

2. Ricavi generati: un altro metodo per misurare il successo potrebbe essere quello di basare il successo sulle entrate generate da una versione del prodotto. Gli sviluppatori si concentrano sulle cose che portano al profitto? (Ricorda, lo scopo di qualsiasi attività commerciale è realizzare un profitto .)

Naturalmente, molte persone sono intrinsecamente motivate, il che significa che sono motivate dalla soddisfazione di sapere che hanno fatto qualcosa di grande e benefico.

Naturalmente sono stati condotti studi e articoli di blog scritti che suggeriscono che la retribuzione degli incentivi è dannosa.

a positive review makes them feel like they are doing good work in order to get the positive review... as if they were Pavlovian dogs working for a treat, instead of professionals who actually care about the quality of the work that they do.

Non sono d'accordo.

Quindi cosa dice del proprietario di un'azienda il cui reddito derivante dall'utile dell'azienda può variare in base a decisioni strategiche buone o scarse?

I titolari di aziende non sono incentivati perché alcuni manager lo hanno dettato per il modo in cui verranno risarciti. Invece, sono incentivati naturalmente dal sistema capitalistico di mercato. Il semplice fatto è che se l'azienda fa bene, l'imprenditore viene premiato. Se l'azienda fa male, il proprietario dell'attività non viene ricompensato.

Ciò significa quindi che clienti e clienti dovrebbero comprendere la situazione dei proprietari di aziende e offrire qualche forma alternativa di ricompensa? Non è il proprietario di un'azienda qualcuno che ha bisogno di sentire anche il 'atta-boy'?

La linea di fondo, la verità della questione è che questo approccio capitalistico ha funzionato per secoli.

Credo che i vantaggi finanziari, come la partecipazione agli utili, siano vantaggiosi in termini di ottenere tutti sulla stessa pagina rispetto a ciò che è importante. Fintanto che tutte le parti dell'organizzazione hanno la proprietà di un area che contribuisce direttamente al profitto del business, quindi i premi finanziari possono aiutare tutti a riflettere più attentamente su come le loro decisioni influenzano l'organizzazione.

Ancora, questo funziona solo se hai il controllo del tuo destino. Se tu, come dipendente, non puoi prendere decisioni, questo sarà dannoso per la tua motivazione.

I premi finanziari dovrebbero essere gli unici vantaggi? Io non la penso così Credo che la ricerca sostenga chiaramente il fatto che le persone sono motivate intrinsecamente e vogliono sentirsi importanti, ma voglio anche che i miei sviluppatori riflettano su come le loro decisioni influiscono sui risultati.

Quando sei motivato finanziariamente, come i proprietari dell'azienda, è meno probabile che tu spenda tutto il tuo tempo a pensare a come ridisegnare i vecchi e brutti sistemi legacy semplicemente perché ti infastidisce nel vedere if(true) nel codice. Quando ci sono i segni del dollaro in gioco (o laks, euro, ecc.), Allora è più probabile che tu pensi a come generare entrate invece di come spenderli.

DISCLAIMER: ho sperimentato questa esperienza come sviluppatore. I finanziari mi hanno fatto pensare a come fare soldi, e questo mi ha aiutato a pensare come un imprenditore.

Utilizzare le metriche complesse è destinato a fallire nella mia esperienza perché quando le persone si rendono conto di quale metrica è che inizieranno a personalizzare il proprio lavoro per soddisfare tale metrica in modi controproducenti.

Qualunque sia la metrica, linee di codice, frequenza di errori, numero di bug corretti; qualsiasi metrica obiettivo può essere giocata.

Per inciso, non penso davvero che i bonus siano una buona idea. Tendono a incentivare comportamenti scorretti: basta guardare a Wall Street.

Non lasciare che ti portino in una situazione di bonus in cui il bonus si basa su cosiddette misure oggettive.

In tutti i miei 25 anni (quasi 26 :-) ora) di IT in qualità di sviluppatore, non mi sono ancora imbattuto in una cosiddetta misura oggettiva che non può essere pervertita. Le linee di codice una volta erano la misura aurea, fino a quando la gente ha iniziato a scrivere commenti incredibilmente lunghi che non dicevano nulla. I check-in sono stati pervertiti semplicemente controllando ciascun file separatamente ...

Avrei postato lo stesso video di @Bobby Tables se avessi visto la tua domanda prima. Sono stati in situazioni in cui i bonuss erano parte del gioco. Tendono solo a rendere più difficile la collaborazione e a ottenere aiuto dai tuoi colleghi.

La tua gestione (e tu!) dovrebbe riflettere su ciò che vuoi stimolare nel team di sviluppo. E il sistema di bonus dovrebbe essere basato su questo. Sì, questo significa tratti e misure molto soggettivi, ma nonostante i ritiri delle valutazioni soggettive, sono in definitiva molto più benifici delle cosiddette misurazioni oggettive che promuovono l'esatto opposto dei comportamenti che vorresti vedere.

Dovrebbe esserci una sorta di valutazione dei lavoratori basata sulle qualità che sono davvero importanti per il tuo lavoro come sviluppatore. Il miglior sistema di bonus che ho trovato si basa sulle prestazioni della compagnia per tutti e si aggiusta su o giù in base alle valutazioni individuali.

Ad esempio: la compagnia ha raggiunto i suoi obiettivi per l'anno: tutti in linea di principio ricevono un salario mensile come bonus; ma la prospettiva economica è davvero bassa, quindi è dimezzata. Le valutazioni di tutti i lavoratori hanno qualità importanti per il loro lavoro, scalate da A (molto peggio di quanto previsto) a E (molto meglio di quanto previsto). Il lavoratore A riceve valutazioni in media di un C - > gli ottiene il bonus standard. Il lavoratore X riceve valutazioni medie di un D - > le ottiene il bonus standard più il 10%. Il lavoratore Z riceve valutazioni con una media di B - > ottiene il bonus standard meno il 10%.

Questo sembra funzionare meglio in quanto le valutazioni come questa possono essere orientate verso comportamenti che vorrebbero vedere, come la cooperazione, l'assistenza e l'addestramento di lavoratori meno esperti, la leadership, ecc. Funziona meglio quando le valutazioni sono preparate da qualcuno in una posizione di leadership diretta rispetto al lavoratore valutato. Ciò può significare il responsabile dello sviluppo, ma anche un leader di squadra senza ulteriori dichiarazioni gerarchiche.

Il valutatore, soprattutto quando non sono in contatto quotidiano con la persona valutata, dovrebbe sempre ricevere input dai collaboratori diretti e da altre persone che si occupano regolarmente di quella persona. L'input è ottenuto in modo informale in quanto le persone non abituate a valutare gli altri, di solito non amano l'idea di sentirsi responsabili dell'altezza di un'altra ricompensa.

Penso che le metriche dovrebbero essere basate su quale sia lo scopo dei bonus. In altre parole, quali sono gli obiettivi che l'azienda sta perseguendo offrendo dei bonus?

Ad esempio, se la base di codice ha un sacco di bug, potrebbe essere ragionevole avere una metrica come "se il numero di bug trovati nelle funzionalità che hai scritto in questo trimestre è del 10% in meno rispetto al trimestre precedente, riceverai un bonus. "

Semplici misure oggettive sono fuorvianti e imprecise. Le misure oggettive complesse sono leggermente meno imprecise, ma ancora più facili da "giocare" e fuorvianti.

Suggerisco qualche forma di voto o sondaggio tra il team di sviluppo. Per esempio, chiunque può votare (in modo anonimo) per i primi tre contributori a livello di gestione / supporto, livello senior e livello junior (ovviamente, non puoi votare per te stesso). I primi tre di ogni categoria ottengono dei bonus. È importante che i voti vengano riportati in modo completamente anonimo, ma ogni utente riceve solo X voti.

Varia lo schema esatto per abbinare il tuo ambiente. Alcune possibilità: ognuno riceve un bonus; l'importo varia in base ai risultati del sondaggio (con un premio minimo). Meno o più categorie. Aggiungi una categoria generale. Le diverse categorie ottengono diversi numeri di voti. Le persone ottengono diversi numeri di voti per la loro categoria. Ecc.