Stimare il costo dello sviluppo software

Abbiamo parlato con il nostro CEO Simone Zinanni di come scegliere un’azienda partner per lo sviluppo software ed hardware. Ora che abbiamo fatto questa scelta, siamo arrivati al momento fatidico del preventivo.

Senza dubbio, è piuttosto difficile stimare al 100% il prezzo dello sviluppo di un software personalizzato dando un’occhiata soltanto ai requisiti del cliente; ogni progetto è unico e richiede un approccio individuale.

Oggi ne parliamo con Fabrizio Venere, Project Manager in Develer

Ciao Fabrizio, partiamo dall’inizio: in generale, da quali fattori può dipendere il costo complessivo di un progetto di sviluppo software?

Eh, bella domanda: non è mica facile rispondere, i fattori da considerare sono davvero tanti! Innanzi tutto, ci possono essere due scenari da considerare.

Il primo: il nostro team entra a lavorare su un progetto già iniziato, quindi dobbiamo fare “raffinamento”, rivedere quello che è stato fatto o aggiungere feature a un progetto/prodotto già esistente. Questa cosa ha, secondo me, una certa complessità.

Secondo scenario: arriva il cliente e ci propone di fare un prodotto da zero: quindi ci sono delle idee, ma non esiste nulla di già realizzato o preesistente. 

Questo secondo caso è sicuramente più sfidante, più lungo nel tempo e bisogna capire effettivamente quali sono le esigenze, però stimarlo è più semplice, perché ho un progetto e tutta la libertà di realizzarlo come voglio.

Quando, come nel primo caso, esiste già un substrato, la questione è più complessa, perché bisogna andare a integrarsi all’interno di un ecosistema già avviato.

Devi capire come interfacciarti con questo sottostrato – e non è detto che sia immediatamente comprensibile – ma soprattutto c’è la grande difficoltà di dover costruire qualcosa, essendo dipendenti da quello che è già stato fatto in passato. 

Quindi siamo su due livelli di complessità molto differenti.

E poi, ovviamente, dobbiamo parlare delle risorse interne che dovranno portare avanti il progetto…

Per quanto riguarda le risorse, anche qui siamo di fronte a una grande variabilità: generalmente noi ci basiamo su quella che a primo acchito potrebbe essere la complessità insita del progetto, ma ovviamente anche sul budget che il cliente mette a disposizione e sulla nostra disponibilità interna del momento.

In linea di massima, abbiamo bisogno di almeno tre persone – numero che va a salire in base alla difficoltà o alla durata temporale del progetto stesso – che possano lavorare in maniera parallela e farsi le code review tra di loro, e non avere un “one man show”. 

Quindi un team di almeno tre sviluppatori?

Sì, parlo di un team di almeno tre persone. Come poi è strutturato questo team, dipende, perché magari la complessità del progetto richiede che siano tutti senior. O magari ne basta uno solo, in modo da avere un technical leader e poi due persone più junior.

Come si vede, sono molteplici i fattori che concorrono al costo complessivo. 

Però di sicuro la cosa essenziale è cercare di capire all’inizio cosa vuole il cliente.

E come si capisce che cosa vuole il cliente?

Non esiste una regola unica. Noi stiamo sperimentando, da un anno e mezzo circa e dove possibile, di fare le prime iterazioni col cliente a livello di design thinking. 

Il cliente ha un’idea che chiaramente spesso è soltanto tale; noi abbiamo un team che cerca “di mettere su carta” le cose che il cliente ha in testa, traducendole in wireframe e in mockup.

Per esempio, se si parla della GUI di un macchinario industriale, facciamo sessioni di design collaborativo in cui il cliente può già visualizzare delle bozze di schermate. 

In questo modo, noi già cominciamo a capire come dovrà essere strutturata l’interfaccia grafica. E questa è soltanto la parte superficiale, perché dietro c’è tutto un mondo col quale poi quelle interfacce grafiche dovranno comunicare.

Questo lavoro preliminare ci permette di arrivare a dei prototipi delle interfacce grafiche, compresa la parte della user experience. Abbiamo così già un’idea dell’effort necessario per la loro realizzazione.

Successivamente bisogna capire come quelle interfacce dovranno comunicare col mondo sottostante. Lì si fanno ragionamenti di carattere tecnologico: che tipo di vincoli abbiamo? È possibile utilizzare un linguaggio piuttosto che un altro? Che tipo di seniority è necessaria per poter realizzare quel prodotto con quelle specifiche tecnologie?

Ecco, questa è la fase preliminare, che generalmente dura un mesetto, in cui cerchiamo di capire bene che cosa vuole il cliente.

E la facciamo a prescindere, prima di aver preso in carico il progetto, per poter fornire un preventivo?

Sì, noi ci facciamo dire le esigenze. Di solito regaliamo al cliente una giornata di design thinking, quindi un workshop seguito proprio dal nostro Matteo Forni: utilizzando gli strumenti che mette a disposizione l’approccio di Matteo, si cominciano a disegnare i vari flussi di lavoro.

