Torna al sito

Sviluppo software su misura

Quasi nessuno cerca «software su misura» come prima scelta. Ci si arriva dopo: dopo un gestionale che non fa quella cosa, dopo tre strumenti che non si parlano, dopo un foglio di calcolo condiviso che è diventato il sistema informativo dell'azienda senza che nessuno l'abbia deciso.

Quando ci si arriva, la domanda non è più «se» ma «quanto perimetro». Realizzo applicazioni web, portali e API che si innestano su quello che già usate, invece di sostituire tutto.

Quando conviene il software su misura e quando no

Non conviene quando esiste un prodotto pronto che copre il 90% del bisogno e il restante 10% è negoziabile. Comprare costa meno che costruire, e la manutenzione è di qualcun altro.

Conviene in tre situazioni: quando il processo da automatizzare è ciò che vi distingue dai concorrenti e nessun prodotto generico lo rispecchia; quando il costo per utente di una soluzione pronta cresce oltre il ragionevole; e quando servono integrazioni fra sistemi che nessun prodotto prevede.

C'è anche una via di mezzo che spesso è la risposta giusta: tenere il prodotto pronto e costruire solo il pezzo che manca, collegandolo tramite API. Meno codice da mantenere, stesso risultato.

Dai requisiti al perimetro: evitare di costruire la cosa sbagliata

La causa più frequente di un progetto software andato male non è tecnica: è che si è costruito con precisione qualcosa che non serviva. Per questo la fase di analisi non consiste nel raccogliere una lista di funzioni, ma nel capire quale attività quotidiana dovrebbe cambiare e in che modo.

Ne esce un perimetro scritto, con dentro ciò che la prima versione fa e — soprattutto — ciò che non fa. La seconda lista è quella che tiene in piedi i tempi.

Preferisco arrivare presto a qualcosa di usabile e poi correggere sull'uso reale, invece di consegnare tutto insieme dopo mesi. Le correzioni fatte su un sistema che qualcuno sta usando sono quelle giuste; quelle fatte su un documento sono ipotesi.

Architettura e stack: le scelte che si pagano dopo

Le scelte tecnologiche hanno una vita più lunga del progetto. Uso strumenti diffusi e documentati — Python, Node.js, PHP sul backend, PostgreSQL o MySQL per i dati, TypeScript con Vue o React sul frontend — non per conservatorismo, ma perché fra tre anni deve essere possibile trovare qualcun altro che ci metta mano.

Una tecnologia poco diffusa, per quanto elegante, è un vincolo che scaricate su chi verrà dopo. Se la scelgo è perché c'è una ragione precisa, e la ragione va detta.

Backend e API: integrare invece di sostituire

Il valore di gran parte del software aziendale sta nelle connessioni: prendere un dato dove nasce e portarlo dove serve, senza che qualcuno lo ricopi a mano. Costruisco API REST e GraphQL con questo scopo, e mi collego a ciò che c'è già — gestionali, CRM, sistemi di fatturazione, servizi di terze parti.

Dove il sistema esistente non ha un'interfaccia utilizzabile ci sono comunque strade percorribili, e vanno valutate una per una: alcune sono solide, altre sono soluzioni fragili che si romperanno al primo aggiornamento. Distinguere fra le due è parte del lavoro.

Qualità del codice: test, documentazione, manutenibilità

I test automatici non servono a dimostrare che il codice è giusto: servono a poterlo cambiare senza paura. Sono la differenza fra un sistema che evolve e uno che a un certo punto nessuno osa più toccare.

Documento le decisioni, non le righe: perché è stato scelto questo approccio, cosa si è escluso e per quale motivo. È l'informazione che serve fra due anni, quando il codice si legge da solo ma le ragioni sono sparite.

Il codice è vostro, in un repository che controllate voi. Nessun pezzo resta sotto il mio account.

Rilascio, monitoraggio, evoluzione

Il rilascio in produzione fa parte dello sviluppo, non è un adempimento successivo: la stessa pipeline automatica che costruisce e collauda porta il software online, e l'infrastruttura su cui gira è progettata insieme all'applicazione, non scelta alla fine.

Dopo il rilascio serve sapere se funziona: monitoraggio dei tempi di risposta e degli errori, e un canale per raccogliere ciò che gli utenti trovano scomodo. La prima versione è un'ipotesi verificata solo in parte.

Parliamone

Descrivimi in poche righe la situazione e cosa vorresti ottenere: rispondo con una prima valutazione e con le domande che servono a inquadrare il lavoro.

Raccontami il tuo progetto

Gli altri servizi