motto:
Il marito, guardando i bambini sporchi, dice alla moglie: allora, li laviamo o ne facciamo nascere di nuovi?
Sotto il taglio c'è la seconda parte di un articolo del nostro team leader, nonché direttore dello sviluppo prodotto RAS, Igor Marnat, sulle peculiarità della motivazione dei programmatori. La prima parte dell'articolo può essere trovata qui -
Nella prima parte dell’articolo ho toccato i due livelli inferiori della piramide di Maslow: bisogni fisiologici, bisogni di sicurezza, comodità e costanza per passare al livello successivo, il terzo, ovvero:
III - Bisogno di appartenenza e di amore
Sapevo che la mafia italiana si chiamava “Cosa Nostra”, ma sono rimasto molto colpito quando ho scoperto come si traduce “Cosa Nostra”. “Cosa Nostra” tradotto dall'italiano significa “La nostra attività”. La scelta del nome è molto vincente per la motivazione (lasciamo da parte la professione, in questo caso ci interessa solo la motivazione). Una persona di solito vuole far parte di una squadra, fare qualche grande, comune, la nostra attività.
Grande importanza è data alla soddisfazione del bisogno di appartenenza e di amore nell'esercito, nella marina e in tutte le grandi formazioni paramilitari. E, come vediamo, nella mafia. Questo è comprensibile, perché è necessario forzare le persone che hanno poco in comune, che inizialmente non formano una squadra di persone che la pensano allo stesso modo, che sono riunite mediante la coscrizione (non volontaria), che hanno diversi livelli di istruzione, diversi valori personali , per dedicare letteralmente la propria vita, a rischio mortale, a qualche causa comune, affidare la propria vita a un compagno d'armi.
Questa è una motivazione molto forte; per la maggior parte delle persone è estremamente importante sentirsi parte di qualcosa di più grande, sapere di far parte di una famiglia, di un paese, di una squadra. Nell'esercito, le uniformi, i vari rituali, le sfilate, le marce, gli stendardi e così via servono a questi scopi. Più o meno gli stessi fattori sono importanti per qualsiasi squadra. I simboli, il marchio aziendale e i colori aziendali, gli accessori e i souvenir sono importanti.
È importante che gli eventi significativi abbiano una propria incarnazione visibile a cui possono essere associati. Al giorno d'oggi è piuttosto normale per un'azienda avere i propri prodotti, giacche, magliette, ecc. Ma è importante valorizzare anche il team interno all’azienda. Spesso rilasciamo magliette in base ai risultati di un rilascio, che vengono distribuiti a tutti coloro che sono coinvolti nel rilascio. Alcuni eventi, celebrazioni congiunte o attività con tutta la squadra sono un altro importante fattore di motivazione.
Oltre agli attributi esterni, molti altri fattori influenzano il sentimento di appartenenza ad una squadra.
In primo luogo, la presenza di un obiettivo comune che tutti comprendono e condividono una valutazione della sua importanza. I programmatori di solito vogliono capire che stanno facendo una cosa interessante e lo stanno facendo insieme, come una squadra.
In secondo luogo, la squadra deve disporre di uno spazio di comunicazione in cui sia presente tutta la squadra e che appartenga solo ad essa (ad esempio, una chat nel messenger, sincapp periodici della squadra). Oltre alle questioni lavorative, alla comunicazione informale, a volte alla discussione di eventi esterni, alla luce off-top, tutto ciò crea un senso di comunità e squadra.
In terzo luogo, vorrei evidenziare l'introduzione di buone pratiche ingegneristiche all'interno del team, la volontà di elevare gli standard rispetto a quelli accettati in azienda. Implementare i migliori approcci accettati nel settore, prima nel team, e poi nell’azienda nel suo insieme, dà al team l’opportunità di sentirsi in qualche modo avanti rispetto agli altri, aprendo la strada, questo crea un senso di appartenenza ad una bella squadra.
Il senso di appartenenza è influenzato anche dalla partecipazione del team alla pianificazione e alla gestione. Quando i membri del team sono coinvolti nella discussione degli obiettivi del progetto, dei piani di lavoro, degli standard del team e delle pratiche ingegneristiche e nei colloqui con i nuovi dipendenti, sviluppano un senso di partecipazione, proprietà condivisa e influenza sul lavoro. Le persone sono molto più disposte a mettere in pratica le decisioni prese e espresse da loro stesse rispetto a quelle proposte da altri, anche se sono praticamente in sintonia.
Compleanni, anniversari, eventi significativi nella vita dei colleghi: una pizza in comune, un piccolo regalo da parte del team regalano una calda sensazione di coinvolgimento e gratitudine. In alcune aziende è consuetudine apporre piccoli cartelli commemorativi per 5, 10, 15 anni di lavoro in azienda. Da un lato, non credo che questo mi motivi così tanto per nuovi traguardi. Ma, ovviamente, quasi tutti saranno contenti di non essersi dimenticati di lui. Questo è uno di quei casi in cui l'assenza di un fatto demotiva piuttosto che la sua presenza. D'accordo, può essere un vero peccato se LinkedIn te lo ricordasse la mattina e si congratulasse con te per il tuo decimo anniversario sul posto di lavoro, ma nessun collega dell'azienda si congratulasse con te o si ricordasse di te.
Naturalmente, un punto significativo è il cambiamento nella composizione della squadra. È chiaro che anche se l'arrivo o la partenza di qualcuno dal team viene annunciato in anticipo (ad esempio, nella newsletter dell'azienda o del team o in una riunione del team), ciò non motiva particolarmente nessuno a nuovi traguardi. Ma se un bel giorno vedi una nuova persona accanto a te, o non vedi quella vecchia, può essere una sorpresa e, se te ne vai, decisamente spiacevole. Le persone non dovrebbero scomparire silenziosamente. Soprattutto in un team distribuito. Soprattutto se il tuo lavoro dipende da un collega di un altro ufficio che improvvisamente si alza e scompare. Vale sicuramente la pena informare la squadra separatamente in anticipo di tali momenti.
Un fattore importante, che in inglese si chiama proprietà (la traduzione letterale di “possesso” non ne riflette appieno il significato). Questo non è un sentimento di proprietà, ma piuttosto un sentimento di responsabilità per il tuo progetto, quella sensazione quando ti associ emotivamente al prodotto e il prodotto a te stesso. Ciò corrisponde più o meno alla preghiera del Marine nel film “Full Metal Jacket”: “Questo è il mio fucile. Esistono molti fucili simili, ma questo è il mio. Il mio fucile è il mio migliore amico. Lei è la mia vita. Devo imparare a possederlo nello stesso modo in cui possiedo la mia vita. Senza di me, il mio fucile è inutile. Sono inutile senza il mio fucile. Devo puntare dritto con il fucile. Devo sparare con maggiore precisione rispetto al nemico che sta cercando di uccidermi. Devo sparargli prima che lui spari a me. Lascia che sia così... ".
Quando una persona lavora a lungo su un prodotto, ha l'opportunità di assumersi la piena responsabilità della sua creazione e sviluppo, di vedere come una cosa funzionante nasce dal "nulla", come le persone la usano, nasce questa sensazione potente. I team di prodotto che lavorano insieme per lungo tempo su un progetto sono solitamente più motivati e coesi rispetto ai team che si riuniscono per un breve periodo di tempo e lavorano in modalità catena di montaggio, passando da un progetto all'altro, senza la piena responsabilità dell'intero prodotto , dall'inizio alla fine.
IV. Necessità di riconoscimento
Una parola gentile fa piacere anche al gatto. Tutti sono motivati dal riconoscimento dell'importanza del lavoro svolto e dalla sua valutazione positiva. Parla con i programmatori, fornisci loro feedback periodici, celebra un lavoro ben fatto. Se si dispone di un team ampio e distribuito, gli incontri periodici (i cosiddetti one to one) sono perfetti allo scopo; se il team è molto piccolo e lavora insieme a livello locale, questa opportunità viene solitamente fornita senza incontri speciali in calendario (anche se quelli periodici a uno è tutto Serve ancora, puoi farlo solo meno spesso). Questo argomento è ben trattato nei podcast per manager su manager-tools.com.
Tuttavia, vale la pena tenere a mente le differenze culturali. Alcuni approcci familiari ai colleghi americani non sempre funzioneranno con quelli russi. Il livello di cortesia accettato nella comunicazione quotidiana nei team dei paesi occidentali inizialmente sembra eccessivo ai programmatori russi. Una certa franchezza caratteristica dei colleghi russi può essere percepita come maleducazione dai colleghi di altri paesi. Questo è molto importante nella comunicazione in una squadra interetnica, molto è stato scritto su questo argomento, il manager di una squadra del genere deve ricordarlo.
Le dimostrazioni delle funzionalità, in cui i programmatori mostrano le funzionalità sviluppate durante uno sprint, sono una buona pratica per soddisfare questa esigenza. Oltre al fatto che questa è un'ottima opportunità per liberare i canali di comunicazione tra i team, presentare nuove funzionalità ai product manager e ai tester, è anche una buona opportunità per gli sviluppatori di mostrare i risultati del loro lavoro e indicarne la paternità. Bene, e perfeziona le tue capacità di parlare in pubblico, ovviamente, il che non è mai dannoso.
Sarebbe una buona idea celebrare il contributo significativo di colleghi particolarmente illustri con certificati, segni commemorativi (almeno una parola gentile) nelle riunioni di squadra congiunte. Le persone di solito apprezzano molto tali certificati e segni commemorativi, li portano con sé quando si spostano e generalmente si prendono cura di loro in ogni modo possibile.
Per evidenziare un contributo più significativo e a lungo termine al lavoro della squadra, all'esperienza e alla competenza accumulate, viene spesso utilizzato un sistema di gradi (anche in questo caso si può tracciare un'analogia con il sistema dei gradi militari nell'esercito, che, oltre a ad assicurare la subordinazione, serve anche a questo scopo). Spesso i giovani sviluppatori lavorano il doppio per ottenere nuove stelle sulle loro spalle (ad esempio passare da sviluppatore junior a sviluppatore a tempo pieno, ecc.).
Conoscere le aspettative dei tuoi dipendenti è fondamentale. Alcuni saranno più motivati da un voto alto, dalla possibilità di essere chiamati, ad esempio, architetto, mentre altri, al contrario, saranno indifferenti ai voti e ai titoli e considereranno l'aumento di stipendio un segno di riconoscimento da parte dell'azienda. . Comunicare con le persone per capire cosa vogliono e quali sono le loro aspettative.
Una dimostrazione di riconoscimento, un livello di fiducia più elevato da parte del team, può essere data dando più libertà di azione o coinvolgimento in nuovi ambiti lavorativi. Ad esempio, dopo aver acquisito una certa esperienza e raggiunto determinati risultati, un programmatore, oltre a implementare le sue funzionalità secondo le specifiche, può lavorare sull'architettura di cose nuove. Oppure lasciati coinvolgere in nuove aree che potrebbero non essere direttamente correlate allo sviluppo: automazione dei test, implementazione delle migliori pratiche ingegneristiche, aiuto nella gestione dei rilasci, partecipazione a conferenze, ecc.
V. Il bisogno di cognizione e autorealizzazione.
Molti programmatori si concentrano su diversi tipi di attività di programmazione in diverse fasi della loro vita. Ad alcune persone piace fare apprendimento automatico, sviluppare nuovi modelli di dati, leggere molta letteratura scientifica per lavoro e creare qualcosa di nuovo da zero. Un altro è più vicino al debug e al supporto di un'applicazione esistente, in cui è necessario scavare in profondità nel codice esistente, studiare log, stack trace e captcha di rete per giorni e settimane e non scrivere quasi nessun nuovo codice.
Entrambi i processi richiedono un grande sforzo intellettuale, ma il loro risultato pratico è diverso. Si ritiene che i programmatori siano riluttanti a supportare le soluzioni esistenti; sono piuttosto motivati a svilupparne di nuove. C'è un pizzico di saggezza in questo. D'altra parte, il team più motivato e unito con cui abbia mai lavorato si dedicava al supporto di un prodotto esistente, trovando e correggendo i bug dopo che il team di supporto li aveva contattati. I ragazzi vivevano letteralmente per questo lavoro ed erano pronti per uscire il sabato e la domenica. Una volta abbiamo affrontato con entusiasmo un altro problema urgente e complesso, la sera del 31 dicembre o il pomeriggio del 1° gennaio.
Diversi fattori hanno influenzato questa alta motivazione. Innanzitutto si trattava di un’azienda con un grande nome nel settore, a cui il team si associava (vedi “La necessità di affiliazione”). In secondo luogo, erano l’ultima frontiera, dietro di loro non c’era nessuno, a quel tempo non esisteva un team di prodotto. Tra loro e i clienti c'erano due livelli di supporto, ma se il problema li raggiungeva, non c'era nessun posto dove ritirarsi, nessuno era dietro di loro, l'intera azienda era con loro (quattro giovani programmatori). In terzo luogo, questa grande azienda aveva clienti molto grandi (governi nazionali, aziende automobilistiche e aeronautiche, ecc.) e installazioni su larga scala in diversi paesi. Di conseguenza, problemi sempre complessi e interessanti, problemi semplici sono stati risolti con il supporto dei livelli precedenti. In quarto luogo, la motivazione del team è stata fortemente influenzata dal livello professionale del team di supporto con cui hanno interagito (c'erano ingegneri molto esperti e tecnicamente capaci) e siamo sempre stati fiduciosi nella qualità dei dati che hanno preparato e delle analisi che hanno effettuato , eccetera. In quinto luogo, e penso che questo sia il punto più importante, la squadra era molto giovane, tutti i ragazzi erano all'inizio della loro carriera. Erano interessati a studiare un prodotto ampio e complesso, risolvendo problemi seri che erano nuovi per loro in un nuovo ambiente, cercavano di eguagliare professionalmente il livello dei team, dei problemi e dei clienti circostanti. Il progetto si è rivelato un'ottima scuola, tutti in seguito hanno fatto una buona carriera in azienda e sono diventati leader tecnici e dirigenti senior, uno dei ragazzi ora è responsabile tecnico presso Amazon Web Services, l'altro alla fine è passato a Google e tutti di loro ricordano ancora questo progetto con affetto.
Se questo team fosse composto da programmatori con 15-20 anni di esperienza alle spalle, la motivazione sarebbe diversa. Naturalmente l’età e l’esperienza non sono fattori determinanti al 100%; tutto dipende dalla struttura della motivazione. In questo caso particolare, la voglia di conoscenza e di crescita dei giovani programmatori ha dato ottimi risultati.
In generale, come abbiamo già accennato più volte, devi conoscere le aspettative dei tuoi programmatori, capire chi di loro vorrebbe ampliare o cambiare il proprio campo di attività e tenere conto di queste aspettative.
Oltre la piramide di Maslow: visibilità dei risultati, gamification e competizione, niente cazzate
Ci sono altri tre punti importanti riguardanti la motivazione dei programmatori che meritano sicuramente di essere menzionati, ma inserirli nel modello dei bisogni di Maslow sarebbe troppo artificiale.
Il primo è la visibilità e la vicinanza del risultato.
Lo sviluppo del software è solitamente una maratona. I risultati degli sforzi di ricerca e sviluppo diventano visibili dopo mesi, a volte anni. È difficile raggiungere una meta che è ben oltre l’orizzonte, la mole di lavoro è terrificante, la meta è lontana, non chiara e non visibile, “la notte è buia e piena di orrori”. È meglio spezzare la strada in parti, creare un percorso verso l'albero più vicino che sia visibile, raggiungibile, i contorni siano chiari e non sia lontano da noi - e raggiungere questo obiettivo vicino. Vogliamo fare uno sforzo di diversi giorni o settimane, ottenere e valutare il risultato, quindi andare avanti. Pertanto, vale la pena suddividere il lavoro in piccole parti (gli sprint in agile servono bene a questo scopo). Abbiamo completato parte del lavoro - registrato, espirato, discusso, punito il colpevole, premiato l'innocente - possiamo iniziare il ciclo successivo.
Questa motivazione è in una certa misura simile a quella che sperimentano i giocatori quando completano i giochi per computer: ricevono periodicamente medaglie, punti, bonus man mano che completano ogni livello; questa può essere chiamata “motivazione alla dopamina”.
Allo stesso tempo, la visibilità del risultato è letteralmente importante. Una funzionalità chiusa nell'elenco dovrebbe diventare verde. Se il codice viene scritto, testato, rilasciato, ma non vi è alcun cambiamento nello stato visivo visibile al programmatore, si sentirà incompleto, non avrà alcun senso di completamento. In uno dei team del nostro sistema di controllo della versione, ogni patch ha attraversato tre fasi successive: la build è stata assemblata e i test sono stati superati, la patch ha superato la revisione del codice, la patch è stata unita. Ogni fase era contrassegnata visivamente con un segno di spunta verde o una croce rossa. Una volta che uno degli sviluppatori si è lamentato del fatto che la revisione del codice richiedeva troppo tempo, i colleghi hanno dovuto accelerare e le patch sono rimaste in sospeso per diversi giorni. Ho chiesto, cosa cambia effettivamente per lui? Dopotutto, quando il codice viene scritto, la build viene assemblata e i test vengono superati, non è necessario prestare attenzione alla patch inviata se non ci sono commenti. I colleghi stessi lo esamineranno e lo approveranno (se, ancora una volta, non ci sono commenti). Lui rispose: “Igor, voglio ricevere le mie tre spunte verdi il prima possibile”.
Il secondo punto è gamification e competizione.
Durante lo sviluppo di uno dei prodotti, il nostro team di ingegneri aveva l'obiettivo di assumere una posizione di rilievo nella comunità di uno dei prodotti open source, per entrare nella top-3. A quel tempo, non esisteva un modo oggettivo per valutare la visibilità di qualcuno nella comunità; ciascuna delle grandi aziende partecipanti poteva affermare (e periodicamente affermare) di essere il contributore numero uno, ma non esisteva un modo reale per confrontare i contributi dei partecipanti. tra loro, per valutarne nel tempo la dinamica. Di conseguenza, non c'era modo di fissare un obiettivo per la squadra che potesse essere misurato in alcuni pappagalli, valutare il grado del suo raggiungimento, ecc. Per risolvere questo problema, il nostro team ha sviluppato uno strumento per misurare e visualizzare il contributo delle aziende e dei singoli contributori . Dal punto di vista motivazionale si è rivelata semplicemente una bomba. Non erano solo gli ingegneri e i team a monitorare costantemente i propri progressi e quelli dei colleghi e dei concorrenti. Anche il top management della nostra azienda e tutti i principali concorrenti hanno iniziato la loro giornata con Stackalytics. Tutto è diventato molto trasparente e visivo, ognuno poteva monitorare attentamente i propri progressi, confrontarsi con i colleghi, ecc. È diventato conveniente e facile per ingegneri, manager e team fissare obiettivi.
Un punto importante che emerge quando si implementa qualsiasi sistema di parametri quantitativi è che non appena li si implementa, il sistema si sforza automaticamente di dare priorità al raggiungimento di questi parametri quantitativi, a scapito di quelli qualitativi. Ad esempio, il numero di revisioni del codice completate viene utilizzato come una delle metriche. Ovviamente, la revisione del codice può essere eseguita in diversi modi, puoi dedicare diverse ore alla revisione approfondita e al controllo di una patch complessa con test di controllo, eseguendola sul tuo banco, controllando con la documentazione e ottenendo più una revisione nel tuo karma, oppure fai clic ciecamente su un paio di dozzine di patch in un paio di minuti, dai a ciascuno +1 e ottieni più venti in karma. Ci sono stati casi comici in cui gli ingegneri hanno fatto clic sulle patch così rapidamente da dare +1 alle patch automatiche dal sistema CI. Come abbiamo poi scherzato, "vai, vai, Jenkins". Nel caso dei commit, ci sono state anche molte persone che hanno ripassato il codice con strumenti di formattazione del codice, modificato commenti, cambiato punti in virgole e così aumentato il proprio karma. Affrontare questo problema è abbastanza semplice: usiamo il buon senso e, oltre alle metriche quantitative, utilizziamo anche quelle essenziali e qualitative. Il grado di utilizzo dei risultati del lavoro del team, il numero di collaboratori esterni, il livello di copertura dei test, la stabilità dei moduli e dell'intero prodotto, i risultati dei test su scala e prestazioni, il numero di ingegneri che hanno ricevuto la spalla del revisore principale cinghie, il fatto che i progetti siano stati accettati nella comunità dei progetti principali, il rispetto dei criteri delle diverse fasi del processo di ingegneria: tutti questi e molti altri fattori devono essere valutati insieme a semplici parametri quantitativi.
E infine, il terzo punto: nessuna stronzata.
Gli sviluppatori sono persone molto intelligenti ed estremamente logiche nel loro lavoro. Trascorrono 8-10 ore al giorno costruendo catene logiche lunghe e complesse, in modo da vederne al volo le vulnerabilità. Quando fanno qualcosa, loro, come tutti gli altri, vogliono capire perché lo stanno facendo, cosa cambierà in meglio. È estremamente importante che gli obiettivi fissati per la tua squadra siano onesti e realistici. Cercare di vendere una cattiva idea a un team di programmazione è una cattiva idea. Un’idea è negativa se non ci credi tu stesso o, in casi estremi, non hai lo stato interno di disaccordo e impegno (non sono d’accordo, ma lo farò). Una volta abbiamo implementato un sistema di motivazione in un'azienda, uno dei cui elementi era un sistema elettronico per fornire feedback. Hanno investito molti soldi, hanno portato persone in America per la formazione, in generale hanno investito al massimo. Una volta, in una conversazione dopo la formazione, uno dei manager ha detto ai suoi subordinati: “L'idea non è male, sembra che funzionerà. Non ti darò personalmente un feedback elettronico, ma tu lo dai alla tua gente e lo pretendi da loro. Questo è tutto, non è stato possibile implementare ulteriormente nulla. L'idea, ovviamente, non si è conclusa con nulla.
Fonte: habr.com