Come far emergere i problemi di un team e trasformarli in azioni

Un team può consegnare software e, nello stesso tempo, perdere energie su richieste poco chiare, responsabilità incerte o cambiamenti comunicati troppo tardi. Guardando soltanto le attività completate, questi problemi possono restare nascosti. Chi ci lavora ogni giorno, invece, ne vede gli effetti: deve chiedere conferme, interrompere un’attività o spiegare a un cliente una funzionalità che ha appena scoperto.

Per un responsabile, capire dove intervenire richiede un lavoro di ascolto e approfondimento. Chiamo discovery dei problemi del team questo percorso: raccogliere i segnali, ricostruire gli episodi, confrontare i punti di vista e decidere che cosa cambiare. Il risultato atteso è un insieme di problemi comprensibili, con azioni che qualcuno possa effettivamente portare avanti.

Nel mio lavoro ho costruito questo percorso attraverso colloqui individuali, retrospettive e confronti tra reparti. Qui descrivo come organizzarlo e come dare seguito a ciò che emerge, compresi i casi in cui la soluzione supera l’autorità del responsabile del team.

Ascoltare prima di proporre un cambiamento

Quando si assume la responsabilità di un gruppo, le persone conoscono una parte della storia che il nuovo responsabile deve ancora imparare. Sanno quali tentativi sono già stati fatti, dove si interrompe una comunicazione e quali difficoltà si ripetono. Una proposta ragionevole sulla carta può ignorare proprio questi elementi.

Il mio primo passo è stato conoscere le persone, farmi conoscere e organizzare incontri individuali. All’inizio ottenere un confronto aperto richiedeva più tempo; la confidenza è cresciuta attraverso il rapporto quotidiano.

Per iniziare, può essere utile chiedere di ricostruire un episodio recente: un’attività che ha richiesto più passaggi del previsto, una decisione rimasta sospesa, un’informazione arrivata troppo tardi. L’episodio permette di capire che cosa è successo prima di stabilire chi avrebbe dovuto comportarsi diversamente.

«Comunichiamo male» lascia aperte molte interpretazioni. «Ho saputo del rilascio mentre mostravo il prodotto a un cliente» indica già un momento, una persona coinvolta e una conseguenza. Da lì si può cercare quale informazione mancasse, quando sarebbe servita e chi fosse nella posizione di fornirla.

Questa attenzione ai fatti serve anche quando arriva un feedback su un collega. Il punto di vista di chi lo porta è un’informazione da approfondire: va compreso il contesto e, quando occorre, ascoltata anche l’altra persona prima di arrivare a una conclusione.

Dare ai one-to-one uno spazio distinto

I one-to-one sono incontri individuali tra responsabile e collaboratore. Nel mio team li organizzo una volta al mese con ciascuna persona, anche per mantenere un contatto regolare in un ambiente di lavoro completamente remoto.

Per usarli nella discovery, bisogna lasciare spazio a ciò che ostacola il lavoro della persona. Se tutto il tempo viene assorbito dall’elenco dei ticket, diventa difficile parlare di aspettative poco chiare, rapporti di collaborazione o decisioni che non si sa se prendere in autonomia.

Come traccia per il colloquio, si possono usare domande come queste:

• In quale attività recente ti sei bloccato, e che cosa ti mancava per procedere?
• C’è una decisione per cui non sai se puoi agire da solo o devi chiedere conferma?
• Quale passaggio del nostro modo di lavorare ti fa perdere tempo?
• C’è qualcosa che faccio io, come responsabile, che rende il tuo lavoro più difficile?

Sono domande di partenza. Vale la pena seguire la risposta e chiedere un esempio, senza trasformare l’incontro in un questionario da completare.

Un caso utile è l’incertezza sul proprio ruolo. Una persona può avere bisogno di sapere quali decisioni le competono, quando coinvolgere il responsabile e dove finisce il suo ambito di autonomia. In una situazione di questo tipo ho chiarito per iscritto responsabilità e confini attraverso un accordo operativo individuale, condiviso con la persona e con il coinvolgimento della direzione.

Questo aiuta a scegliere dove trattare il problema. Una difficoltà personale può richiedere un confronto riservato; un passaggio di lavoro che blocca più persone può diventare un tema della retrospettiva. Prima di portare nel gruppo informazioni emerse in un colloquio, va chiarito con la persona che cosa sia opportuno condividere.

