I rischi di prototipare a fedeltà troppo alta

Qualche giorno fa mi sono imbattuto (su segnalazione di Totanus) in un’esperienza molto particolare dal punti di vista di chi si occupa di progettazione e realizzazione vissuta da Ted Patrick, uno dei più attivi evangelisti Flex.

Ted come molti sviluppatori usa Flex (ma il discorso vale anche per altri linguaggi/ambienti di sviluppo) per prototipare gli applicativi che andrà in seguito a sviluppare nel dettaglio utilizzando chiaramente i componenti di default che sono disponibili. Questi componenti sono però pensati a livello visuale e funzionale per creare applicazioni potenzialmente finali.

Dove sta dunque il problema?

Il problema è che Ted quando mostra i suoi prototipi con una così alta fedeltà ai clienti si trova davanti un gruppo di persone che pensa che l’applicazione sia già terminata e dunque non comprende perchè dovrebbero pagarlo per realizzare la definitiva.

Questo problema è abbastanza noto a chi usa la prototipazione rapida da molti anni ed è il tipico rischio che in genere si prendono inconsciamente coloro che sviluppano in ambienti agili (es: ROR).

Infatti realizzare direttamente prototipi ad alta fedeltà da un lato accellera lo sviluppo ma dall’altro non da il tempo agli stakeholders di comprendere l’evoluzione e la maturazione del prodotto; non portando così il giusto ritmo nei cambiamenti di requisiti e facendo passare il progetto come “semplice”.

Ted dall’alto della sua esperienza ha risolto la situazione creando un foglio di stile per l’UI di default di Flex semplificato ai minimi termini (wireframes), soluzione che però probabilmente non gli risolverà comunque tutte problematiche date da un approccio prototipale diretto.

  1. Frenz

    In un approccio prettamente prototipale, il valore aggiunto sta nel sviluppare le funzioni essenziali, sottolineo che sono abbastanza ignorante in materia di Flex.
    Tornando alla progettazione; quindi anche se si arriva ad una UI di buon livello, la leva operativa per motivare i costi dell’intero progetto sta nel far comprendere come a livello applicativo il prototipo faccia poco o nulla…

  2. Luca Mascaro

    Secondo una logica di buon senso si, ma Ted dimostra come in realtà quello che spesso il cliente capisce è ciò che vede, dunque se vede un interfaccia anche semi-statica che però comprende tutte le funzionalità visualmente vi è il forte rischio che le percepisca come già sviluppate

  3. Frenz

    Compreso, paradossalmente il rischio con una UI molto ricca esiste.

  4. Alessio

    Francamente mi sembra un rischio che si può avere solo lavorando direttamente con l’utente finale, mentre su progetti importanti è (dovrebbe essere) sempre presente il supporto dei sistemi informativi, che sanno benissimo cosa vuol dire “prototipo” (che per inciso è qualcosa di più di una semplice dimostrazione dell’interfaccia utente).

    Cmq, lì bisogna ancora di più essere in grado di far parlare il commerciale della situazione che sarà sicuramente in grado di vendere le giornate che servono per portare il progetto fino in fondo. :)

    Ciao,
    Alessio

  5. Antonio

    Io non prenderei delle posizioni drastiche in merito alla fedeltà del prototipo.

    La fedeltà può essere legata agli obiettivi che si vogliono raggiungere e al tipo di cliente che si ha davanti.

    Prima di adottare un protoipo ad alta fedeltà è bene conoscere le persone alle quali lo si propone.