Sviluppo software:
Sviluppo app Venezia:
una cosa sola, fatta bene
Le app che le persone usano davvero fanno una cosa e la fanno meglio di qualsiasi alternativa.
Quelle che nascono come contenitore di tutto quello che l’azienda vorrebbe comunicare hanno tutte lo stesso destino: si scaricano al lancio, si aprono una volta, restano lì.
Per questo nei progetti di sviluppo app a Venezia passiamo del tempo a togliere funzioni prima di scriverne una riga. Non per risparmiare: perché ogni funzione in più allontana quella principale.
La domanda che facciamo è sempre la stessa: se questa app potesse fare una cosa sola, quale sarebbe.
La risposta è difficile da dare. Ed è quella che decide se il progetto funzionerà.
La verifica iniziale:
tre domande prima di preventivare
Prima di stimare qualsiasi cosa chiediamo tre risposte. Sono le stesse che ci facciamo noi.
Quante volte una persona aprirà questa app in un mese. Se la risposta è una o due, l’app non ce la farà: verrà disinstallata quando serve spazio. Questo numero da solo decide molti progetti.
Cosa succede se non c’è connessione. Se la risposta è “niente, si aspetta”, forse basta un sito. Se invece il lavoro deve continuare lo stesso, serve un’app vera.
Chi la userà e in che condizioni. Un tecnico con i guanti su un tetto e un cliente sul divano richiedono due progetti diversi, e il primo è quello dove i dettagli contano.
Con queste risposte si capisce in mezz’ora se il progetto sta in piedi.
Il momento più economico per fermarsi è prima di cominciare.
Gli store:
quello che nessuno mette a preventivo
Pubblicare un’app non è caricare un file. È un passaggio con regole proprie, e ogni tanto con sorprese.
Chi ha persone sul campo ha esigenze precise, ed è una parte importante del tessuto di Venezia.
Nel veneziano turismo internazionale, artigianato d’eccellenza e il polo industriale e portuale convivono a pochi chilometri. Pubblici e stagionalità completamente diversi.
Se quello che serve è un sito e non un’applicazione, la pagina giusta è realizzazione siti internet a Venezia.
Servono gli account da sviluppatore, che hanno un costo annuale e vanno intestati a voi, non all’agenzia: è un punto su cui insistiamo, perché un’app pubblicata sull’account del fornitore è un problema il giorno che cambiate fornitore.
Poi c’è la revisione. Ogni versione viene esaminata e può essere respinta: per una schermata di accesso poco chiara, per una richiesta di permessi non spiegata, per regole sui contenuti o sui pagamenti. Succede, si corregge e si ripresenta, ma va messo nei tempi.
Ci sono infine gli adempimenti: informativa sulla privacy, dichiarazione sui dati raccolti, requisiti di accessibilità.
Mettiamo questa fase nel preventivo perché esiste, non perché ci piace.
Come siamo fatti:
Continuità:
l’app vive finché qualcuno la segue
Su un’app la continuità non è un valore aggiunto, è un requisito tecnico.
Ogni anno arrivano nuove versioni dei sistemi operativi e nuove regole degli store. Serve qualcuno che se ne accorga per tempo e intervenga prima che l’app venga rimossa o smetta di aprirsi sui telefoni nuovi.
Da noi il progetto ha un referente che resta lo stesso, e il codice è vostro e documentato: se un domani volete portarlo altrove, potete farlo senza ricominciare.
Siamo oltre quaranta persone in un unico studio a Sarezzo, vicino a Brescia, e operiamo su Venezia come nel resto d’Italia.
Un’app abbandonata dal suo sviluppatore ha una vita di circa due anni. Poi va rifatta.
Quanto costa sviluppare un’app:
da cosa dipende il preventivo
Le variabili sono poche e sono tutte verificabili prima di firmare.
Quante funzioni deve avere. È di gran lunga la voce principale. Ogni schermata è progettazione, sviluppo e prove su due sistemi.
Nativa o multipiattaforma. La prima significa due lavori, e si sente sul totale.
Cosa c’è dietro. Se l’app deve parlare con i vostri gestionali, il lavoro sul server può pesare quanto l’app stessa. È la voce che viene sottovalutata più spesso.
Chi la userà. Un’app per il pubblico richiede più cura sull’aspetto e sui casi limite; una per venti tecnici interni può essere più essenziale.
A parte va il mantenimento annuale, che non è opzionale. Il conto va fatto a tre anni, perché è la vita minima di un’app che ha senso.
Dipende quasi tutto da una cosa: quante funzioni deve avere. Ogni schermata è progettazione, sviluppo e prove su due sistemi operativi.
Le altre variabili che pesano sono la scelta fra nativa e multipiattaforma, e soprattutto cosa c’è dietro: se l’app deve dialogare con i vostri gestionali, il lavoro sul server può costare quanto l’app.
C’è poi una voce che va tenuta separata e che quasi nessuno mette nel primo preventivo: il mantenimento annuale. Non è assistenza opzionale, è quello che tiene l’app pubblicata quando i sistemi si aggiornano.
Il nostro modo di lavorare è definire prima cosa deve fare l’app, schermata per schermata, e stimare su quello. Una cifra data prima di quel passaggio è un’ipotesi che cambierà.
Per un’app essenziale, poche schermate e nessun collegamento con i vostri sistemi, dalle otto alle dodici settimane.
Per un’app aziendale con parte server, accesso utenti e dialogo con il gestionale, dai quattro ai sei mesi. La parte lunga raramente è l’app: sono i collegamenti e le prove sul campo.
A questi tempi va aggiunta la pubblicazione sugli store, che richiede una revisione da parte loro. Di solito è questione di giorni, ma può capitare un rifiuto da correggere, quindi conviene non fissare il lancio con margini stretti.
Lavoriamo per versioni successive: si mette in mano alle persone qualcosa di funzionante presto, così se serve cambiare direzione lo si scopre al secondo mese e non al quinto.
È la domanda giusta, e va fatta prima di firmare.
Un’app, a differenza di un sito, si degrada se nessuno la tocca. I sistemi operativi si aggiornano una o due volte l’anno e cambiano requisiti, permessi e componenti. Gli store impongono scadenze per adeguarsi, e un’app non aggiornata prima o poi viene rimossa o smette di aprirsi sui telefoni nuovi.
Quindi esiste un costo annuale anche se non aggiungete nessuna funzione. Va considerato parte del progetto, non un extra.
Nei nostri preventivi lo indichiamo dall’inizio con una cifra di riferimento. Le app che ci arrivano da fuori da sistemare sono quasi sempre app di cui nessuno aveva spiegato questa parte.
Sul vostro, sempre, ed è un punto su cui insistiamo anche quando all’inizio sembra un fastidio burocratico.
Gli account da sviluppatore hanno un costo annuale e vanno intestati alla vostra azienda. Un’app pubblicata sull’account del fornitore diventa un problema il giorno in cui volete cambiare fornitore: recensioni, storico e continuità degli aggiornamenti sono legati a quell’account.
Vi aiutiamo ad aprirli e configurarli, e li usiamo con le autorizzazioni che ci date.
Vale lo stesso per il codice: è vostro e documentato. Se un domani il progetto va altrove, chi lo riceve deve poterci lavorare senza ricominciare da zero.
Sì, e per molte app aziendali è la ragione principale per cui si fa un’app invece di un sito.
L’app tiene i dati sul dispositivo e li sincronizza quando la connessione torna. È la situazione tipica di chi lavora in cantiere, in capannone, in campagna o in zone con copertura scarsa.
La complessità sta nella sincronizzazione: cosa succede se due persone modificano la stessa cosa mentre sono scollegate, quali dati vincono, come si segnalano i conflitti. Sono decisioni da prendere all’inizio, perché determinano l’impianto.
È un lavoro che aggiunge costo, e nei casi in cui serve ripaga più di qualsiasi altra funzione.
Sì, ed è quasi sempre la parte più consistente del progetto.
L’app da sola raccoglie o mostra dati, ma il valore nasce quando quei dati entrano ed escono dai sistemi che usate già: gestionale, magazzino, anagrafiche clienti, commesse.
Quanto costa dipende da come è fatto il vostro sistema. Alcuni hanno già un modo pulito per scambiare dati, altri richiedono un lavoro su misura, e su gestionali molto vecchi a volte serve un passaggio intermedio.
È la prima verifica tecnica che facciamo, prima di dare qualsiasi cifra, perché può cambiare il preventivo più di ogni altra scelta.
Se l’app è per uso interno il problema non esiste: si installa a chi lavora e si spiega come si usa.
Se è rivolta al pubblico, questa è la parte difficile e va affrontata prima di sviluppare, non dopo. Le persone installano poche app e le scelgono con attenzione: serve un motivo chiaro, ripetuto in ogni punto di contatto, e spesso un vantaggio concreto legato all’uso.
Il lancio va organizzato: chi già vi conosce, il sito, i punti vendita, le comunicazioni ai clienti. Contare sul fatto che vi trovino cercando negli store è una speranza, non un piano.
Ne parliamo prima di cominciare, perché se non c’è una risposta convincente a questa domanda, il progetto non sta in piedi comunque sia fatto bene.
Uso interno:
Raccolta dati in cantiere, magazzino, assistenza sul campo. Meno affascinanti e quasi sempre le più redditizie.
Offline:
Funzionare senza connessione e sincronizzare dopo. È la ragione tecnica più solida per fare un’app invece di un sito.
Server:
La parte che nessuno vede e che spesso costa quanto l’app. Gestisce dati, utenti e collegamenti con i vostri sistemi.
Integrazioni:
Dialogo con gestionale, magazzino, anagrafiche. Prima verifica tecnica che facciamo, perché sposta il preventivo.
Notifiche:
Utili quando comunicano qualcosa che cambia: uno stato, un turno, una scadenza. Usate per promuovere, fanno disinstallare.
Store:
Account intestati a voi, revisione e possibili rifiuti, adempimenti su privacy e dati. Una fase con tempi propri.
Raccontaci cosa dovrebbe fare. Ti diciamo se serve un’app, se basta un sito e quanto costerebbe l’una o l’altra strada.
Le recensioni dei clienti che ci hanno scelto.
Sviluppiamo strategie di comunicazione, marketing digitale, branding e innovazione su misura, integrando competenze creative e tecnologiche per accompagnare aziende e organizzazioni nel raggiungimento dei propri obiettivi.
Diventa il nostro prossimo cliente soddisfatto
