di Davide Casari

La prima volta che all’università mi hanno messo davanti agli occhi il grafico che rispecchia il ciclo di vita di un prodotto, sono di certo rimasto piacevolmente sorpreso.

Forse avevo 19/20 anni e probabilmente avrò percepito che chi l’aveva pubblicato, qualcosa di molto intelligente di sicuro lo aveva pensato.
Praticamente predice il futuro, un futuro dove alla fine per quanto bravi si possa essere e per quanto si possa credere nella propria idea, si perde sempre.


Ma se decidessimo “adesso” che non vogliamo accettare la fase finale, quella di declino?


In ambito Agile si parla tantissimo di come realizzare un prodotto ma mai del perché alla fine questo vada in declino.


Come facciamo a trovare un workaround a questo tragico destino?


Cominciamo cercando di capire insieme se effettivamente la fase di declino di un prodotto è il mercato a decretarla o siamo noi stessi che, pian piano e con il passare del tempo la avviamo e poi la viviamo fino all’effettiva morte del prodotto stesso.


In questo articolo riordiniamo le idee sulla fase di Refactoring di un prodotto ovvero partiamo da un prodotto che già esiste sul mercato, che sta entrando nella sua fase di declino e quale è il metodo giusto per evitare la tragica fine preventivata.


Portiamo lo sguardo ad un semplice esempio conosciuto al più delle persone: Nokia Lumia, che tanto era rinomato per la qualità di Nokia, è stato un prodotto fallimentare entrato in declino e deceduto. La causa è il Prodotto, il Mercato o le Persone che si occupavano dello sviluppo del prodotto?


Partiamo sganciandoci completamente dal concetto di vendita perché il
concetto legato alla vendita ci distorce dal ragionare su quali siano gli effettivi problemi. Vorrei ricordare che uno dei principi fondamentali della metodologia Lean Production è quello di prendere decisioni di lungo periodo a discapito dei guadagni nel breve periodo.

Perché lo dico? Dobbiamo staccarci dal concetto di vendita perché tutte le decisioni che prendiamo devono avere un respiro tale da poterci far pensare, in una fase di “Alte Revenue”, ad una strategia per affrontare il mercato quando il prodotto entrerà nella sua fase di declino.


Per farlo, la strategia dovrebbe essere almeno indirizzata seguendo quello che noi abbiamo definito come Refactoring Life Cycle. Analizziamo quindi in dettaglio quali dovrebbero essere le fasi di re-factoring di un prodotto per essere pronti ad affrontare l’inevitabile fase di declino:

La prima è la fase dell’indifferenza, ovvero la cosiddetta confort zone.


Il nostro prodotto produce revenue indipendentemente dal periodo dell’anno: non c’è un team dedicato perché ormai è un prodotto maturo
che vive di vita propria e senza troppi problemi, non viene dato spazio alle
persone per lavorarci e nel caso ci siano problemi qualcuno interviene al volo e sistema “cosi come viene” perché “finchè funziona tiriamo avanti”.

Non si ha nessuna visione futura di prodotto.


Ad un certo punto subentra il momento di shock, ovvero il momento in cui
non si può più far finta che non ci interessi un determinato avvenimento.


Questo momento può essere, in base ai punti di vista, sia uno shock positivo
(cambiamento tecnologico) che negativo (l’arrivo sul mercato di un competitor) ma in entrambi i casi costringono l’organizzazione ad un cambiamento.


La seconda è quella in cui le persone sono in panico, ovvero ci si rende
conto che bisogna mettere le mani sul prodotto ma a questo punto nessuno lo vuole fare perché non ha la conoscenza tecnica di dominio. Si cerca senza fine un capro espiatorio e tutti danno la colpa ai reciproci manager per non essersene preoccupati prima.

Questi a loro volta alzano le barriere rifacendosi alla mancanza di budget, risorse che dovevano essere dedicate ad altri progetti ed un effettivo “C-Level Sponsor” che portasse avanti l’importanza del prodotto.


