Sapere quanto regge, prima di scoprirlo.

Il prodotto funziona con gli utenti di oggi. La domanda è cosa succede con quelli che state aspettando, e la risposta non si può indovinare.

Cosa succede davvero

Cosa ottieni

La mappa dei punti che cedono per primi

Analisi delle performance di software e infrastruttura, criticità in ordine di gravità, punti di miglioramento, e un piano di intervento con tempi e costi. Non un elenco di cose da sistemare: una sequenza, perché l'ordine è quello che fa la differenza tra spendere bene e spendere tanto.

Cosa ti impegna

Accesso al codice e all'infrastruttura

E, dove possibile, il tempo di chi lo conosce: molte scelte hanno una ragione, e chi le giudica senza chiedere sbaglia. Quando quella persona non c'è più — capita spesso — la ricostruiamo dal codice.

Cosa non è

Non è la premessa a una riscrittura

Il risultato più frequente è che alcune cose vanno cambiate e molte no — e sapere quali è tutta la differenza fra spendere bene e spendere tanto.

Starter

Le porte.

Build, Scale e Rescue sono impegni lunghi, e prima di prenderli è normale volerci vedere chiaro.

Gli starter sono il modo di cominciare senza impegnarsi: durano poche settimane, costano poco, e finiscono con qualcosa in mano che vale anche se poi lavori con altri. Tre ti danno una risposta prima di partire: un piano, una verifica, un audit. Il quarto, il Dry Run, ti fa vedere come lavoriamo su un pezzo vero del tuo progetto.

Come si lavora, da lì in poi

  1. Prima

    Decidi tu su cosa si spende la capacità

    Ogni attività viene descritta, progettata dal punto di vista tecnico e dell'interfaccia, stimata in impegno, e resta ferma finché non la approvi. Così vedi cosa verrà realizzato prima che si spenda il tempo per farlo. Non stai approvando una fattura: stai decidendo dove va a finire il tempo che hai già comprato.

  2. Ogni giorno

    Vedi la pipeline mentre si muove

    Hai accesso allo strumento dove vivono le attività: in che stato sono, in quale sprint di due settimane cadono, se si è in anticipo o in ritardo. Non un riepilogo a fine mese — la stessa vista che usiamo noi.

  3. Durante

    Nessuno rilascia il proprio codice

    Chi scrive non è chi approva. Ogni modifica passa da un secondo tecnico prima di arrivare da qualsiasi parte.

  4. Prima del rilascio

    Un ambiente dove provarlo tu

    Il lavoro arriva dove puoi vederlo prima della produzione. Se non è come te l'aspettavi, torna indietro.

  5. Sempre

    Codice e server restano tuoi

    Nessun vincolo tecnico che ti costringa a restare.

Il metodo, nel dettaglio