Quanto Tempo Ci Vuole per Sviluppare un'App? [Tempistiche Reali per Tipo di Progetto]

C'è una domanda che riceviamo in quasi ogni prima conversazione con un nuovo cliente: "Quanto tempo ci vorrà?" È una domanda legittima. I budget dipendono dalla risposta. Le decisioni del consiglio di amministrazione si basano su di essa. Le date di lancio vengono annunciate in funzione di quella risposta.

La risposta onesta — quella che a volte delude le persone — è che le tempistiche dipendono da cosa si sta realizzando, da quanto chiaramente è definito il progetto, dalla velocità con cui vengono prese le decisioni e dal fatto che l'ambito rimanga stabile abbastanza a lungo da consentirci di completare il lavoro. Dire "sei mesi" a un cliente può essere assolutamente corretto. Dire la stessa cosa al cliente successivo con un brief vago e obiettivi che cambiano in corso d'opera significa prepararsi a un disastro.

Abbiamo scritto questa guida perché riteniamo che Lei meriti dati concreti, non risposte evasive. Le forniremo intervalli temporali effettivi per tipo di progetto, illustreremo le fasi dello sviluppo e la durata reale di ognuna, spiegheremo i fattori specifici che fanno saltare le tempistiche (e quelli che le accelerano), e Le diremo onestamente cosa succede quando una scadenza fissa si scontra con un brief poco definito. Al termine, dovrebbe avere un'idea molto più chiara di quanto tempo richiederà il Suo progetto — e di cosa può fare per ridurre al minimo quella stima.

---

Tempistiche di Sviluppo per Tipo di Progetto

Ogni progetto è diverso, ma la maggior parte rientra in categorie riconoscibili. La tabella seguente riflette le tempistiche che osserviamo nella pratica — non i casi migliori ottimistici né quelli peggiori catastrofici, ma l'intervallo realistico quando un progetto è ragionevolmente ben definito e gestito da un team esperto. Ogni intervallo presuppone un team di delivery completo (product manager, designer, almeno due sviluppatori, un QA engineer) che lavora in sprint focalizzati.

Tipo di Progetto	Tempistiche Tipiche	Cosa Include	Presupposti Chiave
App web semplice / strumento interno	6 – 12 settimane	Interfacce CRUD, autenticazione utenti, dashboard di base, fino a 2–3 integrazioni	Requisiti ben definiti, nessuna logica di business complessa, nessuna app mobile
MVP SaaS	12 – 20 settimane	Architettura multi-tenant, abbonamenti/fatturazione, set di funzionalità core, pannello di amministrazione, flusso di onboarding	Set di funzionalità concordato in anticipo, una sola piattaforma (web), nessuna integrazione con sistemi legacy
MVP app mobile	16 – 24 settimane	iOS o Android (o entrambi), schermate principali, notifiche push, API backend, sottomissione all'app store	Nativo o cross-platform, nessuna sincronizzazione in tempo reale, backend sviluppato da zero o ben documentato
Piattaforma marketplace	20 – 32 settimane	Flussi per acquirenti e venditori, pagamenti e accrediti, annunci, recensioni, strumenti di moderazione	Modello utente a due lati, integrazione dei pagamenti, nessuna complessità normativa
Piattaforma enterprise	6 – 18 mesi	Workflow personalizzati, integrazione ERP/CRM, accesso basato su ruoli, requisiti di conformità, reportistica	Ampio gruppo di stakeholder, rilascio a fasi, sistemi esistenti da integrare

Vale la pena approfondire alcuni aspetti. Gli intervalli sono più ampi per i progetti più complessi non perché si voglia essere evasivi, ma perché la complessità e i fattori organizzativi generano davvero una grande varianza. Un marketplace sviluppato per un cliente che ha già affrontato questo tipo di progetto, con un brief di prodotto dettagliato e in grado di prendere decisioni di design in 24 ore, raggiungerà il lancio più rapidamente rispetto a uno sviluppato per un imprenditore alla prima esperienza che ancora definisce il prodotto mentre il team lo costruisce. Entrambe sono situazioni legittime. Producono semplicemente tempistiche diverse.

