Team di progetto e team di prodotto: imparano nello stesso modo?

Un team impara (anche) facendo: ma cosa fa e come lo fa, lo influenza molto più di quanto e come impara.

All’interno della città Verso Agile – tappa esplorativa di questo mese – è opportuno approfondire un tema: l’apprendimento nel corso dei progetti e dei prodotti.

Durante i periodi di formazione capita, talvolta, di avere discussioni su quanto le persone siano influenzate negativamente dal “saltare da un progetto all’altro”. In questo articolo, andremo a riflettere, quindi, sulle modalità e sui diversi livelli di apprendimento delle persone, nel corso di un progetto o durante lo sviluppo di un prodotto.

Progetto: cos’è e cosa (non) accade durante il suo sviluppo

Tutti sanno – più o meno – cos’è un progetto: c’è un prima, un durante e un dopo. Al termine di ogni progetto, dovrebbe essere consuetudine prendersi del tempo per riflettere sul come si è lavorato e trovare spunti di miglioramento (e per rispettare il dodicesimo principio del Manifesto Agile). È una forma di apprendimento questa: diversa dal leggersi un libro, diversa dal partecipare ad un corso di formazione; ma comunque apprendimento.
Eppure, quando ci si confronta con le persone di un team sul quando e sul quanto spesso si incontrano, si scopre che: si riuniscono all’inizio del progetto (con qualche assente), si ritrovano durante il progetto (con disciplina variabile), ma alla fine del progetto capita spesso di “saltare un giro”.

Accade frequentemente di passare ad un altro progetto senza fare tesoro di ciò che è stato appreso nel corso di quello precedente, poiché si lavora su molteplici progetti in parallelo o se ne inizia subito un’altro.

Tale dinamica rappresenta un’occasione di apprendimento persa, quando il lavoro e il tempo delle persone vengono frammentati tra più progetti.

Team di progetto e team di prodotto

Prima è stato detto “tutti sanno cos’è un progetto”. Eppure per le persone il confine tra progetti e prodotti è ancora labile e spesso i termini vengono usati intercambiabilmente.

Una possibile causa potrebbe risiedere nel disallineamento tra l’esterno e l’interno di un’azienda. Un esempio: in termini commerciali e di comunicazione un’organizzazione dichiara di fare prodotti, che però sviluppa per progetti più o meno auto-conclusivi e personalizzati secondo le esigenze dei vari clienti, mentre le persone coinvolte nel team lavorano contemporaneamente su molteplici progetti.

Apparentemente, tra un team di prodotto e un team di progetto non si evidenziano grandi differenze:

• • sono gruppi composti da persone;
  • ogni individuo possiede una serie di competenze;
  • tali competenze permettono di raggiungere un obiettivo entro un certo periodo di tempo;
  • ogni gruppo rispetta tutta una serie di vincoli (scopo, budget e costi).

Progetti e prodotti: come si genera il valore

Risulta, invece, una grossa differenza in termini di come il valore viene generato durante lo sviluppo di un prodotto rispetto ad un progetto:

• Nello sviluppo di prodotto, il valore viene rilasciato lungo un periodo di tempo mediamente più lungo rispetto ad un progetto, basandosi sui risultati ottenuti di volta in volta, in maniera più o meno iterativa, o più o meno incrementale.

• In un progetto, al contrario, l’intero processo si conclude con un rilascio finale generale e definitivo, con poco o nessun seguito rispetto al lavoro svolto e ai risultati raggiunti.

Progetto: le competenze individuali e i colli di bottiglia

Le competenze delle persone vengono ottimizzate per massimizzare la copertura del maggior numero di progetti. Si lavora “assieme”, ma con discontinuità, scarsa collaborazione e interventi puntuali; per poi “saltare” alle attività di un ennesimo progetto.

Le competenze delle persone in azienda sono organizzate a silos e l’attenzione ricade sulla gestione del tempo delle persone. Inoltre, questi silos non sono omogenei: per scelta, per contesto, per contingenza o per puro caso ci sarà abbondanza di alcune competenze e scarsità di altre. Di conseguenza, le persone con le competenze più scarse o un maggior numero di richieste diventano automaticamente dei colli di bottiglia.

L’apprendimento nei team di prodotto

Mentre ci si concentra sugli svantaggi dei colli di bottiglia – indisponibilità, rallentamenti, necessità di assumere o formare persone -, si finisce per sottovalutare l’effetto negativo sull’apprendimento.

