Sovrallocazione delle risorse e livellamento: come trovarla e risolverla a mano, con un esempio

Un piano può rispettare tutte le dipendenze ed essere comunque impossibile. Nel rilascio di un’app che fa da esempio in tutta la guida le date sono corrette, eppure nei giorni 8 e 9 Dana, l’unica tester, risulta assegnata a due attività di test a tempo pieno contemporaneamente. Il diagramma di Gantt disegna una barra per attività, quindi le due barre di Dana negli stessi giorni sembrano una normale coppia di barre sovrapposte.

Questa guida mostra come misurare la sovrallocazione delle risorse giorno per giorno sul calendario di ciascuno, poi la elimina a mano con quattro mosse: livellare entro il margine, riassegnare, posticipare e aggiungere capacità. Ogni mossa è provata sullo stesso rilascio, con il giorno di fine che produce e i giorni di sovrallocazione che lascia.

Che cos’è la sovrallocazione delle risorse#

La sovrallocazione delle risorse è una condizione del cronoprogramma in cui a una persona o a un’attrezzatura viene assegnato in un periodo più lavoro di quanto il suo tempo lavorativo disponibile consenta. Se nessuno interviene, diventa un ritardo sulla fine: nell’esempio qui sotto, due giorni al 200% per una tester spostano il rilascio di un’app dal giorno 12 al giorno 14 quando nessun altro può fare un test. Ed è un problema che resta nascosto. Lo US Government Accountability Office (GAO) ne spiega il motivo nella sua Schedule Assessment Guide: un cronoprogramma senza assegnazione delle risorse presuppone un numero illimitato di risorse con disponibilità illimitata^[1].

La soluzione si chiama livellamento delle risorse (resource leveling). Il GAO lo descrive come l’adeguamento dell’inizio pianificato delle attività, o delle assegnazioni di lavoro delle persone, in base alla loro disponibilità, e aggiunge che può essere semplice quanto spostare lavoro da una persona sovrallocata a una sottoutilizzata o rinviare un inizio finché la persona non è libera^[1]. Il livellamento che resta entro il margine, così che la data di fine non si sposti, si chiama resource smoothing; Microsoft Project lo offre con l’opzione Livella solo all’interno del margine di flessibilità disponibile^[2].

Chi ha bisogno di un controllo della sovrallocazione, e quando#

Un piano ha bisogno del controllo a partire da circa 3 persone nominate e 15 attività, che è la nostra regola pratica per il punto in cui qualcuno si ritrova con due attività aperte nello stesso giorno. Il project manager lo esegue e prende le decisioni di livellamento. I team lead leggono il risultato per le proprie persone e, nei team da 4 a 15, ognuno legge la propria riga per vedere quali attività si sono spostate. Lo sponsor vede solo la conseguenza, una data di fine.

Esegui il controllo dopo la prima bozza completa, quando dipendenze, durate e assegnatari sono tutti inseriti, e prima di salvare la baseline. Poi ripetilo ogni volta che una data si sposta, perché uno slittamento a monte spinge attività nei giorni di qualcun altro.

Due situazioni possono farne a meno. Chi lavora su un solo flusso alla volta, o un team che prende attività da una board con un limite al lavoro in corso, non può essere prenotato due volte dal piano, perché il limite fissa già quante attività tiene ciascuno. Un piano che si ferma alle fasi non ha nulla da livellare: la guida del GAO dice che il livellamento non va mai applicato ai cronoprogrammi di sintesi^[1].

Come si misura il carico, giorno per giorno#

Il carico di una persona in un giorno è dato dalle ore di tutte le attività assegnate a lei quel giorno, ciascuna moltiplicata per la sua assegnazione, divise per le ore che lavora quel giorno; sopra il 100% è sovrallocata. In questa guida l’assegnazione è la quota di tempo che una persona dedica a un’attività (50%, 100%), e il carico è sempre quel rapporto giornaliero.

Per Dana al giorno 8 dell’esempio, con due attività al 100% e una giornata di 8 ore, il carico è (8 + 8) / 8 = 200%.

Il calendario cambia il denominatore. In un giorno di assenza è zero, quindi qualsiasi lavoro pianificato è sovrallocazione. Mezza giornata di permesso lascia 4 ore, e un’attività al 100% diventa 8 / 4 = 200%. Chi è disponibile all’80% del tempo lavora 6,4 ore su una giornata di 8, quindi una sola attività assegnata al 100% lo porta a 8 / 6,4 = 125%.

Conta per giorno, poi riassumi. Se il giorno 1 è un lunedì, la settimana di Dana dal giorno 6 al giorno 10 contiene 48 ore di test contro 40 disponibili, un carico del 120%, e il mese di 20 giorni lavorativi attorno al rilascio contiene 64 ore contro 160, cioè il 40%. Una vista mensile mostra Dana con tempo libero. Microsoft Project permette al livellamento di cercare le sovrallocazioni su qualsiasi periodo, da minuto per minuto a mese per mese, e la sua documentazione avverte che, a seconda del periodo scelto, una risorsa può sembrare sovrallocata senza essere segnalata^[2].