La riga relativa all'enterprise è volutamente ampia — da 6 a 18 mesi — perché i progetti enterprise sono quelli in cui l'ambito, la complessità delle integrazioni e la velocità decisionale istituzionale variano in modo più drammatico. Abbiamo consegnato strumenti enterprise in cinque mesi. Abbiamo anche visto team ben dotati impiegare due anni su piattaforme di complessità tecnica comparabile, perché procurement, approvazione della conformità e allineamento degli stakeholder hanno aggiunto mese dopo mese al calendario.

---

Le 5 Fasi dello Sviluppo Software e la Loro Durata

È utile capire cosa accade concretamente all'interno di quelle tempistiche — perché lo "sviluppo" non è una cosa sola. È una sequenza di fasi, ognuna con i propri output, dipendenze e modalità di fallimento.

Fase 1: Discovery — Da 2 a 4 Settimane

La discovery è la fase che la maggior parte dei clienti vorrebbe saltare e che molte agenzie eseguono male. Se eseguita correttamente, è l'investimento con il massimo rendimento dell'intero progetto.

Durante la discovery cerchiamo di rispondere a tre domande: Quale problema stiamo realmente risolvendo? Come si misura il successo? E quali sono i rischi per cui dobbiamo pianificare? Conduciamo workshop strutturati con gli stakeholder, mappiamo i flussi di lavoro esistenti, analizziamo i sistemi che devono integrarsi e produciamo un documento dei requisiti di prodotto che diventa il punto di riferimento assoluto per tutto ciò che segue.

Due settimane sono realistiche per uno strumento interno o un MVP ben definito. Quattro settimane sono appropriate per qualsiasi progetto con più gruppi di stakeholder, integrazioni legacy o requisiti normativi. La discovery non può essere compressa ulteriormente in modo sicuro — quello che si perde è la precisione che rende tutto il lavoro successivo più rapido.

Fase 2: Design — Da 2 a 4 Settimane

Il design si svolge in gran parte in sequenza con la discovery, sebbene in pratica le due fasi si sovrappongano. Produciamo architettura informativa, wireframe e design UI ad alta fedeltà che il team di sviluppo realizza esattamente come indicato — non "interpreta liberamente".

La velocità di questa fase dipende quasi interamente dalla rapidità con cui le decisioni di design vengono approvate. Un unico stakeholder del cliente che può dire sì o no a un design entro un giorno significa che due settimane di lavoro di design rimangono due settimane. Un comitato di cinque persone con opinioni contrastanti sui colori dei pulsanti significa che due settimane di lavoro di design diventano cinque.

Utilizziamo un design basato su componenti in Figma, il che significa che il design system creato in questa fase continua a dare i suoi frutti durante tutto lo sviluppo e rende il lavoro sulle funzionalità future significativamente meno costoso.

Fase 3: Sviluppo — Da 4 a 24 Settimane (Varia in Base al Tipo di Progetto)

Questa è la fase più lunga e variabile. Gli sviluppatori stanno costruendo il prodotto vero e proprio, il che significa API backend, architettura del database, interfacce frontend, integrazioni con servizi di terze parti e l'infrastruttura su cui gira il tutto.

Lavoriamo in sprint di due settimane, rilasciando software funzionale e testabile alla fine di ogni sprint piuttosto che un unico grande rilascio alla fine. Questo è importante perché significa che si vede un progresso reale, non solo aggiornamenti di stato. Significa anche che i cambiamenti di ambito — e ce ne sono quasi sempre — possono essere gestiti deliberatamente piuttosto che assorbiti invisibilmente finché non diventano una crisi.

I tempi di sviluppo sono quelli in cui risiedono principalmente gli intervalli per tipo di progetto della nostra prima tabella. Uno strumento interno semplice potrebbe richiedere quattro settimane di sviluppo attivo. Una piattaforma marketplace potrebbe richiederne diciotto.

Fase 4: Testing — Si Svolge in Parallelo allo Sviluppo