La fase di panico però ad un certo punto deve finire per forza, o perché
tutti si sono licenziati e se ne sono andati dall’azienda oppure perché arriva
il momento della consapevolezza ovvero quel momento dove ci si rende
conto che bisogna smettere di avere paura, si capisce se ha senso ripartire e
ci si rimbocca le maniche per ricostruire il prodotto.

Tutte le persone dedicate al team si devono “responsabilizzare” sul
lavoro che dovranno portare avanti.


Attenzione!!! Spesso l’ Agile viene utilizzato solo come gestione del lavoro,
sfalsando il mindset Agile che sta alla base della metodologia. Se si lavora
in maniera meccanica, rispettando solo le tecniche e le pratiche, siamo
di fronte ad una semplice gestione del lavoro e prendiamo la parte meno
importante della mentalità Agile.

La responsabilizzazione è uno dei capisaldi della metodologia ed ognuno all’interno del team deve cercare di raggiungere l’obbiettivo comune.


Finalmente è arrivato il momento di partire e passare alla fase dell’azione,
ovvero ci si organizza aziendalmente su come raggiungere l’obbiettivo di
business.


Entra in campo lo sponsor di prodotto (C-Level), il quale raduna il/i manager(s) che si devono occupare di costruire il team di lavoro e conferisce il budget per area.


A questo punto entriamo nel cuore della metodologia del lavoro Agile: le tecniche e pratiche che in tanti conosciamo e che ci hanno sempre permesso di partire nel modo migliore per l’ideazione e lo sviluppo del prodotto, ora continuano ad aiutarci nella fase di Refactoring.


Grazie ad Inception ed Envisioning si rende partecipe il team di quello che
si dovrà fare, si da più consapevolezza sull’idea del futuro prodotto e di cosa si vuole portare avanti.

L’ insieme delle pratiche come ad esempio Value Stream MAP, User Story Mapping, Stakeholders Map, Risk Analysis e valutazine dei KPI permetteranno al team di procedere in modo più sicuro nella rielaborazione del valore che deve caratterizzare il prodotto sul mercato.


Seguite le pratiche e rifatto il prodotto entriamo finalmente nella parte della curva che ci piace ovvero quella dei profitti: tutto sta funzionando, il
mercato è dalla nostra parte, rilasciamo continuamente funzionalità a seconda di cosa chiedono i nostri stakeholders.

Proprio ora arriva il momento del dilemma ovvero quando ci dobbiamo
chiedere: vogliamo continuare ad essere focalizzati sul prodotto o torniamo
a quella che era una visione solo di progetto?


Le due visioni sono contrastanti.


La visione di prodotto ci permette di avere un team dedicato che segue e
capisce il mercato perfettamente, pronto ad affrontare i cambiamenti tecnologici e totalmente focalizzato sul prodotto.


La visione di progetto invece ci permette la chiusura di un ciclo ovvero finito un periodo di tempo il team si ricolloca e il focus sul prodotto tornerà attivo quando si avranno altri momenti di shock.


Naturalmente la logica ci induce a pensare che se seguiamo una visione
di progetto sicuramente prima o poi si tornerà nella fase dell’indifferenza,
facendo ripartire il “Ciclo di Vita di Refactoring di Prodotto” ed in base a
come si comporterà il team potrà o non potrà tornare un prodotto di successo.


Le casistiche di business all’interno di un’organizzazione aziendale sono
talmente varie che questo modello non ci permette di dire quale sia il
metodo giusto per affrontare il ciclo di Refactoring di un prodotto.
Sicuramente esserne consapevoli e avere un modello da seguire per essere
preparati a fronteggiare la fase di declino proposta da Raymond Vernon (autore di Product Life Cycle Stages), ci permette di essere più precisi nelle decisioni che dobbiamo prendere quando guardiamo
al futuro dei nostri prodotti sul mercato.


E voi che visione scegliereste . . .?