Archivi tag: stima tempi e costi

Quanto costa creare una App? Calcola il preventivo online

Rispondi alle domande seguenti e scopri subito costi di sviluppo e tempi di consegna per realizzare la tua App iOS/Android.

Lo sviluppo di App iOS/Android è un’attività abbastanza giovane, basti pensare che l’iPhone ha fatto la sua comparsa in Italia nel 2009. Di conseguenza le persone molto spesso non hanno la minima idea di quanto costi sviluppare una App su misura.

Abbiamo quindi pensato di realizzare un calcolatore di costo per consentire a chiunque di farsi un’idea dei costi e tempi di sviluppo della propria App, ancora prima di contattarci.

Il calcolatore prende in considerazione gli elementi tipici e rilevanti di una App. Abbiamo cercato di elencare le caratteristiche che più spesso ci chiedono.

Se qualcosa non è chiaro puoi contattarci oppure leggere i seguenti articoli che approfondiscono la tematica sintetizzata dal calcolatore:

Quali sono i dati importanti per avere un preventivo preciso?

La richiesta di un preventivo è la fase più delicata per lo sviluppo di una soluzione su misura:

  • più le richieste sono poco dettagliate e più il preventivo sarà approssimativo, sarà possibile cioè dare solo un’idea a grandi linee di tempi e costi;
  • più le richieste sono poco dettagliate e più tempo sarà necessario per redigere il preventivo.

Questo articolo vuole quindi essere una guida per aiutare i Clienti a formulare richieste il più preciso possibile in modo da avere preventivi altrettanto precisi e in tempi ragionevoli.

A questo proposito è utile seguire questa traccia:

  1. Esiste già una soluzione che fa buona parte di quello che serve al Cliente?
    1. Sì: questa soluzione è modificabile (è ad esempio open-source)?
      1. Sì: quali sono le modifiche richieste per raggiungere l’obbiettivo?
      2. No: bisogna sviluppare una soluzione da zero;
    2. No: bisogna sviluppare una soluzione da zero;

 
Nel caso in cui la soluzione richiesta non sia banale, bisogna sempre tener presente che svilupparla da zero è molto più costoso che modificarne una già esistente.

Nel caso 1.1.1 cioé modifica di una soluzione già esistente è bene chiedere direttamente allo sviluppatore il quale, se disponibile, probabilmente farà il preventivo più conveniente.

Il caso che riserva più sorprese sia allo sviluppatore che al Cliente è indubbiamente l’1.1.2: richiesta di sviluppo da zero di una soluzione copiandone una già esistente.

In questo caso tipicamente il Cliente ha una percezione ridotta del set di funzionalità implementate nella soluzione da copiare e cioè ne vede solo una parte (quella che gli interessa di più) dando per scontato tutto il resto.

Inoltre, sempre in questo caso, il Cliente può venire polarizzato dal prezzo di vendita della soluzione da copiare e aspettarsi pertanto una cifra analoga senza tener presente che il prezzo di vendita di una soluzione venduta a tanti non può essere la stessa di una soluzione sviluppata ad hoc per una sola realtà.

Nel caso per esempio delle estensioni i prezzi di mercato si aggirano sulle poche decine di dollari, questo ovviamente non significa che per svilupparli siano bastate poche decine di dollari: il produttore dell’estensione la può vendere a cifre irrisorie a patto che a comprarla siano migliaia di persone es. 20 dollari per 1000 persone uguale 20000 dollari, tutt’altra questione.

Tipicamente i siti che vendono queste estensioni riportano il numero di download o di acquisti. Per farsi un’idea delle cifre coinvolte è bene quindi fare la moltiplica.

Senza dilungarsi troppo, per altri ragionamenti sul costo di un software e su quanto vale un software si può approfondire con i seguenti articoli:

Tipicamente è in questo caso che il preventivo risulta più alto delle aspettative del Cliente e richiede maggior tempo per essere redatto con il conseguente rischio che venga rifiutato.

Al Cliente conviene quindi sforzarsi di isolare le uniche parti che gli servono davvero.

Questo lavoro può essere fatto solo dal Cliente e prevede che quest’ultimo rifletta attentamente sulle funzionalità che sono per lui di primaria importanza e quali sono invece quelle non necessarie.

Tanto sarà più preciso in questa fase tanto minore sarà l’importo e i tempi di sviluppo del preventivo.

Per fare un esempio ipotizziamo che un cliente, proprietario di un hotel, dopo aver saputo la commissione richiesta da siti come booking.com per inserire le proprie offerte, decida di farsi fare un preventivo per lo sviluppo di una soluzione simile a booking.com da ospitare sul sito del proprio hotel e che gli consenta di gestire in prima persona le prenotazioni per la sua struttura.

A questo punto, se la richiesta di questo ipotetico Cliente si limitasse ad essere “vorrei una soluzione simile a booking.com per il mio hotel” avrebbe come risposta un preventivo da decine di migliaia di euro e diversi mesi di lavoro.

Questo perché le funzionalità di booking.com intanto non sono solo quelle visibili direttamente sul sito, ma c’è anche tutta la parte di amministrazione.

Inoltre non bisogna dimenticare che booking.com avrà un team di sviluppatori che da anni mantengono sviluppato un sistema del genere sul quale l’intera società fa profitto interagendo con centinaia di albergatori in tutto il mondo.

E’ pertanto ingenuo pensare che un sistema del genere possa avere un costo alla portata del singolo utente.

E’ anche vero che in realtà al Cliente non servono tutte le funzionalità implementate da booking.com, magari gliene servono solo un decimo.