Il testing non è una fase che avviene dopo il completamento dello sviluppo. È un'attività continua che si svolge in parallelo durante tutto il processo di costruzione. I nostri QA engineer scrivono i casi di test a partire dal documento dei requisiti, li eseguono sugli output di ogni sprint e reinseriscono i bug nel ciclo di sviluppo prima che si accumulino.

Il testing end-to-end dedicato prima del lancio richiede tipicamente da una a due settimane aggiuntive rispetto al QA sprint-per-sprint. Questo è non negoziabile. Il costo di un bug in produzione — in termini di fiducia degli utenti, di tempo di sviluppo di emergenza, di reputazione — è di ordini di grandezza superiore al costo di individuarlo durante il testing.

Fase 5: Deploy e Lancio — Da 1 a 2 Settimane

Il deploy di una moderna applicazione web non è semplicemente premere un pulsante. Comporta la configurazione dell'infrastruttura di produzione, la configurazione del monitoraggio e degli avvisi, l'esecuzione dei controlli di sicurezza finali, il popolamento dei dati di produzione ove necessario e l'esecuzione di una sequenza di lancio che renda la transizione dallo staging al live il più trasparente possibile per gli utenti.

Per le app mobile, aggiungere a questo il tempo di revisione dell'app store. La revisione dell'App Store di Apple richiede attualmente da due a sette giorni per le sottomissioni standard, anche se può richiedere più tempo per le app in determinate categorie. Google Play di solito effettua la revisione entro uno o tre giorni, anche se i nuovi account sviluppatore possono richiedere più tempo.

---

Cosa Fa Durare i Progetti Più del Previsto

Ogni progetto che supera le tempistiche previste lo fa per una ragione. Nella nostra esperienza, le cause si raggruppano in cinque categorie — e sono per lo più prevedibili in anticipo se si sa cosa cercare.

Requisiti Vaghi o Incompleti

La causa più comune di sforamento delle tempistiche è iniziare a costruire prima che qualcuno abbia chiaramente definito cosa si sta costruendo. Quando i requisiti sono vaghi, gli sviluppatori fanno delle ipotesi. Quelle ipotesi vengono riviste durante le sessioni di test o di demo e si rivelano errate. Il lavoro viene rifatto. Questo ciclo si ripete su ogni funzionalità scarsamente definita fino a consumare settimane.

La soluzione è una discovery adeguata. All'inizio sembra un sovraccarico. Ripaga molte volte.

Lentezza nelle Decisioni da Parte del Cliente

I team di sviluppo hanno un ritmo. Quando quel ritmo si scontra con una decisione che non può essere presa senza l'input del cliente — un'approvazione del design, una revisione dei testi, una questione di policy su come vengono segmentati gli utenti — e quella decisione impiega cinque giorni per tornare invece di uno, l'intero sprint si adatta. Moltiplicato per dieci decisioni nell'arco di un progetto, si aggiungono da due a quattro settimane alle tempistiche senza che una singola riga di codice sia sbagliata.

Questa non è una critica ai clienti. I fondatori e i responsabili operativi occupati hanno altri lavori. Ma è un resoconto onesto di dove va il tempo.

Complessità delle Integrazioni

L'integrazione con sistemi di terze parti è quasi sempre più difficile di quanto sembri dall'esterno. Le API scarsamente documentate, che si comportano diversamente in ambiente sandbox rispetto all'ambiente di produzione, che applicano rate limiting in modo inaspettato o che restituiscono strutture dati inconsistenti aggiungono tutte tempo allo sviluppo. I sistemi legacy — ERP, vecchi CRM, database personalizzati — spesso non hanno alcuna API formale, richiedendo middleware personalizzato o livelli di trasformazione.

Valutiamo il rischio di integrazione durante la discovery. Ma una parte di esso emerge solo quando uno sviluppatore si connette effettivamente al sistema e inizia a inviare richieste reali.

Cambiamenti di Ambito a Metà Sviluppo

