Analisi di fattibilità tecnica

La fattibilità tecnica di un progetto non è la risposta alla domanda «si può fare?». Perché nel software moderno quasi tutto «si può fare», con abbastanza tempo, abbastanza budget e abbastanza ingegneri. La vera domanda non è questa. La vera domanda è: «è compatibile con il suo budget, il suo calendario e gli obiettivi del suo cliente?». La nostra analisi di fattibilità cerca la risposta a questa domanda. Quale integrazione di terze parti ha un costo superiore alla sua stima di traffico mensile; quale normativa limita la sua progettazione dei dati; per quale funzionalità la tecnologia in uso non basta; quale obiettivo di performance è matematicamente impossibile: lo elenchiamo in anticipo. Questo elenco non serve a dirle «il suo progetto non si farà»; al contrario, serve a dirle «con queste piccole revisioni il suo progetto diventa possibile e sostenibile». Trasformare un altro sogno in realtà passa da un'accurata analisi di tre settimane all'inizio.

Quando prendiamo in carico un progetto per l'analisi di fattibilità, il nostro team cerca risposte scritte a cinque domande indipendenti: (1) Da quali servizi di terze parti dipenderà, e quali sono i loro limiti e costi giornalieri/mensili? (2) Quali normative influenzano la progettazione dei dati e il periodo di conservazione? (3) Come si presenta la curva del numero stimato di utenti e del costo dei server: primo mese, primo anno, quinto anno? (4) Quale stack tecnologico è compatibile con l'architettura esistente e resta sostenibile? (5) Quante specializzazioni parallele servono per garantire la data di consegna attesa dal cliente? Quando le risposte a queste cinque domande si riuniscono, emerge il profilo reale del progetto: tutta la differenza tra «perfetto sulla carta» e «collaudato sul campo». Le pagine con le risposte vengono consegnate come allegato al contratto; se in seguito nasce una controversia, leggiamo insieme nello stesso documento perché una cosa è com'è.

Non tutti i progetti sono realizzabili nella forma in cui si presentano all'inizio. Ma ogni progetto ha una versione realizzabile. Il nostro studio di fattibilità non si limita a dire «sì/no»: spesso traccia anche una roadmap alternativa a cui possiamo dire «sì, se diventa così». L'approccio MVP significa rilasciare prima la versione minima che soddisfa l'esigenza reale del cliente e offre un valore concreto all'utente. Le funzionalità successive si pianificano su una mappa visibile; oltre al vantaggio di velocità, il feedback degli utenti reali permette di ridisegnare il resto del percorso. Nell'approccio per fasi dividiamo il progetto in 3-4 tappe. Alla fine di ogni fase il cliente vede qualcosa online, una parte del pagamento si chiude e l'ambito della fase successiva viene ricalcolato con i dati più aggiornati. Il rischio diminuisce, la soddisfazione del cliente cresce, il team di sviluppo non si sente sotto pressione. Il cambio di tecnologia è talvolta l'unica strada che evita di raddoppiare il budget del progetto. Cross-platform invece di un'app mobile nativa; integrazione su un SaaS leader di mercato invece di un CRM su misura; sistemi più semplici basati su regole dove AI/ML non sono necessari. Calcoliamo il rapporto costo/valore di ciascuna opzione e glielo presentiamo: la decisione è sempre sua.

La «Roadmap tecnica» che riceve al termine delle tre settimane di fattibilità è ciò che chiamiamo «la costituzione del progetto». Questo documento è l'unico punto di riferimento a cui ogni team tornerà, dall'avvio del progetto alla consegna. Il documento è essenziale ma completo: diagrammi architetturali, schemi del database, elenco delle integrazioni di terze parti, tabella dei costi dei server, analisi di conformità legale, calendario di consegna con Buffer, registro dei rischi e alternative. Tutto in un unico PDF, in un linguaggio leggibile dagli avvocati sia della sua agenzia sia del suo cliente. Quando in seguito nasce una controversia sul progetto — «questa funzionalità era prevista?», «perché questo costo è così?», «come è stata fissata questa scadenza?» — guardiamo questo documento. Non verbale ma scritto; non stimato ma calcolato; non unilaterale ma firmato. Ecco che cos'è la costituzione di un progetto.