Isolare le sole funzionalità necessarie è la chiave per raggiungere l’obbiettivo senza spendere un capitale.

Un modo per capire quali sono queste funzionalità è quello di immedesimarsi negli utenti del sistema e chiedersi di volta in volta come avviene l’interazione con esso.

Es.: l’utente effettua una prenotazione.

  1. l’utente si collega al sito;
  2. l’utente inserisce i dati della propria prenotazione: data di arrivo, data di partenza, numero di persone;
  3. il sistema propone le soluzioni disponibili nel periodo di tempo specificato mostrando per ogni soluzione l’importo complessivo;
  4. l’utente sceglie la soluzione che preferisce;
  5. l’utente conclude la prenotazione inserendo i propri dati anagrafici e i dati della carta di credito;
  6. il sistema effettua la transazione;
  7. il sistema notifica al cliente il buon esito dell’operazione inviandogli una mail riassuntiva della prenotazione effettuata;

 
Alternativa 4: nel caso in cui il sistema non abbia trovato soluzioni che soddisfino i parametri specificati mostra un messaggio all’utente e lo invita a telefonare per mettersi d’accordo con i gestori dell’hotel.

Alternativa 5: il sistema dopo aver verificato che i dati immessi non sono corretti notifica all’utente l’errore e richiede nuovamente l’inserimento dei dati corretti.

Il modo sbagliato per descrivere il caso d’uso dell’esempio precedente sarebbe stato:

  1. l’utente si collega al sito;
  2. l’utente effettua la prenotazione;

 
Il punto 2 è troppo vago e sottintende un mondo di possibilità: può risultare ovvio per il Cliente, ma non certo per lo sviluppatore il quale può non conoscere il dominio applicativo.

Quando si specificano le funzionalità richieste bisogna cioè mettersi nei panni anche di chi le dovrà implementare.

Un altro modo utile per definire i dettagli delle funzionalità richieste è quello di disegnare le schermate del sistema nelle varie fasi di interazione, magari anche semplicemente su un pezzo di carta, giusto per avere un’idea ancora più chiara di che cosa dovrà fare il sistema.

Nel caso in cui il problema da risolvere fosse estremamente complicato o estremamente ampio potrebbe essere più conveniente saltare tutta questa fase e optare per uno sviluppo iterativo come descritto nel seguente articolo: Perché un processo di sviluppo iterativo è meglio per il Cliente?.

Perché un processo di sviluppo iterativo è meglio per il Cliente?

Tradizionalmente lo sviluppo del software viene suddiviso nelle seguenti fasi:

  1. Elicitazione dei requisiti;
  2. Stima di tempi e costi;
  3. Sviluppo;
  4. Rilascio;
  5. Supporto post-rilascio;

Questo approccio, nonstante sia ancora quello più utilizzato, soffre di evidenti limiti, primo fra tutti il fatto che la stima di tempi e costi avviene nelle prime fasi e resta immutata per tutta la fase dello sviluppo.

Esistono vari motivi per cui questo è un limite e dipendono tutti dalla discrepanza tra teoria e pratica:

  • nella realtà non è vero che si possono elicitare tutti i requisiti all’inizio del progetto;
  • nella realtà non è vero che i requisiti elicitati nella fase iniziale restano immutati fino alla fine dello sviluppo;

Queste considerazioni determinano di fatto un errore di valutazione per quanto riguarda la stima di tempi e costi.

L’errore che si può commettere in questo frangente è direttamente proporzionale alle dimensioni del software che si vuole realizzare.

Sottostimare la realizzazione di un software non sarebbe di per sé così grave se non venisse accompagnato dalla storica riluttanza dei committenti a non voler pagare le funzionalità non previste nelle fasi iniziali o addirittura non presenti nel contratto di sviluppo sottoscritto e anzi a pretenderle forti del fatto che pagheranno in un momento futuro.

Stanti le cose, molti sviluppatori cercano di porre rimedio a questo scenario con pagamenti anticipati di quote del progetto e gonfiando le stime iniziali.

Le possibili conseguenze di questa “soluzione” possono essere:

  • il rifiuto del cliente a causa di tempi e cifre fuori mercato;
  • la sovrastima del progetto: il cliente pagherà di più di quello che sarebbe stato il giusto.

In sintesi, utilizzando questo tipo di approccio, in 2 casi su 3 una delle due parti reseterà insoddisfatta: lo sviluppatore se ha sottostimato (caso più probabile), il committente se lo sviluppatore ha sovrastimato.

Consapevoli di tutto ciò, su progetti di grandi dimensioni, è più saggio accettare l’impossibilità di effettuare stime ragionevolmente precise e cambiare tipo di approccio.

Lo sviluppo a iterazioni non soffre di questi limiti poiché non è necessario elicitare dettagliatamente i requisiti e non è necessario effettuare una stima a priori.

Secondo questo metodo infatti le uniche cose che si definiscono sono:

  • la durata delle iterazioni: in genere un mese;
  • il costo di ogni iterazione;

In questo modo il Cliente ha i seguenti vantaggi:

  • non pagherà più del necessario;
  • avrà un feedback sullo stato di avanzamento dei lavori al completamento di ogni iterazione in modo da non avere sorprese e poter correggere la rotta man mano che si procede;
  • avrà la massima libertà, in qualsiasi momento, di chiedere modifiche alle funzionalità già implementate o addirittura di richiedere nuove funzionalità inizialmente non previste;
  • potrà decidere di sospendere o interrompere lo sviluppo quando vuole.

Abbinare lo sviluppo di software su misura alla modalità di sviluppo a iterazioni è il modo più efficace ed efficiente di ottenere gli strumenti giusti per far crescere la propria impresa.