8 errori costosi nello sviluppo di app che le PMI continuano a commettere

Ecco la scomoda verità sui progetti di app che vanno per il verso sbagliato: nel momento in cui il codice sembra errato, il progetto era già perso da settimane. Gli errori costosi nello sviluppo di app per le piccole imprese non avvengono quasi mai alla tastiera. Avvengono in conversazioni informali — il brief che non è mai stato messo per iscritto, la funzione che qualcuno ha aggiunto 'già che ci siamo', lo sviluppatore scelto perché lo ha raccomandato un amico. Sul momento nulla di tutto questo sembra una decisione. E tutto vi costa più avanti.

Ho visto molte piccole imprese commissionare la loro prima app, e sono stato chiamato a salvarne parecchie dopo i fatti. I titolari raramente sono persone superficiali. Sono acuti, attenti, bravi a gestire un'azienda. Ma il software ha le sue trappole, che non esistono in nessun'altra parte della loro vita lavorativa, e nessuno li ha avvisati. Così finiscono dritti negli stessi otto scogli, più o meno nello stesso ordine, ogni volta.

Questa è la lista che avrei voluto avesse ogni titolare prima di spendere un centesimo. Non teoria — gli errori reali e ricorrenti, e le piccole correzioni di rotta che avrebbero salvato ogni progetto. Se state per costruire un'app, o siete già a metà dello sviluppo e qualcosa vi sembra storto, leggete prima questo. La maggior parte di questi errori è ancora correggibile se la cogliete in tempo.

Errore 1: Costruire prima di aver provato che qualcuno la vuole

L'errore più costoso è anche il più comune: impegnarsi in uno sviluppo completo prima che esista una prova concreta che l'app risolva un problema per cui le persone pagheranno o che useranno. Al titolare l'idea sembra ovvia — certo che i clienti la vorranno — e proprio quella certezza è ciò che è pericoloso. La certezza ha l'aspetto di una validazione. Non lo è.

Validare non significa chiedere a dieci amici se l'idea piace loro; tutti dicono di sì per gentilezza. Significa mettere la versione più piccola possibile davanti a utenti reali in una situazione reale e osservare cosa fanno davvero. Un prototipo cliccabile, una landing page che misura le iscrizioni, una versione manuale 'da concierge' in cui simulate l'automazione a mano — ognuna di queste vi dice più di un'app finita costruita su un'intuizione. L'ordine conta: provate la domanda a basso costo, poi costruite a caro prezzo. Invertitelo e potete spendere tutto il budget rifinendo qualcosa che nessuno apre due volte.

Errore 2: La dilatazione dell'ambito travestita da ambizione

Ogni app comincia snella e ordinata. Poi inizia il 'già che ci siamo'. Già che costruiamo la schermata di prenotazione, potrebbe anche gestire i buoni regalo? E i punti fedeltà? E un sistema di segnalazioni? Ogni aggiunta suona ragionevole presa da sola. Insieme triplicano in silenzio i tempi e il conto — e spostano il lancio così avanti che lo slancio iniziale si spegne.

La soluzione non è dire di no alle buone idee. È parcheggiarle. Tenete una lista 'versione due' ben visibile dove ogni idea brillante attende il suo turno. Questo produce un effetto psicologico oltre che pratico: le persone smettono di lottare per infilare funzioni nella prima versione non appena si fidano che ci sia davvero un posto per la loro idea più avanti. La vostra prima versione deve fare una cosa davvero bene, non dieci cose in modo accettabile. Un'app che padroneggia un singolo flusso di lavoro viene usata. Un'app che fa tutto a metà viene abbandonata.

Errore 3: Nessun brief scritto — solo un'immagine mentale condivisa

Questo errore è invisibile finché non morde. Il titolare ha un'app chiara in testa. Lo sviluppatore ha un'app chiara in testa. Tutti annuiscono alla riunione di avvio. Nessuno la mette per iscritto come si deve — e le due immagini, si scopre, non sono mai state la stessa immagine. Lo scoprite a metà strada, quando ciò che si sta costruendo non è ciò che immaginavate, e adesso c'è una discussione su chi ha detto cosa.

