In che modo un approccio Agile può facilitare il lavoro del PM? Vediamo insieme come e quando è opportuno applicarlo ai diversi tipi di progetto.
Dopo aver parlato di Development Team, Scrum Master e soprattutto del Product Owner nell’articolo precedente (lo trovi qui), ci dedichiamo ora all’analisi di un’altra figura chiave all’interno di qualsiasi progetto, anche se non strettamente legata al mondo dello sviluppo software: il Project Manager.
Il project Manager è una figura trasversale che, come un bravo direttore d’orchestra, ha il compito di coordinare i vari developer/solisti oltre ad occuparsi del controllo dei costi.
Proprio come in un concerto, l’obiettivo è fare in modo che la somma delle performance dei solisti crei un’unica armoniosa melodia, che nel nostro caso è la delivery di un prodotto impeccabile e nei tempi previsti.
La domanda a cui vogliamo dare risposta oggi però va oltre la semplice definizione di chi è il PM, per indagare un particolare aspetto legato al come svolge la sua attività.
Non è un segreto che la capacità di sfruttare al meglio i vantaggi della metodologia Agile sia uno dei punti di forza dei servizi forniti da Hermes, quindi potresti aspettarti un approccio rigido e inflessibile.
Invece la capacità di mettersi costantemente in gioco è il primo driver di crescita, quindi è lecito domandarsi: “il Project Manager deve essere per forza Agile?”.
Essendo grandi sostenitori della causa, forse ti aspetterai un’articolata risposta con tutti gli indiscutibili benefici di un approccio 100% Agile; ma non sarà così.
Molte domande non hanno una soluzione univoca, per cui la risposta corretta spesso è: dipende.
Esistono infatti specifici casi in cui un approccio rigidamente Agile rappresenterebbe un errore strategico, perché la realtà è che ogni progetto va gestito in accordo con la sua natura.
L’importanza di valutare il singolo progetto
Ogni progetto ha caratteristiche ben definite, che vanno interpretate accuratamente per non correre il rischio di tramutare un possibile vantaggio competitivo (l’approccio Agile) in una zavorra che penalizza l’avanzamento dei lavori.
Proviamo quindi a fare chiarezza partendo proprio dall’interpretazione delle caratteristiche di un progetto.
Per meglio comprendere il valore aggiunto della metodologia Agile, dobbiamo considerarne 4 aspetti fondamentali:
- Project Control
- Push and Pull
- Approccio Iterativo e Incrementale
- Lean Thinking
Per rispondere alla domanda sul corretto ruolo e approccio del PM, consideriamo il primo aspetto, che ci aiuterà a comprendere meglio come gestire e impostare correttamente il lavoro.
Possiamo considerare ogni progetto con tre approcci differenti: definito, statistico o empirico. In questo grafico si vede bene il loro posizionamento in relazione alle due variabili determinanti: il costo e il tempo di realizzazione.
Ogni singolo progetto è una sfida a sé, con obiettivi e modalità di sviluppo differenti, quindi la competenza del PM è innanzitutto capire la natura del progetto stesso.
Definiti, empirici, statistici: i diversi tipi di progetti
Un progetto si considera “definito” quando conosciamo esattamente:
- quali risorse servono per realizzarlo
- che tempi di sviluppo sono necessari
- quali processi bisogna aggregare per raggiungere gli avanzamenti desiderati, nei tempi (e costi) richiesti dal committente.
L’esempio più banale? Una catena di montaggio, dove il processo è standardizzato e, come si vede nel grafico, è lineare e quindi meno costoso e più veloce.
Un approccio “empirico” è invece all’estremo opposto dello schema, quindi si tratta di un progetto caratterizzato da:
- incertezza sulle risorse da impiegare
- incertezza sui tempi di realizzazione
- incertezza sui costi dell’opera.
In questo caso possiamo conoscere al massimo 1 dei 3 elementi base (risorse, processi e tempi) e questa estrema variabilità è tipica dei progetti che partono da un’idea astratta, da una nuova visione, e vanno impostati completamente da zero.
Un esempio classico di un progetto empirico è proprio lo sviluppo di un nuovo software.
Raramente possiamo predeterminarne i processi: le risorse vengono infatti individuate strada facendo e i tempi di lavorazione possono essere stimati solo durante lo sviluppo e raramente prima.
Potremmo dire che la differenza tra un approccio definito e uno empirico sia la stessa che passa tra rinnovare una cucina e ristrutturare l’intera casa cambiando anche la disposizione delle camere.
Nel primo caso sai esattamente cosa ti serve e quanto ti costa, devi solo trovare le risorse per sostituire i pezzi necessari.
Nel caso di una ristrutturazione completa puoi fare tutte le stime possibili, ma alla fine ti costerà circa il doppio di quanto avevi previsto, ci saranno imprevisti e la consegna avverrà con un ritardo di almeno 3-6 mesi sulla data indicata all’inizio.
E per quanto riguarda l’approccio “statistico”?
Non abbiamo dimenticato questa terza categoria, ma l’abbiamo lasciata per ultima proprio perché è l’anello di congiunzione tra l’approccio definito e quello empirico.
La buona notizia è che con l’esperienza si può portare un progetto empirico a diventare definito, passando per una fase statistica.
Cosa significa esattamente?
Facciamo l’esempio di un e-commerce: il cliente vuole realizzare la sua nuova piattaforma da zero e questo andrà sicuramente considerato come un progetto ad approccio empirico, che per ottimizzare costi e tempi e valorizzare la creatività andrà affrontato in maniera Agile.
Se in seguito, grazie al buon lavoro del team, arrivassero altre dieci richieste di progetti simili, allora potremmo iniziare ad avere una stima molto realistica dello sviluppo del progetto, portandolo nella categoria di quelli STATISTICI, dove conosciamo almeno due variabili su tre fra risorse, processi e tempi.
Una volta che il team fa esperienza, raccoglie dati e raggiunge una sorta di standardizzazione del processo, all’ennesima richiesta di un e-commerce con quelle caratteristiche si potrebbe quasi inserire il “pilota automatico”, perché a quel punto ci sarebbero tutte le carte in regola poter considerare quel progetto come “definito”.
Ok, ma cosa c’entra tutto questo ragionamento con la domanda iniziale sul ruolo e l’approccio del Project Manager?
Adesso uniamo i puntini, perché questa spiegazione sulle varie tipologie di progetto era doverosa per permetterti di comprendere in maniera chiara che un PM non dovrebbe seguire rigidamente un unico tipo di approccio.
Potremmo dire che il PM debba essere quasi agnostico, capace di adattarsi in maniera liquida al contesto dello specifico caso o progetto del momento.
Quindi il PM non deve essere per forza Agile, ma questo diventa un grosso vantaggio se deve gestire progetti con un approccio empirico.
Gli errori da non commettere
Quello che spesso accade con un approccio più tradizionale, detto anche “waterfall” (a cascata) è invece che il progetto inizi con un budget e una timeline rigidamente predeterminata, ma senza una vera certezza del risultato finale, dei tempi, processi e costi necessari.
Questa situazione è deleteria per l’intero progetto, perché stressa al massimo i membri del team, castra la loro creatività e impone il rispetto di una deadline che il più delle volte è insostenibile e diventa un limite per la qualità del risultato finale.
Come nell’esempio della ristrutturazione di una casa, trattare un progetto empirico come se fosse definito è un errore grave, che costringe gli sviluppatori a rincorrere la deadline alla meno peggio per non scontentare gli investitori, portando comunque a un risultato approssimativo.
Nella metodologia Agile un approccio del genere è considerato limitante.
I valori della metodologia prediligono infatti il lavoro di squadra, il confronto orizzontale e l’evoluzione creativa senza paletti rigidi.
Il risultato è una conseguenza di questa interazione e quello che succede nella pratica dei nostri progetti è che la figura del PM si trasforma di fatto in quella del Product Owner di cui abbiamo già parlato.
Questa è la figura che, senza imporre dall’alto le sue decisioni, è responsabile del backlog delle attività e soprattutto della corretta comunicazione tra il Team di sviluppo e gli Stakeholder, affinché le attività si svolgano in maniera efficace e tutti siano sempre allineati sulla timeline.
Tutto questo rende il processo di lavoro sostenibile e ottimizzato e favorisce il raggiungimento degli obiettivi nei modi e tempi più brevi in assoluto, pur garantendo la migliore qualità.
Quello che spesso non si comprende è che quando si avvia un progetto non ci sono antagonisti, perché in realtà tutti desiderano lo stesso risultato e bisogna affrontare la sfida nella maniera ottimale, così come fanno i Product Owner/Project Manager selezionati da Hermes.
Giacomo Caturegli | LinkedIn
