Sviluppo di un'app mobile aziendale, passo dopo passo
Lo sviluppo di un'app mobile aziendale va da scoperta e perimetro a design, realizzazione, test e pubblicazione sugli store. Ecco cosa si decide a ogni passo.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Il processo di sviluppo di un'app mobile aziendale ha sette passi principali: scoperta, definizione del perimetro, design, sviluppo, test, pubblicazione sugli store e manutenzione dopo il lancio. Ogni passo produce un risultato, e il successivo parte solo quando quel risultato è approvato. Il processo sembra lineare, ma in pratica contiene ritorni indietro. Un buon progetto è sano perché compie questi giri presto e a basso costo, non perché non li compie mai.
Ciò che distingue un'app aziendale da una personale è che dietro ci sono più decisori, sistemi esistenti e una catena di approvazione con regole. Questo articolo spiega che cosa decide un titolare o un responsabile a ogni passo, dove si perde tempo e quando l'intero processo non serve.
A quali domande risponde la fase di scoperta?
La scoperta chiarisce quale problema l'app deve risolvere. Chi è l'utente, quando e perché la aprirà, e perché un sito mobile o uno strumento esistente non può soddisfare quel bisogno? Un progetto che parte senza risposte oneste finisce spesso in un'app che nessuno apre una volta online.
In questa fase si mappano anche i sistemi esistenti: dove si trovano i dati degli utenti, con quale sistema interno deve dialogare l'app, l'approvazione di chi serve? Pensate a un'app di iscrizione e prenotazione per un gruppo di spa. Se le informazioni di prenotazione stanno in un software separato in ogni sede, il vero lavoro dell'app è dialogare in modo sicuro con quel software. Numero e natura di questi collegamenti condizionano ogni passo successivo.
Come si fissa il perimetro e che cosa entra nella prima versione?
Il perimetro è l'elenco scritto delle funzioni della prima versione. L'errore più comune è cercare di farci stare tutto. L'approccio più sano è rilasciare la versione più piccola che completi il compito principale dell'utente, poi ordinare il resto in base a dati d'uso reali.
Quando si scrive il perimetro, le funzioni si dividono in tre gruppi: essenziali, auspicabili e per dopo. Se questa suddivisione non viene messa per iscritto, ogni richiesta aggiunta lungo la strada amplia silenziosamente il perimetro. L'ampliamento progressivo del perimetro è la ragione più comune dei progetti in ritardo.
- Scrivere in una frase il compito principale dell'utente
- Etichettare ogni funzione come essenziale, auspicabile o per dopo
- Elencare i sistemi interni e i fornitori a cui l'app si collegherà
- Decidere in anticipo come si richiede una modifica del perimetro
Che cosa accade durante design e prototipazione?
Il design non è solo aspetto. È costruire il percorso. Quali schermate attraversa l'utente per completare un compito, che cosa vede quando qualcosa non va, che cosa succede quando cade la connessione? Queste domande si mettono alla prova in un prototipo cliccabile prima di scrivere una riga di codice, perché cambiare un percorso sulla carta costa molto meno che cambiarlo nel codice.
Il prototipo viene mostrato ad alcuni utenti reali. Le persone interne all'organizzazione conoscono il percorso e non se ne allontanano. Ciò che serve imparare è dove esita chi vede il prodotto per la prima volta. Qui si considera anche l'accessibilità: dimensione del testo leggibile, contrasto sufficiente e aree di tocco comode non sono dettagli da aggiungere dopo.
Come procedono sviluppo e test?
Lo sviluppo procede per periodi brevi, e alla fine di ciascuno viene mostrato un pezzo funzionante. In questo modo le sorprese arrivano presto anziché tardi. Anche il test non è una fase lasciata alla fine. Accompagna lo sviluppo: controlli automatici, prove su dispositivi reali e uno sguardo a diverse dimensioni di schermo.
Nelle app aziendali il test conta soprattutto per i collegamenti. Anche se un collegamento di pagamento, di notifiche o di un sistema interno funziona bene, bisogna vedere che cosa accade con una rete lenta o durante un'interruzione. Se il team sul campo di un produttore di pavimenti usa l'app soprattutto sul posto con segnale debole, il comportamento senza connessione è il cuore del prodotto.
Il collaudo si svolge con il team stesso dell'azienda. Le persone che conoscono il flusso di lavoro reale trovano lacune che il team tecnico non può vedere. Se il tempo concesso a questo passo viene ridotto, i difetti emergono dopo che l'app è arrivata sullo store.
Come si gestiscono la pubblicazione sugli store e il periodo successivo?
L'invio allo store è una fase con un proprio processo di revisione, i cui tempi non si possono prevedere con esattezza. Per questo la data di lancio si pianifica lasciando margine per la revisione. Anche le regole degli store e le dichiarazioni sulla privacy si preparano prima della pubblicazione, perché una dichiarazione mancante può portare al rifiuto dell'app.
La pubblicazione è l'inizio del lavoro, non la fine. Nel primo periodo si tengono d'occhio i rapporti sui crash, le recensioni degli utenti e i dati d'uso di base. L'app continua a vivere con gli aggiornamenti del sistema operativo, il rinnovo delle librerie e le nuove funzioni. Se il piano di manutenzione non viene discusso prima del rilascio, l'app invecchia in silenzio.
Quali errori sono comuni nel processo di un'app aziendale?
Il primo errore è saltare la scoperta e passare subito al design. Un progetto che non conosce il problema costruisce un prodotto bello ma inutile. Il secondo è coinvolgere tardi i decisori. Un'obiezione dei vertici a metà sviluppo è la modifica più costosa che ci sia.
Il terzo errore è concentrarsi solo sulla data di lancio e non pianificare la manutenzione. Il quarto è procedere su supposizioni senza mai parlare con gli utenti. Il quinto è costruire una struttura che dipende da una sola persona. Il codice, le credenziali di accesso e gli account degli store devono essere sempre intestati all'organizzazione.
Quando non serve un'app aziendale?
Non ogni esigenza richiede un'app. Dove gli utenti leggono informazioni di tanto in tanto e non hanno bisogno di funzioni del dispositivo come la fotocamera o le notifiche, spesso basta un sito mobile o un'app web ben fatti. E se non siete sicuri di quanto spesso gli utenti torneranno al vostro prodotto, la via sensata è fare prima una piccola prova.
Il criterio: l'utente svolge questo compito ripetutamente e le funzioni del dispositivo aggiungono valore? Se entrambe le risposte sono sì, un'app ha senso. In caso contrario, l'investimento è meglio spenderlo su un altro canale. Per vedere come si comporta il vostro sito attuale su mobile, il nostro test di velocità del sito vi dà gratis una prima impressione.
Il processo di un'app aziendale va dalla scoperta alla manutenzione in sette passi, e la maggior parte di tempo e denaro si perde in perimetri vaghi, decisioni tardive e manutenzione non pianificata. Scrivete chiaramente il problema, tenete piccola la prima versione, coinvolgete presto i decisori e discutete la manutenzione prima del lancio. Se desiderate affinare insieme la vostra idea di app, potete fissare un colloquio conoscitivo con rabbitclip.
Domande frequenti
Quanti passi ha il processo di sviluppo di un'app mobile aziendale?
Di solito sette passi principali: scoperta, perimetro, design, sviluppo, test, pubblicazione sugli store e manutenzione. Ogni passo ha un risultato che richiede approvazione.
Quali funzioni appartengono alla prima versione?
L'insieme più piccolo che completa il compito principale dell'utente. Il resto si aggiunge nelle versioni successive, guidato da dati d'uso reali.
Quanto dura la revisione dello store e come va pianificata la data di lancio?
I tempi di revisione non si possono prevedere e possono variare. Pianificate la data di lancio con margine per un possibile rifiuto e la relativa correzione.
Serve manutenzione dopo la pubblicazione dell'app?
Sì. Aggiornamenti del sistema operativo, rinnovo delle librerie e correzione dei bug richiedono attenzione costante. Il piano di manutenzione va discusso prima del rilascio.
Quando basta un sito mobile al posto di un'app?
Quando gli utenti leggono informazioni solo ogni tanto e non hanno bisogno di funzioni del dispositivo. Flussi ripetuti e funzioni del dispositivo sono ciò che rende utile un'app.
