Durante la mia carriera professionale mi sono capitate parecchie situazioni in cui il processo di analisi, che precede nell'ordine quelli di progettazione e sviluppo, non si è presentato esattamente come ci si sarebbe aspettato dalle descrizioni dei manuali di ingegneria del software. Queste situazioni, che possono spiazzare l'analista non esperto, a mio parere, sono invece la norma o comunque la maggior parte.

Quello che ci si attende negli scenari da manuale è che il problema da risolvere sia completamente descritto e descrivibile, che non sfuggano gli aspetti considerati importanti, quelli che se individuati in una fase successiva mettono in discussione la progettazione già completata od a buon punto. Non è quasi mai così.
A pensarci bene, è tutto sommato anche una situazione naturale, perchè il cliente conosce il suo problema e lo vede dal suo punto di vista, ossia alla luce della sua conoscenza del dominio, e non del come andrà rappresentato. D'altro canto, l'analista conosce le tecniche di rappresentazione e modellazione, ma non è esperto del dominio del problema (o non lo è come il cliente) e cerca di farsene un'idea attraverso i confronti con quest'ultimo. In questa fase di intervista può verificarsi uno scontro vero e proprio a causa del cliente che vuole "correre avanti" suggerendo all'analista la soluzione o cercando di sorvolare su punti da lui giudicati non importanti ma che servono all'altro per farsi il quadro completo.
Quest'ultimo si trova dunque in una posizione delicata, perchè se non particolarmente esperto potrebbe sentirsi "invaso" nel suo territorio di competenza ed indisporsi perdendo la sua oggettività, oppure farsi a sua volta una visione autonoma della soluzione non conducendo più un'analisi sistematica. Se con l'esperienza, questo atteggiamento può essere controllato con un po' di introspezione, è invece difficile controllare il cliente che non si "affida" e che non fornisce tutti gli elementi per completare il quadro.

Per queste situazioni io suggerisco due strade alternative la cui scelta è data dalla tipologia di cliente, dal team che opera sul progetto e dal progetto stesso.

La prima consiste nel raccogliere i requisiti in modo asettico basandosi sui contenuti offerti dal cliente e proporre al cliente la soluzione "bloccata contrattualmente" in funzione delle richieste emerse dall'analisi. Nei casi più fortunati, il cliente che si impegna nella consultazione della documentazione preliminare prodotta (se è il caso aiutato dall'analista) prima di passare alla fase progettuale, capisce da solo che ci sono elementi di incongruenza e finalmente collabora per risolverli. In quelli più sfortunati, il capitolato così prodotto può essere usato per risolvere i contenziosi che non si riuscissero a risolvere con altri tipi di mediazione.

Per realizzare la seconda strategia occorre proporre una soluzione in mancanza di requisiti completi che abbia un senso e che possa funzionare alla luce di quelli che sono gli elementi raccolti. Questa è ovviamente una situazione in cui il cliente è più assente che presente e dove le lacune vanno colmate pena l'impossibilità di proseguire. L'effetto che si vuole ottenere in questo caso è di mettere il cliente di fronte allo scenario ipotetico che si prospetterebbe mantenendo l'attuale condizione di analisi. Se la soluzione prospettata è corretta, od il cliente la ritiene tale, si può così strappare un'approvazione che funga da "paracadute" alla presentazione dell'implementazione; se la soluzione è scorretta, si spera che il cliente evidenzi le inesattezze e collabori finalmente alla loro correzione.

Quello che però ho imparato essere essenziale e che sempre più mi sta portando ove possibile verso processi agili, è che il dialogo va sempre cercato e sollecitato a costo di apparire pedanti. E' ovvio che il cliente si stanca nel rispondere a domande le cui risposte sono per lui (ma non per l'analista) scontate e noiose, ma coinvolgendolo in una logica agile di raffinamenti successivi le possibilità di successo aumentano. E' importante far capire alla controparte che la capacità di risolvere il problema non necessariamente comporta la conoscenza del dominio ma che lui è parte integrante e determinante del processo di soluzione. Finchè non accetta questo, ogni strategia per metterlo di fronte a questa realtà deve essere intrapresa; per questo la prototipazione veloce, il mocking, la formalizzazione dei requisiti sono tecniche che solo apparentemente constituiscono voci accessorie di costo, bensì sono spesso determinanti per giungere ad una soluzione soddisfacente per tutti.