Spesso, il cliente si rende conto delle potenzialità di questo approccio, per cui portiamo avanti questa prima parte di design creativo, il cui obiettivo finale è preparare tutte le interfacce, o comunque i prototipi “a maggior valore”.

I clienti spesso rimangono entusiasti perché si rendono conto di quante cose – a cui non avevano pensato – possono effettivamente far parte del prodotto finale o magari quante ne avevano pensate, ma sono poco utili o poco funzionali o possono essere fatte in maniera differente. 

Questo tipo di approccio ha un duplice obiettivo: consente di allineare il cliente al nostro modo di lavorare, che nell’industria manifatturiera o in ambito industriale è molto complesso, e permette anche a noi di capire quale potrebbe essere l’effort da dover prevedere per un progetto.

Alla fine di questa attività che succede? 

Succede che il technical leader, grazie anche ai feedback del designer, riesce a dare una stima abbastanza realistica.

Per esempio, dice: “Ok, per poter approcciare questo lavoro noi avremmo bisogno almeno di due mesi di lavoro e un team di tre persone”.

Dove con “due mesi di lavoro”, non vuol dire che alla scadenza del secondo mese il prodotto è pronto e confezionato. No. Si innesca un meccanismo tale per cui si comincia a lavorare in maniera iterativa e agile, e si realizzano per prime le cose a maggior valore 

In base a che cosa il tech leader fa questa stima? 

Sicuramente in base alla sua sensibilità tecnica.

Ripeto, quella stima significa: io sono ragionevolmente convinto che al termine di quel monte ore le cose a maggior valore saranno sicuramente consegnate. Poi, a quel punto, il cliente parte con i suoi test, si rende conto che magari determinate cose possono essere riviste o possono essere migliorate o alcune non sono utili. Per cui ci sono altre rilavorazioni, che riguardano il raffinamento delle cose fatte precedentemente e le cose a minor valore che sono rimaste da fare, il bug fixing e, soprattutto, il feedback che il cliente dà. 

Quindi il concetto è che non esiste una stima con un numero preciso, ma un’indicazione che fa capire al cliente: da quel momento in poi hai un MVP (minimum viable product), quindi un prodotto che racchiude la maggior parte delle funzionalità più importanti inizialmente pensate.

Anche se non “ready to market”, l’MVP è qualcosa di già funzionante, che permette al cliente di lavorarci per capire quali sono le migliorie da apportare al prodotto.

Quindi, riassumendo, che cosa influisce sul costo?

Allora, sicuramente cambia molto se il progetto è ex novo o se dobbiamo inserirci in un qualcosa di già esistente. In questo ultimo caso, vanno valutate, per esempio, anche l’integrazione con altri sistemi e la migrazione di dati.

Poi, ovviamente, il design creativo e le risorse impiegate nel progetto: quante ne servono e quanto skillate.

E poi il tipo di contratto ha una notevole influenza. Quanti e quali tipi di contratto possiamo avere?

Di solito, nel mondo del software, esistono tre tipi di contratto che possono venire applicati:

– L’approccio Fixed Price

– L’approccio Time&Materials

– L’approccio Float Scope Fixed Budget

L’approccio a prezzo fisso è quello più rischioso per entrambi, cliente e fornitore. 

Perché generalmente il cliente deve arrivare, se vuole un preventivo, con un capitolato tecnico, quindi un faldone di un numero spropositato di pagine, in cui ci dovrebbero essere scritti, fino alla virgola, tutti i possibili dettagli, tutte le possibili implementazioni e tutte le possibili declinazioni di una particolare funzionalità.

Noi su quella base facciamo la stima, ma è una cosa che ormai non si usa più o comunque si usa molto meno perché è rischioso, perché possono cambiare i termini nel corso del tempo, non è possibile prevedere cambi, non è possibile fare change management o risk management.

E’ un approccio che può aver senso per progetti molto piccoli, in cui il perimetro di progetto è chiaro, sia per il cliente che per il fornitore, e sappiamo che non si esce fuori da lì. 

Nel contratto Time&Materials, invece, il cliente paga un compenso in base al tempo impiegato e alla quantità di materiale utilizzato, e il costo concordato tra cliente e fornitore viene rendicontato via via, con una gestione agile del progetto, cioè non fissa e immobile come col famoso capitolato tecnico, ma improntata a velocità, flessibilità e adattabile alle richieste dei clienti. Nel contratto T&M non c’è quindi un importo totale prestabilito, ed è quinid il contratto più pericoloso per il cliente perchè il rischio è tutto a suo carico.

