Modellazione 3C con FTEC e Dinamiche Logaritmiche

1. Introduzione e Obiettivo

La gestione di progetti complessi, soprattutto in ambito IT, richiede una chiara comprensione e un bilanciamento tra tre fattori fondamentali, denominati le 3C:

Costo: rappresenta le risorse effettive impiegate nel progetto
Capacità: indica quanta "forza lavoro" o "numero di FTEC" è realmente disponibile
Complessità: misura quanto è impegnativo il progetto in termini di requisiti, rischi e incertezze

Da questi tre cardini discendono la pianificazione del tempo, il budget e la gestione dei rischi. Lo scopo di questa pubblicazione è fornire un modello che mostri:

Come il progetto si "sbilancia" quando una delle 3C è sottostimata o sovrastimata
Perché il tempo di consegna subisce un effetto logaritmico (non lineare) in caso di squilibri
In che modo introdurre il concetto di FTEC e la serializzazione dei ruoli può migliorare la stima e il controllo del progetto
Come figure di governance possano ridurre il carico operativo

2. Il Modello 3C: Costo, Capacità, Complessità

Il cuore del modello si basa sulla formula di regime:

\[\frac{\text{Costo} \;\Leftrightarrow\; \text{Capacità}(\text{Complessità})}{\text{Tempo}} = R\]

Dove \(R\) rappresenta lo stato di "regime" (equilibrio). Se Costo, Capacità e Complessità restano coerenti, il progetto procede entro i tempi previsti. Se qualcosa si sbilancia, si crea uno scostamento e il tempo inizia a crescere in modo non lineare.

Rappresentazione grafica delle 3C

Complessità (X) ↑ │ │ ┌───────┐ │ │ │ Capacità (K) <────┼─────┤ R ├────> Costo (C) │ │ │ │ └───────┘ │ ▼ Tempo (T)

Modello 3C - Rappresentazione Grafica

In condizioni ottimali:

La Complessità è ben stimata
La Capacità è adeguata (numero di risorse e competenze corrette)
Il Costo rispecchia i reali effort (non si sfora)

In questa situazione, il progetto rimane in regime. Se la Complessità risulta molto più alta di quanto stimato, o la Capacità è inferiore, il Costo effettivo può sforare e/o il Tempo si allunga.

3. La Formula di Regime e l'Effetto Logaritmico

Quando il rapporto tra Costo e Capacità, a parità di Complessità, si disequilibra (scostamento \(E\)), il tempo si estende in maniera non lineare:

\[T_{\text{eff}} = T_0 + \alpha \,\ln\!\Bigl(1 + \beta\,E\Bigr)\]

Dove:

\(T_0\) = tempo pianificato a regime
\(E\) = scostamento (per es. Costo reale - Capacità pianificata)
\(\alpha\), \(\beta\) = costanti di progetto

Motivazione: Nel project management, ritardi e sforamenti generano overhead, rilavorazioni e confusione, che si accumulano in modo logaritmico. Non è un'esplosione immediata (esponenziale), ma un prolungamento via via più oneroso.

4. Definizione dell'FTEC

Per calcolare in modo trasparente la Capacità di un progetto, introduciamo l'FTEC (Full Time Equivalent Container):

È un contenitore di 40 ore settimanali
È serializzato: i ruoli diversi (analista, developer, tester, ecc.) non lavorano contemporaneamente sul medesimo contenitore, a meno di scaling interno
Include la valutazione di overhead: se ogni settimana si perdono 4-8 ore in meeting e interruzioni, possiamo fissare \(E=0\) come 32-36 ore effettive

Obiettivo: evitare la somma ingenua di "giorni-uomo" (che gonfierebbe la capacità), e considerare che, di fatto, il "tempo reale" è uno solo.

5. Serializzazione dei Ruoli e Scalabilità Interna

I ruoli diversi lavorano in sequenza all'interno dell'FTEC:

┌─ FTEC (40 ore settimanali) ───────────────────────┐ │ │ │ ┌─────────┬────────────┬─────────┬─────────┐ │ │ │ BA │ Dev │ QA │ ... │ │ │ │ (10h) │ (20h) │ (10h) │ │ │ │ └─────────┴────────────┴─────────┴─────────┘ │ │ │ └───────────────────────────────────────────────────┘

FTEC - Distribuzione dei Ruoli

Se nella settimana allochi 10 ore a BA, 20 a Dev, 10 a QA, la somma è 40. Non c'è "parallelo" tra ruoli diversi.

Scalabilità interna: Se hai 2 developer (ruolo Dev duplicato), in quello slot di 1 ora, 2 Dev lavorano contemporaneamente, producendo 2 "ore-uomo" di sviluppo.

Formalmente:

\[\text{Ore-uomo}(i) = c_i \,\times\, T_i\]