Preparare una retrospettiva che faccia capire i problemi

La retrospettiva è un incontro in cui il gruppo esamina un periodo di lavoro e decide che cosa mantenere o migliorare. Nella prima che ho organizzato ho chiesto al team di guardare ai sei o sette mesi precedenti. Mi serviva capire una storia a cui avevo partecipato solo in parte.

Il team lavora da remoto, ma quell’incontro si è svolto alla prima occasione in presenza. Abbiamo usato una lavagna e post-it. Lo stesso lavoro può essere organizzato su una lavagna condivisa online: il supporto deve permettere a tutti di scrivere, leggere e collegare i contributi.

Prima dell’incontro è utile comunicare il periodo da osservare, le domande e il risultato atteso. Le persone possono così arrivare con episodi da discutere. Per una prima ricognizione ampia dedico circa mezza giornata, distribuendola indicativamente in questo modo:

Questa distribuzione serve soprattutto a proteggere il tempo per le proposte. Se la discussione dei problemi occupa tutta la riunione, le decisioni vengono rinviate o prese in fretta. La durata va comunque adattata al numero di persone e all’ampiezza del periodo: quattro ore sono il formato che uso per questo confronto, non un requisito di ogni retrospettiva.

Partire da ciò che ha funzionato

Le persone scrivono che cosa è andato bene e ne spiegano il motivo. Una comunicazione anticipata ha evitato interruzioni? Una regola ha reso chiaro chi dovesse decidere? Un cambiamento tecnico ha semplificato il lavoro?

Questa fase consente di riconoscere le pratiche da conservare. Una successiva modifica del processo dovrebbe tenere conto anche di ciò che il team considera utile, altrimenti rischia di rimuovere una soluzione insieme al problema che si vuole correggere.

Approfondire i problemi prima delle soluzioni

Nel formato che uso, nella seconda fase ciascuno aggiunge i propri post-it e li spiega. Come moderatore, chiedo a chi ha scritto ogni post-it che cosa intenda, quale episodio abbia in mente e quali conseguenze abbia osservato.

Qui è utile mantenere la discussione sul problema abbastanza a lungo da comprenderlo. Davanti a «ci sono difficoltà con i rilasci», la prima proposta potrebbe essere una nuova riunione. Approfondendo, si può scoprire che il rilascio era stato comunicato, ma che mancavano un ambiente accessibile o il tempo per provare la funzionalità. Le azioni necessarie cambiano.

I post-it vengono poi raggruppati in macroaree: per esempio comunicazione tra reparti, gestione dei rilasci, complessità del codice. Il raggruppamento aiuta a collegare episodi simili, conservando però i dettagli che li rendono comprensibili. Una colonna intitolata «comunicazione» non spiega ancora dove intervenire.

Tutti devono avere spazio per contribuire. Chi facilita deve fare attenzione anche a chi tende a parlare meno e a chi, al contrario, rischia di occupare tutto il confronto.

Prima di adottare un confronto con contributi attribuiti, considera se le persone si sentano libere di esporsi. La guida Atlassian alle retrospettive invita a chiarire come verranno usate le informazioni e contempla anche una raccolta anonima. In un team piccolo, però, il contenuto di un episodio può rendere riconoscibile chi lo segnala.

Se qualcuno teme conseguenze, proponi un confronto riservato con un interlocutore che ritenga affidabile e concordate che cosa riportare al gruppo. Se il problema riguarda il responsabile, quell’interlocutore può dover essere un’altra persona. Evita di imporre una spiegazione pubblica o promettere anonimato che non puoi garantire. Il silenzio, da solo, non permette di concludere che non ci siano difficoltà.

Chiedere proposte collegate a un problema

Nella terza fase si aggiungono le idee di soluzione, mantenendo il collegamento con i problemi raccolti. Le proposte vengono discusse una alla volta.

Nella mia prima retrospettiva erano soprattutto i membri del team a proporle: conoscevano meglio di me il lavoro e i suoi vincoli. Il mio compito era organizzare il confronto e approfondire i contributi. Con il tempo ho iniziato a partecipare anche alle proposte, grazie a una conoscenza più diretta del contesto.

