PROGETTO o PRODOTTO software? Implicazioni strategiche

In molte organizzazioni che sviluppano software si parla di “progetti di sviluppo” piuttosto che “prodotti” sviluppati. Ma quali sono i risvolti di questa scelta, spesso implicita e poco ragionata?

Risposta:

• facilità di gestione, a fronte di
• introduzione di silos
• aumento del debito tecnico, allungamento del time-to-market e aumento del costo
• povertà di feedback all’indietro
• poco supporto per ragionamenti strategici.

Vediamo perché.

La ragione principale per avviare un “progetto” software è di pianificarne lo sviluppo andando a decidere quali saranno le varie milestone, i relativi artefatti consegnati, le attività necessarie per ottenerli, le loro relazioni di dipendenza e infine le risorse da allocare. Pianificare è la parola chiave.

E quindi il progetto avrà una data di inizio, una data prevista di fine, e una sequenza temporale di attività. Sarà facile per il project manager seguirne l’evoluzione, monitorando il completamento delle varie attività, l’impiego delle risorse, la consegna degli artefatti previsti e l’andamento dei costi. 

Però come sappiamo da decenni ormai in moltissime situazioni questo schema, adatto per costruire un grattacielo, non funziona bene per il software. Una ragione è l’incertezza sul cosa vada costruito e l’incertezza sul modo di costruirlo. Data questa incertezza, uno deve chiedersi quanto valido sia il piano predisposto.

Ma anche se si riuscisse a dominare questo aspetto (ad esempio adottando un metodo agile di sviluppo) rimangono tutta una serie di problemi. Il primo è: cosa succede del sistema costruito alla fine del progetto? Normalmente viene messo in esercizio e la sua gestione passa al personale di Operations incaricato di mantenerlo in funzionamento, monitorandolo di continuo. Il problema è legato al passaggio di consegne, dal gruppo di sviluppo al gruppo di Operations. 

Una seconda sfaccettatura è legata a chi mantiene il codice del sistema, attuando interventi correttivi ed evolutivi. Spesso si assegna questa responsabilità a un gruppo di persone che, in maniera saltuaria quando serve, si attivano per queste modifiche. Si tratta di un altro passaggio di consegne, perché non è detto che queste persone siano le stesse che l’hanno costruito. 

Come in tutti i passaggi di consegna, le due conseguenze negative che ci si deve attendere sono un degrado delle conoscenze e la mancanza di un ciclo di feedback all’indietro. Ad es. è stato descritto fin dagli anni ‘80 che sviluppare software non è “scrivere del testo”, ma formalizzare in linguaggi di programmazione un proprio modello mentale di come il software funziona. E per quanto bene si riesca a documentare tale modello (in documentazione informale, formale, visuale, o come clean code) comunicare questo modello non avviene mai perfettamente, a meno che le due persone coinvolte non abbiamo lavorato insieme per un po’ di tempo su quel modello. L’effetto negativo è quindi una crescita dell’entropia del sistema, e un degrado della qualità interna del sistema. Con la conseguenza di un incremento del debito tecnico, e quindi del time-to-market e costo.

Ma c’è di peggio. Adottando l’ottica a progetto difficilmente si deciderà di coinvolgere Operations e i manutentori in maniera proattiva sia per prestare attenzione a segnali premonitori di problemi incombenti, sia per sfruttare il sistema in esercizio per raccogliere informazioni dal campo che possano essere utili a decidere come far evolvere il sistema.

Secondo la Treccani, con strategia si intende, all’interno delle scienze aziendali,

l’insieme delle scelte e delle azioni, coordinate e coerenti, operate all’interno dell’azienda al fine di conseguire un obiettivo predeterminato che riguarda una parte o tutte le aree aziendali.

Procedendo per progetti, una volta che il progetto è terminato, il sistema raramente diventa argomento da trattare in riunioni strategiche e raramente lo si associa a obiettivi aziendali.

Se invece si procedesse per prodotti si avrebbero a disposizione molte più leve strategiche:

1. un prodotto viene concepito e pianificato in base a una visione e alla sua capacità di perseguire determinati obiettivi aziendali. Questo consente di focalizzare il lavoro sulle feature centrali di quel prodotto e inoltre aiuta ad allineare tutte le persone coinvolte.
2. Gli obiettivi aziendali cambiano al cambiare del livello di maturità del prodotto. Ad es. un prodotto nascente avrà come scopo quello di sondare la risposta del mercato o verificare la fattibilità tecnica di un sistema. In fasi successive, lo stesso prodotto potrà avere lo scopo di allargare la sua base di clienti. La possibilità di associare al prodotto obiettivi diversi in tempi diverse consente di seguire l’andamento del mercato e aggredire in maniera efficace nuove opportunità.
3. Il prodotto viene assegnato a uno o più team (team, non gruppi) che sono stabili e autosufficienti, per seguire il prodotto in tutte le sue fasi di vita, inclusa la messa in esercizio e la manutenzione. Questo riduce il problema del passaggio di consegne. 
4. L’evoluzione del prodotto viene governata in fasi, in modo che in ogni fase si ipotizzi la capacità di sortire gli effetti desiderati, si monitori degli indicatori che lo segnalano, si valuti di continuo i rischi che cìo non avvenga. Inoltre in ogni fase si decide quanto investire su quel prodotto a fronte degli obiettivi previsti. Questo consente di procedere in maniera iterativa, monitorando di continuo il ritorno dell’investimento sulla base di dati raccolti dal campo.
5. Le fasi possono riguardare anche dei Minimum-Viable-Product volti ad esplorare la risposta degli utenti e del mercato a nuove idee. Questo consente di essere proattivi e mettere sul mercato prima di concorrenti un prodotto che anticipa le richieste dei clienti.

Questi benefici di una organizzazione a prodotto dello sviluppo del software sono importanti a livello strategico perché impattano su aspetti quali l’allineamento, il focus, la definizione di obiettivi di business, il loro monitoraggio basato su dati, il controllo del debito tecnico, l’essere in grado di sondare il mercato che consentono di sfruttare il prodotto software come leva strategica.

Ovviamente, un’organizzazione a prodotto non è una panacea. Ad es. se dovessimo realizzare un sistema la cui vita attesa è molto breve (qualche mese) dopodiché si sa che verrà cestinato, una gestione a progetto sarà più adeguata perché più semplice.

Nel vostro caso, che tipo di organizzazione si privilegia? Funziona? È sempre stato così?

Pubblicato originariamente come Articolo LinkedIn.