Il cliente è dentro il processo, non fuori.
Ogni attività che facciamo passa da te tre volte: quando si decide cosa fare, quando si decide quanto costa, e quando è pronta per essere vista. Nel mezzo non devi fare niente — ma non ti arriva niente a sorpresa.
Quello che segue è il metodo che applichiamo su ogni progetto.
L'unità di lavoro
Prima di scrivere codice,
si scrive cosa deve fare.
Ogni attività ha una scheda, e la scheda dice sei cose: cosa si costruisce, in quale contesto di business si inserisce, quali condizioni deve rispettare per essere considerata finita, cosa resta fuori, quali aspetti tecnici vanno tenuti a mente, e cosa serve sapere a chi la testerà.
Il pezzo che di solito manca altrove è il secondo. Uno sviluppatore che sa perché una cosa serve prende decisioni tecniche diverse da uno che sa solo cosa gli è stato chiesto — e le prende meglio.
Le decisioni
L'AI riempie i buchi. Il processo li fa vedere.
Con l'AI, scrivere prima cosa deve fare il software conta ancora di più. Se le chiedi di fare A, e per farlo bisogna decidere X, Y e Z, quelle decisioni l'AI le prende da sola. Di solito in modo plausibile, ed è per questo che non te ne accorgi: magari te ne rendi conto quando sei già in produzione.
Perché una decisione resti in mano a una persona, prima bisogna vederla. Il processo serve a questo: la scheda di ogni attività, la progettazione validata da un secondo tecnico, i test. Così le scelte emergono quando cambiarle costa ancora poco, e le prendiamo insieme a te.
Il percorso
Otto passaggi. Tre li fai tu.
01
Noi
Si descrive l'attività
02
Tu
Il contenuto lo approvi
03
Noi
Si progetta tecnicamente
04
Noi
Un secondo tecnico valida la progettazione
05
Tu
Approvi tempi e costi
06
Noi
Si sviluppa
07
Noi
Un secondo tecnico rivede il codice e lo prova
08
Tu
Lo provi tu, dove lo vedi girare
Il ritmo
Due settimane per volta.
Il lavoro è organizzato in cicli di due settimane, riempiti fino a saturare la capacità del team. Tu vedi quali attività cadono in quale ciclo, e da lì ricavi quando una cosa sarà pronta — non a fine mese, non su richiesta: è la stessa vista che usiamo noi.
Ogni attività ha un tempo stimato e un tempo consumato. La differenza fra i due dice quanto manca, e se ci sta nel ciclo.
Quando qualcosa non finisce nel ciclo, passa al successivo portandosi dietro solo l'effort rimanente. Non viene ricontato da capo.
- Stimato
- Consumato
- Residuo che passa al ciclo dopo
- Capacità libera
Chi controlla
Nessuno rilascia il proprio codice.
Vendiamo il tempo di persone, e le persone sono diverse: il metodo serve a far sì che il livello del lavoro non dipenda da chi ci mette le mani. Per questo ogni modifica passa da un secondo tecnico prima di andare da qualsiasi parte. Non è una formalità: chi rivede legge il codice, lo prova in un ambiente separato, e se trova qualcosa il lavoro torna indietro.
Con l'AI il codice arriva in fretta e in grande quantità. Una revisione su migliaia di righe tutte insieme non si riesce a fare con attenzione. Per questo lavoriamo a passi piccoli: ognuno ha la sua revisione, ed è abbastanza breve da essere letto davvero. La responsabilità di quello che va in produzione la condividiamo con te.
Prima ancora della revisione, ogni modifica passa dalla pipeline di CI/CD: test automatici che verificano che il software faccia ancora quello che deve, controllo della copertura dei test, verifiche di sicurezza sul codice. Se un controllo fallisce, la modifica si ferma lì. Con l'AI oggi è molto più semplice coprire di test tutta la codebase. Però va chiesto: l'AI non lo fa di sua iniziativa, come non lo farebbe uno sviluppatore lasciato da solo. Nel nostro processo è un passaggio previsto.
01
Locale
dove si sviluppa
02
Dev
prova interna
03
Staging
dove provi tu
04
Produzione
i tuoi utenti
Ogni passaggio è automatico — nessun comando digitato a mano
Ci sono quattro ambienti — quello dove si sviluppa, quello dove si prova internamente, quello dove provi tu, e la produzione. Ognuno ha una pipeline che rilascia da sola: nessuno digita comandi su un server per mandare in produzione.
I rilasci hanno un giorno e un'ora fissi, con una persona che li coordina. Non si rilascia il venerdì sera perché era pronto.
Come si parla
Ogni due settimane, con chi lavora al tuo prodotto.
C'è un allineamento fisso con te ogni due settimane, e uno interno ogni settimana. Le decisioni prese non restano nella call: finiscono scritte nell'attività a cui appartengono, dove le ritrovi fra sei mesi quando serve capire perché una cosa è stata fatta così.
Se qualcosa non funziona, hai un modo strutturato per segnalarlo: cosa hai fatto, cosa ti aspettavi, cosa è successo, dove e quando. Sembra burocrazia ed è il contrario — è la differenza fra un problema risolto in un'ora e tre giorni di andirivieni per capire di cosa stiamo parlando.
- Cosa hai fatto
- Ho esportato gli ordini di marzo in CSV.
- Cosa ti aspettavi
- Un file con tutti gli ordini del mese.
- Cosa è successo
- Il file contiene solo gli ordini fino al 15.
- Dove
- Back office · Ordini
- Quando
- 3 apr, 10:42
- Utente
- Mario Rossi · amministratore
- Ambiente
- prodstgdev
La conoscenza non resta in testa a una sola persona.
Uno dei rischi più comuni negli engagement esterni è la dipendenza da una persona chiave. Quando quella persona esce, esce anche il contesto.
In Astrorei il lavoro viene documentato e distribuito nel team: codice, decisioni architetturali, accessi, materiali di progetto. Così il know-how accumulato resta un asset stabile per il cliente, non un rischio operativo.
La collaborazione continua perché crea valore, non perché il contesto è rimasto bloccato da qualche parte.