Un rappresentante interno, una votazione e badge possono incoraggiare buone pratiche di programmazione?

Ricompensa extra come denaro, badge o rappresentante funzioneranno, a breve termine , come diete e qualsiasi altro sistema di ricompensa / punizione.

Ricompensa intrinseca , come scopo & l'autonomia dovrebbe invece essere utilizzata e fornire più risultati a lungo termine. È molto più difficile metterlo in pratica rispetto ai semplici sistemi di ricompensa estrinseca, ma paga.

Molti esperti hanno fatto ricerche sull'argomento. Ecco i miei due preferiti:

Daniel Pink ha fatto una ottima presentazione a TED sull'argomento che è facile da guardare e capire.

Alfie Kohn , autore di Punita dai premi , ha scritto sull'argomento:

Sure, bribes and threats can produce temporary compliance. Offer a reward to adults for going to the gym, or to children for picking up a book, and it may work -- for a while. But they come to think of themselves as extrinsically motivated, so when the reward is no longer available there's no reason to continue. Indeed, they may wind up less interested in exercising or reading than they were before.

Un altro problema con i premi (e le punizioni) è che modificherà il modo in cui le persone si comportano. Per esempio, se dai il bonus al tuo dipendente, saranno focalizzati sull'ottenimento di quei bonus, indipendentemente dagli altri obiettivi (aziendali). Creerà individualismo e competizione tra reparti e dipendenti. Il risentimento avrà luogo e tutti guarderanno tutti. Soprattutto quando uno dei tuoi obiettivi è "aiutare a misurare le prestazioni individuali".

Il resto del dipendente può confutare le regole del gioco e uscire. L'aumento del turnover diventerà quindi un nuovo problema.

Tieni presente che molti suggerimenti su come migliorare la motivazione sono stati fatti in questa community .

Sì, potrebbe

Ma solo se lo progettate con molta attenzione, altrimenti potrebbe ritorcersi contro. Ho fatto alcuni commenti ma ho pensato di riassumere la mia posizione

Per la reputazione l'obiettivo principale dovrebbe essere quello di fornire una misurazione che i dipendenti possano utilizzare per tracciare il loro miglioramento delle competenze nel tempo. Progettatelo con molta attenzione tenendo presente questo, la cosa difficile è trovare dei buoni modi per misurare le abilità, non posso farlo da capo.

I badge sono principalmente una cosa "divertente", li terrei principalmente lontani da problemi più orientati all'abilità. I distintivi come "questo gufo notturno di una settimana" o un gruppo "Distintivo spedito!" Andrebbero bene. Se hai alcuni distintivi basati sull'abilità come "Risolti molti bug" o "Segnalati molti bug", pensa molto attentamente a come potrebbe essere percepito e giocato. I badge dovrebbero essere più utili a evidenziare il comportamento che a promuoverlo. Assicurati di avere badge di squadra e individuali.

Consiglio vivamente contro i badge negativi, queste cose dovrebbero essere divertenti e rendere le persone timide di commettere errori è pericoloso. Generare un'e-mail utile e amichevole per quei casi.

Consiglio vivamente di non permettere loro di decidere e votare sui badge. Le persone possono inviare i loro suggerimenti per i badge, ma dal momento che il loro effetto sulle persone può essere piuttosto severo, i badge utilizzati dovrebbero essere presi da un'attenta decisione di una persona che sa quello che stanno facendo e non il voto di maggioranza.

Le recensioni di codice sono un'idea interessante e credo che uno dei modi in cui potresti generare un valore di abilità. Evidenziare il codice e discuterlo potrebbe essere davvero utile. Tuttavia, potrebbe ritorcersi contro, se tutti sanno che stanno giudicando potenzialmente tutto ciò che scrivono lo sviluppo può rallentare a passo d'uomo. Soprattutto con lo sviluppo iterativo dove a volte scrivi qualcosa velocemente e poi refactoring non vuoi che questo comportamento.

Forse ciò potrebbe essere compensato sia dalla persona che invia il codice stesso che da qualcun altro solo in grado di inviare il codice di una certa età. Tuttavia può essere difficile sapere quali effetti ci saranno

Alla fine penso che dovrai provarlo e vedere cosa funziona e cosa no, c'è un buon libro chiamato La realtà è rotta che potrebbe essere interessante. Anche il libro di Daniel Pinks "Drive" è una lettura obbligata.

A mio parere, NO , poiché misura non la buona pratica in sé, ma un sintomo (se altri pensano è una buona pratica).

Parafrasare un libro di Uncle Bob (ho dimenticato il titolo): un buon codice sembra quasi senza sforzo, rende il problema un aspetto banale, come se il linguaggio fosse stato creato per scriverlo.