Un’evoluzione di questo tipo di contratto, e che preferiamo usare qui in Develer, è il contratto a budget fisso con feature variabili. In questo caso, concordiamo un budget per il lavoro attraverso le nostre attività di consulenza pre-progetto, con le tecniche di stima illustrate prima. Le feature sono variabili e vengono determinate in base a quelle che sono le priorità di business del cliente. Si lavora immediatamente per fornirgli maggior valore; lavorando in modalità agile: l’obiettivo è quello di rilasciare, ogni settimana o ogni due settimane, un pezzo di codice “core”, in modo che il cliente possa immediatamente testarlo e darci un feedback.

La forza di questo modello contrattuale sta nel fatto che consente di fare modifiche in base a ciò che gli sviluppatori imparano durante la realizzazione del prodotto. Tuttavia, stabilisce un vincolo reale sul progetto per quanto riguarda i tempi e i costi. Il rischio del progetto è reciprocamente condiviso tra il cliente e il fornitore.

È un cap, fondamentalmente un time&materials con un limite massimo da non eccedere. 

Noi lo consigliamo per l’elasticità, la trasparenza e la gestione condivisa delle opportunità perché in un progetto fixed price, non si possono pensare delle modifiche. Mentre in un approccio float scope, in qualunque istante, è possibile gestire il cambiamento.

Tu che sei un Project manager, quali sono le best practice che consiglieresti per stimare il costo di un software?

Innanzi tutto, come detto prima, consiglio sicuramente delle sedute preventive di design collaborativo. A queste aggiungerei anche degli incontri con i technical leader.

In generale, il consiglio è di coinvolgere tutti gli stakeholder, soprattutto se si lavora con aziende medio-grandi, perché è necessario capire le esigenze e le aspettative di tutti. 

Quindi non parlare soltanto alle persone del business, ma mettere a sedere allo stesso tavolo anche il Product owner, il marketing, il commerciale e soprattutto i tecnici, perché spesso si parla con tutti lasciando fuori chi dopo dovrà davvero sviluppare il prodotto.

E se non si coinvolgono gli sviluppatori, a volte ci si trova con richieste difficilmente realizzabili o proprio non realizzabili nel monte ore concordato.

Tutto chiaro fin qui. Ma accade che un cliente, dopo tutto questo spiegone, dica: “Io voglio sapere il prezzo e basta!”. 

Assolutamente sì,

Noi gli si dice che non siamo nelle condizioni di poter dire un prezzo preciso per consegnare il prodotto finito. Noi possiamo dire solo il prezzo per una quota parte del prodotto finale, perché poi ci sono tanti aspetti che verranno, che emergeranno, che saranno verificati nel corso del lavoro.

Ci sono volte in cui perdiamo il cliente per questo, ma qui stanno la correttezza, l’onestà e la trasparenza di Develer

Domanda cattiva: il fatto che noi non facciamo questo costo fisso non è perché non siamo bravi a fare le stime? 

Eheh! Le stime le facciamo e con l’esperienza che abbiamo – lo vediamo dai nostri clienti soddisfatti – sono indovinate le stime e rispettati tempi e costi.

Come dicevo, è una questione di trasparenza, la nostra. Noi non facciamo il costo fisso, perché la materia è variabile, c’è sempre un delta che esiste a prescindere dalla capacità o meno, perché durante il percorso ci sono variabili esterne, come che ne so, un browser che cambia versione.

Di per sé la materia è così e richiede un approccio elastico; non può esserne usato uno rigido perché parliamo di prodotti digitali. 

Per essere più trasparenti possibili, noi coinvolgiamo sempre il cliente nelle nostre attività iterative. Quindi, quando andiamo a pianificare il lavoro della settimana nello sprint, il cliente sa benissimo che una feature la suddividiamo in tante sotto attività nella board di Trello che abbiamo e, visto che siamo a un livello granularità più bassa, quelle attività si stimano.

Generalmente si utilizzano gli story point: per esempio, un nostro story point è mezza giornata di lavoro di uno sviluppatore. Quindi alla fine, andando a fare la somma algebrica, possiamo sapere che l’operazione X sarà due giorni e mezzo di lavoro di uno sviluppatore.

Ecco, quel livello di granularità è trasparente, per cui il cliente sa quanto ci vuole per fare quella attività che è piccola. Non possiamo avere lo stesso livello di dettaglio per tutte le funzionalità, perché ci vorrebbero mesi soltanto per individuarle, capirne le implicazioni e stimarle.

Ripeto, è l’essenza del prodotto digitale che determina il modo di lavorare.

Il problema è farlo capire a chi ha sempre avuto a che fare, per esempio, con un prodotto meccanico, per cui si fa la macchina e finisce lì. Da un lato, si sta tranquilli perché si sa che il prodotto è finito e non va aggiornato e manutenuto più di tanto, mentre il prodotto digitale “non è finito mai”. Dall’altra parte, però, ha il vantaggio di essere scalabile, modificabile e versionabile a piacimento. Queste nuove opportunità del prodotto vanno approcciate con metodi diversi rispetto a quelli tradizionali.