Archivi tag: preventivi

Quanto costa sviluppare un’App Android, iOS, iPhone, iPad, Windows Phone, BlackBerry ?

NOVITÀ: CALCOLA ONLINE IL PREVENTIVO DELLA TUA APP!

Rispondi alle domande e scopri subito costi di sviluppo e tempi di consegna della tua App iOS/Android.

Prova subito il nostro calcolatore online!

Da qualche anno ormai le vendite di smartphone e tablet hanno superato quelle di PC (fonte mashable.com).

Se il trend continua, in breve tempo saranno di più le persone che possiedono uno smartphone di quelle che possiedono un computer.
Già adesso le statistiche dicono che il 17% del traffico web è generato dai dispositivi mobili (smartphone e tablet) (fonte mashable.com).

Continua la lettura di Quanto costa sviluppare un’App Android, iOS, iPhone, iPad, Windows Phone, BlackBerry ?

Come fate a creare Applicazioni Web Su Misura a prezzi contenuti?

Questa è una domanda che ci sentiamo rivolgere spesso quando un potenziale nuovo cliente confronta il nostro preventivo con quello della concorrenza.

In effetti noi di Garda Informatica abbiamo un approccio innovativo.
Continua la lettura di Come fate a creare Applicazioni Web Su Misura a prezzi contenuti?

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?.