Non vi serve una specifica di cento pagine. Vi servono poche pagine che qualsiasi nuovo arrivato possa leggere e capire: chi usa quest'app, quali sono le tre o quattro cose che deve farci, com'è un risultato riuscito. Aggiungete uno schizzo sommario delle schermate chiave. Tutto qui. Lo scopo del brief non è la burocrazia — è un riferimento condiviso che entrambi potete indicare quando memoria e realtà cominciano a divergere, cosa che fanno sempre.

Errore 4: Scegliere lo sviluppatore nel modo sbagliato

La maggior parte dei titolari sceglie il primo sviluppatore in base a uno di due segnali fragili: il preventivo più basso, oppure una raccomandazione personale da parte di qualcuno di un altro settore. Entrambi possono funzionare per fortuna. Nessuno dei due è un modo affidabile di scegliere qualcuno a cui affiderete una fetta considerevole di denaro e diversi mesi del futuro della vostra azienda.

Il preventivo più basso è particolarmente insidioso nel software, perché il divario tra un preventivo e il costo finale è enorme e invisibile. Uno sviluppatore economico che ha bisogno di tre giri di rilavorazioni, sparisce per due settimane e vi lascia un codice che nessun altro è in grado di mantenere risulta molto più costoso di uno un po' più caro che fa le cose per bene. Il prezzo è ciò che vedete; il costo totale è ciò che pagate.

Cosa controllare davvero

Chiedete di vedere cose che hanno rilasciato e che sono ancora in funzione e, se potete, parlate con quei clienti senza lo sviluppatore nella stanza. Chiedete come gestiscono i cambiamenti a metà progetto, perché di cambiamenti ce ne saranno. Chiedete a chi appartengono il codice e gli account a lavoro finito — la risposta dovrebbe sempre essere a voi. E fate attenzione a se vi pongono buone domande a loro volta. Uno sviluppatore che si limita a eseguire ordini costruirà esattamente la cosa sbagliata, in modo molto efficiente. I bravi vi ribattono, indicano le lacune nel vostro ragionamento e trattano il brief come punto di partenza per una conversazione, non come una lista della spesa fissa.

Errore 5: Mettere a budget lo sviluppo, dimenticare il resto

Un'app non è un acquisto una tantum come una brochure stampata. È una cosa viva che va nutrita. I titolari mettono a budget abitualmente lo sviluppo e nient'altro, poi vengono colti di sorpresa dai costi che arrivano dopo: l'hosting, le commissioni degli store, la manutenzione per stare al passo con gli aggiornamenti del sistema operativo del telefono, e l'inevitabile serie di correzioni e piccoli miglioramenti una volta che le persone reali iniziano a usarla.

Una regola pratica sensata: qualunque sia il costo dello sviluppo, accantonate di nuovo una fetta consistente di quella cifra per il primo anno di esercizio. Il numero esatto varia, ma l'errore è universale — trattare il giorno del lancio come il traguardo quando in realtà è la linea di partenza. L'app che viene lanciata e poi abbandonata in silenzio perché non c'è budget per mantenerla è uno degli esiti più tristi e comuni di tutto questo campo, ed è del tutto evitabile con una pianificazione onesta a monte.

Errore 6: Progettare per voi stessi anziché per il vostro utente

Conoscete la vostra azienda da cima a fondo, il che vi rende il peggior giudice possibile su quanto sia facile da usare la vostra app. Le cose che per voi sono ovvie — il gergo, l'ordine in cui svolgete le attività, le scorciatoie che prendete senza pensarci — disorientano un utente alle prime armi. Un'app che ha perfettamente senso per il titolare e confonde tutti gli altri ha fallito, per quanto ingegnosa sia.

Il rimedio è economico e un po' umiliante: osservate persone reali mentre la usano prima di lanciare. Non il vostro team, che sa già come dovrebbe funzionare — clienti o dipendenti veri che non l'hanno mai vista. Consegnate loro l'app, date un compito e non dite nulla. Dove esitano, toccano la cosa sbagliata o sospirano, ecco il vostro riscontro di progettazione. Cinque persone bastano a far emergere i problemi peggiori. Saltare questo passaggio è il motivo per cui le app escono con un pulsante 'invia' che nessuno trova e un percorso di iscrizione che perde metà di chi ci prova.

