Le vere tempistiche dello sviluppo di un'app: dall'idea al lancio

Se chiede a dieci agenzie quanto serve per sviluppare un'app, riceverà dieci risposte sicure e nemmeno una sarà vera. La risposta onesta è che il primo giorno nessuno può dirglielo con precisione, ma chiunque abbia davvero rilasciato software può descriverle la forma del percorso: quali fasi esistono, quali divorano in silenzio il calendario e dove le Sue decisioni accelerano le cose o le bloccano del tutto. È proprio questa forma, scritta nero su bianco.

Ho visto molti titolari di piccole imprese affrontare un progetto di app aspettandosi una marcia ordinata e lineare, dallo schizzo all'App Store. Ciò che ottengono, invece, somiglia più a una serie di plateau e salti improvvisi. Settimane in cui sembra non accadere nulla, poi un giorno in cui all'improvviso tutto si incastra. Niente di tutto questo è segno che qualcosa non va. È semplicemente il modo in cui si fa il software, e una volta che riesce a dare un nome alle fasi, l'intero processo smette di essere una scatola nera in cui paga sperando che vada bene.

Fissiamo quindi aspettative realistiche. Per una prima versione mirata di un'app aziendale — non una piattaforma sterminata, ma una prima versione che fa bene una cosa sola — di solito si parla di un intervallo tra i tre e i cinque mesi, da un avvio serio a un lancio reale. Dove si collocherà entro questo intervallo dipende meno dalla tecnologia che dalla Sua chiarezza, dalla rapidità con cui decide e da quanto cerca di stipare prima del lancio. Vediamolo passo per passo.

Perché la stima che Le hanno dato è probabilmente sbagliata

Il dato delle sei settimane non è esattamente una bugia: è il tempo che serve per costruire la parte che tutti riescono a immaginare. Le schermate. I pulsanti. Ciò che si può mostrare in una demo. Quel numero ignora in silenzio tutto ciò che circonda l'app visibile: le decisioni, i dati, le integrazioni con gli strumenti che già usa, i test, la revisione dello store, l'inevitabile giro di «ma a proposito, potrebbe fare anche questo?»

Un modo utile di vederla: il codice è raramente il collo di bottiglia. Il collo di bottiglia è la chiarezza. Ogni ora in cui il Suo sviluppatore aspetta una decisione — quale gestore dei pagamenti, cosa succede quando una prenotazione viene annullata, chi può vedere cosa — è un'ora di slittamento del calendario. I progetti che finiscono in fretta non sono quelli con i migliori ingegneri. Sono quelli in cui la titolare risponde alle domande in un giorno invece che in due settimane.

Mentre legge le fasi qui sotto, faccia quindi attenzione ai momenti in cui la palla è nel Suo campo. Sono i punti in cui un progetto mantiene lo slancio oppure si arena in silenzio per tre settimane perché un'e-mail è rimasta senza risposta. La tempistica è una responsabilità condivisa, e la metà che spetta al cliente è quella che si tende a sottovalutare.

Fase 1: Analisi e definizione dell'ambito (1–3 settimane)