Conta anche il perimetro. Un carico calcolato dentro un solo progetto ignora il lavoro della persona sugli altri progetti, quindi chi è condiviso fra tre piani può sembrare libero in ciascuno. Dove le persone sono condivise, esegui il controllo tra progetti.

Un esempio pratico: il rilascio di un’app con una sola tester#

L’esempio ha 6 attività, 4 persone e un percorso critico di 12 giorni. Un team prepara il rilascio di un’app di shopping: Lena scrive le specifiche, Marco sviluppa l’API di checkout, Priya sviluppa le schermate mobile e Dana è l’unica tester. Le durate sono in giorni lavorativi di 8 ore, ogni dipendenza è fine-inizio e ogni assegnazione è al 100%. Un dettaglio sta in un calendario: Priya ha un giorno di ferie prenotato al giorno 9.

Il percorso critico passa per specifiche, API, test dell’API e regressione: 2 + 5 + 3 + 2 = 12 giorni. Il carico di Dana è del 100% al giorno 7, del 200% nei giorni 8 e 9 e di nuovo del 100% dal giorno 10 al giorno 12. Nelle date non c’è nulla che sembri sbagliato.

Misurato, il problema è di 2 giorni sovrallocati per una persona, un picco del 200% e 16 ore di lavoro in eccesso. Mettere in sequenza i test di Dana costa 2 giorni (mossa 3 più sotto), quindi questo è il tetto per qualsiasi soluzione. Il test dell’API non può aiutare anticipandosi, perché l’API di checkout è finita solo alla fine del giorno 7 e il test, che sta sul percorso critico, non ha margine da cedere.

Quattro mosse per livellare il piano a mano#

Prova le mosse in quest’ordine e registra due risultati per ciascuna: il nuovo giorno di fine e i giorni sovrallocati che restano. Il livellamento entro il margine viene per primo perché, quando funziona, non costa nulla; comprare capacità viene per ultimo perché costa denaro.

1. Livellare entro il margine. Il test delle schermate ha 1 giorno di margine, quindi può scorrere dai giorni 7–9 ai giorni 8–10. Dana allora ha entrambi i test nei giorni 8, 9 e 10. Per liberare il test dell’API, il test delle schermate dovrebbe finire entro il giorno 7, cioè iniziare il giorno 5, mentre Priya sta ancora sviluppando le schermate fino alla fine del giorno 6. Risultato: fine al giorno 12, 3 giorni sovrallocati invece di 2. Scartata.
2. Riassegnare. Priya finisce le schermate il giorno 6 ed è libera dal giorno 7, tranne che per le ferie del giorno 9. Le riassegnazioni possibili sono due, e il calendario le distingue: - Priya prende il test dell’API. Le servono i giorni 8, 10 e 11, finisce il giorno 11 e spinge il test di regressione ai giorni 12–13. Risultato: fine al giorno 13, 0 giorni sovrallocati. - Priya prende il test delle schermate. Si svolge nei giorni 7, 8 e 10 e finisce il giorno 10, entro il suo giorno di margine, mentre Dana tiene il test dell’API e la regressione. Risultato: fine al giorno 12, 0 giorni sovrallocati. Il costo è che le schermate vengono testate dalla sviluppatrice che le ha realizzate.

Dimentica le ferie e la prima opzione sembra gratuita, con Priya pianificata al lavoro in un giorno di assenza.

1. Posticipare. Se nessun altro può testare, Dana svolge le tre attività in sequenza: test delle schermate nei giorni 7–9, test dell’API nei giorni 10–12, regressione nei giorni 13–14. Il GAO osserva che le attività posticipate dal livellamento sono di solito quelle con il margine libero più ampio^[1]. Qui quella scelta è peggiore: posticipare invece il test delle schermate lascia Dana ferma il giorno 7 e fa finire la regressione il giorno 15. Risultato: fine al giorno 14, 0 giorni sovrallocati.
2. Aggiungere capacità. Un tester a contratto sul test dell’API nei giorni 8–10 mantiene il giorno 12 al costo di 3 giornate pagate più un briefing; la guida al recupero di un progetto in ritardo confronta le persone aggiuntive per costo per giorno recuperato.

La nostra raccomandazione per questo rilascio: dare a Priya il test delle schermate, perché per questo team un difetto di layout trovato dopo il rilascio costa meno di un giorno di slittamento. Per una modifica al flusso di pagamento daremmo a Priya il test dell’API e accetteremmo il giorno 13. Come regola generale, prima riassegna e poi posticipa. Inverti l’ordine quando l’unica persona libera finirebbe per testare il proprio lavoro su qualcosa di rischioso e la data concordata ha spazio: se il rilascio fosse promesso per il giorno 15, la mossa 3 non cambia nulla di ciò che si vede fuori dal team.

