Sta emergendo tra i programmatori e i team di sviluppo un approccio troppo individualista e dannoso nel modo in cui vengono gestiti i progetti software. L’obiettivo delle persone sembra diventato solo quello di chiudere i propri task il prima possibile, senza preoccuparsi di come questo possa impattare il lavoro degli altri membri del team e del fatto che questo aspetto non porta che un valore effimero al progetto.
Chiudere i task non è l’obiettivo finale
Questo approccio potrebbe anche essere il primo segnale di un mancato governo da parte dell’azienda, si verifica nei progetti fortemente strutturati a task, dove ad ogni persona viene assegnato un compito che deve essere completato il prima possibile e su questo compito viene poi valutata la performance del proprio lavoro.
Quel programmatore è una macchina da guerra, finisce tutto quello che gli viene assegnato già al mattino e poi si mette a fare altro
Quante volte avete sentito questa frase e il compiacimento diffuso da parte di colleghi e management? Ma è davvero così positivo?
Per riuscire ad avere certe performance, si tende a chiudere la persona in un ambiente isolato, asciugarla da ogni preoccupazione, per spingerla al risultato massimo.
Da un certo punto di vista, la cosa è positiva: vengono tagliate tutte le distrazioni, le continue riunioni, le interminabili telefonate e le situazioni di multitasking in modo da focalizzarsi sull’obiettivo. Da un altro punto di vista, si perde di vista il quadro generale e si rischia di creare un ambiente di lavoro tossico, fortemente individualista, in cui le persone non si aiutano e non condividono le proprie conoscenze.
Il fatto che poi molti programmatori siano persone propense all’isolamento quando svolgono il proprio lavoro non giova a questa situazione.
La sindrome del cavallo da corsa
Capite quanto sia facile, in un ambiente come questo, non accorgersi dei malumori o dello stacco fra le varie figure, se si guarda solamente il risultato nel breve termine. Come un cavallo da corsa indossa i paraocchi per correre veloce verso al traguardo senza guardare il mondo esterno, così i programmatori sono lanciati nella risoluzione dei propri task.
L'importante è la fine del task, non l'economia del progetto
Code language: JavaScript (javascript)
Premiare l’individualismo
Viene quindi premiato l’individualismo, legato al risultato tangibile.
Peccato che un progetto è composto anche da una serie di risultati intangibili, come la condivisione delle conoscenze, la collaborazione e la crescita personale e professionale delle persone coinvolte.
Le metriche dettate dal management e da molti tool che vengono utilizzati in azienda tendono a valutare tutto quello che è tangibile: il numero di task chiusi, le linee di codice scritte, il tempo fra l’apertura di un problema e la sua risoluzione: difficilmente tengono conto dei task intangibili.
Pensate a tutte le volte che avete dato un aiuto a un collega per sbloccarsi da un problema, alla correzione di una riga di codice che risolve un problema noto da mesi e mai risolto, alle sessioni di pair programming o alla dritta detta davanti al caffè.
Occorre quindi pensare ai progetti in modo olistico e cercare di staccarsi dalla logica del task come unico obiettivo. Un team lavora insieme deve raggiungere un obiettivo comune. Non vincono i singoli, ma vince il gruppo che è in grado di evolvere e migliorare il prodotto in modo continuo e armonico.
Il problema del “finire i task”
La vera sfida è quella di riuscire a trasformare una serie di persone, inserite in un contesto dove viene premiata la performance del singolo, in una squadra che pensa, agisce e lavora ad obiettivi nel lungo termine.
Fare squadra non è solo una questione di soft skill, ma è anche una questione di cultura aziendale e di come vengono valutate le persone all’interno dell’azienda.
Creare compartimenti stagni non giova a nessuno e deve essere bilanciato con delle attività in grado di portare del valore anche verso le persone più lente o isolate, in modo da poterle trainare ad un miglioramento culturale e personale.
Quando si hanno team composti da persone più o meno esperte, se si riesce a trovare il modo per versare delle conoscenze da una persona all’altra, diventa un arricchimento sia per il progetto che per le singole persone.
Per chi gestisce un progetto software, è fondamentale utilizzare al meglio il tempo delle persone in modo da accrescere il valore del progetto oltre alla chiusura dei task.
È essenziale favorire una cultura collaborativa all’interno del team, in cui le persone possano aiutarsi reciprocamente e condividere conoscenze.
Di chi è la responsabilità?
Sicuramente favorire un approccio collaborativo è responsabilità del management, ma anche i singoli membri del team hanno un ruolo importante in questo processo. È fondamentale che i membri del progetto siano consapevoli del fatto che il loro lavoro non è solo quello di chiudere i propri task ed andare a casa il prima possibile.
Nelle riunioni periodiche, negli stand-up, deve essere compito dei membri del team informare gli altri se ci sono dei blocchi o se hanno bisogno di aiuto. Allo stesso modo, i membri del team devono essere pronti ad aiutare i colleghi condividendo le proprie conoscenze e competenze.
Non è però detto che questo aspetto emerga in modo spontaneo. Per questo è necessario che il management promuova attivamente la collaborazione, cogliendo queste situazioni e spronando le persone a lavorare in modo collaborativo.
Quali strategie possiamo mettere in atto per mitigare questo problema?
Esistono vari modi per evitare che questo modo possa compromettere l’economia del progetto.
Se parliamo di soft skill, dobbiamo sicuramente inserire nel gruppo di lavoro persone che abbiano una predisposizione naturale al lavoro di squadra, che sappiano lavorare in gruppo e che siano in grado di condividere le proprie conoscenze.
Se una persona finisce i propri task e non ha nulla da fare, potrebbe essere spronata a fare code review del lavoro degli altri membri del team, a fare refactoring del codice appena aggiunto o a fare mentoring e coaching delle persone meno esperte, e su questo tipo di attività dovrebbe essere valutata la performance del singolo.
Gestione delle superstar
In un mondo perfetto, tutti riescono a fare il proprio lavoro, pranzano a casa con la famiglia e al pomeriggio giocano a tennis.
In un mondo normale ci si trova di fronte a dei problemi e non è detto che tutti siano risolvibili con le proprie forze. A volte è necessario farsi aiutare da i cosiddetti “programmatori superstar”.
A tal proposito mi viene in mente una discorso di Ottavio Bianchi ai calciatori del Napoli quando arrivò Maradona in squadra:
“Lui è Maradona e noi siamo noi. Il problema nasce se qualcuno di noi vuole fare il Maradona. Se accettiamo questo ovvero che lui è lui e noi siamo un’altra cosa possiamo vincere, ma se noi noi non lo accettiamo o qualcuno di noi non lo accetta la cosa non funziona.”
A volte la superstar è necessaria per chiudere alcuni task: immaginate tutte le situazioni nelle quali vi siete trovati di fronte a un problema che una persona molto competente sull’argomento avrebbe risolto in pochi minuti, mentre voi ci avete impiegato giorni.
In questi casi è facile che la singola persona lavori su task ben definiti e che non abbia, o abbia scarso bisogno di aiuto da parte degli altri.
L’ossessione al completamento del task da parte della superstar non è un problema, ma è fondamentale che il management sia in grado di gestire queste situazioni e di garantire che il lavoro della “superstar” sia comprensibile e mantenibile da tutti i membri del team.
Per questo è fondamentale che il team analizzi successivamente il codice scritto dalla “superstar”, lo riveda, lo documenti e ne faccia refactoring, per poterlo rendere comprensibile e mantenibile da tutti.
L’effetto “catena di montaggio”
Dobbiamo quindi evitare di pensare alla programmazione come a una catena di montaggio, in cui ogni persona è responsabile di un singolo task e non ha alcuna responsabilità nei confronti degli altri.
Perché hai messo questa riga di codice che rallenta il programma?
Perché in questo modo ho risolto una segnalazione di sicurezza.
Ma non ti sei accorto che potevi fare in questo modo?
No, non mi sono accorto, non era il mio task.
Attenzione però a non abusare dell’approccio inverso dove, appena una persona finisce le proprie attività, viene assalita con l’assegnazione continua di nuovi compiti o chiusura dei lavori di altre persone.
Questo potrebbe portare a situazioni in cui le persone percepiscono un aumento dello stress e un carico di lavoro eccessivo, che li porta a non gestire nel modo ottimale i propri compiti.
Il “burnout” è un problema reale e tangibile e una situazione mal gestita potrebbe favorire l’insoddisfazione lavorativa e l’allontanamento delle persone migliori, che si sentono sopraffatte dal numero di attività che devono portare a termine.
Allo stesso modo ci potrebbero essere persone che rallentano volutamente il proprio lavoro, per evitare di dover fare il lavoro degli altri. In questi casi diventa fondamentale che il management sia in grado di gestire queste situazioni, riesca a garantire che il carico di lavoro sia equamente distribuito tra i membri del team e metta in atto una serie di strategie per migliorare la collaborazione all’interno del team.
Conclusioni
Un buon programmatore non è colui che finisce tutti i task assegnati, ma colui che viene messo in grado di lavorare in modo collaborativo e di condividere le proprie conoscenze con gli altri membri del team.
Occorre saper far crescere il gruppo di lavoro nel quale si è inseriti, ed è importante che il management non valuti i propri risultati solo da dati numerici, ma sia in grado di gestire le persone, ascoltarle, spronarle e capire dove sono le differenze per appianarle.
Il valore che può dare un senior va oltre la risoluzione del task, deve estendersi alle attività di coaching e mentoring, in modo da far crescere chi ha meno esperienza.
Questo è il modo migliore per garantire che il progetto software sia di successo e che il team sia in grado di crescere e migliorare nel tempo.