Refactoring Life Cycle: come evitare il declino di un prodotto

AgileItalia è la prima rivista italiana completamente dedicata all’universo Agile, abbiamo chiesto a Davide Casari, co-founder di questa interessante realtà, di parlarci di uno dei trend del 2022 in ambito Agile: il Refactoring Life Cycle.

Avete un prodotto che non va più sul mercato? Ecco come si esce da una situazione di crisi costruendo un modello utile per tutti.

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.

Refactoring Life Cycle

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:

Fase dell’indifferenza

La prima è la fase dell’indifferenza, ovvero la cosiddetta comfort 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 “così 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.

Fase di panico

La seconda fase è 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.

Momento della consapevolezza

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’obiettivo comune.

Fase dell’azione

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

Entra in campo lo sponsor di prodotto (C-Level), 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.

Momento del dilemma

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 . . .?

La rivista AgileItalia è stata fondata nel 2018 da Tiziano Interlandi, Pierpaolo Cimirro e Davide Casari, è bimestrale e completamente gratuita ed esiste grazie al contributo di più di 70 autori che raccontano le esperienze di cambiamento e innovazione sul campo. Puoi leggere il numero di AgileItalia con il nostro articolo a questo link.