perché la cosa giusta a volte è fare meno
C’è un momento preciso, in cui mi frego da solo.
Il problema è davanti a me, nudo. Lo guardo come guarderei un oggetto in laboratorio: lo giro, lo scompongo, provo a capire quale parte pesa davvero, quale è solo rumore. Dopo un po’ emerge una soluzione. Non è elegante, non ha il sapore della “grande idea”, però regge. È semplice. Sembra costruibile.
Ed è proprio quando la vedo reggere che inizia la tentazione.
Funziona, sì. Però potrebbe essere più completa. Potrebbe includere un caso in più, un percorso in più, un modo più raffinato di guidare chi la userà. Potrei metterci dentro un tocco mio, qualcosa che mi faccia dire: ecco, questa non è solo una soluzione, è una cosa che ho fatto io.
Così aggiungo.
All’inizio sono piccole cose, dettagli che sembrano innocui. Una funzione “nel caso servisse”. Un miglioramento che rende tutto più fluido, almeno nella mia testa. Poi un’altra funzione, perché tanto ormai ci sono. Poi un’altra ancora, perché a questo punto è un peccato non farla bene.
E senza accorgermene, la soluzione diventa più interessante del problema.
Quasi sempre, anche meno utile.
Il ciclo che non chiamavo per nome
Per molto tempo ho trattato questo comportamento come episodi sparsi, piccole deviazioni. Solo di recente ho iniziato a vederlo come un ciclo. Un quasi loop infernale.
Parte quasi sempre da una cosa sana: riconosco un problema reale e immagino una soluzione semplice. Non sempre facile, ma semplice. Una soluzione che non pretende un ecosistema intero per stare in piedi.
Poi entra in scena la mia parte da builder. Quella che si esalta quando vede margini di miglioramento, possibilità di espansione, nuove strade da aprire. Quella che, di fronte a una soluzione che funziona, sente un fastidio sottile: “Ok, ma possiamo farla meglio”.
È lì che nasce la sovrasoluzione.
Non è un salto improvviso. È una stratificazione. Ogni strato sembra ragionevole. Insieme, cambiano la natura dell’oggetto.
Nel software lo senti subito: più funzioni aggiungi, più punti di rottura crei. Spuntano casi particolari che prima non esistevano. Ti ritrovi a inseguire comportamenti inattesi, integrazioni, scelte che non avevi previsto. Nel mondo fisico o nei progetti organizzativi la logica è la stessa, solo più lenta: aumentano le dipendenze, le variabili, le persone da allineare, le condizioni che devono verificarsi.
Poi arriva la fase che non puoi simulare davvero: la soluzione incontra il mondo reale.
E il mondo reale ha una qualità che fa male, perché è indifferente. Non ti contesta, non ti applaude. Usa o non usa.
A volte le persone che dovrebbero beneficiare della mia soluzione non chiedono nulla di ciò che ho aggiunto. A volte non lo notano. A volte lo percepiscono quasi come un peso. Quello che riduce il problema era già lì, prima che io lo riempissi di extra.
È in quel momento che prendo il martello.
Non nel senso emotivo. Nel senso tecnico. Smonto finché resta solo ciò che fa il lavoro. E quasi sempre, la versione che funziona di più assomiglia molto alla prima idea che avevo intravisto, quando la soluzione era ancora una linea chiara e non un castello.
Che cos’è una sovrasoluzione, davvero
Ho iniziato a chiamarla così perché avevo bisogno di un nome che mi obbligasse a vederla.
La sovrasoluzione non nasce quando una soluzione fallisce. Nasce quando funziona già.
Il problema è già risolto, o potrebbe esserlo, ma io sento che manca qualcosa. E quel “qualcosa” spesso non ha a che fare con chi userà la soluzione. Ha a che fare con me.
È un bisogno interno: curiosità, voglia di esplorare, desiderio di lasciare una firma, di dimostrare a me stesso che posso costruire qualcosa di più completo. In quel momento non sto solo risolvendo. Sto anche giocando. Sto imparando. Sto mettendo le mani dentro una macchina per capire come gira.
Questo, di per sé, non è un errore.
Diventa un errore quando confondo il mio bisogno con il bisogno dell’altro.
La sovrasoluzione è un oggetto che ha senso nella testa di chi lo costruisce perché lì dentro vive un intero mondo di ipotesi, scenari, anticipazioni. Ma la realtà non vive di ipotesi. Vive di attrito.
E l’attrito non perdona.
Il builder non è il nemico
Se ti riconosci in questa cosa, la tentazione è moralizzarla: ego, perfezionismo, mania di controllo.
È vero che c’è dell’ego, perché creare qualcosa di proprio è anche un modo di esistere. Ma ridurre tutto a una colpa è troppo comodo e troppo superficiale.
Io non vedo una separazione netta tra un innovatore, un inventore e uno scienziato. In tutti e tre c’è una forma di espressione. Un artista che scolpisce una statua e uno scienziato che prova a scoprire qualcosa di nuovo sul mondo, nel loro gesto condividono qualcosa. Non stanno solo risolvendo un problema esterno. Stanno rispondendo a una domanda interna.
Questa spinta è ciò che crea soluzioni che prima non esistevano.
Il punto non è spegnerla. Il punto è collocarla.
Perché esistono giorni in cui si costruisce per imparare, per vedere fin dove possiamo spingerci. E in quei giorni la sovrasoluzione è un esperimento, non un fallimento.
Ed esistono giorni in cui si costruisce perché qualcuno, da qualche parte, ha un problema oggi. E in quei giorni la sovrasoluzione è spesso solo un ritardo.
La confusione nasce quando si trattano queste due fasi come se fossero la stessa.
Il conto della complessità
La complessità non si presenta sempre come un mostro. A volte è una seduttrice delicata:
“Se aggiungi questa cosa, l’esperienza sarà migliore.”
“Se prevedi anche questo caso, eviti un problema futuro.”
“Se fai anche quest’altro, diventa più professionale.”
Ogni frase sembra giusta. E lo è, isolata.
Il problema è che la complessità è cumulativa. Ogni aggiunta introduce un nuovo punto di attenzione. Un nuovo passaggio da spiegare. Una nuova scelta da far fare a chi usa la soluzione. Un nuovo pezzo da mantenere vivo.
A un certo punto, senza un gesto esplicito, il centro di gravità cambia. Non stai più lavorando per ridurre il problema. Stai lavorando per tenere insieme la soluzione.
E il mondo reale, quando incontra quella soluzione, non guarda la qualità dei dettagli. Guarda quanto costa usarla.
Costa in tempo. Costa in concentrazione. Costa in decisioni.
Se la soluzione chiede troppo, viene scartata senza dramma. Non perché sia sbagliata, ma perché è più di quello che serve.
Questa è la parte difficile da accettare da builder: il valore percepito non cresce in proporzione alla quantità di lavoro incorporato. Cresce in proporzione alla riduzione di attrito.
Il martello come disciplina
Quando prendo il martello non lo faccio per punirmi. Lo faccio per riallinearmi.
Smontare una sovrasoluzione significa distinguere tra ciò che è strutturale e ciò che è ornamentale. Significa tornare a una domanda che sembra banale e invece è spietata: “Questa cosa riduce davvero il problema di chi sta dall’altra parte?”
Tagliare è più difficile che aggiungere.
Aggiungere ti dà una sensazione di progresso. Tagliare ti costringe a riconoscere che alcune scelte erano per te, non per l’utente. Ti costringe a lasciare andare lavoro fatto, energia spesa, ore investite.
Ma quando tagli bene succede una cosa quasi fisica: l’oggetto respira. Torna leggero. Torna usabile.
E in molti casi, paradossalmente, diventa più forte. Perché dipende da meno cose per funzionare.
Guatemala, fango e connessione che va e viene
In Guatemala ho capito questa lezione senza poterla discutere troppo.
Lì non avevo il lusso di costruire un castello.
Il contesto era quello che era: monitoraggio ambientale, raccolta dati sul campo, persone con confidenze digitali diverse, telefoni con batterie stanche, connessioni intermittenti, giornate lunghe. A volte eri in un posto in cui tutto funzionava, a volte eri in un posto in cui nulla funzionava. E quando dico nulla, intendo anche le cose che in città dai per scontate.
All’inizio, la mia testa ha fatto ciò che fa sempre. Ha visto il problema e ha iniziato a disegnare una soluzione “bella”. Un’app proprietaria, un sistema completo di auto-reporting, un flusso che guidasse l’utente, magari con un’interfaccia pulita, coerente, standard.
Era una sovrasoluzione perfetta.
Perfetta perché, nel mio immaginario, avrebbe reso il sistema più solido. Più moderno. Più “da progetto serio”. E in teoria avrebbe anche potuto funzionare.
Solo che in Guatemala la teoria ti presenta il conto subito.
Un’app richiede sviluppo, sì. Ma soprattutto richiede manutenzione. Richiede che qualcuno la aggiorni, la supporti, la aggiusti quando qualcosa cambia. Richiede che le persone la usino nel modo previsto. Richiede che il contesto si adatti.
E il contesto non si adatta.
Il problema reale non era “costruire una bella app”. Il problema reale era “raccogliere dati affidabili senza aggiungere frizione a chi già sta facendo fatica”.
A un certo punto ho fatto quello che avrei dovuto fare subito: ho guardato la situazione, non l’idea.
La soluzione semplice era quasi ridicola per quanto era poco romantica.
Un form. Compilabile online e offline. Un invio. Dati centralizzati. Possibilità di scaricare tutto in un file Excel.
Fine.
Non c’era nulla di innovativo. Non c’era la mia firma. Non c’era quella sensazione di “ho costruito qualcosa di nuovo”. C’era però una cosa fondamentale: funzionava nel contesto.
Funzionava perché non chiedeva alle persone di imparare un sistema complesso. Funzionava perché reggeva anche quando la connessione spariva. Funzionava perché se qualcosa andava storto non si rompeva tutto. Funzionava perché non pretendeva infrastrutture.
Quello è stato il mio martello.
Non un gesto spettacolare, ma una scelta: rinunciare alla soluzione che mi rappresentava di più per scegliere quella che risolvesse davvero il problema.
Connectus e la scelta dell’ordine
Con Connectus ho visto lo stesso meccanismo, ma in un terreno diverso.
Il problema era chiaro: incastrare persone, trovare un momento comune, soprattutto quando un team è sparso e i fusi orari fanno il resto. Avevo in testa una quantità di funzioni possibili, e molte erano anche sensate. Avevo idee salvate, note, funzioni aggiuntive.
Potevo fare quello che faccio spesso: costruire tutto, poi uscire.
Questa volta ho cambiato l’ordine.
Ho costruito la versione base e l’ho messa online. Non quando era perfetta, quando era usabile.
Solo dopo ho aggiunto una funzione extra, e l’ho fatto per un motivo concreto: mi serviva. La programmazione in giorni, non solo in slot di tempo. Non era una previsione. Era un bisogno emerso dall’uso.
Questa scelta non ha ridotto la mia creatività. L’ha resa più precisa.
Perché mi ha permesso di separare due momenti che prima confondevo: il momento in cui costruisco per far vivere una soluzione nel mondo e il momento in cui costruisco per esplorare.
Due tipi di progetti, una domanda sola
Da qui la distinzione diventa semplice.
Ci sono progetti di apprendimento. Progetti in cui la sovrasoluzione è il campo di addestramento. Lì puoi permetterti di complicare, perché stai pagando per imparare. E quel pagamento ha senso.
E ci sono progetti di adozione. Progetti che devono essere usati da persone reali, con pazienza limitata, tempo limitato, contesti imperfetti. Lì la sovrasoluzione è quasi sempre un ostacolo.
Il disastro nasce quando trattiamo questi due contesti come uno solo. Ed io sono bravo in questo: Quando costruisco per imparare e poi mi arrabbio perché nessuno lo adotta. Quando costruisco per essere adottato e poi mi perdo nel piacere di espandere.
La soluzione non è smettere di innovare. È sapere perché sto innovando.
Se voglio imparare, posso complicare.
Se voglio essere adottato, devo prima semplificare.
E posso sempre complicare dopo. Non il contrario.
Conclusione: sapere perché sto costruendo
Molte sovrasoluzioni non sono sprechi. Sono tentativi. Mi hanno insegnato cose che una soluzione minimale non mi avrebbe insegnato.
Diventano un problema solo quando chiedo al mondo di validare ciò che ho costruito per me.
Oggi, quando vedo una soluzione semplice, provo a non scappare. La costruisco. La metto fuori. La lascio respirare nel contesto reale.
Se basta, bene.
Se non basta, lo scopro presto.
E se poi sento ancora la spinta a espandere, a complicare, a lasciare un segno, posso farlo sapendo che sto entrando in un progetto diverso.
Non tutto ciò che costruisco deve funzionare nel mondo.
Ma ciò che voglio portare nel mondo deve prima funzionare nella sua forma più semplice.
La domanda che mi guida è sempre la stessa: sto costruendo per imparare, o per essere adottato?
Post più recenti
All images, videos, and other content featured on this site remain the property of their respective owners, and no claim of ownership is made.