Per molto tempo, a livello produttivo, abbiamo dato quasi per scontata una sequenza abbastanza semplice: si progetta un prodotto, lo si realizza, lo si testa, si correggono gli eventuali problemi e, quando si ritiene che abbia raggiunto un livello adeguato di maturità, lo si mette sul mercato. La commercializzazione rappresenta, in questa logica, una sorta di confine tra due momenti distinti: prima c’è il produttore che sviluppa e verifica, dopo c’è il cliente che acquista e utilizza.
Naturalmente nella realtà non è mai stato tutto così lineare: i prodotti possono manifestare difetti, essere richiamati, modificati e migliorati e le informazioni raccolte dal mercato hanno sempre contribuito allo sviluppo delle generazioni successive. Eppure, almeno concettualmente, il principio di produzione rimaneva chiaro.
Il software, negli anni, ha però progressivamente modificato questa logica, rendendo normale qualcosa che per molti prodotti tradizionali apparirebbe piuttosto strano: acquistare oggi qualcosa di incompleto.
Il tema riguarda le cosiddette politiche di rilascio, cioè il momento nel quale un’azienda decide che ciò che ha realizzato è sufficientemente maturo per incontrare il mercato.
Possiamo chiamare la prima logica Validate Then Release: sviluppo, test, correzione, validazione e, solo successivamente, commercializzazione. In questo modello il produttore cerca di assorbire internamente la maggior parte dell’incertezza relativa al prodotto, magari ne ritarda l’ingresso sul mercato e si accolla tutti i costi di testaggio sostenuti prima che il prodotto raggiunga i clienti.
Esistono naturalmente settori nei quali questa impostazione non rappresenta semplicemente una scelta aziendale: pensiamo per esempio ai dispositivi medici, per i quali la normativa europea prevede requisiti di sicurezza e prestazione, gestione del rischio, valutazione clinica e procedure di valutazione della conformità prima dell’immissione sul mercato. Questo non significa che, una volta commercializzato, un dispositivo medico smetta di essere osservato. Al contrario, il Regolamento europeo prevede una sorveglianza post-commercializzazione durante il suo ciclo di vita, destinata a raccogliere e analizzare sistematicamente informazioni su qualità, prestazioni e sicurezza e a individuare eventuali azioni preventive o correttive.
La differenza però è importante: la sorveglianza dopo la commercializzazione non sostituisce la validazione che deve avvenire prima. Il mercato può fornire nuove informazioni e far emergere condizioni non previste, ma non diventa il laboratorio nel quale verificare per la prima volta se il prodotto è adeguato alla propria destinazione.
Quando il software ha cambiato il confine
Con il software è accaduto qualcosa di diverso, soprattutto quando Internet ha reso estremamente semplice raggiungere prodotti già installati. A differenza di un prodotto fisico distribuito in centinaia di migliaia di esemplari, su quale intervenire significherebbe recuperare i prodotti, portarli in assistenza, sostituire componenti e organizzare campagne di richiamo, su un prodotto software la correzione può essere distribuita attraverso una patch o un aggiornamento.
Non significa che correggere software sia gratuito e nemmeno che le conseguenze di un errore siano necessariamente trascurabili. Questo però ha favorito una politica che potremmo sintetizzare come Release Then Iterate: sviluppare, testare fino a raggiungere una soglia ritenuta sufficiente, rilasciare il prodotto, osservarne il comportamento nell’utilizzo reale e continuare successivamente a correggerlo e perfezionarlo.
Nel mondo dello sviluppo software la filosofia del Release Early, Release Often (rilascia presto, rilascia spesso) è diventata particolarmente nota, soprattutto nell’ambito open source, e il rapporto continuo tra sviluppo, rilascio e utilizzo ha progressivamente modificato anche le aspettative degli utenti. Ma cambiamento culturale è notevole perché oggi, commercializzare, non significa più necessariamente avere terminato lo sviluppo.
Aggiornamenti, patch, nuove release e correzioni fanno ormai parte della normale vita di un software e, in molti casi, non consideriamo nemmeno più il prodotto digitale come qualcosa che possa essere realmente “finito”. Ci aspettiamo, anzi, che ciò che acquistiamo oggi possa essere diverso e possibilmente migliore tra sei mesi.
A questo punto distinguerei due fenomeni apparentemente simili.
Un prodotto può essere rilasciato perfettamente funzionante e completo rispetto alle caratteristiche dichiarate e successivamente ricevere nuove funzionalità. In questo caso non stiamo necessariamente parlando di qualcosa che non era sufficientemente maturo al momento della vendita, ma di sviluppo incrementale. Potremmo sintetizzare questa politica come Release Then Expand: una prima versione contiene un determinato insieme di funzioni, quelle successive ampliano progressivamente il prodotto.
Ma se una cosa è aggiungere domani ciò che oggi non avevo promesso, un’altra è correggere domani ciò che avrebbe dovuto funzionare già oggi.
Nel primo caso abbiamo un prodotto che cresce; nel secondo un prodotto che continua a maturare anche attraverso l’esperienza degli utilizzatori. Naturalmente le due cose possono convivere: uno stesso aggiornamento può correggere problemi esistenti e introdurre nuove funzionalità, ma dal punto di vista della politica di prodotto restano fenomeni differenti.
Esiste poi un’altra logica, spesso confusa con l’idea di commercializzare velocemente qualcosa di incompleto: quella del Minimum Viable Product, o più semplicemente MVP.
Mentre il modello Release Early, Release Often definisce la frequenza del lavoro, l'MVP definisce l'oggetto del primo rilascio: la versione più semplice di un prodotto che ha l'unico scopo di testare il mercato con il minor sforzo possibile. In questo caso l'azienda potrebbe scoprire che la propria intuizione era corretta e decidere di investire nello sviluppo, ma anche modificare profondamente il progetto oppure abbandonarlo.
L’MVP non è quindi un sinonimo elegante di prodotto difettoso o non terminato. ma volutamente limitato per sondare e quindi imparare dal mercato prima di sostenere il costo necessario a costruire il prodotto completo.
Quattro modi di considerare “pronto” un prodotto
Possiamo quindi individuare quattro logiche rispetto al momento della commercializzazione.
Nel Validate Then Release il prodotto viene portato sul mercato dopo avere raggiunto il livello di validazione previsto.
Nel Release Then Iterate viene commercializzato quando è sufficientemente maturo per essere utilizzato, accettando che una parte del perfezionamento avvenga successivamente.
Nel Release Then Expand ciò che viene commercializzato è completo rispetto al proprio perimetro iniziale, che verrà progressivamente ampliato attraverso nuove funzionalità.
Con il Minimum Viable Product, infine, la prima versione serve a produrre conoscenza: verificare se l’idea funziona, come viene utilizzata e se abbia senso continuare a investirvi.
Queste categorie non sono quattro metodologie accademiche alternative, né rappresentano compartimenti stagni. Sono piuttosto un modo per osservare le diverse politiche di rilascio e porci una domanda: quanta incertezza l’azienda decide di gestire e risolvere prima della commercializzazione di un prodotto?
Ed è qui che il discorso smette di riguardare soltanto il software.
Un’automobile contemporanea è ormai qualcosa di profondamente diverso rispetto a quella di qualche decennio fa. Meccanica, elettronica, software, sensori, connettività e servizi digitali convivono e una parte crescente delle funzioni può essere modificata senza cambiare fisicamente il veicolo.
Gli aggiornamenti over-the-air permettono di intervenire a distanza e vengono utilizzati anche come rimedio nell’ambito di campagne di richiamo. Negli Stati Uniti, già nel 2022 la NHTSA registrava 23 richiami che prevedevano una soluzione OTA, più del doppio rispetto all’anno precedente.
Non parliamo necessariamente di elementi secondari dell’infotainment. Esistono richiami relativi a problemi software che interessano illuminazione, sistemi di assistenza alla guida, telecamere e altre funzioni rilevanti per la sicurezza. Non sto dicendo che le automobili moderne vengano deliberatamente commercializzate senza essere testate, e sarebbe scorretto sostenerlo, ma che anche un prodotto fisico complesso e legato alla sicurezza può oggi essere modificato dopo essere entrato nelle mani del cliente. Una possibilità che modifica inevitabilmente il rapporto tra sviluppo, validazione e commercializzazione.
Nasce quindi spontanea una domanda: se la possibilità tecnica di correggere dopo riduce il costo e le tempistiche di produzione del correggere prima, è legittimo domandarsi se, nel tempo, questo possa modificare anche la percezione di trovarci davanti ad un prodotto sufficientemente maturo per essere commercializzato?
Finché questa dinamica riguardava prevalentemente il software potevamo considerarla una caratteristica particolare dei prodotti digitali., ma oggi software e connettività sono presenti nelle automobili, nei televisori, negli elettrodomestici, nei sistemi domotici, nei macchinari industriali e in un numero crescente di oggetti.
La distinzione tra prodotto fisico e prodotto digitale diventa quindi sempre meno netta e, insieme alla tecnologia, potrebbero progressivamente trasferirsi anche le logiche produttive tipiche del mondo software.
A quel punto la questione non riguarda più semplicemente la comodità di ricevere una nuova funzione senza andare in assistenza, ma il significato stesso di prodotto finito.
La possibilità di correggere un prodotto dopo la vendita potrebbe diventare automaticamente una giustificazione per verificarlo meno prima della vendita?
Forse la prossima discussione sulla qualità dei prodotti non riguarderà soltanto quanto siano innovativi, performanti o capaci di aggiornarsi, ma qualcosa di molto più semplice: quanto del loro processo di sviluppo siamo disposti ad accettare che avvenga dopo averli già comprati.
Naturalmente nella realtà non è mai stato tutto così lineare: i prodotti possono manifestare difetti, essere richiamati, modificati e migliorati e le informazioni raccolte dal mercato hanno sempre contribuito allo sviluppo delle generazioni successive. Eppure, almeno concettualmente, il principio di produzione rimaneva chiaro.
Il software, negli anni, ha però progressivamente modificato questa logica, rendendo normale qualcosa che per molti prodotti tradizionali apparirebbe piuttosto strano: acquistare oggi qualcosa di incompleto.
Il tema riguarda le cosiddette politiche di rilascio, cioè il momento nel quale un’azienda decide che ciò che ha realizzato è sufficientemente maturo per incontrare il mercato.
Possiamo chiamare la prima logica Validate Then Release: sviluppo, test, correzione, validazione e, solo successivamente, commercializzazione. In questo modello il produttore cerca di assorbire internamente la maggior parte dell’incertezza relativa al prodotto, magari ne ritarda l’ingresso sul mercato e si accolla tutti i costi di testaggio sostenuti prima che il prodotto raggiunga i clienti.
Esistono naturalmente settori nei quali questa impostazione non rappresenta semplicemente una scelta aziendale: pensiamo per esempio ai dispositivi medici, per i quali la normativa europea prevede requisiti di sicurezza e prestazione, gestione del rischio, valutazione clinica e procedure di valutazione della conformità prima dell’immissione sul mercato. Questo non significa che, una volta commercializzato, un dispositivo medico smetta di essere osservato. Al contrario, il Regolamento europeo prevede una sorveglianza post-commercializzazione durante il suo ciclo di vita, destinata a raccogliere e analizzare sistematicamente informazioni su qualità, prestazioni e sicurezza e a individuare eventuali azioni preventive o correttive.
La differenza però è importante: la sorveglianza dopo la commercializzazione non sostituisce la validazione che deve avvenire prima. Il mercato può fornire nuove informazioni e far emergere condizioni non previste, ma non diventa il laboratorio nel quale verificare per la prima volta se il prodotto è adeguato alla propria destinazione.
Quando il software ha cambiato il confine
Con il software è accaduto qualcosa di diverso, soprattutto quando Internet ha reso estremamente semplice raggiungere prodotti già installati. A differenza di un prodotto fisico distribuito in centinaia di migliaia di esemplari, su quale intervenire significherebbe recuperare i prodotti, portarli in assistenza, sostituire componenti e organizzare campagne di richiamo, su un prodotto software la correzione può essere distribuita attraverso una patch o un aggiornamento.
Non significa che correggere software sia gratuito e nemmeno che le conseguenze di un errore siano necessariamente trascurabili. Questo però ha favorito una politica che potremmo sintetizzare come Release Then Iterate: sviluppare, testare fino a raggiungere una soglia ritenuta sufficiente, rilasciare il prodotto, osservarne il comportamento nell’utilizzo reale e continuare successivamente a correggerlo e perfezionarlo.
Nel mondo dello sviluppo software la filosofia del Release Early, Release Often (rilascia presto, rilascia spesso) è diventata particolarmente nota, soprattutto nell’ambito open source, e il rapporto continuo tra sviluppo, rilascio e utilizzo ha progressivamente modificato anche le aspettative degli utenti. Ma cambiamento culturale è notevole perché oggi, commercializzare, non significa più necessariamente avere terminato lo sviluppo.
Aggiornamenti, patch, nuove release e correzioni fanno ormai parte della normale vita di un software e, in molti casi, non consideriamo nemmeno più il prodotto digitale come qualcosa che possa essere realmente “finito”. Ci aspettiamo, anzi, che ciò che acquistiamo oggi possa essere diverso e possibilmente migliore tra sei mesi.
A questo punto distinguerei due fenomeni apparentemente simili.
Un prodotto può essere rilasciato perfettamente funzionante e completo rispetto alle caratteristiche dichiarate e successivamente ricevere nuove funzionalità. In questo caso non stiamo necessariamente parlando di qualcosa che non era sufficientemente maturo al momento della vendita, ma di sviluppo incrementale. Potremmo sintetizzare questa politica come Release Then Expand: una prima versione contiene un determinato insieme di funzioni, quelle successive ampliano progressivamente il prodotto.
Ma se una cosa è aggiungere domani ciò che oggi non avevo promesso, un’altra è correggere domani ciò che avrebbe dovuto funzionare già oggi.
Nel primo caso abbiamo un prodotto che cresce; nel secondo un prodotto che continua a maturare anche attraverso l’esperienza degli utilizzatori. Naturalmente le due cose possono convivere: uno stesso aggiornamento può correggere problemi esistenti e introdurre nuove funzionalità, ma dal punto di vista della politica di prodotto restano fenomeni differenti.
Esiste poi un’altra logica, spesso confusa con l’idea di commercializzare velocemente qualcosa di incompleto: quella del Minimum Viable Product, o più semplicemente MVP.
Mentre il modello Release Early, Release Often definisce la frequenza del lavoro, l'MVP definisce l'oggetto del primo rilascio: la versione più semplice di un prodotto che ha l'unico scopo di testare il mercato con il minor sforzo possibile. In questo caso l'azienda potrebbe scoprire che la propria intuizione era corretta e decidere di investire nello sviluppo, ma anche modificare profondamente il progetto oppure abbandonarlo.
L’MVP non è quindi un sinonimo elegante di prodotto difettoso o non terminato. ma volutamente limitato per sondare e quindi imparare dal mercato prima di sostenere il costo necessario a costruire il prodotto completo.
Quattro modi di considerare “pronto” un prodotto
Possiamo quindi individuare quattro logiche rispetto al momento della commercializzazione.
Nel Validate Then Release il prodotto viene portato sul mercato dopo avere raggiunto il livello di validazione previsto.
Nel Release Then Iterate viene commercializzato quando è sufficientemente maturo per essere utilizzato, accettando che una parte del perfezionamento avvenga successivamente.
Nel Release Then Expand ciò che viene commercializzato è completo rispetto al proprio perimetro iniziale, che verrà progressivamente ampliato attraverso nuove funzionalità.
Con il Minimum Viable Product, infine, la prima versione serve a produrre conoscenza: verificare se l’idea funziona, come viene utilizzata e se abbia senso continuare a investirvi.
Queste categorie non sono quattro metodologie accademiche alternative, né rappresentano compartimenti stagni. Sono piuttosto un modo per osservare le diverse politiche di rilascio e porci una domanda: quanta incertezza l’azienda decide di gestire e risolvere prima della commercializzazione di un prodotto?
Ed è qui che il discorso smette di riguardare soltanto il software.
Un’automobile contemporanea è ormai qualcosa di profondamente diverso rispetto a quella di qualche decennio fa. Meccanica, elettronica, software, sensori, connettività e servizi digitali convivono e una parte crescente delle funzioni può essere modificata senza cambiare fisicamente il veicolo.
Gli aggiornamenti over-the-air permettono di intervenire a distanza e vengono utilizzati anche come rimedio nell’ambito di campagne di richiamo. Negli Stati Uniti, già nel 2022 la NHTSA registrava 23 richiami che prevedevano una soluzione OTA, più del doppio rispetto all’anno precedente.
Non parliamo necessariamente di elementi secondari dell’infotainment. Esistono richiami relativi a problemi software che interessano illuminazione, sistemi di assistenza alla guida, telecamere e altre funzioni rilevanti per la sicurezza. Non sto dicendo che le automobili moderne vengano deliberatamente commercializzate senza essere testate, e sarebbe scorretto sostenerlo, ma che anche un prodotto fisico complesso e legato alla sicurezza può oggi essere modificato dopo essere entrato nelle mani del cliente. Una possibilità che modifica inevitabilmente il rapporto tra sviluppo, validazione e commercializzazione.
Nasce quindi spontanea una domanda: se la possibilità tecnica di correggere dopo riduce il costo e le tempistiche di produzione del correggere prima, è legittimo domandarsi se, nel tempo, questo possa modificare anche la percezione di trovarci davanti ad un prodotto sufficientemente maturo per essere commercializzato?
Finché questa dinamica riguardava prevalentemente il software potevamo considerarla una caratteristica particolare dei prodotti digitali., ma oggi software e connettività sono presenti nelle automobili, nei televisori, negli elettrodomestici, nei sistemi domotici, nei macchinari industriali e in un numero crescente di oggetti.
La distinzione tra prodotto fisico e prodotto digitale diventa quindi sempre meno netta e, insieme alla tecnologia, potrebbero progressivamente trasferirsi anche le logiche produttive tipiche del mondo software.
A quel punto la questione non riguarda più semplicemente la comodità di ricevere una nuova funzione senza andare in assistenza, ma il significato stesso di prodotto finito.
La possibilità di correggere un prodotto dopo la vendita potrebbe diventare automaticamente una giustificazione per verificarlo meno prima della vendita?
Forse la prossima discussione sulla qualità dei prodotti non riguarderà soltanto quanto siano innovativi, performanti o capaci di aggiornarsi, ma qualcosa di molto più semplice: quanto del loro processo di sviluppo siamo disposti ad accettare che avvenga dopo averli già comprati.
