Quando assumere o sbloccare il flusso di consegna

La riunione si blocca quando la spiegazione del ritardo diventa «serve più personale», ma nessuno riesce a indicare dove il lavoro si ferma. In quel momento l’assunzione sembra una decisione concreta: ha un costo noto, una procedura conosciuta e promette sollievo senza dover ridefinire responsabilità o priorità. Può anche essere la scelta giusta. Non lo è, però, quando la nuova capacità alimenta una coda che nessuno ha esaminato.

Per chi possiede risultati e impegni di consegna, la distinzione conta perché un ritardo persistente non è soltanto una questione di produttività. Allunga il ciclo di feedback: le decisioni arrivano tardi, le promesse restano aperte più a lungo e gli ingegneri spendono tempo a coordinare lavoro già iniziato invece di completarlo. La consulenza tecnica è utile proprio quando il problema non è scegliere una tecnologia, ma rendere esplicito quale vincolo sta governando la consegna.

La decisione tra capacità e flusso #

Prima di autorizzare un’assunzione, conviene mettere sul tavolo due ipotesi concorrenti: manca capacità per svolgere il lavoro richiesto, oppure il lavoro attraversa un flusso che ne ritarda l’uscita. Le due ipotesi producono gli stessi sintomi in superficie — backlog, persone occupate, scadenze che slittano — ma chiedono interventi diversi.

Decisione	Quando è ragionevole	Cosa costa	Cosa non risolve	Primo controllo
Aggiungere capacità	Il carico resta superiore a quanto il team può completare anche con poche attese e responsabilità chiare	Inserimento, coordinamento e nuova domanda di supporto	Approvazioni lente, passaggi ripetuti, priorità in conflitto	Verificare che il lavoro attenda esecuzione, non una decisione
Riparare il flusso	Il lavoro invecchia tra una fase e l’altra o aspetta una persona, un gruppo o un via libera	Rendere esplicite proprietà, priorità e deleghe	Un limite reale di competenze o ore disponibili	Seguire un elemento di lavoro dall’avvio alla consegna
Combinare le due mosse	Esiste un vincolo di capacità, ma il flusso rende difficile vederlo	Richiede sequenza e disciplina, non una riorganizzazione immediata	La necessità di scegliere quale vincolo affrontare per primo	Rimuovere prima l’attesa più osservabile e riesaminare la capacità

Un’assunzione aggiunge persone al sistema; non elimina automaticamente il punto di blocco in cui il sistema smette di far avanzare il lavoro. Se una richiesta aspetta l’approvazione di un’unica figura, un nuovo sviluppatore può produrre più richieste da approvare. Se un team specialistico serve ogni iniziativa, l’aumento dell’input rende più costosa la stessa dipendenza.

Il punto non è opporre organico e organizzazione come se una delle due opzioni fosse sempre più matura. L’organico è una risposta valida a un limite di capacità reale. Diventa una scorciatoia quando sostituisce la domanda più scomoda: quale attività deve aspettare, chi può sbloccarla e perché quella decisione non è già distribuita?

Le code che nascondono il vincolo #

Il conteggio delle attività aperte dice poco se non si osserva l’età dell’attesa. Un backlog pieno può contenere lavoro che procede in parallelo; una coda piccola può trattenere un impegno importante per giorni perché manca una decisione, una revisione o un proprietario riconoscibile. Per questo è più utile seguire un singolo elemento e annotare ogni passaggio di mano rispetto a sommare ciò che risulta «in corso».

Un percorso tipico mostra come il ritardo si formi senza che nessuno appaia inattivo. Il team prepara la soluzione, un responsabile deve confermare una priorità, un gruppo condiviso verifica un requisito e nel frattempo arriva altro lavoro che sembra più urgente. Ogni passaggio è difendibile isolatamente, ma la loro sequenza crea una coda che nessun singolo team possiede davvero.

flowchart LR
    A[Richiesta pronta] --> B[Team di consegna]
    B --> C{Decisione di priorità}
    C -->|in attesa| D[Coda di approvazione]
    D --> E[Specialista condiviso]
    E --> F[Consegna]
    C -->|approvata| E

Il diagramma non dimostra che tutte le approvazioni siano inutili. Mostra piuttosto dove chiedere conto del tempo: chi può decidere, entro quale confine e con quali informazioni. Se la risposta è «dipende da chi è disponibile», il vincolo non è ancora una persona in meno; è un diritto decisionale lasciato implicito.

Anche la complessità dell’architettura può aggravare il problema, perché sistemi difficili da comprendere richiedono più coordinamento per ogni modifica. Il coordinamento aggiuntivo può rallentare la consegna. Tuttavia non conviene attribuire ogni attesa al software: una struttura semplice può rallentare ugualmente se la responsabilità attraversa troppi confini organizzativi.