Per valutare un’idea, può aiutare una domanda semplice: quale comportamento dovrebbe cambiare se la applicassimo? «Migliorare la comunicazione» resta troppo ampio. «Rendere disponibile la nuova funzionalità internamente prima di mostrarla ai clienti» permette di discutere accesso, tempi e responsabilità.

Non tutte le proposte devono diventare una regola. Alcune richiedono un intervento tecnico, altre un chiarimento tra due persone, altre ancora un accordo tra reparti.

Scegliere le priorità e rendere visibile il seguito

Alla fine della retrospettiva preparo un riepilogo e un possibile piano d’azione. La raccolta è condivisa; come responsabile mi occupo di dare un ordine ai follow-up e seguirne l’avanzamento.

La mia valutazione è stata qualitativa, basata su quanto un problema potesse incidere sul lavoro dell’azienda. Ho dato precedenza ai problemi che coinvolgevano più reparti, per poi scendere nel dettaglio del team e delle esigenze individuali. Nel mio contesto era utile affrontare prima le difficoltà che si propagavano oltre lo sviluppo.

Per applicare questo criterio, bisogna rendere esplicito il ragionamento: chi subisce il problema, quanto spesso si presenta, quale lavoro blocca e quali persone devono partecipare alla soluzione. Un problema individuale urgente può richiedere un intervento immediato; il numero di reparti coinvolti non basta, da solo, a determinarne la priorità.

Il piano deve chiarire anche che cosa viene rimandato e perché. Altrimenti un contributo che non compare tra le prime azioni può sembrare dimenticato.

Per tenere traccia del seguito, si può usare una scheda come questa. È un modello proposto al lettore, compilato qui con un caso esemplificativo sui rilasci:

Nel piano effettivo, i ruoli devono corrispondere a persone individuate e il momento di verifica a una scadenza concordata. Se manca il tempo per eseguire l’azione, anche questa è una decisione da affrontare.

Il follow-up deve controllare sia ciò che è stato fatto sia l’effetto sul problema. Aver inviato una comunicazione è verificabile, ma non dice ancora se il destinatario abbia potuto prepararsi. Nel caso del rilascio, serve capire se la persona ha avuto accesso alla funzionalità, l’ha provata e sa presentarla.

Collegare ogni problema alla risposta adatta

Dalla raccolta possono emergere problemi molto diversi. Cercare una soluzione organizzativa identica per tutti porta facilmente a introdurre riunioni e regole che non affrontano la difficoltà concreta.

Richieste di funzionalità senza una valutazione comune

Un esempio è la richiesta che arriva al team e si trasforma subito in sviluppo. Prima di impegnare le persone, occorre capire quale esigenza soddisfi, quale sforzo richieda e come si colleghi agli obiettivi aziendali.

Ho introdotto linee guida per le richieste di nuove funzionalità, chiedendo che passassero da me. La valutazione avviene insieme al team e all’amministratore, tenendo conto della direzione definita per l’anno. Il team contribuisce alla valutazione del lavoro e la decisione tiene insieme fattibilità e obiettivi.

Questo passaggio mi ha aiutato a ridurre il lavoro dispersivo. Una richiesta può essere interessante senza essere prioritaria in quel momento: avere criteri condivisi permette di spiegare perché venga accolta, rimandata o rifiutata.

Per chi applica questo metodo, è utile rendere visibile la decisione a chi ha fatto la richiesta. Un punto di ingresso unico funziona se produce una valutazione comprensibile; altrimenti può diventare soltanto un nuovo collo di bottiglia.

Difficoltà di onboarding legate al codice

Un altro problema emerso riguardava l’ingresso dei nuovi sviluppatori. Quando la difficoltà riguarda la lettura e la manutenzione del codice, l’intervento deve arrivare anche lì. Nel nostro caso è stato avviato un refactoring strutturato per rendere il codice più comprensibile, anche a figure junior.

Se manca una spiegazione, può servire documentazione. Se la struttura del codice ostacola la comprensione, aggiungere soltanto una procedura di onboarding lascia intatta una parte del problema.

Rilasci che sorprendono chi lavora con i clienti