"Possiamo semplicemente aggiungere..." è la frase più costosa nello sviluppo software. Non perché le singole modifiche siano sempre grandi, ma perché si accumulano. Una funzionalità aggiunta alla sesta settimana potrebbe richiedere di ripensare il modello di dati che era stato finalizzato alla seconda settimana. Un nuovo tipo di utente aggiunto alla decima settimana potrebbe rompere le ipotesi incorporate in ogni schermata dell'applicazione.

I cambiamenti di ambito non sono intrinsecamente negativi — i requisiti evolvono, i mercati cambiano, si impara. Ma devono essere gestiti attraverso un processo formale di gestione dei cambiamenti che tenga conto del loro impatto effettivo sulle tempistiche e sui costi. Quando vengono assorbiti informalmente, le tempistiche si allungano invisibilmente e poi all'improvviso.

Vincoli Tecnici Non Rilevati

Alcuni vincoli emergono solo quando si inizia a costruire: un browser mobile che gestisce un'interazione UI in modo diverso da come è stato testato, una query del database che funziona bene con i dati di test ma degrada sotto il carico di produzione, un requisito di sicurezza che l'API del partner di integrazione non può soddisfare senza una soluzione personalizzata. Questi non sono fallimenti nella pianificazione — sono l'incertezza intrinseca della costruzione di software complesso. I team esperti li individuano presto attraverso spike e prototipi. I team meno esperti li scoprono alla quattordicesima settimana.

---

Cosa Accelera Davvero un Progetto

I fattori che accelerano un progetto sono il riflesso speculare di quelli che lo rallentano — ma vale la pena enunciarli esplicitamente perché sono azionabili.

• Requisiti chiari e scritti prima dell'inizio dello sviluppo. Non un deck di slide. Un documento dei requisiti con user story, criteri di accettazione e wireframe annotati che tutti hanno approvato. Questo elimina la principale fonte di rework.
• Un product owner dedicato lato cliente. Una persona con l'autorità di prendere decisioni di prodotto, disponibile quotidianamente, in grado di rispondere alle domande in ore piuttosto che in giorni. Nella nostra esperienza, questo singolo fattore ha un impatto sul ritmo del progetto maggiore di quasi qualsiasi altra cosa.
• Librerie di componenti e design system pre-costruiti. Manteniamo librerie di componenti frontend riutilizzabili e moduli backend che significano che gli elementi comuni — autenticazione, permessi basati su ruoli, sistemi di notifica, flussi di pagamento — non devono essere progettati da zero su ogni progetto.
• Rilascio a fasi e ambito MVP definito. Concordare in anticipo cosa contiene la prima versione rilasciabile — e mantenere tutto il resto in un backlog futuro — previene il scope creep che blocca la maggior parte dei progetti. Si ottiene qualcosa nelle mani degli utenti più rapidamente, il che genera feedback reali che migliorano le fasi successive.
• Un team esperto e orientato al livello senior. Gli ingegneri senior prendono le decisioni architetturali correttamente al primo tentativo. Identificano i rischi prima che si materializzino. Scrivono codice più facile da testare ed estendere. Il costo giornaliero è più elevato. Il costo totale del progetto è abitualmente inferiore perché non generano il rework che producono i team con prevalenza di figure junior.

---

Confronto delle Tempistiche: Agenzia vs Freelancer vs Team Interno

Una delle decisioni che influenza le tempistiche tanto quanto qualsiasi fattore tecnico è chi realizza il prodotto.

Tipo di Ingaggio	Tempo Tipico per Iniziare	Velocità di Sviluppo	Punti di Forza Tipici	Rischi Tipici
Agenzia Software	2 – 4 settimane (onboarding)	Veloce una volta avviata — team completo disponibile	Stack di competenze completo, delivery gestita, responsabilità	Tariffa giornaliera più alta, può gestire più clienti contemporaneamente
Freelancer / Sviluppatore Singolo	1 – 2 settimane	Più lento — una persona, un compito alla volta	Costo inferiore, comunicazione diretta	Punto unico di fallimento, capacità limitata, lacune nelle competenze non-dev
Team Interno	3 – 6 mesi (assunzioni)	Più veloce una volta costituito, più lento da assemblare	Profonda conoscenza del prodotto, piena disponibilità	Alto costo fisso, difficile da scalare, le assunzioni richiedono tempo