Prima di considerare livellato il piano, verifica:

• che il carico di ogni persona sia pari o inferiore al 100% in ogni giorno, con ferie e giorni part-time inseriti nei calendari;
• il giorno di fine rispetto a quello prima del livellamento;
• che ogni attività spostata a mano abbia una dipendenza o una nota che spieghi il perché, così che il prossimo aggiornamento non la annulli (il GAO chiede che le modifiche fatte per risolvere i conflitti di risorse siano documentate e comprese da tutti^[1]);
• le persone condivise, su tutti i loro progetti.

Errori comuni#

• Dividere l’assegnazione per far sparire l’avviso. Mettere Dana al 50% su entrambi i test toglie le celle rosse mentre ogni test mantiene i suoi 3 giorni, quindi sulla carta metà delle ore di test sparisce. Fatto onestamente, ogni test al 50% dura 6 giorni.
• Tenere ferie e giorni part-time fuori dal calendario. Nell’esempio, il giorno 9 di Priya è l’unico dato che distingue una riassegnazione che costa 1 giorno da una che non costa nulla.
• Assegnare tutto il team a un’attività. Cinque nomi al 100% sono il carico di cinque persone per l’intera durata. Suddividi l’attività in sottoattività con un responsabile ciascuna, oppure dai a ogni persona la sua quota reale.
• Livellare un piano per fasi. Una barra "Test" di 15 giorni assegnata a due tester non dice nulla su chi è occupato in quale giorno.
• Livellare una volta sola. Il GAO raccomanda di confrontare la data dell’ultimo livellamento con quella dell’ultima modifica alle risorse e alla loro disponibilità^[1]. Ricontrolla dopo ogni slittamento.

I limiti del livellamento#

Il livellamento, a mano o via software, conta le ore e tratta come intercambiabili le persone con le stesse ore. Dana potrebbe essere l’unica con accesso al laboratorio dei dispositivi, e Marco potrebbe essere due volte più veloce di chiunque altro sull’API; nessuno dei due fatti compare in una percentuale di carico. Quando sono le competenze a decidere chi può fare cosa, fissa prima le assegnazioni e livella dopo.

Il livellamento automatico sbaglia in modo diverso. Il GAO chiede ai pianificatori di esaminare l’output delle routine di livellamento automatico e correggerlo dove serve, e avverte che una routine può rivelarsi inefficiente posticipando attività in attesa di una persona disponibile solo in parte^[1]. Nell’esempio, una routine che non divide il test dell’API attorno alle ferie di Priya lo fa iniziare il giorno 10 e chiude il rilascio il giorno 14, un giorno dopo la divisione fatta a mano.

A mano, oltre una certa dimensione le mosse smettono di convergere. La nostra opinione: oltre circa 5 persone condivise su 3 o più progetti, ogni correzione in un piano apre un conflitto in un altro, e un motore di livellamento automatico come quello di Microsoft Project vale il tempo speso a rivederne l’output.

Anche i dati in ingresso pongono un limite. Se le stime di durata sono sbagliate, il sovraccarico si sposta con loro. La guida del GAO aggiunge che il livellamento può avere un effetto minimo o nullo sul cronoprogramma oppure ritardare pesantemente la data di fine prevista, a seconda del margine disponibile, e che quando ritarda il completamento le risorse sono un vincolo reale e il piano richiede un altro approccio^[1]. Regola pratica: se la stessa persona è sopra il 100% per più di 10 giorni lavorativi in un trimestre, spostare le date non basta; riduci l’ambito o aggiungi una persona.

Come farlo in Planitude#

Assegna le persone alle attività (clic destro su una barra, poi Assegna persone) con la quota di tempo che ciascuna dedica. La vista Carico di lavoro mostra il carico di ogni persona per giorno, settimana o mese, misurato sul suo calendario e sulla sua disponibilità. Le celle sovrallocate diventano rosse con un’icona di avviso, una cella settimanale o mensile diventa rossa se anche uno solo dei suoi giorni è sovrallocato e riporta quanti giorni e il picco, e un clic su una cella elenca le attività che la compongono. Il diagramma di Gantt indica in un avviso le persone sovrallocate.

Il portfolio somma il carico di ogni persona su tutti i progetti che puoi vedere. Quando l’assistente propone una modifica, l’anteprima segnala chiunque verrebbe sovrallocato, con il picco e la sua disponibilità. Un piano importato da un file .mpp mantiene il ritardo di livellamento che Microsoft Project ha memorizzato per ogni attività, cioè il tempo per cui è trattenuta rispetto al suo inizio al più presto^[3], e le date ne tengono conto.

Planitude non livella automaticamente. Non calcola nemmeno nuovi ritardi di livellamento: mostra il sovraccarico, e tu lo risolvi con le mosse descritte sopra.

Domande frequenti#