Il post sul blog di Jeff Atwood su Mechanical Turk di Amazon suggerisce che non dovrebbe offrire ricompense monetarie ma piuttosto una motivazione intrinseca , "motivazione che è guidata da un interesse o godimento nell'attività stessa ed esiste all'interno dell'individuo piuttosto che fare affidamento su qualsiasi pressione esterna".

In che modo un membro del team (un manager, un lead o uno sviluppatore) promuove la motivazione intrinseca in un team di software?

MODIFICA: Fornisci risposte complete. Condividi la tua esperienza personale con analisi obiettive.

EDIT # 2: per facilitare una discussione produttiva e sull'argomento, dovremmo presumere che la compensazione monetaria sia soddisfacente per lo sviluppatore.

Non uccidendolo . Scommetto che tutti coloro che lavorano da più di 5 giorni hanno incontrato abbastanza motivatori per riempire i libri. Tutti giurano, se ne hanno l'opportunità, faranno meglio. Ma in qualche modo, questi assassini persistono, e quelli che li implementano di solito continuano a pensare, sono migliori, 'ancora uno dei bravi ragazzi', ecc.

Quindi, secondo me, il modo migliore non è di cercare di fare del bene, ma di evitare di fare del male.

EDIT, modificato su richiesta:

La versione lunga

A mio avviso, la motivazione intrinseca è fortemente connessa all'identificazione con il lavoro / l'azienda.

L'identificazione viene da identificare , come in "rendere identico", così qualcuno che si identifica con il suo lavoro cerca di avere il minor numero di differenze possibile tra "fare il lavoro" e "fare la cosa che vuole".

Pertanto, tutto ciò che forza una decisione tra il beneficio della Società / del Team lavorando e il beneficio di se stessi è un potenziale killer della motivazione, e come tale, dovrebbe essere evitato.

Alcuni di quegli assassini che ho incontrato sono:

Comunicazioni interrotte: importa soprattutto come e a chi si dice qualcosa invece di cosa. La motivazione per fare la cosa giusta (ad res) è punita uccidendo il messaggero, ridendo di cassandra ed eseguendo pubblicamente l'atleta.

Segni: un sacco di cc, cc e to nelle e-mail, e una discrepanza tra le cose dette nelle riunioni e le cose dette in mensa.

Forma rispetto ai risultati: è importante soprattutto come viene svolto il lavoro, non ciò che produce. La motivazione per produrre qualcosa di valore viene uccisa non apprezzando la cosa prodotta e punendo la produzione. È molto più semplice non produrre nulla seguendo il protocollo.

Segni: "Facebook Blocker", orari di lavoro fissi, regolamenti sulla scrivania. (Penso che Jeff Atwood abbia scritto sth. Su "Furniture Police")

Noia / vicolo cieco: in questo lavoro, quando uno rimane, manca qualcosa, che si tratti dell'opportunità di imparare, di raggiungere una diversa area di competenza (ad es. Dalla programmazione alla progettazione) o di ottenere una paga che può provvedere a una famiglia . E più a lungo rimane, minori sono le opportunità.

La scelta è tra il miglioramento dell'azienda e il miglioramento di se stessi.

Segni: tutti sono conosciuti come "il ragazzo X", dove X è la cosa che ha fatto per sempre.

Come parte del ciclo di vita dello sviluppo del software

• Assegna i compiti giusti alle persone giuste (se possibile)
  • Ciò implica che vogliono innanzitutto l'attività
  • Altrimenti, considera che forse questa attività non dovrebbe essere eseguita
• Assegna compiti impegnativi
  • I programmatori sono persone creative e preferiranno avere un compito che è mentalmente impegnativo e non solo una rielaborazione di qualcosa che hanno già fatto.
  • Naturalmente puoi solo assegnare le attività che hai a portata di mano come parte delle tue esigenze, ma prova a identificare come ciascuna di queste esigenze può rappresentare una sfida e scegli lo sviluppatore giusto per essa. Se le tue esigenze sono sempre le stesse e noiose, c'è anche qualcosa da fare qui. Non c'è un motivatore intrinseco qui, ma c'è un punto intrinseco di fallimento e ridondanza.