Per la maggior parte delle aziende che stanno costruendo un primo prodotto o una nuova piattaforma, un'agenzia è il percorso più rapido verso un'applicazione funzionante. La ragione è semplice: il team esiste già. Non è necessario assumere separatamente un designer, uno sviluppatore backend, uno sviluppatore frontend e un QA engineer — sono già al lavoro insieme, con processi consolidati, dal primo giorno dell'ingaggio.

I freelancer possono funzionare bene per progetti piccoli e ben definiti in cui è necessaria una singola disciplina. Un singolo sviluppatore non può però essere contemporaneamente product manager, designer, ingegnere full-stack e QA engineer — e la maggior parte delle applicazioni serie ha bisogno di tutto questo.

I team interni hanno senso una volta che si è lanciato un prodotto, si hanno esigenze di sviluppo continuative e si può giustificare il costo fisso. Costruire un nuovo prodotto con un team interno che non è ancora stato assunto è un rischio di tempistiche che la maggior parte delle aziende non può permettersi.

---

La Strategia MVP-First

Uno dei consigli più costanti che diamo ai clienti preoccupati per le tempistiche è questo: non cercare di costruire tutto in una volta.

La strategia MVP-first significa definire la versione più piccola della propria applicazione che fornisca valore reale a utenti reali — e costruire quella per prima. In genere questo richiede da 8 a 14 settimane a seconda del tipo di progetto. La visione completa potrebbe richiedere nove mesi per essere costruita. Consegnare qualcosa di utilizzabile in dodici settimane supera una costruzione completa di nove mesi per ragioni che vanno oltre la gestione dei tempi.

In primo luogo, si ottiene feedback reale dagli utenti prima di aver speso l'intero budget. La funzionalità che si pensava fosse la proposta di valore core potrebbe rivelarsi qualcosa che gli utenti usano a malapena. La cosa che si considerava secondaria potrebbe essere quella di cui chiedono in ogni conversazione di supporto. Saperlo alla quattordicesima settimana cambia la forma di ogni sprint successivo.

In secondo luogo, si riduce il rischio di costruire la cosa sbagliata. La maggior parte dei primi prodotti evolve significativamente tra il concetto iniziale e il product-market fit. Un MVP di dodici settimane che raggiunge gli utenti mette in una posizione di evolversi in modo intelligente. Una costruzione completa di nove mesi che raggiunge gli utenti mette nove mesi indietro rispetto a dove si sarebbe potuti essere — e richiede comunque la stessa evoluzione.

In terzo luogo, dimostra progressi agli stakeholder. Che gli stakeholder siano investitori, un consiglio di amministrazione, utenti interni o clienti paganti, qualcosa di reale a cui possono accedere ha un peso diverso rispetto a un diagramma di Gantt e un aggiornamento di stato. Costruisce fiducia, attrae feedback e crea slancio.

Strutturiamo quasi ogni nuovo progetto di prodotto attorno a un MVP-first. L'obiettivo è sempre portarLa a qualcosa di rilasciabile, poi iterare da lì con il vantaggio dei dati del mondo reale.

---

Scadenze Fisse e il Loro Costo

A volte la scadenza non è negoziabile. Una data di go-live normativa. Un annuncio a una conferenza. Una milestone contrattuale con un proprio cliente. Quando la data è fissa, le variabili che di solito assorbono la pressione — ambito, costo e qualità — devono essere gestite deliberatamente.

La realtà della gestione del progetto è catturata in quello che viene talvolta chiamato il triangolo di ferro: si può averlo veloce, economico o di qualità — e di solito se ne possono scegliere due. Quando la velocità è fissa, qualcos'altro deve cedere.

