do more with less
news, esperienze, esempi da condividere e qualcosa su di me

giovedì 4 aprile 2013

Usabilità comune e usabilità di business - migliorare la raccolta dei requisiti per un’applicazione

Capire quali siano le aspettative del nostro cliente, quando raccogliamo i requisiti per un’applicazione, è forse una delle fasi più delicate del ciclo di vita di un’applicazione. Far in modo che analisti funzionali e/o tecnici sappiano parlare la lingua del business e viceversa, è sicuramente un’impresa ardua ma non per questo impossibile. Iniziare condividendo alcuni concetti base è una delle possibili soluzioni per far si che il risultato ottenuto (applicazione) coincida con il risultato atteso (requisiti del business).

Ogni parte coinvolta nella fase di raccolta dei requisiti deve essere proattiva nei confronti delle altre parti condividendo, esponendo e comunicando in modo chiaro le proprie aspettative o le soluzioni proposte;  verificando che le controparti abbiano compreso il contenuto trasmesso. Un classico esempio di incomprensione nasce dall’usabilità attesa, dal business, dopo aver esposto i requisiti e i vincoli funzionalit ai quali la soluzione dovrebbe rispondere. In molti casi, il risultato finale non coincide con le aspettative a causa delle cose non dette, sottaciute in quanto considerate ovvie o che si credevano comprese dalla controparte.

L’esperienza accumulata in anni di analisi dei requisiti, mi ha portato a enunciare due definizioni per spiegare, alle parti coinvolte (business e tecnici), le aree di usabilità normalmente “non esplicitate” in fase di analisi.

Usabilità comune

Con questo termine si intende l’usabilità funzionale o d’interfaccia che chiunque utilizzi un’applicazione si aspetta come standard per la tecnologia o il device utilizzato.

Usabilità di business

Con questo termine si intende l’usabilità standard o comune del dominio di business a cui la soluzione da realizzare si rivolge.

Un esempio che aiuta a capire la diversità tra queste due tipologie di usabilità è fornito dal caso d’uso: eliminazione di un record. L’usabilità comune prevede che all’utente che richiede la cancellazione di un record, per esempio premendo su un pulsante “elimina”, venga presentata una richiesta di convalida tramite un messaggio che lo invita a confermare o meno l’operazione esplicitando le conseguenze della conferma (per esempio: “Sei sicuro di voler cancellare il record? Premendo sul pulsante conferma il record sarà eliminato e non sarà più possibile recuperarlo. Per annullare l’operazione cliccare sul pulsante annulla”.). Da cliente questo è quello che mi attenderei senza doverlo esplicitare in fase di analisi (Usabilità Comune). In alcune situazioni, potrebbe capitare, di voler consentire la cancellazione senza richiesta di conferma. In questi casi ci troviamo in presenza di una Usabilità di Business che richiede un’esplicita comunicazione da parte del richiedente in quanto difforme dall’aspettativa comune degli utenti.

Spetta ai tecnici condividere con il business l’usabilità comune in modo che sia esplicito il comportamento standard che l’applicazione assumerà; spetta al cliente (business) esplicitare l’usabilità attesa dal dominio di business specifico per l’applicazione in corso di analisi.

Una cattiva comunicazione nella fase di raccolta dei requisiti porta a incomprensioni e insoddisfazioni con l’inevitabile gioco delle parti  che non giova all’interesse comune che è quello di realizzare una soluzione che fornisca valore al business.

Quindi non siate timorosi e comunicate, comunicate e comunicate garantendovi così una maggior probabilità di successo nei vostri progetti.