• Uso giochi di integrazione / ispezione continua
  • Sono divertenti e motivazionali
  • Incoraggiano le persone a lottare per la perfezione
  • Non sono intrinseci in se stessi, ma fanno appello alla qualità interna dello sviluppo che vuole perfezionarsi, imparare e condividere, ma potrebbe aver bisogno di una spinta occasionale.
• Usa i wallboard (o radiatori ) per SCM, l'integrazione continua e gli strumenti di ispezione continua sono divertenti e motivazionali (ti servono comunque come parte della tua infrastruttura)
  • Fanno appello agli sviluppatori per gli stessi motivi del gioco CI
  • Anche senza l'aspetto competitivo, danno un senso di orgoglio e diritto agli sviluppatori che prendono parte a un progetto.
  • Permette loro di vedere l'evoluzione di un design più grande se fanno parte di una grande squadra.
  • Aiuta anche a ottenere i tuoi team (e non i tuoi sviluppatori, individualmente) a:
    • competere (tra progetti, sulla qualità del codice per instnace - non competere su LOCs ... )
    • collaborare (volendo costruire software che appartiene a una famiglia)
• Usa retrospettive
  • Aiutano a identificare i problemi in una collaborazione modo
  • Offrono agli sviluppatori un senso di appartenenza al progetto (e ai suoi errori)
  • Non assegnano né ricompensa né colpa (ma danno un senso di responsabilità )
• le revisioni del codice devono essere parte integrante del processo (o temeranno invece di abbracciarle).
  • Gli sviluppatori impareranno naturalmente a cercare e ad elogiare
  • Saranno più aperti alle critiche
• Consentire (e incoraggiare) critiche creative e costruttive
• Consentire (e incoraggiare) lo sviluppo personale
  • Sotto forma di progetti per animali domestici
  • Sotto forma di prototipi (che possono essere progetti di animali domestici)
  • Gli sviluppatori sono più felici quando non hanno bisogno di nascondersi nel loro ufficio
• Consentire (e incoraggiare) la condivisione delle conoscenze
• Consentire (e incoraggiare) gli sviluppatori a lucidare il proprio codice
  • Passare al compito successivo può essere eccitante, ma essere costretti ad abbandonare un compito su cui hai lavorato per un po 'senza finirlo in un livello soddisfacente di qualità è male per molte ragioni. Perdi questi sentimenti di cui sopra (orgoglio per il buon lavoro, artigianato, ecc ...) e perderai sulla qualità.
  • Permette agli sviluppatori di divertirsi mentre finiscono i loro compiti, sperimentare implementazioni alternative (potenzialmente vantaggioso per te se arrivano i benchmark)
• Ruota fastidiosi compiti tra team / singoli
  • Per garantire che più persone abbiano le competenze necessarie
  • Far sì che condividano il loro fardello e provino un po 'più di compassione per quelli che affrontano compiti ingrati in qualche momento (invece di indicare i loro colleghi con un "Ahah!") E che vogliono aiutarli

Fai tutto il possibile per evitare la codifica da cow-boy o l'effetto sottomarino: vuoi che i tuoi sviluppatori siano orgogliosi di ciò che fanno, godano ciò che fanno e si divertano a mostrarlo agli altri e far partecipare gli altri ai loro sforzi.

Anche per le attività di documentazione, che possono essere riepilogative per i programmatori, prova quanto segue, per rendere la documentazione più divertente per loro e collegarla alla sensazione di produrre un prodotto ben rifinito. La documentazione deve apparire come parte integrante del prodotto stesso, non solo come consegna formale.

