Quando un software fa troppo: perché aggiungere funzionalità non significa creare valore

Esiste un momento, nello sviluppo di un software, in cui il progetto sembra aver raggiunto tutti gli obiettivi prefissati.

Le funzionalità richieste sono state implementate, i test superati, il sistema rilasciato nei tempi concordati e il cliente approva il risultato. Dal punto di vista tecnico, non c'è nulla da eccepire. Ma è proprio da quel momento che inizia la prova più importante.

Quando il software entra nella quotidianità dell'azienda, le persone iniziano a confrontarsi con lo strumento non più come progetto, ma come parte del proprio lavoro. È in questa fase che emerge un fenomeno sorprendentemente frequente: molte delle funzionalità sviluppate vengono utilizzate solo sporadicamente, mentre altre non entrano mai davvero nelle abitudini operative 

Non significa necessariamente che siano inutili o progettate male. Nella maggior parte dei casi rispondono a esigenze reali emerse durante l'analisi, e anche la progettazione risponde alle richieste fatte. Il punto è un altro: ciò che ha perfettamente senso quando viene valutato come singolo requisito può perdere efficacia quando entra a far parte di un sistema molto più articolato.

Per questo motivo il successo di un software non coincide con la sua consegna. Un progetto genera valore quando viene adottato con naturalezza dalle persone che dovranno utilizzarlo ogni giorno. È allora che la qualità della progettazione smette di essere una questione tecnica e diventa una questione organizzativa.

Quando un progetto cresce, difficilmente lo fa per decisioni sbagliate. Al contrario, cresce perché quasi ogni nuova richiesta appare ragionevole.

C'è una funzionalità che permette di automatizzare un'attività ripetitiva. Un'altra che evita un possibile errore. Una terza che gestisce un caso particolare. Una quarta che potrebbe tornare utile se, in futuro, cambiasse il processo aziendale. Osservate singolarmente, ognuna di queste funzionalità decise è difficili da contestare.

Ma la complessità non nasce quasi mai da una scelta evidentemente sbagliata. Nasce dall'accumulo di molte scelte corrette che vengono prese una alla volta, senza considerare attentamente il loro effetto complessivo.

Ogni nuova funzionalità modifica infatti l'equilibrio del sistema e aggiunge nuove possibilità, ma anche nuovi percorsi, nuove eccezioni, nuove interazioni e nuove dipendenze.

In progettazione esiste sempre un compromesso. Ogni funzione aggiunta aumenta ciò che il software può fare, ma riduce, almeno in parte, la sua semplicità, la sua leggibilità e la sua capacità di evolvere senza aumentare ulteriormente la complessità. Questo non significa che aggiungere funzionalità sia sbagliato, significa riconoscere che ogni scelta produce contemporaneamente un beneficio e un costo, e che progettare significa valutare entrambi.

Quando si discute una nuova funzionalità, l'attenzione si concentra quasi sempre sul problema che quella funzione permetterà di risolvere. Molto più raramente ci si chiede quale sarà il suo impatto negli anni successivi.

Una nuova funzionalità non termina il proprio ciclo di vita quando viene completata dagli sviluppatori. Da quel momento inizia, piuttosto, a far parte del patrimonio del software. Ogni aggiornamento dovrà continuare a tenerne conto. Ogni modifica futura dovrà verificare che continui a funzionare correttamente. Ogni nuova integrazione dovrà convivere anche con quella logica.

Esiste poi un costo ancora meno visibile. Le organizzazioni non imparano un software una volta sola. Ogni nuovo assunto dovrà essere formato. Ogni cambiamento richiederà tempo di adattamento. Ogni funzione poco utilizzata continuerà comunque a occupare spazio mentale nelle persone che utilizzano il sistema.

È per questo che il costo di una funzionalità non coincide con il suo sviluppo ma continua ad accompagnare il software per tutta la sua vita operativa. Questa prospettiva rende alcune funzionalità molto più costose di quanto sembrino durante la fase di analisi.

Durante la progettazione di un software esiste quasi sempre un utente ideale, la persona che conosce perfettamente il sistema, ricorda ogni procedura, utilizza tutte le funzionalità disponibili e segue il percorso previsto dai progettisti.

Nella realtà quell'utente non esiste.

Le persone lavorano in un contesto fatto di urgenze, interruzioni, abitudini consolidate e tempi ridotti.