dove \(c_i\) è il numero di risorse parallele nel ruolo \(i\), e \(T_i\) le ore di orologio allocate a quel ruolo.

6. Stima dei Costi nell'FTEC

Costo di un Ruolo

Se il ruolo \(i\) ha costo orario \(\rho_i\) e conta \(c_i\) persone, e gli si dedicano \(T_i\) ore di orologio all'interno dell'FTEC:

\[\text{Costo}(i) = (\rho_i \times c_i) \times T_i\]

Costo di un FTEC

\[\text{Costo(FTEC)} = \sum (\rho_i \times c_i) \times T_i \quad \text{con} \quad \sum T_i \leq 40\]

Se tutto il team è interno con salario fisso, spesso consideriamo "1 FTEC = costo settimanale fisso" (al netto di straordinari)
Se alcuni sono consulenti "time & material", il costo varia in base alle ore effettive \(T_i\)

7. Capacità(Complessità): Formalizzazione Matematica

Carico Operativo dei Ruoli (\(H_i\))

Un progetto può richiedere "\(H_i\) ore-uomo" per completare i task del ruolo \(i\). Perché 1 FTEC basti, serve:

\[\sum_i T_i \leq 40\] \[c_i \times T_i \geq H_i, \;\forall i\]

Se queste condizioni non sono soddisfatte, occorre 2 FTEC, 3 FTEC, ecc. Di fatto, puoi rappresentare la funzione "quanti FTEC servono" in base alla complessità (ore-uomo totali).

8. Governance e Architettura: Migliorare la Qualità, Non la Quantità

Aggiungere figure di governance (Architect, PMO/Scrum Master, BA/QA Lead) non aumenta le 40 ore settimanali, ma può:

Ridurre il carico su Dev/QA/BA (meno errori, meno rifacimenti)
Coordinare meglio, diminuendo overhead

Formalmente si può introdurre un ruolo "Lead" con tempo \(T_{\text{Lead}}\) che riduce \(H_{\text{Dev}}, H_{\text{QA}}, H_{\text{BA}}\), migliorando l'efficienza. È uno scambio dentro le stesse 40 ore.

9. Rappresentazioni Grafiche

Grafico delle 3C

Possiamo immaginare un diagramma a cubo in cui i tre assi rappresentano Costo (C), Capacità (K), Complessità (X):

Complessità (X) ↑ | (K)<---- Regime ----> (C) | | Tempo (T)

Dove ci posizioniamo sul "piano" definito da K e C, e la Complessità sposta l'"altezza" del regime. Se la Complessità cresce a parità di Capacità, il Costo deve salire o il Tempo si dilata.

Numero di FTEC necessari (Funzione a gradini)

Se la massima capacità di 1 FTEC (distribuendo le 40 ore in modo ottimale tra i ruoli) è, ad esempio, 64 ore-uomo, allora la funzione che restituisce "FTEC_needed" in base alla Complessità risulta:

Relazione Complessità-FTEC

10. Conclusioni

Il modello presentato fornisce un approccio integrato che copre diversi aspetti fondamentali della gestione dei progetti:

Modello 3C

Il bilanciamento tra Costo, Capacità e Complessità è cruciale. Qualsiasi scostamento produce un ritardo non lineare che segue una curva logaritmica, potenzialmente compromettendo il successo del progetto se non gestito appropriatamente.

FTEC e Serializzazione

L'introduzione del concetto di FTEC come contenitore di 40 ore settimanali permette di evitare le sovrastime additive tipiche dell'approccio a "giorni-uomo". La serializzazione dei ruoli, con la possibilità di scaling interno per ruoli specifici, offre un modello più realistico della capacità effettiva del team.

Gestione dei Costi

Il modello fornisce una struttura chiara per la stima dei costi, considerando sia scenari con team interno che situazioni miste con consulenti esterni, attraverso la formula del costo per ruolo e FTEC.

Capacità e Complessità

La formalizzazione matematica della relazione tra capacità e complessità permette di determinare in modo oggettivo quando è necessario scalare con ulteriori FTEC, evitando sovraccarichi e mantenendo la qualità del lavoro.

Ruolo della Governance

L'integrazione di figure di governance e architettura rappresenta un investimento strategico che, pur rimanendo all'interno dello stesso contenitore FTEC, può significativamente migliorare l'efficienza complessiva riducendo errori e overhead.

Effetto Logaritmico

La comprensione dell'effetto logaritmico sui tempi in caso di squilibri sottolinea l'importanza di mantenere il progetto in regime, evidenziando come piccoli scostamenti iniziali possano portare a dilatazioni temporali significative nelle fasi successive.

In conclusione, questo modello offre un framework completo per la pianificazione e il controllo di progetti IT, evitando le comuni trappole della sovrastima delle capacità e della sottovalutazione della complessità. La sua applicazione pratica può significativamente migliorare la precisione delle stime e la gestione delle risorse.