• Consentire loro di utilizzare gli strumenti, i modelli e il processo che desiderano
  • impostarli prima dell'inizio del progetto e attenersi ad essi per coerenza
  • ma esaminali tra i progetti come parte della tua retrospettiva per assicurarti che il processo sia il più leggero e divertente possibile
  • usare un modello brutto (e soprattutto poco pratico) che ti viene imposto dal dipartimento marketing è un aspetto negativo
• Consentire loro di discutere i punti della documentazione che ritengono eccessivi
  • potrebbero avere ragione e aiutarti a ridurre il carico

Falli diventare insegnanti , evangelisti o qualsiasi altra cosa che li metta nella condizione di portare il know-how o la conoscenza agli altri, sia come parte del tuo SDLC che della tua cultura aziendale. Chiunque abbia avuto la possibilità di insegnare conosce la sensazione che procura, anche quando i tuoi studenti non mostrano segni di gratitudine ( beh, potresti pensare che li stai aiutando e in effetti essere un insegnante schifoso e tutto qui .. ma consideriamo comunque un caso generale ... ) e non ricevi alcun premio diretto. Inoltre, è allo stesso tempo potenziante e umiliante (troverai sempre qualcuno che ti dimostrerà che ti sbagli o ti combatterà su qualcosa).

Le sezioni seguenti delineano punti che non sono realmente intrinsecamente motivazionali.

Anche se potrebbero non essere direttamente correlati alla domanda, preferisco lasciarli elencati perché sono ancora, a mio avviso, buoni suggerimenti per aiutare indirettamente a promuovere questa motivazione intrinseca.

Come parte della tua cultura aziendale

• organizzare colloqui / sessioni regolari affinché gli sviluppatori possano condividere ...
  • ... conoscenza acquisita durante il lavoro sul progetto
  • ... conoscenza di tutto ciò che li rende attivi e appassionati di qualcosa
• fidati dei tuoi sviluppatori
• lasciare decisioni tecniche ai tecnici
  • renderli parte del processo decisionale
  • ascoltali (o non stupirti se stanno zitti)
• rendere le loro vite più facili e senza frustrazione:
  • buoni strumenti di sviluppo
  • buon hardware
  • buon ambiente
  • cibo gratis
  • stupidi giocattoli in giro
  • luoghi per discutere idee e luoghi per riflettere in silenzio

Per i principianti

• Delinea i traguardi raggiunti per i nuovi principianti (pensa ai livelli e ai premi in stile StackOverflow che devono "sbloccare")
• Assegna loro compiti nel loro livello di abilità, ma con sfide sufficienti

Penso che la maggior parte dei proprietari di imprese (co) manchi un punto qui.

Certo, vai avanti e fornisci i migliori strumenti che il denaro può comprare, metti gli sviluppatori nei propri uffici, distribuisci pasti gratuiti / birra in punto / viaggio in Venezuela / qualunque cosa.

Questi sono tutti vantaggi davvero fantastici , ma alla fine servono solo uno scopo: aumentare il profitto del proprietario (e apparentemente facendo "divertire" gli sviluppatori al lavoro). E va benissimo.

Ma, per tutti noi che hanno una vita fuori dal lavoro quotidiano, dico, sì, mi piacerebbe quei vantaggi per favore, ma non sono in alcun modo un sostituto per il mio bonus / ricompensa / 13 ° stipendio / qualunque cosa - la motivazione monetaria funziona abbastanza bene per me. Se non sembra funzionare, forse le persone che gestiscono l'azienda non distribuiscono abbastanza denaro a un ritmo ragionevole.

Sfortunatamente, gli studi mostrano ( vedi questo articolo di New Scientist , abbonamento richiesto per il testo completo) che il denaro non è un grande motivatore per gli sforzi creativi. In effetti può rendere le persone meno impegnative.

Quindi il modo migliore per motivare le persone è aiutarle a credere che il lavoro che stanno svolgendo non è fondamentale per la loro sopravvivenza. Ciò consentirà loro di assumersi maggiori rischi e quindi di essere più creativi.