Il loro obiettivo non è utilizzare tutte le possibilità offerte dal software. È portare a termine il proprio lavoro nel modo più efficiente ed affidabile possibile. Per questo motivo tendono naturalmente a scegliere i percorsi che conoscono meglio, quelli che richiedono meno attenzione e che riducono il rischio di commettere errori.

Quando una funzionalità richiede uno sforzo cognitivo superiore rispetto al beneficio che sembra offrire, viene progressivamente abbandonata, non perché inutile ma perché il costo di utilizzarla viene percepito come superiore al valore che restituisce.

Qui nasce il divario tra software progettato e software realmente utilizzato.

Quando un'azienda commissiona un software, è naturale che voglia cogliere l'occasione per risolvere il maggior numero possibile di problemi. Ogni richiesta nasce da un'esigenza reale e, come tale, merita di essere ascoltata.

Il ruolo di un partner tecnologico, però, non consiste nel trasformare automaticamente ogni richiesta in una nuova funzionalità, né nel limitarsi a valutarne la fattibilità tecnica: nella maggior parte dei casi, infatti, realizzarla è possibile. Il vero valore della consulenza sta nell'aiutare il cliente a prendere decisioni progettuali consapevoli, valutando non solo il beneficio immediato di una scelta, ma anche l'impatto che avrà sul software negli anni successivi.

Per questo una consulenza efficace non si limita ad assecondare ogni richiesta, ma offre un punto di vista diverso. A volte significa sviluppare una nuova funzionalità, altre proporre una soluzione alternativa, altre ancora spiegare perché una richiesta, pur essendo comprensibile, rischia di introdurre una complessità superiore al valore che è in grado di generare 

È una posizione apparentemente controintuitiva. In un progetto software, aggiungere una funzionalità è quasi sempre la decisione più semplice; stabilire se sia davvero opportuno farlo richiede invece un'analisi più approfondita. Assumersi la responsabilità di una scelta progettuale significa anche avere il coraggio di sconsigliare una soluzione quando il suo impatto sul lungo periodo rischia di essere superiore ai benefici che promette nel presente. Proprio in questa capacità di guardare oltre il rilascio del software si misura il valore di un partner tecnologico.

Molti progetti vengono valutati il giorno della consegna. È un momento importante, ma rappresenta solo l'inizio della vita del software, non il momento in cui se ne può misurare il reale valore.

La qualità di un sistema emerge nel tempo: quando cambiano i processi aziendali, entrano nuovi utenti, si rendono necessarie nuove integrazioni o l'organizzazione evolve e il software deve evolvere con essa. È in queste situazioni che diventano evidenti le conseguenze delle scelte fatte in fase di progettazione. 

Le funzionalità che hanno saputo rispondere a esigenze concrete continuano a generare valore e rendono il sistema più solido. Quelle che non sono mai entrate davvero nei processi quotidiani, invece, non scompaiono: continuano a occupare spazio nell'architettura, devono essere mantenute, testate, documentate e considerate ogni volta che il software viene aggiornato o modificato.

Per questo progettare un software significa assumersi una responsabilità che va oltre il rilascio. Ogni scelta influenza la capacità del sistema di adattarsi nel tempo e di continuare a supportare il lavoro dell'azienda senza trasformarsi, progressivamente, in un vincolo. Un progetto ben riuscito non è quello che soddisfa solo le esigenze del presente, ma quello che permette all'organizzazione di evolvere senza essere frenata dalle decisioni prese anni prima.

Normalmente si tende a pensare che un buon software sia quello che riesce a fare tutto. L'esperienza vissuta racconta una storia diversa.

I progetti che mantengono il loro valore nel tempo non sono necessariamente quelli con il maggior numero di funzionalità.
Sono quelli in cui ogni scelta progettuale ha superato una domanda molto semplice:
Questa funzione continuerà a generare valore anche quando il progetto sarà terminato?

Se la risposta è sì, vale la pena investire tempo, risorse e complessità per realizzarla.

Se la risposta è incerta, aggiungerla significa introdurre un elemento che accompagnerà il software per tutta la sua vita senza la garanzia di produrre un beneficio proporzionato.

In fondo progettare non significa decidere che cosa è possibile costruire, significa decidere che cosa merita davvero di entrare a far parte del sistema.