Per dare agli altri reparti il tempo di prepararsi, ho introdotto comunicazioni preventive, disponibilità interna prima del rilascio pubblico, un ambiente di test e l’uso di feature flag. Queste ultime consentono di controllare l’attivazione di una funzionalità, per esempio rendendola disponibile inizialmente solo a un gruppo interno, come illustrato da Pete Hodgson in Feature Toggles.

Il percorso prevede che le persone possano provare, valutare e conoscere la funzionalità prima di una data pubblica concordata. Questo collega una scelta tecnica a una necessità organizzativa: il momento in cui il codice è disponibile e quello in cui tutti possono usare la funzione non devono per forza coincidere.

Affrontare i problemi tra reparti

Per le retrospettive interreparto uso le stesse tre fasi. Cambiano però le persone che possono decidere e gli impegni da coordinare.

Il responsabile dello sviluppo può predisporre l’ambiente, comunicare una novità e organizzare una dimostrazione. Se un altro reparto non riesce a dedicare tempo alla preparazione, bisogna affrontare quel vincolo con chi ne gestisce le priorità.

Ho affiancato alle retrospettive anche confronti con gli altri responsabili e con l’amministratore. Servono a riportare le difficoltà e coordinare interventi che il solo team di sviluppo non può completare.

Il problema va portato a quel livello in una forma che permetta di decidere. Nel caso del rilascio, per esempio, occorre chiarire quale preparazione manchi e quale conseguenza abbia sulla data prevista. Le alternative possono essere riservare tempo, ridurre il contenuto da preparare o rivedere la data. La scelta va concordata tra chi ha responsabilità sulle attività coinvolte.

Aver rispettato la propria parte della procedura lascia comunque aperto il problema se il risultato richiede la partecipazione di più reparti. Il follow-up deve rendere visibile questa dipendenza.

Anche le regole che ne derivano vanno discusse prima di diventare ufficiali. Il mio percorso è raccogliere le informazioni, preparare una bozza, rileggerla e confrontarla con le persone coinvolte. I feedback servono a correggere ambiguità e verificare che il comportamento richiesto sia chiaro. Questo coinvolgimento è parte del lavoro necessario per rendere applicabile una direttiva.

Far emergere i problemi anche tra una retrospettiva e l’altra

La retrospettiva offre uno spazio per osservare il periodo nel suo insieme. Nel lavoro quotidiano, però, non voglio che una persona aspetti mesi per segnalare qualcosa che la sta bloccando.

Oltre ai one-to-one mensili, ho introdotto due brevi allineamenti settimanali del team. La retrospettiva resta trimestrale. Ogni tre mesi si tiene anche un incontro di tutta l’azienda per condividere risultati, difficoltà e direzione: l’ho proposto, mentre a condurlo è l’amministratore.

Sono momenti con scopi diversi. Gli allineamenti aiutano a intercettare i problemi mentre il lavoro procede; i colloqui individuali danno spazio alle esigenze della persona; la retrospettiva permette di riconoscere ciò che si ripete e discuterne insieme. La condivisione aziendale fornisce il contesto per comprendere le priorità.

Nel tempo ho visto le persone diventare più dirette e a proprio agio nel segnalare le difficoltà. Molti problemi vengono affrontati prima della retrospettiva. È un cambiamento che considero utile: il confronto entra nel lavoro quotidiano e l’incontro trimestrale può concentrarsi anche sui problemi che richiedono una lettura più ampia.

Per iniziare ad applicare questo percorso, scegli un problema emerso dal team e seguilo fino alla verifica concordata. Riprendi l’episodio da cui siete partiti, controlla che cosa è cambiato e ascolta di nuovo chi lo subiva. Se l’azione è stata eseguita ma la difficoltà rimane, tornate a capire quale parte del problema non avete ancora affrontato.

Letture che hanno accompagnato il mio percorso

Tra le letture che mi hanno dato spunti sulla gestione e sulla crescita delle persone ci sono Un puzzle elegante di Will Larson e The Manager’s Path di Camille Fournier. Per chi vuole approfondire i colloqui individuali e il feedback, l’indice di The Manager’s Path permette di individuare questi argomenti nei capitoli dedicati alle basi del management e alla gestione delle persone. Le cadenze e il formato della retrospettiva descritti qui sono le scelte adottate nel mio contesto.