La compressione delle tempistiche attraverso risorse aggiuntive funziona fino a un certo punto. Aggiungere un secondo sviluppatore frontend a uno sviluppo limitato dal frontend può accorciare il calendario. Ma c'è un limite — aggiungere cinque sviluppatori a un progetto che ne ha uno non lo rende cinque volte più veloce. L'onboarding, il sovraccarico di coordinamento e le parti non parallelizzabili dello sviluppo software limitano i guadagni. C'è anche un costo: ogni sviluppatore senior aggiuntivo aggiunge un costo significativo alla tariffa giornaliera, e il tempo impiegato per integrare il loro lavoro aggiunge il suo proprio sovraccarico.

La compressione delle tempistiche attraverso la riduzione dell'ambito è la leva più affidabile. Se la scadenza è inamovibile, la conversazione che abbiamo con i clienti è sempre: cosa possiamo rimandare a un rilascio successivo senza compromettere il valore core del lancio? Questo richiede una prioritizzazione onesta, non ottimismo. Le funzionalità che sembrano essenziali in fase di pianificazione spesso si rivelano cose di cui gli utenti possono fare a meno per i primi mesi.

La compressione delle tempistiche accettando il debito di qualità è l'opzione di cui nessuno vuole parlare ma che molti progetti finiscono per adottare implicitamente. Ridurre il tempo di testing, saltare la code review, rilasciare senza una gestione adeguata degli errori — queste cose possono far risparmiare giorni nel breve termine e costare mesi nel lungo termine. Siamo trasparenti con i clienti quando vediamo questa pressione accumularsi, perché la decisione di accumulare debito tecnico dovrebbe essere presa consapevolmente, non scoperta in produzione.

---

Come Pianifichiamo le Tempistiche in Cyberbeak

Saremo diretti riguardo al nostro processo perché riteniamo che la trasparenza in questo ambito costruisca migliori relazioni di lavoro.

Ogni progetto inizia con una fase di discovery strutturata che produce un documento di ambito scritto, un feature backlog prioritizzato e una stima delle tempistiche suddivisa per sprint. Le tempistiche non sono una singola data scritta a matita su un'ipotesi ottimistica — sono un piano sprint-per-sprint con milestone, dipendenze contrassegnate esplicitamente e rischi identificati documentati insieme agli approcci di mitigazione.

Incorporiamo un buffer a livello di sprint — tipicamente dal dieci al quindici percento della capacità di ogni sprint — per assorbire le incognite che sono intrinseche allo sviluppo software senza far saltare il calendario complessivo. Non si tratta di imbottitura; è pianificazione onesta. I progetti che affermano di non avere margine stanno prendendo quel margine in prestito dalla fase di testing o dal lavoro di integrazione, e lo ripagano sempre con gli interessi.

Teniamo revisioni settimanali delle milestone con i clienti. Non sono riunioni di stato in cui leggiamo da un foglio di calcolo di avanzamento. Sono sessioni di lavoro in cui dimostriamo ciò che è stato costruito, esaminiamo ciò che sta arrivando, segnaliamo tutto ciò che si è discostato dal piano e prendiamo decisioni congiunte su come rispondere. Se una funzionalità richiede più tempo del previsto, lo diciamo nella riunione di quella settimana — non nell'ultima settimana prima della scadenza.

Utilizziamo un processo di gestione dei cambiamenti per qualsiasi aggiunta di ambito che emerge a metà progetto. Non è burocrazia fine a se stessa. È il modo in cui manteniamo oneste le tempistiche originali. Ogni richiesta di modifica riceve una valutazione dell'impatto documentata: quanti giorni aggiuntivi, qual è il costo, cosa sposta dal piano dello sprint corrente. Questo rende il trade-off visibile, e il cliente decide se accettarlo.

Infine, tracciamo il rischio tecnico in modo esplicito. Durante la discovery identifichiamo le integrazioni, le strutture dati e i casi limite che con maggiore probabilità genereranno sorprese. Pianifichiamo spike — esplorazioni brevi e limitate nel tempo — nelle fasi iniziali del progetto per validare le nostre ipotesi su quei rischi prima che diventino ipotesi portanti. Questo individua i vincoli non rilevati che affossano le tempistiche nei progetti che non li pianificano.