Prima che qualcuno disegni una sola schermata, c'è una fase che non sembra avanzamento ma determina tutto: capire cosa sta davvero costruendo e, ancora più importante, cosa non sta costruendo. È qui che un'idea vaga («un'app per i miei clienti») diventa un elenco concreto e completabile di funzioni per la versione uno.

Fatta bene, l'analisi è soprattutto conversazione e domande scomode. Chi la usa, e su quale dispositivo? Qual è l'unica cosa che deve fare in modo eccellente? Cosa può aspettare la versione due? Un buon partner qui obietterà, ed è ciò che vuole: ogni funzione che taglia ora sono settimane che riguadagna. Il risultato è di solito un breve ambito scritto e un wireframe grezzo, qualcosa che può tenere in mano e di cui può dire sì, è proprio questo.

Fase 2: Design e prototipo (2–4 settimane)

Ora l'app diventa qualcosa che può vedere e toccare, prima che una sola riga di codice reale La vincoli a qualcosa. I designer trasformano il wireframe in vere schermate — i colori, il flusso, la sensazione reale d'uso — di solito sotto forma di prototipo interattivo che può scorrere con le dita sul Suo telefono.

Questa fase vale oro per un motivo: cambiare un design costa poco, cambiare software già costruito costa caro. Spostare un pulsante in un prototipo richiede cinque minuti. Spostarlo dopo che la funzione è stata sviluppata, testata e collegata ai Suoi dati può richiedere un giorno. È quindi il momento di essere esigente, di mostrarlo a qualche cliente o collaboratore reale e di intercettare i problemi del tipo «ah, questo non lo capirà nessuno» finché sono ancora indolori da correggere.

Il modo più comune in cui questa fase si dilata non è il designer, ma l'indecisione dalla Sua parte. Giri infiniti di piccole modifiche, o tre persone con potere di veto che non si accordano mai. Decida presto chi approva, dia il feedback a blocchi anziché alla spicciolata, e questa fase resta serrata.

Fase 3: Sviluppo (6–12 settimane)

È la parte che tutti immaginano pensando a «fare un'app», ed è il tratto continuo più lungo — ma raramente il più imprevedibile, se le prime due fasi sono state fatte come si deve. Gli sviluppatori costruiscono l'app a blocchi, di solito in cicli brevi in cui vede pezzi funzionanti ogni una o due settimane, anziché sparire per tre mesi e ricomparire con un prodotto finito.

Quel ritmo conta. Vuole reagire presto a software reale e funzionante, non a un rapporto sullo stato. Quando potrà usare davvero il flusso di prenotazione alla quarta settimana, noterà cose che nessuna specifica avrebbe potuto cogliere, e correggerle alla quarta settimana costa molto meno che alla decima. Un buon processo di sviluppo rende l'app costantemente visibile per Lei, non solo alla fine.

Cosa allunga in silenzio lo sviluppo

Due cose dilatano uno sviluppo più di ogni altra. La prima sono le integrazioni: ogni sistema esterno con cui l'app deve dialogare (il Suo gestore dei pagamenti, il Suo strumento di prenotazione esistente, il Suo gestionale di contabilità, un servizio di consegna) aggiunge lavoro, e ciascuno può riservare le proprie sorprese. La seconda è il scope creep: il gocciolio costante di piccole aggiunte, ognuna apparentemente minima ma che insieme spostano il lancio in avanti di un mese. Entrambe sono gestibili, ma solo se le vede arrivare.

• Ogni integrazione esterna aggiunge giorni, a volte settimane: la preventivi esplicitamente, non dia per scontato che sia gratis.
• «Solo un'altra piccola funzione» è di gran lunga la causa più comune di una data di lancio mancata.
• I dati reali sono più disordinati di quelli di test; preveda tempo per i casi limite che il Suo foglio di calcolo tollerava in silenzio.
• Account utente, pagamenti e notifiche sono ingannevolmente profondi: costano sempre più di quanto sembri.
• Approvazioni e contenuti che deve al team (loghi, testi, note legali) possono bloccare uno sviluppo tanto sicuramente quanto un bug.

Fase 4: Test e correzioni (2–4 settimane)

Ecco una fase di cui ci si dimentica l'esistenza, salvo poi mal sopportarla quando si presenta. Una volta costruita l'app, va messa alla prova: su telefoni diversi, con cattiva connessione, da persone che non l'hanno costruita e che faranno cose che nessuno aveva previsto. Testare non è una formalità. È la differenza tra un'app di cui i Suoi clienti si fidano e una che disinstallano dopo il primo crash.

Si aspetti che qui emerga un elenco di bug e spigolature. Non è segno che lo sviluppo sia andato male; è l'intero scopo della fase. Alcuni sono correzioni rapide, altri rivelano una decisione da riconsiderare. I team che gestiscono bene questo lo trattano come una parte normale e pianificata del lavoro — non come un'emergenza, né come qualcosa da saltare perché il lancio incombe. Saltare i test non fa risparmiare tempo. Sposta soltanto i bug dal Suo telefono di prova ai telefoni dei Suoi clienti, dove costano dieci volte di più da correggere.

Fase 5: Lancio e l'attesa dello store (1–2 settimane, più la revisione)

Il lancio è meno un singolo momento e più un rilascio accurato. Se è un'app web, controlla del tutto la tempistica: aziona l'interruttore quando è pronto. Se va sull'App Store di Apple o su Google Play, cede loro una parte del calendario: il loro processo di revisione può richiedere da un giorno a oltre una settimana, e ogni tanto Le rimandano indietro l'app con qualcosa da correggere. Vale la pena saperlo in anticipo, così non coglie di sorpresa una data di lancio promessa ai clienti.

Il modo intelligente di lanciare non è una rivelazione in pompa magna a tutta la Sua base clienti. È prima un rilascio discreto a un piccolo gruppo — una manciata di clienti ben disposti o il Suo stesso personale — così da intercettare i problemi del mondo reale prima che li vedano tutti. Poi allarga la porta. Un lancio che sembra noiosamente privo di intoppi è un lancio andato bene.

1. 1
   Soft-launch a un piccolo gruppo

   Rilasci prima a una manciata di utenti ben disposti o di collaboratori. L'uso reale trova ciò che i test hanno mancato, con la posta in gioco al minimo.
2. 2
   Invii presto se va sugli store

   Apple e Google controllano l'orologio della revisione, non Lei. Invii con un margine, così una revisione lenta o un rifiuto non fanno saltare la data promessa.
3. 3
   Tenga d'occhio da vicino la prima settimana

   Tenga qualcuno a disposizione per reagire in fretta. La prima settimana fa emergere i casi limite reali che nessun ambiente di test riproduce.
4. 4
   Pianifichi il lavoro del giorno dopo prima di lanciare

   Un'app non è mai 'finita' al lancio. Concordi in anticipo chi si occupa delle inevitabili piccole correzioni e del primo giro di feedback.

Mettere insieme l'intera tempistica

Impilate una dopo l'altra, queste fasi danno un quadro realistico. Nessuna è esotica; ciò che fa inciampare le persone è dimenticare che quelle poco appariscenti — analisi, test, attesa dello store — sono tempo reale sul calendario, non errori di arrotondamento. Ecco più o meno come una prima versione mirata tende a distribuirsi nei mesi.

Faccia la somma e capisce perché tre-cinque mesi è l'intervallo onesto per una vera prima versione, e perché chi promette sei settimane sta in silenzio ridefinendo cosa significhi «un'app». Non è pessimismo: è la differenza tra una data che rispetterà davvero e una per cui passerà l'intero progetto a scusarsi.

Come accelerare davvero (e come no)

Può andare più veloce, ma le leve vere non sono quelle a cui si pensa di solito. Buttare più sviluppatori su un progetto definito a metà di solito lo rende più lento, non più rapido. Gli acceleratori onesti sono poco appariscenti: decida cosa lasciar fuori, risponda in fretta alle domande e resista alla tentazione di aggiungere cose a metà sviluppo.

Quello di gran lunga più importante è un ambito spietato. Più la Sua prima versione è piccola e chiara, prima si lancia, e un'app lanciata che si ripaga Le insegna in due settimane più di altri due mesi di pianificazione. Aggiungere lo può sempre. Non può recuperare i mesi spesi a costruire funzioni che alla fine nessuno voleva.

C'è una verità collegata che vale la pena dire ad alta voce: non tutto ha bisogno di essere un'app su misura. A volte il vero problema è una porzione di lavoro manuale che un'automazione potrebbe sbrigare in silenzio, senza alcuna app. Un buon partner Le dirà quando è questo il caso, invece di venderle lo sviluppo più grande, perché l'app più economica è quella che non ha avuto bisogno di fare.

Domande frequenti