Quanto tempo serve per sviluppare un software su misura
La risposta breve
Il tempo dipende meno dalla quantità di codice e più dalla velocità con cui si prendono le decisioni. Due progetti di dimensioni simili possono durare uno il doppio dell'altro soltanto perché in uno le risposte arrivano in un giorno e nell'altro in tre settimane.
Chi chiede "quanto ci vuole?" di solito si aspetta un numero legato alla complessità tecnica. La complessità pesa, eppure raramente è lei a far slittare un progetto. Lo fanno slittare le attese. Una decisione rimandata, un dato che non arriva, un fornitore esterno che non risponde, commenti che si accumulano per un mese e poi arrivano tutti insieme.
Qualche riferimento. Un MVP ben delimitato si porta a un livello presentabile agli investitori in 6-8 settimane, e un'installazione per un evento può andare in scena anche in una settimana quando la data lo impone. Sono tempi reali, a patto che il perimetro sia chiaro e le decisioni arrivino in fretta. Li abbiamo raccontati in cosa entra davvero in un MVP da 6-8 settimane.
Gestionale, app o piattaforma
Il tipo di prodotto conta meno del numero di processi diversi che deve reggere. Un gestionale interno con tre flussi lineari si fa prima di un'app semplice che deve parlare con cinque sistemi esterni.
In un gestionale su misura la parte lunga è l'inizio. Bisogna capire come lavora l'azienda nella realtà, con le sue eccezioni, le regole mai scritte e i passaggi che oggi stanno in un foglio Excel o nella testa di una persona. Chiarito questo, lo sviluppo procede in modo regolare.
Un'app mobile aggiunge passaggi che non dipendono né da voi né dal fornitore. La revisione degli store, i test su dispositivi diversi, le differenze fra sistemi operativi. Meglio metterli in calendario da subito.
Una piattaforma per clienti esterni chiede più rifinitura. Registrazione, permessi, pagamenti, email, casi limite. Ogni pezzo in sé è semplice, ma sono tanti e devono funzionare tutti dal primo giorno.
Cosa allunga un progetto
Di solito le stesse quattro cose, e nessuna è tecnica in senso stretto.
La prima sono le decisioni che non arrivano. Ogni domanda aperta ferma un pezzo di lavoro, e se per rispondere servono tre persone e una riunione, una scelta da dieci minuti diventa una settimana d'attesa.
Poi i dati. Se il nuovo sistema deve partire con quelli del vecchio, estrarli, pulirli e verificarli richiede tempo, tanto più quanto sono vecchi e disordinati. Se è il vostro caso, leggete come migrare i dati dal vecchio gestionale.
Le integrazioni sono il terzo punto. Ogni sistema esterno è un piccolo progetto dentro il progetto, con credenziali da ottenere, documentazione da capire e comportamenti da scoprire sul campo. Spesso dipende da un terzo che ha i suoi tempi.
Infine il feedback lento. Una versione mostrata e commentata dopo tre settimane vuol dire tre settimane di lavoro costruite su ipotesi mai verificate, e quando il commento arriva a volte tocca tornare indietro.
Come accorciare i tempi senza tagliare qualità
Si accorcia togliendo attese. Il lavoro resta lo stesso. Le leve che funzionano di più sono organizzative, e buona parte sta dalla vostra parte.
- Una persona che decide, con il mandato di dire sì o no entro un giorno o due e il buon senso di coinvolgere altri quando serve. Un comitato rallenta tutto.
- Un perimetro iniziale stretto. Partire dalle funzioni indispensabili e aggiungere il resto dopo il lancio è più veloce che infilare tutto nella prima versione.
- Dati e accessi pronti presto. Esportazioni, credenziali, contatti dei fornitori esterni vanno chiesti la prima settimana, non il giorno in cui servono.
- Feedback frequenti e brevi. Vedere il lavoro ogni due settimane e commentarlo subito evita di scoprire un malinteso quando è già costato un mese.
Noi lavoriamo a sprint di due settimane che chiudono sempre con una demo funzionante. Così si vede il ritmo delle decisioni, oltre a quello del codice.
Perché le stime iniziali cambiano
Una stima fatta prima di conoscere i dettagli è un'ipotesi ragionata. Promesse non ne fa. Diventa affidabile man mano che il perimetro si chiarisce.
La stima più onesta dichiara le proprie assunzioni, tipo "consideriamo due integrazioni", "i dati arrivano già deduplicati", "le schermate sono dieci". Se un'assunzione cambia, la stima cambia con lei e sapete il perché. Diffidate di chi vi dà un numero preciso senza avervi fatto domande, perché quel numero non tiene conto di niente del vostro progetto. Per il prezzo vale lo stesso discorso, come spieghiamo in come si prezza davvero un software su misura.
Aiuta molto rivedere la stima a ogni fine sprint, confrontando il previsto con il fatto. Uno scostamento viene fuori presto, quando si può ancora decidere cosa rimandare, e non alla vigilia della consegna.
Domande frequenti
Quanto tempo serve per sviluppare un gestionale su misura?
Dipende da quanti processi ed eccezioni ci sono da gestire, dai dati da migrare e dalle integrazioni con altri sistemi. Pesa molto la fase iniziale di analisi, perché capire bene come lavorate evita di rifare parti più avanti. Un fornitore serio vi dà una stima dopo avervi fatto domande.
Si può avere un software su misura in poche settimane?
Sì, se il perimetro è stretto e le decisioni arrivano in fretta. Un MVP ben delimitato può essere pronto per gli investitori in 6-8 settimane, un'installazione per un evento anche in una. Bisogna però accettare che la prima versione contenga solo l'indispensabile.
Perché i progetti software sono sempre in ritardo?
Il codice c'entra poco. Le cause più frequenti sono decisioni rimandate, dati che arrivano tardi, integrazioni con sistemi esterni e commenti raccolti troppo di rado, tutte cose che si possono pianificare fin dall'inizio.