---

Domande Frequenti

È possibile consegnare più velocemente pagando di più?

Fino a un certo punto, sì — ma con limiti chiari. Un budget aggiuntivo può finanziare un team più grande, che può parallelizzare più lavoro e comprimere il calendario. Tuttavia, lo sviluppo software ha dipendenze sequenziali intrinseche: alcune cose non possono iniziare finché altre non sono terminate, indipendentemente da quanti sviluppatori siano disponibili. Aggiungere risorse aiuta maggiormente nelle build con vincoli frontend o backend dove c'è un lavoro genuinamente parallelizzabile. Oltre una certa dimensione del team, il personale aggiuntivo aggiunge sovraccarico di coordinamento più velocemente di quanto aggiunga output. Consiglieremo sempre onestamente se un investimento aggiuntivo può effettivamente spostare la data.

Cosa succede se si modificano i requisiti a metà progetto?

I requisiti cambieranno. Lo prevediamo, e il nostro processo lo gestisce. Il punto fondamentale è che i cambiamenti passano attraverso una valutazione formale dell'impatto prima di essere accettati nel piano dello sprint. Documentiamo cosa sia il cambiamento, quanti giorni aggiunge, qual è il suo costo e cosa sposta. Il cliente decide se accettarlo. I cambiamenti assorbiti informalmente — "è solo una piccola cosa" — sono il modo in cui i progetti perdono settimane senza che nessuno sappia esattamente dove sia andato il tempo.

Il testing aggiunge tempo?

Il testing viene eseguito in parallelo con lo sviluppo durante tutto il progetto, quindi non aggiunge tempo sopra lo sviluppo nel modo in cui le persone talvolta presumono. La fase di testing end-to-end prima del lancio — tipicamente da una a due settimane — è già inclusa nelle tempistiche fin dall'inizio. Saltare o comprimere il testing per rispettare una scadenza è una delle decisioni più costose che un progetto possa prendere. Il costo di un bug critico in produzione, in termini di fiducia degli utenti e tempo di ingegneria di emergenza, raramente vale ciò che è stato risparmiato sul calendario di testing.

Quanto tempo richiede l'approvazione dell'app store?

La revisione dell'App Store di Apple richiede attualmente da due a sette giorni lavorativi per la maggior parte delle app, anche se le app con determinate funzionalità sensibili o i nuovi account sviluppatore possono richiedere più tempo, e i rifiuti — che richiedono una nuova sottomissione — aggiungono ulteriore tempo. La revisione di Google Play richiede tipicamente da uno a tre giorni. Teniamo conto del tempo di revisione dell'app store nelle tempistiche dei nostri progetti mobile e sottomettiamo con un buffer sufficiente per gestire un rifiuto e una nuova sottomissione del ciclo standard senza spostare la data di lancio.

Cosa causa i maggiori ritardi nei progetti reali?

Nella nostra esperienza onesta: decisioni lente, non sviluppatori lenti. La causa più comune di un progetto che supera le tempistiche non è tecnica — è l'attesa di approvazioni del design, contenuti da parte dei clienti, accesso ai sistemi, conferma di regole di business che si rivelano non concordate internamente, o un cambiamento di direzione strategica che richiede di ripensare il lavoro già costruito. La seconda causa più comune sono i requisiti che erano più vaghi di quanto sembrassero in fase di pianificazione. Entrambe sono in larga misura prevenibili con il giusto investimento iniziale nella discovery e il giusto impegno di disponibilità da parte del cliente durante tutto il progetto.

---

Se si sta cercando di pianificare le tempistiche di un progetto e si desidera qualcosa di più specifico di una tabella di intervalli, la cosa più utile che possiamo fare è discutere di ciò che si sta costruendo. Offriamo una chiamata di scoping gratuita di un'ora in cui Le porremo le domande che trasformano tempistiche vaghe in tempistiche realistiche — e Le forniremo una visione onesta di quanto probabilmente richiederà il Suo progetto e perché.

Contatti il nostro team e penseremo noi al resto.