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.