motto:
Il marito, guardando i bambini sporchi, dice alla moglie: allora, li laviamo o ne facciamo nascere di nuovi?
Sotto il taglio c'è la discussione del nostro team leader, nonché direttore dello sviluppo prodotto RAS, Igor Marnat, sulle peculiarità della motivazione dei programmatori.
Il segreto del successo nella creazione di prodotti software interessanti è ben noto: prendi un team di programmatori interessanti, offri al team un'idea interessante e non interferire con il lavoro del team. Gli sviluppatori interessanti sono rari e richiesti. Alcuni reclutatori affermano addirittura di avere l'impressione che sia più facile produrre un bravo programmatore che assumerne uno dal mercato. Oltre alle difficoltà legate all'assunzione in quanto tale, l'esperienza di ogni specifico sviluppatore, la sua conoscenza del prodotto esistente e la storia del suo sviluppo, sono spesso insostituibili o difficili e dispendiose in termini di tempo da reintegrare. Pertanto, se sei fortunato e hai già un bel team di programmatori, è importante lavorare sulla loro motivazione. Assumere e formare nuovi sviluppatori, creare una squadra con loro è difficile e richiede tempo quasi quanto dare alla luce e crescere figli.
Consideriamo i principali fattori di motivazione dei programmatori (team di programmatori), utilizzando la piramide di Maslow per chiarezza e strutturazione della presentazione. Se non hai sentito parlare della piramide di Maslow, non si tratta di una teoria indiscussa, ma molto popolare e illustrativa dello psicologo americano Abraham Harold Maslow, che propose una teoria della motivazione personale basata sulla gerarchia dei bisogni umani (vedi immagine sotto).
Maslow ha organizzato i bisogni dell'individuo in ordine gerarchico, dai bisogni fisiologici al bisogno di sviluppo potenziale e autorealizzazione. Un presupposto chiave nella teoria di Maslow è che "una persona non può sperimentare bisogni di livello superiore finché i suoi bisogni di livello inferiore non sono soddisfatti". Ad esempio, una persona non può essere spinta dal bisogno di conoscenza o da bisogni estetici se allo stesso tempo non ha dormito né mangiato per tre giorni.
Prima di entrare nei dettagli, concentriamoci su un fatto ovvio: una squadra è composta da persone, tutte le persone sono diverse, ognuna ha la propria struttura motivazionale. Oltre al fatto che ogni persona è guidata da interessi diversi, ogni persona si trova anche in condizioni di vita diverse. Qualcuno è all'inizio di una carriera e sta pensando a come costruirla, qualcuno si sposerà e qualcuno vuole padroneggiare una nuova area tematica. Ciò che è importante per uno non è affatto importante per un altro, e domani tutto cambierà di nuovo. Per comprendere correttamente questo contesto, esiste un rimedio semplice: devi pensarci e lavorarci. La cosa più importante è la comunicazione.
Assicurati di parlare con il tuo team di qualcosa di diverso dal lavoro, costruisci relazioni informali.
Quindi, ora esaminiamo la piramide di Maslow e consideriamo i suoi livelli applicati alla gestione di un team di programmatori.
I: Bisogni fisiologici, biologici:
Quando si parla di motivazione, molte persone spesso pensano prima di tutto allo stipendio. In questo caso per stipendio intendo una parte permanente del pacchetto retributivo, che non dipende in alcun modo dai risultati. Ciò non si applica ai bonus, ai bonus e alle promozioni aziendali. È lo stipendio che attribuirei al livello dei “bisogni fisiologici” nel nostro caso. Bonus, bonus basati sulla performance, opzioni e azioni aziendali: tutto questo classificherei ad altri livelli.
Secondo me, per quanto strano possa sembrare, lo stipendio potrebbe piuttosto esserlo demotivante fattore piuttosto che un fattore motivante. La particolarità di lavorare con i programmatori è che sono tutte persone, in primo luogo, molto intelligenti (una caratteristica della professione) e, in secondo luogo, profondamente e/o ampiamente istruite. In genere, i programmatori, oltre alla loro professione, hanno una profonda conoscenza di una o più aree tematiche per le quali creano prodotti. Inoltre, i bravi programmatori sono interessati e conoscono bene la storia dello sviluppo della programmazione, degli algoritmi, degli standard, ecc. Lo stesso vale per la loro area tematica. Per le persone di questo livello, lo stipendio di solito non è il principale fattore motivante.
Allo stesso tempo, la mancanza di uno stipendio equo per i programmatori, nella loro comprensione, demotiva e demotiva notevolmente. Avere uno stipendio giusto è la norma. Lo stipendio è molto più alto della norma (mercato) - anche, stranamente, un fattore piuttosto demotivante. Un collega una volta mi ha parlato di un team di programmatori in una delle grandi società di animazione americane, che, a causa di una serie di circostanze, ha ricevuto stipendi a un livello da due a tre volte superiore al mercato. Come ha detto, non aveva mai visto programmatori più annoiati, pigri e demotivati in vita sua. Il fatto di aumentare lo stipendio può motivare a breve termine, ma dopo pochi mesi il nuovo stipendio diventa la norma e smette di motivare. In generale, direi che per i programmatori all'inizio della loro carriera il fattore stipendio è più importante, man mano che crescono professionalmente e si sviluppano, la sua importanza diminuisce e altri fattori iniziano a prevalere.
Il secondo punto importante è la presenza di un giusto equilibrio nel livello degli stipendi nella squadra. Se un team ritiene che il contributo di un membro sia notevolmente inferiore, ma il livello di compenso è lo stesso, ciò demotivarà l'intero team. A volte i manager sono tentati di alimentare il fuoco con il denaro, per trattenere una persona esaurita o demotivata aumentandone lo stipendio al di sopra del normale. Questo di solito crea problemi solo a lungo termine: la motivazione della persona stessa non aumenterà molto, oppure aumenterà per un paio di mesi, ma la motivazione del resto della squadra diminuirà. In tali situazioni, vale la pena cercare altri approcci, a meno che, ovviamente, non si tratti di uno specialista unico che deve essere trattenuto ad ogni costo, anche per un breve periodo.
II. Bisogno di sicurezza, comfort, coerenza delle condizioni di vita:
70 anni fa la presenza di un fornello in macchina poteva essere un fattore motivante nella scelta di un'auto; allora era al di sopra della norma ed era un segno di lusso. Adesso anche l'assenza dell'aria condizionata non ha senso e la sua presenza, ovviamente, non sarà un fattore motivante nella scelta di un'auto. Quindi 10-15 anni fa, un ufficio conveniente, un buon hardware, un caffè delizioso, fitness, orari flessibili, ecc. potrebbero essere buoni fattori motivanti, ma ormai questa è piuttosto la norma per il lavoro di un buon programmatore. Allo stesso tempo, la loro assenza sarà ancora una volta demotivante.
Un importante fattore demotivante è la mancanza di capacità di concentrazione e un ambiente di lavoro rumoroso. Il lavoro di un programmatore richiede silenzio e concentrazione. Se lo spazio ufficio non offre l'opportunità di fornire agli sviluppatori uno spazio di lavoro appartato, è necessario garantire almeno una collaborazione confortevole tra colleghi che non interferiscano tra loro. È meglio unire tra loro compagni energici e rumorosi, dando l'opportunità di concentrarsi a chi ne ha bisogno.
Il costo del tempo di un programmatore è ora significativamente più alto del costo dell'hardware su cui lavora. Due o tre monitor, computer potenti, un posto di lavoro confortevole per ogni sviluppatore dovrebbero essere la norma in ogni azienda. Questo argomento è ben trattato in uno degli articoli di Joel Spolsky “Il test di Joel: 12 passaggi per programmare meglio."
La componente fisica del comfort è la più basilare e semplice; ora parliamo del resto.
In molte aziende, la norma per i programmatori è un orario di lavoro flessibile e nessun codice di abbigliamento. Questo è positivo e corretto se le specificità del lavoro del team lo consentono (ad esempio, non ci sono incontri con clienti, politici o banchieri).
L’importante è avere una finestra temporale specifica in cui l’intero team lavora insieme a livello locale in modo che le persone possano comunicare e risolvere i problemi faccia a faccia. Un programmatore, in sostanza, non lascia il lavoro nemmeno dopo il lavoro. In genere, i problemi lavorativi si ripropongono nella sua mente indipendentemente dalla sua presenza in ufficio e le buone decisioni spesso provengono dall'esterno dell'ufficio. Data la necessità di essere buoni (di cui parleremo più avanti), il controllo meschino è dannoso. Non solo è demotivante, ma riduce anche la produttività. Come dimostra la pratica, in assenza di controllo, è più probabile che un team motivato lavori più a lungo del necessario. Se c'è il controllo, gli sviluppatori possono sedersi alla tastiera dalle nove alle sei, ma il risultato, penso, sarà peggiore. Come si suol dire, una persona può condurre un cavallo all'acqua, ma anche cento non lo costringeranno a bere se non vuole.
La descrizione di questo livello di bisogni menziona anche la libertà dall’ansia e dalla paura, l’assenza di caos e il bisogno di struttura e ordine. Anche questi sono punti estremamente importanti che influiscono molto sul clima in squadra.
In primo luogo, l'assenza di caos, struttura e ordine: il team deve capire chi è responsabile di cosa, come sono distribuiti i ruoli, cosa deve essere fatto, a chi, quando, quali requisiti sono alla base del prodotto, quali sono le aspettative del management e il cliente... La maggior parte di questo dovrebbe essere descritta formalmente, tutto dovrebbe essere discusso periodicamente. Senza discussione e uso periodico, le descrizioni non funzionano. È buona norma discuterli periodicamente e aggiornarli sulla base dei risultati delle analisi post mortem dopo il rilascio.
In secondo luogo, un'atmosfera calma e amichevole. Trascorriamo tutti la maggior parte del nostro tempo al lavoro e vogliamo farlo senza stress, conflitti o paure. Il team di sviluppo di solito lavora sotto la pressione di orari e clienti. Nessuno ha bisogno di ulteriore stress da parte di colleghi e superiori. L'atmosfera nel team, in generale il fatto stesso che un gruppo di sviluppatori possa chiamarsi ed essere una “squadra” è responsabilità diretta e importante del manager, uno dei compiti più importanti a medio e lungo termine. Pertanto, è importante che un manager lavori, in particolare, con i conflitti nella squadra e non lasci che il loro sviluppo segua il suo corso. La gestione dei conflitti è un argomento separato che merita uno studio separato.
Esistono due modi principali per influenzare lo stato emotivo della squadra e il comportamento dei colleghi (se qualcuno aggiungesse nei commenti, sarebbe fantastico). Il primo è il tuo comportamento. L’esempio personale è estremamente importante per un manager e un team. Come si suol dire, così è il prete, così è l'arrivo. Comportati come ti aspetti che si comportino i tuoi colleghi. Il secondo è incoraggiare comportamenti corretti e, per così dire, scoraggiare comportamenti sbagliati. Comunicare con le persone, dare loro feedback, ci sono molti modi per farlo. In generale, il feedback è un argomento per una discussione separata; è una parte ampia e importante del lavoro con motivazione.
Un'altra nota sull'atmosfera, che può sembrare insolita, ma in realtà è importante. Nella maggior parte dei casi, nel team di sviluppo ci sono meno ragazze che uomini. Spesso i gruppi sono interamente maschili. In tali condizioni, anche sotto carico, nella squadra inizia a essere utilizzato un linguaggio a volte osceno. La pratica dimostra che ciò ha un impatto negativo sull'atmosfera; la comunicazione diventa gradualmente scortese. Dovresti evitare di usarlo tu stesso e scoraggiarne l'uso nel tuo team.
I team di sviluppo sono spesso chiamati R&D (ricerca e sviluppo), e la ricerca costituisce una parte significativa del lavoro. Questa è la parte che solitamente è difficile da programmare e pianificare, altrimenti non sarebbe ricerca. È importante che la squadra abbia il diritto di commettere errori, di prendere iniziative, di provare diverse opzioni che possono o meno portare al successo. Gli errori sono una parte normale del lavoro, non possono essere evitati, ma puoi studiarli, analizzarli, imparare da essi per il futuro e andare avanti. Il principio dei 5 perché, nato in Toyota, è un buon modo per arrivare alla causa principale di un problema. Punire gli errori è un ottimo modo per creare un’atmosfera di paura e incertezza. L'unica eccezione è quando, sulla base dei risultati dell'analisi, risulta che l'errore è stato causato da un atteggiamento non professionale nei confronti del lavoro, in questo caso potrebbe essere necessario prendere decisioni sul personale.
L'atmosfera nel team è fortemente influenzata dalle tue aspettative e dal tuo stato emotivo prima dell'inizio della conversazione. Prima di iniziare una discussione difficile, una sorta di debriefing o semplicemente una conversazione emotiva, è importante il tuo umore e il tuo atteggiamento nei confronti della persona con cui parlerai. Per impostazione predefinita, credo sempre e agisco in base a ciò che la persona ha sinceramente cercato di fare al meglio. Se dalla tua posizione sembra che non sia così, devi scoprire con calma e in dettaglio il contesto e capire cosa ha fatto bene, perché pensava che fosse giusto e dove divergono le nostre aspettative. Di solito si scopre che non divergono davvero, è solo che la sua visione del contesto è più completa o fresca, e c'è qualcosa che non sapevi. O, al contrario, non sapeva qualcosa. Ciò è particolarmente importante in un team distribuito, quando le persone comunicano meno spesso di persona e utilizzano e-mail e messaggistica istantanea. Ciò è ancora più critico in un team composto da programmatori provenienti da diversi paesi e distribuiti in diversi fusi orari. È qui che le differenze culturali iniziano a giocare un ruolo importante.
In una situazione difficile, guidare in movimento è facile, molto facile, ma poi tornare indietro è difficile e il sedimento rimane a lungo. Lasciate che vi faccia un semplice esempio tratto da una recente esperienza. Uno dei team manager aveva urgentemente bisogno di commenti su qualche problema con un cliente da parte di un manager di un team correlato in un altro paese. Ha chiamato un collega nel messenger, ha aspettato 15 minuti, ha chiamato di nuovo, poi 15 minuti dopo è andato in una grande chat in cui erano presenti anche gli altri dirigenti, e ha attaccato leggermente il collega, con una dicitura del tipo: “visto che non degnati di rispondermi, forse, e la domanda non è così urgente?" Alla fine, si è scoperto che il nostro messenger aziendale era leggermente noioso e il collega non ha visto affatto la domanda. Ho dovuto scusarmi. In generale, è meglio iniziare con il bene. È sempre possibile commettere un grave errore e finire nei guai in seguito; non c’è problema con questo (anche se non dovresti farlo). In generale, in più di 20 anni di lavoro nel nostro settore, ho incontrato un collega veramente malizioso solo una volta (!). Fortunatamente ci siamo lasciati abbastanza rapidamente. Nella stragrande maggioranza dei casi risulta corretto presumere che i colleghi vogliano il meglio, al meglio della loro comprensione del contesto.
Il tuo compito come manager è garantire la sincronizzazione dei contesti, una comprensione comune delle aspettative, dei requisiti, delle scadenze e degli standard accettati nel team. Possono sembrare piccole cose, ma l'atmosfera nella squadra è costruita proprio da queste piccole cose. Dal punto di vista del team distribuito, uno dei compiti importanti è garantire che i membri del team abbiano una comunicazione faccia a faccia periodica. Ho sentito più di una volta dai programmatori che dopo, ad esempio, gli ingegneri del team di supporto sono venuti da loro e hanno lavorato insieme di persona, sono rimasti volentieri al lavoro per aiutare personalmente Pasha, che era venuto da loro di recente in un caso difficile, sebbene prima Pasha fosse solo un'icona nel messaggero, e nessuno si sarebbe fermato per il bene dell'icona.
A proposito, ho iniziato a parlare del team di supporto e mi sono ricordato di un esempio canonico. Una volta, uno dei clienti in America ha avuto un problema con il prodotto, uno degli ingegneri del team di supporto che ha lavorato alla sua implementazione (distaccato dalla Russia) è rimasto dopo il lavoro per aiutare, ma il problema non è stato risolto e non è stato risolto. In generale, si è soffermato e si è seduto lì quasi fino al mattino. In questo momento, i manager del cliente hanno intensificato il problema, ne hanno individuato la criticità e hanno lasciato il lavoro la sera. Il processo di escalation stava già prendendo slancio in un fuso orario diverso, i responsabili dell'assistenza in Russia hanno iniziato a cercare di aiutare, a causa di alcune difficoltà di comunicazione con l'ufficio del cliente (VPN, problemi di connessione, difficoltà con le chiamate tra paesi, ...) non sapeva che il ragazzo era già in prigione in ufficio e risolve la questione, e ha cercato di trovarlo. L'hanno trovato solo al mattino (americano), quando il problema era già praticamente risolto e il prodotto funzionava. Hanno subito iniziato a dire che diavolo, il cliente ha una tale escalation, non funziona niente, dove sei, non riusciamo a trovarti, ecc. Inutile dire che a causa di tale comportamento il ragazzo era fortemente demotivato. Organizzare il lavoro di un team distribuito è un argomento importante a parte, ma è importante ricordare due cose. Innanzitutto la comunicazione e l'atmosfera sono molto importanti, da questo dipende la riuscita del lavoro. In secondo luogo, questo non funziona da solo; deve essere affrontato separatamente e in modo approfondito.
Un altro punto importante legato a questo livello di bisogni è ancora una volta lo stipendio. Non l'entità dello stipendio in quanto tale, ma la presenza di una determinata procedura per modificarlo. L'azienda deve avere un approccio volto a determinare i requisiti per posizioni a diversi livelli. Ogni sviluppatore dovrebbe essere in grado di discutere le aspettative per il proprio lavoro con l'azienda, capire come e quando i propri sforzi potrebbero influenzare il proprio stipendio. A questo scopo servono incontri periodici con il manager, revisioni semestrali o annuali delle performance. Questo, ancora una volta, è uno di quei momenti la cui presenza non motiva esplicitamente, ma la cui assenza è molto demotivante.
Dalla necessità di ordine e presenza di regole consegue la necessità di rispettare queste regole, di seguire le norme accettate nella squadra, sia formali che informali. In generale, lo definirei il bisogno di “essere buoni”. La presenza di questa esigenza conferma che la microgestione non è necessaria, ma piuttosto dannosa. È sufficiente fornire a una persona tutto il necessario per il lavoro, dargli la conoscenza del contesto, delle priorità e garantire libertà di azione e decisione al suo livello. In tali condizioni, sentirà fiducia, avrà l'opportunità di prendere le proprie decisioni, assumersene la responsabilità e sarà in grado di rivelare il suo potenziale.
Un altro punto importante che dovrebbe essere attribuito alla necessità di ordine e all'assenza di caos è la capacità di concentrazione su un compito, l'assenza di frequenti cambi di contesto. Essere un programmatore richiede tempo e concentrazione. Ai programmatori non piace davvero rinunciare urgentemente a un compito e passare a un altro. Una parte necessaria del lavoro di un programmatore di solito non è solo lo sviluppo vero e proprio del codice, ma anche la correzione dei bug e l’assistenza nell’elaborazione delle richieste dei clienti. Vale la pena pianificare queste cose in anticipo, in modo tale da consentire al programmatore di completare con calma e completamente il lavoro su un compito prima di passare a un altro. L'opzione migliore è darti l'opportunità di pianificare tu stesso il tuo lavoro, identificando in anticipo le priorità e le attività imminenti, assegnando periodi di tempo lunghi ed estesi per lavorare su un tipo di attività. Questo argomento è ben descritto nel libro “Google - Ingegneria dell'affidabilità del sito", che descrive bene gli approcci alla pianificazione del lavoro dei team che garantiscono il funzionamento e lo sviluppo di sistemi di grandi dimensioni, altamente caricati e tolleranti ai guasti, nonché di ingegneri la cui occupazione combina lo sviluppo di software e il suo supporto.
To be continued ...
Fonte: habr.com