• Date al tester un compito reale, non un giro guidato — 'prenota un appuntamento per martedì prossimo', poi restate in silenzio.
• Osservate le sue mani e il suo viso, non solo se alla fine ci riesce.
• Annotate ogni esitazione; una pausa è un problema di progettazione che dall'interno non potete vedere.
• Resistete all'impulso di spiegare — se dovete spiegarlo, avrebbe dovuto farlo l'app.
• Testate con cinque persone, correggete i fallimenti evidenti, poi testate di nuovo.

Errore 7: Costruire app native iOS e Android quando non serviva

C'è un riflesso: costruire un'app 'vera' per iPhone e Android dal primo giorno, completamente nativa, come fanno i grandi marchi. Per la maggior parte delle piccole imprese significa da due a tre volte il costo e la complessità per un beneficio che i vostri utenti non noteranno mai. Peggio ancora, ora mantenete per sempre due basi di codice separate, raddoppiando ogni futura correzione.

Spesso la prima mossa giusta non è affatto un'app nativa. Una web app ben costruita che funziona nel browser di qualsiasi telefono, o un approccio multipiattaforma che produce entrambe le versioni per gli store da un'unica base di codice, vi porta sul mercato più in fretta e a minor costo — e potete sempre passare al pieno nativo più avanti, se l'uso reale dimostra che ne vale la pena. La domanda non è mai 'nativo o web' in astratto. È: qual è la cosa più piccola ed economica che permette a utenti reali di svolgere il compito essenziale? Costruite quella, imparate da essa, poi spendete i soldi grossi con le prove invece che con le supposizioni.

Errore 8: Trattare il lancio come la fine del lavoro

L'ottavo errore è credere che il progetto sia finito quando l'app va online. Non lo è — è lì che inizia il vero progetto. Un'app senza un piano per arrivare nelle mani degli utenti, senza un modo per ascoltare cosa pensano e senza l'intenzione di migliorarla in base a ciò che imparate è un'app che svanisce nel giro di mesi. Lo sviluppo era la parte facile. L'adozione è la parte difficile, e quasi nessuno la pianifica.

Prima di lanciare, sappiate tre cose: come le persone scopriranno che l'app esiste, come misurerete se la stanno davvero usando, e come raccoglierete ciò che vi diranno, così che il prossimo giro di lavoro sia guidato dalla realtà invece che da congetture. Niente di tutto questo è costoso. È semplicemente una mentalità diversa — l'app non è una cosa che finite e abbandonate, è una relazione che mantenete. I titolari che lo capiscono ottengono app che diventano più utili nel tempo. Quelli che non lo capiscono ottengono un picco il giorno del lancio e un lungo, silenzioso declino.

Come evitare tutti e otto in una volta

Letti insieme, questi errori condividono un'unica radice: muoversi in fretta sulle supposizioni invece che lentamente sulle prove. Ognuno di essi è un punto in cui è sembrato più economico saltare il passaggio attento. E ognuno di essi è molto più economico da gestire prima dello sviluppo che dopo. Ecco la sequenza che schiva in silenzio tutti e otto.

1. 1
   Provate la domanda prima di costruire

   Un prototipo, una landing page o una versione manuale. Procuratevi prove concrete che qualcuno la vuole prima di impegnare il budget.
2. 2
   Scrivete il brief e la lista versione due

   Poche pagine chiare che chiunque possa capire, più un parcheggio per ogni idea 'già che ci siamo' affinché non faccia deragliare la v1.
3. 3
   Scegliete lo sviluppatore in base ai risultati, non al prezzo

   Lavori rilasciati, telefonate alle referenze, chiara proprietà di codice e account, e qualcuno che vi pone buone domande a sua volta.
4. 4
   Mettete a budget tutto il primo anno, non solo lo sviluppo

   Hosting, manutenzione, correzioni e supporto. Il giorno del lancio è la linea di partenza, quindi finanziate l'esercizio della cosa.
5. 5
   Scegliete la piattaforma più piccola che svolge il compito

   Web o multipiattaforma per prima nella maggior parte dei casi. Passate al pieno nativo più avanti, con le prove, solo se l'uso lo richiede.
6. 6
   Testate con utenti reali, poi pianificate il lancio

   Osservate cinque sconosciuti mentre la usano, correggete i fallimenti evidenti e decidete a monte come le persone la troveranno e come misurerete l'uso.

Domande frequenti