Il concetto di Minimum Viable Product(MVP) è ben noto e sottende al fatto di effettuare il bulding e delivery di soluzioni software che implementino le funzionalità a più alto valore per i propri clienti o,più in generale, per il proprio target di riferimento . Ciò fatto nel minore tempo possibile. Volendo fornire una definizione di MVP potremmo dire che un MVP è “una versione di un prodotto con abbastanza funzionalità da renderlo utilizzabile subito dagli utenti affinchè gli stessi possano fornire feedback per gli sviluppi futuri”.
Realizzare un MVP è il modo per avviare un nuovo progetto e metterlo sul mercato nel più breve tempo possibile al fine di raccogliere le opinioni degli utenti e quindi, soprattutto nel caso fossero negative o che comunque non soddisfano il Business Plan, prevenire di investire risorse economiche ed umane su un prodotto che potrebbe rivelarsi fallimentare.
Questi feedback iniziali possono, però, essere anche positivi ed in alcuni casi estremamente positivi e questo vuol dire che il prodotto sta avendo il successo auspicato e pertanto deve essere in grado di evolvere avendo a disposizione le necessarie risorse architetturali. E’ in questo momento che diventa importante la Minimum Viable Architecture(MVA).
Contattaci subito e senza impegno per ottenere MVA per i tuoi software.
Cos’è la Minimum Viable Architecture(MVA) e l’errore iniziale comune
Generalmente si progetta un’architettura con un minimo set di componenti perchè il focus è nella costruzione del MVP e la MVA è influenzata quasi esclusivamente dai requisiti funzionali del MVP. Nella realtà la MVA deve, invece, tenere in debita considerazione i Quality Attribute Requirements(QAR), cioè i valori che ha la funzionalità, valore inteso con logicità e buon senso. Per un approfondimento sul concetto di QAR ti suggeriamo il nostro precedente articolo “Scetticismo nella progettazione del software ed i Quality Attribute Requirements(QAR)“.
In pratica la progettazione della MVA, spesso, tende ad essere “tattica” ed a pensare alla velocità e non alla sostenibilità del prodotto. Si scelgono tecnologie già pronte all’uso o che già si utilizzano per altri progetti in modo da effettuare minime configurazioni e cambiamenti.
Questo approccio però è fallimentare sul lungo periodo perchè comporta, soprattutto nel caso del successo del progetto(che è ciò che l’azienda vuole), un continuo ripensamento dell’architettura per soddisfare nuovi requisiti che non sono stati presi in considerazione all’inizio. Questo si traduce in maggiori costi e nel peggiore dei casi nell’impossibilità a soddisfare i nuovi requisiti del prodotto.
Si deve invece definire la MVA attraverso la sostenibilità del progetto nel lungo periodo ed, in generale, le architetture software devono essere guidate da QAR, cioè dal valore della funzionalità, e non dal mero soddisfacimento della funzionalità.
Contattaci subito e senza impegno per consulenza e progettazione di Architetture Software.
Quali decisioni prendere per definire una MVA
Rispondere alla domanda “Cosa significa abbastanza nella MVA” potrebbe sembrare complicato, ma nella realtà è una questione di buon senso strategico, infatti, nelle scelte da prendere per progettare una MVA devono confluire tutte quelle relative al fatto che la MVA sia fattibile e gestibile nel futuro. In poche parole, se ho necessità di effettuare un cambiamento nell’architettura, tale cambiamento non deve far diventare il prodotto sviluppato anti-economico, impraticabile se non impossibile da gestire e migliorare.
Tra gli elementi che devi prendere in considerazione trovi:
- Concurrency: quanti utenti, sensori o altri dispositivi accederanno simultaneamente al prodotto;
- Throughput: quante transazioni o processamenti di dati il prodotto deve essere in grado di effettuare in un determinato periodo di tempo;
- Latenza e responsività: quanto velocemente il prodotto deve rispondere agli eventi;
- Scalabilità: quanto deve essere abile a gestire picchi della domanda e dei processi computazionali;
- Persistenza: quanti dati devono essere archiviati, per quanto tempo e con quali relazioni tra di essi;
- Sicurezza: quali protezioni deve avere il prodotto per ottenere confidenzialità, integrità e disponibilità dei dati;
- Monitoraggio: come si permette ai tecnici(sistemisti, sviluppatori, ecc..) di monitorare le performance e la qualità del prodotto;
- Piattaforme: quali limiti e quali caratteristiche in termini legali o di performance( per es. nel caso delle real-time application) deve soddisfare l’architettura
- User Interface: come l’utente accederà al prodotto, tramite classica UI 2D oppure con Virtual Reality(VR) and Augmented Reality(AR).
Questa lista non vuole essere esaustiva ma ha l’obiettivo di darti l’idea che devi pensare alla MVA guardando al futuro per evitare che l’architettura diventi il limite di espansione e crescita del prodotto software.
Contattaci subito e senza impegno per consulenza e progettazione di Architetture Software.
Glue Labs e la Minimum Viable Architecture(MVA)
Abbiamo progettato MVA per progetti di successo come iPatente Cloud(leggi il Case Study) e architetture complesse per applicazioni impiegate in ambito energetico, sanitario e gestionale. Gli ambienti critici in cui il nostro software opera ci hanno permesso di costruire un’importante sensibilità verso la qualità del software, sensibilità che ci permette di fornirti la tua applicazione con garanzia 12 mesi da qualsiasi bug. Grazie all’esperienza maturata in tantissimi settori, con numerosi Clienti e con un solido gruppo aziendale ti forniamo le competenze per progettare, sviluppare e manutenzionare anche in maniera evolutiva le tue applicazioni. Contattaci subito e senza impegno per maggiori informazioni.
