Indice
Introduzione
Quando si discute la realizzazione di un nuovo prodotto digitale o il suo ammodernamento, inevitabilmente arriva la domanda “quanto costerà?”.
Si potrebbe rispondere “il meno possibile”, ma non sarebbe una risposta utile o seria; bisogna invece seguire un approccio in grado di evitare rischi importanti e massimizzare il valore del software prodotto in relazione all’investimento.
Stabilire i benefici attesi e il potenziale del progetto
A seconda dei casi, gli scopi di un nuovo prodotto digitale sono principalmente quelli di essere il servizio core business di un’azienda, ammodernare il paradigma di un’applicazione software (es. da applicazione client a piattaforma SaaS) o creare un nuovo canale di distribuzione di un prodotto o servizio fisico (es. e-commerce).
In altri casi è quello di aumentare l’efficienza/ridurre i costi o adeguarsi al mercato (es. aggiornamento di un prodotto già esistente).
E’ quindi innanzitutto necessario identificare i benefici attesi dal progetto e i risultati che si possono ottenere da esso per poter decidere se, indipendentemente dal suo costo, sia sensato o meno realizzarlo.
Definire delle stime di costo di massima
In base all’esperienza dei progetti già realizzati e ai dati del timesheet, si può ipotizzare una prima stima del progetto senza dover effettuare un’analisi approfondita (che può però essere fornita come fase a parte).
La stima sarà individuata con un intervallo piuttosto ampio (es. 35.000 / 45.000 Euro).
Sapendo però di lavorare con un certo metodo, la stima non sarà agli estremi del cosiddetto cono di incertezza (16 volte in più o in meno) ma sarà caratterizzata da un fattore più stretto (2x).
In questa fase non ci sono i dati necessari per stimare con precisione la reale dimensione del progetto, ma un’azienda con uno storico affidabile può stabilire sulla base dell’esperienza che tipo di budget sarà necessario per realizzare il progetto lavorando in modo collaborativo.
Allocare un budget adeguatamente superiore alle stime
A questo punto è necessario che l’azienda analizzi se i potenziali ricavi o risparmi attesi dal progetto possano dare un sufficiente ritorno rispetto all’ipotesi di spendere fino ad un 50% in più del costo di massima stimato; in caso negativo il progetto andrebbe cancellato.
Questo non significa che tutto il budget debba essere necessariamente speso, ma riservarlo significa proteggersi dal rischio di sottocapitalizzare il progetto, proprio come fanno gli investitori professionali.
E’ infatti meglio spendere troppo (ma all’interno del budget di progetto) che troppo poco, non riuscendo a realizzare correttamente il prodotto e sprecando l’intero investimento.
Definire un budget di sviluppo inferiore a quello complessivo del progetto e costruire velocemente il prodotto più piccolo possibile
Un budget fisso inferiore a quello allocato costringe sia il cliente che il team di sviluppo a definire e a costruire la versione più piccola possibile del prodotto che al contempo sia in grado, una volta avviato, di fornire valore.
Per fare questo, bisogna effettuare assieme scelte ragionate sulla dimensione del progetto, stabilendo cosa includere e cosa no, e trovare compromessi accettabili e alternative creative; il tutto dovrà poi essere fornito agli utenti reali il più presto possibile.
Mantenere un budget di sviluppo inferiore a quello allocato complessivamente porta a sviluppare di meno, realizzando solo le cose importanti, e a rilasciarle rapidamente.
Se, una volta rilasciato il software, dovesse emergere dagli utenti la necessità di aggiungere ulteriori funzionalità importanti, il cliente avrebbe ancora budget a disposizione.
Conclusione
Consigliamo di lavorare collaborativamente con il team di sviluppo per costruire la minor quantità possibile di funzionalità, ma ottenendo quelle più importanti sulla base del budget a disposizione.
Le possibilità di successo aumentano con un po’ di lavoro iniziale, consegnando software funzionante ogni settimana, scomponendolo e stimandolo di volta in volta in attività più piccole, e tracciando la velocità di sviluppo per prevedere il tempo necessario e il costo residuo.
