Come progettare un software prima di scrivere codice

Descrivi cosa succede oggi, chi soffre, quanto costa l’errore o il ritardo. Se non riesci a dirlo in una pagina, non sei pronto a stimare lo sviluppo.

Un prodotto con troppi utenti primari diventa confuso. Scegline uno per l’MVP.

In PreventivoRapido l’utente primario è chi deve chiudere un preventivo sul campo. In AndroMetrics è chi traccia e legge insight sul proprio percorso — non “tutti gli stakeholder sanitari” al day one.

Disegna i passi: trigger → azione → risultato → eccezione. Solo dopo arriva l’UI. Le schermate senza flussi sono decorazioni.

Prima di scrivere SwiftUI per AndroMetrics abbiamo congelato i flussi di tracking, consenso e report — non la palette.

Alternative: aprire Xcode subito “per vedere qualcosa”. L’abbiamo scartata più di una volta: senza flussi, ogni schermata diventa negoziabile all’infinito e il debito cresce prima del primo commit utile.

Privacy, App Store, integrazioni, migrazione dati, adozione dello staff: elencali presto. Sono i posti dove i progetti muoiono in silenzio.

Scrivi cosa resta fuori. Se “fuori” è vuoto, non hai un MVP: hai un desiderio. Poi sì, apri Xcode o l’editor.

Nella fase pre-codice:

Prima di stimare giorni di sviluppo, chiediti: qual è l’unica azione che, se fallisce, rende inutile l’intera app? Progetta quella per prima. Tutto il resto è negoziabile.