Come dovresti procedere?

Essenzialmente il problema sorge a causa di cose come la retribuzione legata alle prestazioni. Le persone hanno bisogno di sapere che ciò che stanno facendo è giusto, ma non è necessario che dipenda da ciò la dimensione del loro pacchetto retributivo.

Se vuoi motivare le persone con denaro, fallo per cose banali come prestare attenzione alle riunioni.

La creatività è favorita dall'essere in un ambiente in cui la sperimentazione è consentita e non punita a causa del mancato raggiungimento di un obiettivo o altro.

Quello che vuoi è bilanciare la sperimentazione con l'implementazione di metodi collaudati. Quindi inverti il ​​problema. ad es. per ogni N problemi risolti o per ogni insignificante funzione di segnalazione implementata, puoi giocare con alcune nuove tecnologie o cercare nuovi modi di risolvere vecchi problemi.

Se ci sono soldi per i bonus, invece usali per andare in conferenze (a cui il tuo team vuole andare), o mettili verso una sorta di progetto extra-business sperimentale / interessante (che il tuo team vuole essere coinvolto) per comprare attrezzature.

Confidando che i loro sviluppatori facciano la cosa giusta

La maggior parte degli sviluppatori proverà a sviluppare prodotti di qualità se gli verranno fornite le strutture per farlo. Se uno sviluppatore richiede attrezzature più veloci o monitor migliori o condizioni di lavoro silenziose, lavora per fornirle.

La motivazione dipende dagli atteggiamenti verso i compiti che devono essere svolti. Se abbiamo l'atteggiamento di brillare o eccellere in un compito, potremmo effettivamente fare di peggio. Ripensa ai giorni in cui fai i test a scuola o fai parte di un club sportivo, dove volevi eccellere o vincere la partita. Una mentalità prestazionale si traduce in una pressione che spesso ci ostacola per esibirci davvero bene o per trovare soluzioni creative (vedi Dan Pink su Motivation ). Pertanto, l'utilizzo di premi basati sulla propria prestazione, può effettivamente portare a una motivazione meno intrinseca nello svolgere il compito.

Contrariamente a una mentalità da prestazione, c'è un orientamento al lavoro basato su una mentalità di apprendimento . Qui, il risultato non è di per sé importante, ma il processo di svolgere il compito e comprendere il contesto di un compito. Nell'analogia sportiva, questo è quando cerchi solo di migliorare un po '. Non ci si può aspettare di vincere, dare il meglio e imparare dai fallimenti. Migliorare la comprensione di eventuali fallimenti, si traduce in ricchezza personale e conoscenza e può aumentare la nostra motivazione intrinseca a lungo termine. Questo tipo di mentalità è discusso dal Dr. Steve Ritter (CMU) e Carol Dweck (Stanford).

Lasciami interpretare l'avvocato del diavolo.

Le persone sono creature molto egoistiche. Si preoccupano principalmente di se stessi. Molto difficile cambiarlo. Pertanto è necessario esplorare questa debolezza e trasformarla a proprio vantaggio.

Quando le persone possiedono "un interesse o un godimento nell'attività stessa", ciò significa che perseguono il loro interesse personale per soddisfare la loro curiosità o apprendere qualche strumento. Perché imparare qualche strumento? Utilizzarlo nella loro programmazione personale (auto-orientato) o trasformarlo in un vantaggio di marketing (avido profitto). Non c'è quasi traccia di altruismo.

Per "favorire la motivazione intrinseca" devi mettere i tuoi obiettivi in ​​una dolce grazia che i membri del team vorrebbero avere. Combina ciò che è prezioso per l'azienda (conoscenza ed esperienza in alcuni settori tecnici o non tecnici) con ciò che è prezioso per l'individuo personalmente (certificazioni rinomate, titolo professionale, aumento di stipendio). Pensa in questa direzione.

