Web, mobile, AI, SaaS, cloud e lavoro di prodotto

Le fasi si sovrappongono di proposito. Il design parte appena è chiara la prima fetta. Il build non aspetta un file perfetto. Lo scale è già in mente mentre rilasciamo la prima versione — semplicemente non lo sovradimensioniamo il primo giorno.

1. 01

   Discover

   Scriviamo il lavoro prima che qualcuno apra un editor.

   Le prime conversazioni riguardano il prodotto, non uno stack. Per chi è, cosa esiste già, cosa non deve rompersi, e come sarebbe davvero «finito». Se il brief è disordinato, è normale — chiediamo finché è abbastanza specifico da costruirci sopra.

   Ricevete una forma scritta del lavoro: cosa è dentro, cosa è fuori, una prima fetta, i rischi e un modo di lavorare. Potete prenderla o lasciarla. Preferiamo fermarci qui piuttosto che avviare un build in cui nessuno crede.

   Con cosa uscite

   • Uno scope scritto breve e criteri di successo
   • Cosa è dentro, cosa è fuori, e cosa può aspettare
   • Una prima fetta che potreste rilasciare e da cui imparare
   • Come parleremo, faremo demo e decideremo
   
2. 02

   Design

   Potete discutere il prodotto mentre cambiarlo costa ancora poco.

   Trasformiamo lo scope in qualcosa su cui cliccare: flussi, schermate e i pochi componenti che si ripeteranno. Il punto non è un file bello. È trovare i punti scomodi — stati vuoti, permessi, il terzo tap a cui nessuno ha pensato — prima che diventino ticket.

   Se un prototipo statico non basta, lo spikeiamo nello stack reale. Lo revisionate con chi lo userà, non solo con chi l'ha commissionato. Quando siamo d'accordo, quel file è ciò che costruiamo. Non finisce nel vuoto.

   Con cosa uscite

   • Flussi cliccabili e le schermate core
   • Un design system piccolo, non un kit da 200 componenti
   • Domande aperte nominate, non nascoste nei commenti
   • Una sequenza di build allineata alla prima fetta
   
3. 03

   Build

   Software funzionante ogni settimana. Lo vedete, lo provate, aggiustiamo.

   Chi è nel kickoff è chi scrive il codice. Avete un repository che controllate, una demo settimanale di qualcosa su cui cliccare, e un solo posto per le decisioni. Se una settimana è stata magra, lo diciamo. Status senza software funzionante non è un report di avanzamento.

   Test, logging e un modo di rilasciare entrano man mano — non come pulizia alla fine. Se qualcosa non va, lo prendiamo quando è ancora piccolo. Lo scope può cambiare; scriviamo il trade-off così la fattura non diventa la sorpresa.

   Con cosa uscite

   • Un repository, ambienti e un percorso di release che sono vostri
   • Demo settimanali di software funzionante
   • Decisioni scritte, non una chat che nessuno ritrova
   • Qualità e monitoring nel prodotto, non un progetto successivo
   
4. 04

   Scale

   Il lancio non è la fine del rapporto.

   Il go-live è quando iniziano le domande vere: un bug in produzione, un cambiamento nel business, una persona nuova nel vostro team che deve capire il codice. Rafforziamo ciò che già gira, misuriamo ciò che conta, e continuiamo a rilasciare la fetta successiva se ci volete sopra.

   Dovreste poter portare il prodotto in-house. Architettura, test e note restano con voi. Se volete che restiamo, restiamo. Se no, non dovreste sentirvi bloccati.

   Con cosa uscite

   • Un sistema in produzione che potete operare
   • Note di handover che i vostri ingegneri possono seguire
   • La fetta successiva in scope, se volete continuare
   • Supporto che risponde, non un vuoto di ticket