Risposta.

Storicamente, la valutazione dello sforzo si basava su stime esperte o analogie con progetti passati. In condizioni di tempo limitato e informazioni, l'analista di sistema è costretto a lavorare con requisiti ad alto livello, vaghi, spesso affrontando incompletezze e aspettative elevate.

Problema: l'incertezza porta a rischi di sottovalutazione, conflitti con il cliente e il team tecnico, nonché a sforamenti di budget. La valutazione è molto complessa a causa della modifica delle informazioni di base dopo la firma del contratto.

Soluzione:

Utilizzare tecniche di decomposizione dei requisiti e rapidi sorteggi (planning poker, T-shirt size)
Identificare e documentare tutte le assunzioni e i vincoli
Mantenere un protocollo di domande e aree sconosciute
Inclusione di riserve per i rischi (coefficenti di incertezza/buffer)
Cosa più importante: fissare i criteri di completamento (Done) e le condizioni limite

Caratteristiche chiave:

Artefatti brevi: scenari ad alto livello, user stories, diagrammi C4
Visualizzazione dei flussi di valore principali
Accento sui prototipi e wireframe, per concordare più rapidamente

Domande trabocchetto.

È possibile effettuare una valutazione senza compromettere la qualità, se i requisiti non sono ancora definiti completamente?

No, qualsiasi valutazione in questa fase dovrà essere contrassegnata come preliminare, con la registrazione dei rischi e riserve. Altrimenti, la responsabilità per lo sforamento ricadrà sull'esecutore.

Dovrebbe includere nella valutazione solo gli oggetti chiaramente definiti dal cliente?

No. Tutto ciò che non è definito viene valutato tramite un "buffer di incertezza" o speciali Story Points per futuri chiarimenti; è importante indicare: "altri requisiti - al di fuori della valutazione".

L'analista di sistema deve partecipare alla preparazione del TCO (costo totale di proprietà)?

Sì, l'analista fornisce i dati di base: elenco dei requisiti, elenco degli scenari, aree di rischio, vincoli, che è critico per il calcolo corretto del TCO.

Errori comuni e anti-pattern

Valutazione del progetto "a colpo d'occhio" senza considerare le aree di incertezza
Ignorare possibili cambiamenti dopo l'inizio dell'implementazione
Non formalizzare per iscritto assunzioni e vincoli

Esempio dalla vita reale

Caso negativo: L'analista di sistema ha preso i requisiti dal manager "così com'è", ha stimato rapidamente, senza approfondire i dettagli e senza esaminare vincoli e aree nascoste.

Pro:

Veloce, comodo per il cliente

Contro:

Sforamento di budget, insoddisfazione del cliente e del team
Refactoring delle soluzioni e i tempi sono "in crisi" fin dall'inizio

Caso positivo: L'analista ha condotto una sessione di lavoro con le principali parti interessate, ha approfondito anche i requisiti generali, ha redatto una mappa delle aree di incertezza, ha indicato le assunzioni e ha introdotto una riserva.