In azienda è importante verificare, prima di mettere in lavorazione e produzione, se un assunto ipotizzato è verificato e corretto.
Lo strumento per condurre un simile esperimento si chiama POC (Proof of concept).
Come dice il nome stesso, serve a provare che una ipotesi è vera prima di investirci troppo tempo, budget, risorse.
Il POC non va confuso con l’MVP (Minimum viable product), che invece seppure minimale, è un prodotto reale e destinato ad andare in produzione.
Il POC va realizzato nel minor tempo possibile e con gli strumenti più semplici: non è raro dimostrare un assunto senza programmare, usando tool esistenti, in modalità congierge (c’è un umano che risponde al posto del backend) o con software sviluppato non tenendo conto delle buone pratiche destinate alla produzione.
Il POC va realizzato in massima economia: se nel team c’è una figura che può farlo senza incidere troppo sulla roadmap di prodotto, è quella giusta.
L’analisi dei requisiti è minima e così il mockup se ne è previsto uno. Il risultato non deve essere preciso a quello richiesto, basta che funzioni e sia utilizzabile, se durante lo sviluppo si trova un workaround che fa risparmiare del tempo, si deve fare senza pregiudizi.
Per il POC importa soltanto l’esperimento e il risultato: potete scriverlo nel linguaggio di programmazione che preferite, con il framework che volete, nuovo o vecchio che sia, il POC non è codice che verrà convertito in produzione, mai.
Se l’assunto del POC è dimostrato, si analizzerà come e quando inserirlo in roadmap, si analizzerà, aggiungerà al piano di lavorazione etc.
Difficilmente il codice del POC se esiste verrà utilizzato, se non come banale reference.
Quando avete bisogno di dimostrare una ipotesi in azienda, realizzate un POC, ne trarrete giovamento nei tempi e avrete subito delle risposte.
Buona sperimentazione.
One thought on “Proof of concept (POC)”