La lettura delle responsabilità e delle priorità #

Una diagnosi utile parte da una domanda concreta: per far avanzare questo lavoro, quante persone o gruppi devono dire sì? Non si tratta di eliminare controlli necessari, ma di distinguere quelli che riducono un rischio da quelli che esistono perché nessuno ha chiarito chi può assumersi una decisione.

Le approvazioni diventano particolarmente costose quando arrivano dopo che il lavoro tecnico è già iniziato. In quel caso gli ingegneri non ricevono un vincolo all’inizio: ricevono una correzione tardiva, devono riorganizzare il contesto e spesso riaprire conversazioni chiuse solo in apparenza. Il business paga con impegni bloccati; il team paga con interruzioni e lavoro di coordinamento che non compare come funzionalità consegnata.

Una coda è spesso una politica non dichiarata: rende visibile che una priorità o una responsabilità non è stata decisa abbastanza presto. Rendere quella politica esplicita può essere più efficace che introdurre un nuovo livello di gestione, perché consente di stabilire quali decisioni restano centrali e quali devono essere prese vicino al lavoro.

Occorre inoltre separare due casi che vengono spesso confusi. Nel primo, le persone qualificate sono costantemente impegnate in lavoro che può essere completato senza lunghe attese: qui il limite di capacità è plausibile. Nel secondo, le persone attendono informazioni, autorizzazioni o un altro team mentre nuove attività entrano nel sistema: qui aumentare l’input può peggiorare l’età della coda prima ancora di migliorare l’output.

Un intervento reversibile prima della riorganizzazione #

Non serve ridisegnare subito l’organizzazione per verificare l’ipotesi di flusso. È più sensato scegliere un tipo di lavoro limitato, assegnargli un proprietario decisionale esplicito e ridurre per un breve periodo i passaggi necessari per arrivare alla consegna. La reversibilità protegge l’operatività: se l’intervento non cambia l’attesa, si torna indietro con una comprensione migliore del vincolo.

L’esperimento deve osservare il percorso effettivo, non giudicare le persone. Si possono annotare l’età delle attese, il numero di handoff, le decisioni rimaste senza proprietario e le richieste che tornano indietro per una priorità tardiva. Non occorre trasformare tutto in un programma di misurazione: basta rendere visibile il punto in cui il lavoro perde continuità.

Se il flusso migliora senza nuove assunzioni, non significa che il team non abbia mai bisogno di crescere. Significa che la prossima assunzione potrà essere motivata con maggiore precisione: quale capacità manca dopo aver rimosso l’attesa evitabile. Se invece il lavoro continua ad attendere esecuzione nonostante decisioni e passaggi più chiari, l’argomento per aumentare la capacità diventa più solido.

La prima scelta reversibile non deve essere irreversibile: deve rendere più chiaro quale scelta successiva avrà effetto. Questa sequenza evita sia l’immobilismo sia la riorganizzazione teatrale, perché collega ogni intervento a un vincolo osservabile.

Domande frequenti #

Quando assumere è davvero la risposta corretta? #

Quando il lavoro procede con responsabilità chiare e poche attese, ma la domanda supera stabilmente ciò che il team può completare. La capacità è il vincolo se il tempo si concentra nell’esecuzione necessaria, non nell’attesa di decisioni o passaggi tra gruppi.

Cosa conviene osservare già lunedì? #

Si scelga un impegno vicino alla consegna e se ne segua il percorso, segnando ogni handoff, ogni attesa e chi poteva sbloccarla. L’età della coda è più informativa dell’elenco totale delle attività aperte, perché mostra dove il lavoro si è fermato davvero.

Un’organizzazione a matrice causa inevitabilmente ritardi? #

No. Può funzionare se le responsabilità sono comprensibili e le decisioni hanno un confine definito. Il problema non è la matrice in sé, ma il momento in cui più linee di responsabilità possono fermare il lavoro senza che una abbia il mandato di farlo avanzare.

Per quanto tempo dovrebbe durare un intervento reversibile? #

Abbastanza da vedere attraversare il flusso a più elementi dello stesso tipo, non abbastanza da trasformarlo in una nuova struttura per inerzia. La durata va fissata prima, insieme alla condizione che porterà a mantenere, modificare o interrompere l’intervento.

Alla prossima riunione sulla capacità, si scelga un impegno in ritardo e si chieda prima dove ha atteso e chi poteva sbloccarlo; solo dopo si decida se la risposta richiede una nuova assunzione.