Nella mia esperienza, tale codice passa inosservato, e solo dopo un lungo periodo arriva all'attenzione, che questo codice non ha mai creato problemi, e forse uno si ricorda, che il problema era, prima dell'introduzione del codice, un enorme pasticcio di incertezza e vaghezza. Il codice che viene elogiato nelle recensioni è in genere quello che i revisori considerano una buona giornata quando non sono dell'umore giusto per il nitpick, e questo ha il minor numero di modifiche.

L'idea porterebbe una nuova dinamica alla squadra. Se ritieni che la squadra sia in difficoltà, questo è un buon modo per scuotere le cose.

Ricorda solo che non saranno tutti gli unicorni e gli arcobaleni. Ad alcuni non piacerà l'iniziativa, quindi la produttività / qualità complessiva potrebbe risentirne. Tuttavia, questo rischio potrebbe valerne la pena. Dipende dalla tua situazione.

Suggerisco di utilizzare la motivazione estrinseca (quello che stai proponendo è una forma di motivazione estrinseca) per motivare le persone a fare cose "meccaniche", ripetitive e noiose, come ad esempio:

• Mostra in tempo per le riunioni
• Ottenere fogli di lavoro inviati in tempo
• Aggiornamento della documentazione
• Condivisione delle informazioni con il team

Non lo userei per motivazioni su qualsiasi tipo di lavoro che richiede creatività o dove la qualità non può essere misurata oggettivamente. Ad esempio, se hai una persona che crea i widget e puoi convalidare meccanicamente se una parte è buona o cattiva e hai un processo che non consente di realizzare una parte a meno che non segua il processo approvato, allora è produttivo motivare il lavoratore con premi estrinseci per la produttività, perché il processo non permetterà loro di prendere scorciatoie per rendere più unità a scapito della qualità.

Se non hai queste tutele, allora il tuo tentativo di motivazione estrinseca sicuramente si ritorcerà contro. La programmazione rientra esattamente in questa categoria: non siamo in grado di misurare in modo affidabile la qualità del software. Questo perché quando si crea un widget, questo lascia la fabbrica e non influisce sul lavoro che si svolge sul prossimo widget, ma quando si crea un software, è necessario continuare a rielaborarlo più e più volte. Cose che ora hai effetti a lungo termine. Sono questi effetti a lungo termine che sono molto importanti ma non possono essere misurati. La motivazione intrinseca è un motivatore molto più utile per questo genere di cose.

Ciò significa:

• Consenti alle persone di assumersi la responsabilità del proprio lavoro
• Incoraggiare le persone a parlare tra loro su ciò che funziona bene e cosa no
• Mostra un genuino apprezzamento per il lavoro delle persone

Parte di ciò che rende questo lavoro è il gran numero di partecipanti che non si conoscono o che devono lavorare quotidianamente. Penserei che in un piccolo gruppo, sarebbe più un modo di far funzionare il sistema per sembrare buono o per far sembrare cattiva la concorrenza per la promozione. Questo è il motivo per cui le valutazioni formali tra pari sono spesso un sistema scadente. In un piccolo gruppo le persone con il miglior rappresentante saranno quelle che sono i più politicamente astuti e non i migliori programmatori.

La risposta breve è, sì, potrebbe funzionare.

La risposta leggermente più lunga è, sì, potrebbe funzionare, ma potrebbe anche ritorcersi contro.

Oltre ad essere un programmatore professionista, sono anche un analista di comportamento amatoriale.

Uno dei risultati principali della moderna scienza comportamentale è che il comportamento è strongmente influenzato dalle sue conseguenze.

Se controlli le conseguenze, puoi influenzare il comportamento in una certa misura. Il livello dipende da quanto siano importanti le conseguenze specifiche per ogni individuo il cui comportamento si sta tentando di cambiare e da quanto sia facile per loro evitare le conseguenze e trovare gli altri per cui sono disposti a lavorare.

Come programmatore professionista, una conseguenza della scrittura del codice è che mi viene pagato; smettere di pagarmi, e smetterei di presentarmi presto. La paga è una conseguenza molto importante per me (sto allevando una famiglia), e nella mia attuale azienda non ci sono altre conseguenze per cui sarei disposto a lavorare invece di essere pagato.

Se tu fossi il mio capo, dovresti decidere quali conseguenze (incentivi, rinforzi) offrirmi. Ma non puoi decidere come li percepisco. Ad esempio, il mio capo potrebbe decidere di offrire uno spazio di parcheggio speciale se sono stato selezionato come "Coder del mese". Se vivessi a San Francisco o New York City e guidassi una macchina, potrei essere disposto a lavorare per questo. Ma dove vivo ora, il parcheggio non è un problema, e posso comunque andare a piedi al lavoro.

Secondo la mia esperienza, il rischio maggiore che correte nell'implementare un programma come SO sul posto di lavoro è che potreste essere percepiti come offrire voti da parte dei compagni invece di pagare alle persone quello che valgono.