Ha senso caricare di funzionalità un’applicazione software prima di essere messa in produzione?
Per me ne vale la pena solamente quando siamo sicuri che tali funzionalità vengano poi effettivamente usate dalle persone.
Non di rado capita di aprire applicazioni dove le funzioni principali rimangono nascoste tra quelle di dubbia utilità; o, peggio ancora, fra inutili orpelli che compromettono l’usabilità generale.
Un errore molto comune è quello di aggiungere caratteristiche (di poco valore ma che aumentano complessità al software) perché già viste in altri prodotti simili o concorrenti.
Alcuni sbagli probabilmente derivano da un comune pregiudizio: un prodotto che non si presenti subito completo di tutte le funzionalità avanzate verrà giudicato troppo semplice, e quindi non interessante, dall’utente.
Ovviamente, studiare i lavori degli altri e prenderne ispirazione è importantissimo per conoscer meglio il settore e comprendere quale sia l’attuale stato dell’arte.
È però altresì importante valutare, sgombri da qualunque pregiudizio, quali siano le funzionalità da adottare in fase di prima progettazione e quelle di cui possiamo farne a meno.
Quando definiamo le caratteristiche di un nuovo prodotto, dobbiamo esclusivamente mettere in elenco le funzionalità assolutamente necessarie, ed eventualmente sbilanciarsi poco oltre.
Gli sforzi degli analisti, in questa fase, dovrebbero esser maggiormente concentrati nel progettare l’architettura di base del software,
mantenendo semplici e modulari i processi, in modo tale che l’applicazione finale risulti flessibile, snella e aperta il più possibile a future nuove implementazioni.
Altro sforzo, non meno importante, sarà quello di progettare un’interfaccia utente oggettivamente intuitiva e facile da usare (user-friendly).
Minimum Viable Product
Quanto sopra ci riporta alla mente una nota strategia adottata in fase di primo sviluppo delle applicazioni: il Minimum Viable Product (MVP).
Progettare un prodotto minimo funzionante, ma comunque sufficiente allo scopo, ha diversi vantaggi, tra cui:
- il prodotto sarà di base molto più flessibile: non gonfiando inutilmente il software, lo renderà nel futuro più semplice da adattare o modellare;
- riduzione dell’investimento iniziale; la parte di budget non speso potrà eventualmente essere investita successivamente nelle cose effettivamente utili;
- rilascio del prodotto e time-to-market in tempi più brevi;
- ritorno dell’investimento in tempi più brevi;
- l’utilizzo del prodotto consentirà di individuare, con un buon grado certezza, quali siano le funzionalità veramente importanti su cui investire (analisi del comportamento degli utenti e ascolto dei loro feedback);
- riduzione del rischio economico complessivo, nel malaugurato caso che il prodotto non abbia il successo ipotizzato.
Ma quali sono le sufficienti funzionalità che deve avere un prodotto MVP?
Beh, date un’occhiata all’immagine qui sotto (tratta da un articolo di Henrik Kniberg)
Come costruire un Minimum Viable Product
“Less is more”
La nota frase “Less is more!” (“Meno è più!”), attribuita all’architetto Ludwig Mies van der Rohe, sembrerebbe valida anche per il software: molte aziende, ormai famose, hanno iniziato il loro percorso con applicazioni Minimum Viable Product.
Facebook, Airbnb, Instagram, Uber, Dropbox, Spotify,… sono solo alcuni dei casi di successo di applicazioni partite come MVP e che sono poi cresciute, gradualmente e naturalmente, analizzando attentamente il comportamento degli utenti e venendo incontro a ciò che veniva richiesto.