Un team dedicato allo sviluppo di un prodotto è soggetto al cosiddetto apprendimento continuo: il gruppo ha a disposizione tutto il tempo necessario per apprendere e sviluppare le proprie competenze e per approfondire il contesto di quel prodotto (anche se, ovviamente, ciò non accade sempre in modalità lineare e definitiva). I membri di un team di prodotto hanno sempre delle opportunità per:

• Continuare a specializzarsi
• Sviluppare il proprio modello di competenze a “T”

Infine, dal momento che più persone espandono le proprie competenze in maniera verticale o orizzontale, vi è la possibilità di ridurre tutti i problemi relativi ai colli di bottiglia, legati all’esclusività di certe competenze.

L’apprendimento nei team di progetto

Anche in un contesto di progetto è previsto un percorso di apprendimento: all’inizio del processo, le persone hanno scarsa conoscenza del progetto stesso e del contesto; mentre terminato il lavoro risultano acquisite tutte le conoscenze e le competenze richieste.

Tuttavia, quando un progetto finisce si verifica una brusca interruzione del processo di apprendimento. In questo caso, si deve parlare di apprendimento usa&getta: finito il progetto, le singole persone vengono mandate a lavorare su altri progetti e il loro ciclo di apprendimento comincia da capo. Ovviamente ciò non avviene in maniera drastica, ma sicuramente porta alla perdita di tutto il potenziale di apprendimento collettivo che è avvenuto nel progetto.

Ulteriori “apprendimenti”

E’ bene sottolineare che le due situazioni appena descritte – di apprendimento continuo su sviluppo di prodotto e apprendimento usa&getta sui progetti – rappresentano circostanze idealizzate: i “confini” dei due team di prodotto e di progetto sono disegnati come solidi, per rappresentare gruppi di lavoro dedicati al 100% ai loro prodotti o progetti.

Nella realtà sappiamo che non è così: le persone non si dedicano al 100% allo sviluppo di progetti o prodotti. Questo crea un ulteriore effetto deleterio sul processo di apprendimento, la situazione di task-switching, o context-switching: oltre a limitare la produttività delle persone, aumentando il loro carico cognitivo, ne limita anche le capacità di apprendimento.

Quando il contesto permette di “saltare” facilmente da un progetto ad un altro (quando c’è permeabilità tra progetti), si va incontro a due grandi trappole:

• Apprendimento parziale e frammentato, in assenza di tempo per approfondire il dominio di tutti i progetti e i prodotti su cui si lavora;
• Apprendimento verticale e specialistico (visione utilitaristica), quando risulta molto più conveniente restare specialisti su alcune competenze o domini ristretti, utilizzando la propria competenze in maniera plug&play.

Nessuna di queste due situazioni è globalmente ottimale; esse rappresentano quelle circostanze di ottimo locale che più frequentemente impediscono di agilizzare la gestione del lavoro e dell’organizzazione dell’azienda.

Qualche consiglio

Organizzare e formare un’intera azienda che lavora “a progetti” verso un metodo di lavoro “a prodotti” richiede soldi, tempo e fatica. Per questo motivo di seguito sono elencati alcuni consigli, degli step da poter intraprendere in maniera graduale, per iniziare a migliorare il modo in cui le persone imparano facendo:

• Fare le retrospettive regolarmente (non solo dopo il primo mese di lavoro, o solo alla fine, o solo “quando abbiamo tempo”), con un focus particolare sul “cosa abbiamo imparato?”.
• Introdurre pratiche collaborative come swarming, mob programming e pairing per fare in modo che persone con professionalità diverse possano capire il mestiere di rispettivi colleghi e colleghe (approfondimenti sul Mob Programming al link).
• Mappare sistematicamente le competenze delle persone e, soprattutto, le dipendenze tra competenze e progetti in corso, al fine di minimizzare l’impatto dei colli di bottiglia (e prendere consapevolezze come “questo progetto non si può iniziare”).

…e qualche suggerimento

Per una formazione professionale e un affiancamento mirato, volti all’acquisizione della metodologia Agile, Human Reloaded offre corsi e percorsi di formazione eventualmente personalizzabili secondo bisogni individuali e necessità di contesto.

Per approfondimenti tecnici sul tema “progetti e prodotti”, consigliamo la lettura del reportage dell’ultimo meetup di Agile Reloaded.