Che c'entra l'ingegneria con il software?

«Studio di ingegneria» nella testa della gente vuol dire pilastri, solai, cemento armato e un timbro su una tavola. Poi diciamo che facciamo software, e la faccia dall'altra parte è sempre la stessa. C'entra che l'ingegneria dell'informazione è una sezione dell'albo come le altre, e che il modo di lavorare di uno studio tecnico al software si applica benissimo. Solo che quasi nessuno lo fa, quindi quella casella nella testa di chi compra non esiste ancora. Stiamo provando a crearla.

Cambia l'oggetto, non il metodo

Chi fa costruire un capannone pretende il progetto prima di firmare, e non gli verrebbe mai in mente di collaudarlo "a sensazione". Chi commissiona il sistema su cui gira la sua azienda, per la stessa cifra, di solito chiede una demo. Ecco le stesse voci, tradotte.

Nel costruitoNel software

Progetto esecutivo

Documento di architettura: cosa si costruisce, come, e perché proprio così. Con le decisioni scritte, così fra due anni si capisce ancora.

Calcolo strutturale

Dimensionamento sui numeri veri: utenti, richieste al secondo nell'ora di punta, volumi annui, crescita attesa. Poi si misura se la previsione reggeva.

Margine di sicurezza

Riserva di capacità: cosa succede se il carico raddoppia, cosa si degrada per primo, cosa deve restare in piedi comunque. Sono scelte, non conseguenze.

Direzione lavori

Guida tecnica dello sviluppo, con avanzamenti verificabili a ogni tappa invece di un unico verdetto alla fine.

Collaudo

Prove di accettazione concordate prima di cominciare. Il lavoro è chiuso quando le supera, non quando sembra funzionare.

Manutenzione programmata

Aggiornamenti, dipendenze, certificati in scadenza: lavoro prevedibile, quindi preventivato. Se non lo prevedi, torna come emergenza fra diciotto mesi.

Firma del progettista

Un nome che risponde di quello che ha consegnato. È il pezzo che nel software si è perso per strada, ed è quello che tiene insieme tutti gli altri.

Perché conviene a chi paga

Sono le stesse voci di prima, viste dalla parte del portafoglio.

Il preventivo regge, perché il grosso delle sorprese è stato tolto di mezzo prima di iniziare.

Gli imprevisti saltano fuori a metà strada, quando cambiare costa ancora poco, invece che alla consegna.

Il costo del secondo anno si conosce dal primo: esercizio, aggiornamenti e crescita sono già stimati.

Il sistema regge l'aumento del lavoro senza dover essere riscritto da capo.

Quando qualcosa si rompe esiste una procedura e una persona, non una ricerca affannosa.

Perché nel software non va così

Se il metodo è lo stesso, la domanda giusta è perché nessuno lo chiede. Le ragioni sono quattro, e nessuna è che al software non serva.

Nel costruito il progetto è obbligatorio

Un capannone senza progetto firmato non si costruisce: lo vieta la legge. Nel software il progetto è facoltativo, quindi si salta — e chi lo salta comincia prima e costa meno il primo mese.

Il software si può cambiare dopo

Ed è vero, è il suo vantaggio più grande. È anche l'alibi perfetto per non progettare: tanto poi si aggiusta. Si aggiusta finché la struttura regge; quando non regge più non si aggiusta, si rifà.

Un solaio che cede si vede

Un sistema mal progettato non crolla: rallenta, si rompe a intermittenza, costa un po' di più ogni anno. Nessuno collega quel conto a una scelta fatta tre anni prima, e infatti si finisce per credere che il software costi così.

La frase opposta è più corta

"Pronto subito e costa poco" si capisce in due secondi. "Progettiamo prima, così dopo non paghi tre volte" richiede mezzo minuto e un po' di fiducia. Su questo terreno partiamo svantaggiati, e lo sappiamo.

Ci stiamo provando

Sappiamo di remare contro l'abitudine, e non abbiamo una frase più corta di quella di chi promette tutto subito. Abbiamo però una prova: raccontateci il progetto e la prima cosa che vi mandiamo è un documento con architettura, fasi, prezzo a corpo e prove di collaudo. Potete giudicarci su quello, prima di spendere un euro.

Parliamone