Software su misura: quando ha davvero senso
Quando ha senso progettare uno strumento custom e quando stai solo trasformando il caos in codice
C'è una frase che arriva spesso dopo settimane, mesi, a volte anni di tentativi:
"Facciamolo su misura."
Di solito arriva quando un'azienda ha provato diversi strumenti e nessuno sembra calzare davvero. Uno ha troppe funzioni, ma manca proprio quella vista fondamentale. Un altro è semplice, ma non regge le eccezioni. Un altro ancora funziona bene in demo, poi nella pratica richiede più passaggi di prima.
A quel punto il software su misura sembra la soluzione più logica.
E a volte lo è.
Ma non sempre.
Perché uno strumento custom può diventare la cosa più intelligente che costruisci. Oppure può trasformarsi in un Excel con più budget, più riunioni e più persone arrabbiate.
Il punto non è "standard o su misura"
La domanda vera è un'altra:
il processo è abbastanza chiaro da meritare di diventare software?
Perché il codice è bravissimo a eseguire. Molto meno a indovinare.
Se ogni reparto racconta il flusso in modo diverso, se ogni eccezione diventa una nuova richiesta, se nessuno riesce a dire cosa deve restare fuori, il problema non è ancora tecnico. È progettuale.
Prima di costruire, bisogna capire cosa deve succedere, chi deve farlo, con quali dati, in quale momento e con quali responsabilità. Sembra banale. Non lo è quasi mai.
Quando il processo è ancora confuso, un passo utile può essere un Software Fit Sprint: due settimane per mappare i flussi reali, chiarire i criteri e decidere se ha senso costruire, comprare o rimandare.
Prima di scrivere codice, bisogna riuscire a vederlo
Mi è capitato con un progetto nato in modo molto semplice.
Entro in ufficio dal dev per allinearci sul lavoro che stavamo seguendo. A fine riunione mi chiede se ho tempo per ascoltare una richiesta arrivata tempo prima da un amico: voleva diventare cliente e farsi sviluppare un software per gestire i viaggi dei suoi autisti.
Il dev apre un quaderno pieno di appunti. Anni di idee, pensieri, richieste, possibilità. Tutto interessante. Tutto potenzialmente utile. Ma anche tutto ancora troppo aperto.
Mi dice una cosa molto onesta: "Non riesco a immaginarlo e non me la sento di iniziare a scrivere codice alla cieca."
E aveva ragione.
Abbiamo fatto una riunione con il cliente, mi sono fatta spiegare i flussi, poi ho integrato tutto con gli appunti già raccolti. Sono partita dalle 10 schermate previste e ne ho aggiunte altre 5 per chiudere buchi di flusso che non erano ancora stati vagliati.
Quando lo abbiamo mostrato al cliente, il progetto è diventato finalmente visibile. Non perfetto, perché qualche modifica c'è sempre. Ma abbastanza chiaro da permettere agli sviluppatori di iniziare sapendo cosa serviva, come dovevano interagire i componenti e quali parti del processo non potevano restare nella nebbia.
Quando il su misura ha senso
Il software custom inizia ad avere senso quando:
- il processo è specifico, ma abbastanza stabile
- gli errori o i passaggi manuali hanno un costo reale
- le eccezioni sono frequenti, non casi rari
- ruoli e responsabilità sono già abbastanza chiari
- il team sa spiegare cosa oggi lo rallenta
- gli strumenti standard costringono a troppi giri inutili
In questi casi, progettare qualcosa su misura può ridurre attrito, lavoro nascosto e dipendenze da soluzioni provvisorie che provvisorie non sono più.
Quando invece è troppo presto
Ci sono anche segnali opposti.
Se il software deve "mettere d'accordo tutti" prima ancora che qualcuno abbia deciso il processo, attenzione.
Se ogni richiesta suona come "aggiungiamo anche questa cosa, non si sa mai", attenzione.
Se nessuno vuole rinunciare a niente, il problema non è costruire. È scegliere.
Il su misura non serve a portare dentro tutto. Serve a progettare meglio ciò che vale davvero la pena sostenere.
Una piccola matrice prima di costruire
Prima di dire "facciamolo custom", basterebbe fermarsi su quattro domande:
| Domanda | Se sì | Se no |
|---|---|---|
| Il processo è chiaro? | Puoi progettare | Prima mappa |
| Le eccezioni sono ricorrenti? | Valuta custom | Non costruire tutto |
| Il team lo userà davvero? | Vai avanti | Rischio workaround |
| Sai cosa lasciare fuori? | Buon segnale | Perimetro fragile |
Le risposte vuote sono la parte più interessante. Sono quelle che dicono dove il progetto rischia di gonfiarsi, complicarsi o diventare un sistema pieno di cose che nessuno userà davvero.
Il software su misura non comincia quando trovi chi lo sviluppa. Comincia un po' prima, nel momento in cui qualcuno riesce finalmente a guardare il processo e chiedersi: questa cosa deve diventare davvero software, o stiamo solo cercando un modo più elegante per non rincorrerla più a mano?