E ad essere sinceri, sì, ci sono ovviamente persone altruiste. Senza di loro il mondo sarebbe già caduto. Ma poi non sono necessariamente interessati ad unirsi ai tuoi ranghi, possono sempre trovare un altro modo per contribuire alla società (open source, progetti personali, fornire assistenza nei forum ecc.). Quindi sei tornato alle basi, come lubrificare i tuoi programmatori avidi per farli muovere.

Penso che il signor Atwood stia dicendo che dovresti assumere persone interessate ai problemi che risolverai . La loro motivazione deriva da un interesse preesistente, che è intrinseco alla persona. Non penso che tu possa favorire la motivazione intrinseca, penso che puoi solo appellartene.

Il risarcimento è ancora importante, ma dato lo stesso compenso preferirei lavorare in un posto che ha problemi a cui sono interessato. Lavorerò naturalmente e involontariamente più duramente perché ho questo interesse.

È normale che i membri di una squadra siano motivati ​​in modo diverso. Alcune persone lavorano per motivazioni estrinseche (ad es. Denaro) e altre per motivazioni intrinseche (ad es. Software di qualità).

Tuttavia, questi membri del team devono essere in grado di lavorare insieme e condividere i propri punti di forza.

Uno sviluppatore è accettabile se produce lavoro di qualità; tuttavia, se non apprezzano veramente il loro lavoro, sarebbe difficile impiegarli come leader. Un tratto importante della leadership è l'entusiasmo, perché spinge gli altri a godersi il compito da svolgere.

Un'altra dinamica importante è quella dell'interazione sociale sana e regolare. Joel Spolsky ha recentemente scritto sul blog i vantaggi dei pranzi di gruppo : "Mangiare insieme è una parte fondamentale di ciò che significa essere umani e cosa significa avere un posto di lavoro umano ..." Anche se lo sviluppatore stereotipato è introverso, la solitudine è demoralizzante e rende difficile la programmazione.

In sintesi, attraverso una leadership entusiasta e un incoraggiante cameratismo , la motivazione intrinseca che alcuni hanno e manca ad altri può essere trasferita e condivisa dal team.

A mio avviso, la motivazione intrinseca si associa all'ultimo bisogno degli individui nella gerarchia dei bisogni di Maslow; non è un bisogno in sé, ma uno che viene fuori dall'auto-realizzazione. Mentre questa gerarchia potrebbe non essere applicabile in tutte le circostanze, ignorare le basi di questa gerarchia spesso porta alla mancanza di motivazione intrinseca.

Mentre la maggior parte delle organizzazioni si sforza di convincere gli individui a raggiungere il loro ultimo bisogno, la maggior parte non lo fa per non concentrarsi sui bisogni in fondo alla gerarchia.

La mia opinione sull'articolo e la teoria alla base è che è un tentativo da parte dei proprietari di attività di svalutare il costo del lavoro e far credere alle persone che "non hai bisogno di tutto questo denaro per essere felice, quindi non importa se non ti diamo mai un aumento o se ti assumiamo per un tasso inferiore a quello di mercato. Dovresti essere felice di avere un lavoro, figuriamoci uno così coinvolgente come questo, quindi impegnati già con esso! Ora ricorda, avresti meglio venire sabato dalle 6 a mezzanotte perché è quello che fa un'ape operaia "fidanzata". Avrai una bella carezza in testa e un "buon lavoro!" una volta che hai finito di ucciderti per il progetto ".

Lo studio afferma che non importa quanto si paga qualcuno oltre l'importo che li rende "a proprio agio" in quanto non devono preoccuparsi di come pagheranno le loro bollette o metteranno il cibo sul tavolo .. quindi quanto costa? 40k / anno USD? 30k?

Per quanto riguarda la promozione della motivazione intrinseca, sono d'accordo con @keppala. La motivazione intrinseca viene dall'interno. Il meglio che puoi fare è non farlo uscire dai dipendenti che lo hanno.