Un requisito per amico

“Requisito: Cosa ricercata, richiesta; Qualità o dote necessaria per ottenere un fine”.

Durante la realizzazione di un progetto software viene prodotto un quantitativo di carta incredibilmente variabile. Si passa dal paio di chili agevolmente prodotti dall’analista di professione ai pochi grammi della solitaria fattura finale dello sviluppatore freelance.

Indipendentemente dalla metodologia utilizzata, quello che si deve sempre fare è redigere il documento che illustra, in un paio di pagine al massimo, gli obiettivi che il cliente vuole raggiungere e le funzionalità da realizzare.

Punto di vista del cliente
Gli obiettivi devono essere definiti ad alto livello e l’identificazione delle funzionalità deve coinvolgere gli utenti finali.

Linguaggio naturale
La terminologia tecnica utilizzata può essere solo quella dal punto di vista del cliente, a condizione di prevedere un glossario.

Completezza
Devono essere indicati tutti gli obiettivi e le funzionalità principali.

Priorità
Tranne che in casi molto semplici, assegnare priorità agli obiettivi da raggiungere aiuta a limitare i danni nel caso in cui debba interrompere il progetto prima del completamento, tipicamente per sforamento dei tempi o del budget.

Condivisione
Gli obiettivi devono essere condivisi e compresi da tutti i soggetti coinvolti.

Questo documento è previsto, in diverse forme e sotto vari nomi, in quasi tutti i modelli utilizzati per la definizione dei requisiti.

Il motivo è semplice: durante lo sviluppo e l’evoluzione del progetto può capitare che si perda di vista l’obiettivo finale; in pratica il viaggio diventa più importante della meta. In questi casi, poche righe che ricordano i requisiti fondamentali sono un prezioso aiuto per (re)indirizzare il progetto nella giusta direzione.

Naturalmente se siete “harleysti” il viaggio è più importante della meta… ma questa è tutta un’altra storia.

L’insostenibile leggerezza della responsabilità condivisa

“Ping Pong”

Nella realizzazione della componente software di un sistema informativo sono coinvolti sempre almeno due soggetti: il cliente e lo sviluppatore.

“Cliente” e “sviluppatore” possono essere due dipartimenti di una multinazionale, o il piccolo imprenditore e un solitario sviluppatore; resta il fatto che seduti a un tavolo ci sono due soggetti che condividono lo stesso obiettivo (escludiamo in casi in cui una o entrambe le parti siano in malafede).

Quello che succede spesso è che i due sono ai lati opposti del tavolo, concentrati sul lanciare la pallina nella metà campo avversaria.

In alcuni casi si ritiene che questo sia il miglior modo di far progredire il progetto; in altri si tratta di un’attività inconscia basata sul senso di tranquillità che deriva dall’aver passato ad altri il nostro problema.

Al contrario è molto utile pensare al progetto come a una responsabilità condivisa.

Perché?

Che cosa pensate quando un collega vi dice “Ho partecipato al progetto Apollo 13 che è andato molto male ma del cui fallimento posso dimostrare di non avere colpa”?

Questa risposta fa crescere in voi il desiderio di affidare un incarico al collega o di averlo con voi nel vostro team?

Tempo, budget e obiettivi

“Il triangolo solo in geometria è una costruzione innocua.”
Anonimo

Quando si realizza un prodotto software i tre indicatori dell’andamento del progetto sono:

  • il tempo impiegato per completare il progetto;
  • il budget utilizzato (non quello previsto);
  • l’obiettivo raggiunto, ovvero le funzionalità (utili) realizzate.

Mentre l’esistenza di questi indicatori è intuitiva, è molto più difficile convincersi che le tre misure sono tra loro dipendenti.

Più precisamente non sembra possibile riuscire a definire i tre indicatori in modo indipendente.

Per esempio, stanziando un certo budget per la realizzazione di determinate funzionalità, non si riesce a determinare a priori quanto tempo sarà necessario per completare il progetto. Analogamente, fissando un tetto di costo e una data di consegna irrinunciabile, le funzionalità realizzate non saranno quelle inizialmente previste.

Il fatto che il fenomeno si verifichi in quasi tutti i progetti , anche se in misura molto variabile, e sia presente anche nel caso di team competenti e affiatati suggerisce che potrebbe trattarsi di un errore metodologico.

L’errore risiede nel credere possibile definire a priori e in maniera esaustiva le funzionalità che un software deve fornire per soddisfare le necessità del sistema informativo in cui sarà utilizzato.

E’ infatti normale che durante lo sviluppo le funzionalità richieste al prodotto siano in continua evoluzione, con aggiunte, profonde modifiche ed eliminazioni. Tali sconvolgimenti influenzano inevitabilmente costi e tempi di realizzazione.

In un mondo ideale si procederebbe fino al raggiungimento degli obiettivi incuranti di tempi e costi; nella realtà tempi e costi sono quasi sempre gli elementi non negoziabili.

Il problema sembra irrisolvibile: il mutare imprevedibile dei requisiti causa l’inevitabile sforamento dei tempi e costi.

Invece la soluzione è insita proprio nella mutabilità dei requisiti.

Procedendo con una graduale realizzazione e messa in esercizio delle funzionalità richieste, lasciando definire le priorità al cliente, approfondendo i dettagli il più tardi possibile e misurando il conseguimento degli obiettivi dal punto di vista del valore per l’utente si scopre che molte funzioni “immaginate” mesi prima non sono necessarie, che è possibile sostituire una nuova funzionalità con la combinazione di alcune esistenti e che l’80% del lavoro viene fatto con il 20% delle funzionalità.

La nota dolente è che per questa soluzione si deve cambiare un po’ il modo di affrontare lo sviluppo del software. L’argomento è vasto e sarà il tema di molte delle prossime puntate.

Sistema informatico o sistema informativo?

“Tre fili fanno uno spago.”
Proverbio italiano

“Informatico”, “Informativo”… Sembrano la stessa cosa; forse è solo l’errore di battitura di una segretaria distratta.

No. La differenza c’è ed è conveniente averla chiara prima di iniziare a pensare a una qualsiasi soluzione software.

Il modo più semplice per spiegare la differenza tra i due concetti è definire la composizione di un sistema informativo:

  • procedure: rappresentano il “come” del sistema; possono essere scritte o raccontate la sera davanti al fuoco;
  • persone: sono quelle che il sistema lo fanno funzionare, a prescindere da come la pensano alcuni manager;
  • strumenti: pinze, martello e software sono quanto le persone usano seguendo le procedure.

Un “sistema informatico” è solo uno degli strumenti.

E’ composto, oltre che dal software, anche da qualche chilo di hardware che, magari, comprende alcune costose periferiche. Ma rimane comunque solo uno degli strumenti.

Sovente, chi costruisce o vende sistemi informatici tende a dimenticare, per miopia o tornaconto, che della ricetta del successo fanno parte anche persone e procedure.

Più pericoloso è quando a dimenticarlo è il committente.

Sembra strano, soprattutto perché spesso il committente è proprio una delle persone citate tra gli ingredienti del successo.

Dipende dall’umana propensione credere alla pillola magica: “per migliorare il sistema aziendale o risolvere dei problemi basta avere il software giusto”.

Procedure, persone e strumenti sono ingredienti che possono essere usati in proporzioni diverse ottenendo lo stesso risultato.

Si può ridurre l’intervento delle persone automatizzando i processi; si possono diminuire le procedure aumentando nel software l’intelligenza e la capacità di resistere agli errori; si può infine semplificare il software adottando procedure migliori e formando il personale.

I tre ingredienti devono però essere tutti presenti.