Sul come imparare a gestire un team di sviluppo…

Qualche giorno fa, mentre leggevo Peopleware (portate pazienza per la recensione: arriverà) mi sono reso che gestire un “team di sviluppo” non è affatto semplice…

Nel corso del tempo ho accumulato nozioni teoriche/pratiche, esperienza lavorativa (ovviamente anche in team), perfino una certa capacità di spiegare le cose agli altri, ma mi accorgo di non aver mai avuto il piacere di seguire un corso (o qualcosa di simile) su come mettere/tenere in piedi e gestire un gruppo di sviluppo.

Parlo dell’aspetto umano del lavoro, ben diverso da quello tecnico.

Non che mi serva al momento, ma un domani?

“Può un individuo che aspira prima o poi a raggiungere lo status di ‘tecnico professionista‘ accettare serenamente di avere lacune e per giunta in un ambito così “vicino” – per modo di dire – al suo?

Sto notando che nè l’Università nè il mondo del lavoro che ho visto fin qui mi hanno trasmesso nozioni chiare e precise su questo tema. Non imputo colpe a nessuno, ma non mi va l’idea di subire la cosa o, peggio, dover improvvisare qualcosa nel caso servisse.

Non sto parlando di diventare necessariamente un manager o un capo-progetto, ma escluderlo a priori e non prepaparsi affatto secondo me è da folli.

Gestire un team di sviluppo

Da tecnico ho sviluppato naturalmente un senso di appartenenza ad un gruppo, quello dei tecnici appunto.

Per cui – lo ridico per la milionesima volta – mi ritrovo nell’affermazione, contenuta in un post-capolavoro di Spolsky, secondo cui:

“[...] programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are.”

Un corollario implicito è che i tecnici tendono anche ad apprezzare maggiormenti altri tecnici in qualità di loro responsabili, perche li sentono come dei “pari che hanno fatto strada“. Ovviamente questo tipo discorso è estendibile a qualunque altro gruppo o categoria di lavoratori in cui possa esistare un certo livello gerarchico.

Ciò detto, per essere un buon capo di un gruppo tecnico non serve per forza essere un tecnico a propria volta (Peopleware e lo stesso Spolky docent), ci mancherebbe!

Però se si parla di realizzare un prodotto ad un certo punto bisogna entrare nei dettagli tecnici: come minimo serve anche una figura “di collegamento” fra sviluppatori e upper management, che sia in grado di “pilotare” lo sviluppo da questo punto di vista e che non trascuri il lato umano della faccenda. Un primus inter pares è di fatto la scelta più semplice.

Imparare vivendo la situazione?

Per quanto possa imparare e ho imparato “by example” nel corso del tempo osservando, analizzando e studiando chi mi stava sopra in un dato momento, non sono certo di aver appreso compiutamente le basi della “materia”.

Spesso si trattava di persone che, per merito tecnico (onore a loro: un po’ di meritocrazia esiste per fortuna!), sono state promosse di rango, ma un conto è far funzionare le cose ed un conto è far funzionare anche le persone. Esattamente come il fatto di essere bravi nel fare una cosa non implica automaticamente l’essere anche portati a insegnarla e bene a terzi.

Grazie a loro posso dire di aver imparato un’infinità di trucchi e strategie più o meno efficaci per trattare con gli altri, qualcosa che messo insieme costituisce un bel nucleo di esperienza diretta, ma sfortunatamente nulla di esprimibile in un discorso ordinato e compiuto (come lo è spesso imparare solo di e per esperienza: tante piccole illuminazioni in un mare agitato, indefinito e sconosciuto).

C’è chi dice che per comprendere appieno una situazione l’unico modo è trovarvisi dentro in prima persona, quindi si arriva ad un discorso di occasioni afferrate al volo e di punti di vista completamente differenti fra chi vive certe situazioni e chi no. Non basta ragionare per “se io fossi al posto di $TIZIO“, per capire come vanno davvero le cose, come esso le vive.

Ciò nonostante, non mi piace nè intendo accettare di imparare solo “a vista” o solo “per riflesso” dell’esperienza altrui..

Mi serve qualcosa di specifico e preciso per imparare…

Una proposta modesta

Dal momento che nonostante la miriade di esami sostenuti all’Università non ho trovato quello che cercavo (e/o non ci ho fatto troppo caso), personalmente sarei favorevole ad aggiungere almeno un corso di “team management fortemente tecnico” nelle facoltà come quella che ho seguito io, anche solo come esame complementare.

Non un corso di sociologia o psicologia del lavoro, per altro già esistenti, ma uno incentrato sul “gruppo di lavoro tecnico” visto in ottica sia di “soldato semplice” che di “generale“.

All’estero esistono da tempo corsi per creare “team efficienti” (es: questo, della Loyola University) e sarei curioso di sapere se esistono anche in Italia e in quale facoltà tecnica.

Quello che mi piacerebbe è appunto un corso multidisciplinare, tecnico e per tecnici, di “infarinatura” e di livello universitario, che tratti ad esempio questioni che osservo abitualmente come:

• gestire in modo ottimale e prolungato gruppi numerosi di sviluppatori (10+);
• operare una corretta ripartizione delle mansioni fra più persone;
• suddividere ed organizzare le responsabilità nei progetti;
• integrare e gestire al meglio le “nuove leve” in progetti nuovi o già avviati (senza inficiare lo sviluppo dei progetti stessi);
• gestire i turnover;
• ottenere il massimo da una persona senza soffocarla;
• scegliere ed applicare le metodologie di sviluppo adeguate;
• scegliere e promuovere l’utilizzo dei tool migliori;
• favorire la formazione continua tecnica;
• reagire all’impatto di cambiamenti di specifica;
• determinare se e quando è il momento per “promuovere” una persona da mansioni “junior” a “senior“;
• fare da schermo fra “upper management” e sviluppatori “sottoposti”;
• imporre le best practices da seguire;
• ricomporre le dispute tecniche;
• imporre una direzione di sviluppo in ottica di una “visione d’insieme”;
• capacita` di delegare (gentilmente suggerito da Larsen)

Questi punti mischiano insieme tecnica e aspetto umano. O, se preferite, trattano di sviluppo in un contesto allargato e “umanamente scalabile“, che poi sono i gruppi di lavoro tecnici.

Potrei andare avanti per ore ad aggiungerne altri e sono certo che qualunque sviluppatore che abbia sulla groppa qualche anno di esperienza potrebbe fare altrettanto.

Ecco, io vorrei organizzare i piccoli trucchetti che si imparano per “esperienza collettiva” o “guardando i capi” e trarne un qualcosa che aiuti seriamente a far parte ed eventualmente dirigere un gruppo di sviluppatori.

Conclusioni

Il senso del post era ovviamente provocatorio ma in un’ottica professionale non esistono solo le nozioni e il “know how“: spero di aver reso l’idea.

Che ne pensate?