Cos’è il metodo BitBoss

Il metodo BitBoss è l'insieme di processi che applichiamo per un motivo: capire il prima possibile se stiamo costruendo il software giusto.

Un metodo fisso non esiste e non può esistere: non ci sono due progetti uguali. Un tool interno, un nuovo prodotto e un gestionale richiedono, a seconda dell’azienda, quantità diverse di persone, analisi e controllo.

Quello che non cambia sono i principi: sono loro a dare forma, ogni volta, all’approccio giusto per il progetto. Il software che facciamo è su misura, così come il modo in cui lo costruiamo.

L’AI ha reso molto più veloce una parte del lavoro. Noi usiamo quel vantaggio per ridurre l’investimento necessario, arrivare prima al software funzionante e prendere decisioni su qualcosa di reale.

Il punto di partenza

Partiamo da quello che deve funzionare

Prima delle funzionalità vengono il problema, le persone che lo affrontano ogni giorno e il risultato che vogliamo ottenere.

Per questo lavoriamo insieme a chi conosce davvero il processo. Facciamo domande, mettiamo in discussione le richieste quando serve e proviamo a separare ciò che è importante da ciò che sembra soltanto urgente.

Il nostro lavoro non è trasformare una lista di richieste in codice, ma capire insieme il "come" raggiungere il risultato nel modo più efficiente possibile.

Software vero, il prima possibile

Mockup, schemi e documenti servono. Ma la differenza la si fa iterando sul software reale, che deve arrivare il prima possibile.

Cerchiamo quindi di arrivare a una prima versione ridotta ma funzionante, e di farla provare alle persone che dovranno usarla. Da lì i passi successivi potrebbero essere molto differenti da quelli che si immaginavano all’inizio.

Quella prima versione non è un punto d’arrivo: è parte del ragionamento. Costruire serve anche a capire. Quello che impariamo usandola cambia cosa costruiamo dopo, e l’idea evolve insieme al software.

A volte succede nel giro di pochi giorni. Nei progetti più complessi serve più preparazione. Il principio resta lo stesso: ridurre il tempo passato a discutere di ipotesi e aumentare quello passato a osservare il prodotto mentre prende forma.

Il lavoro vero è trovare il compromesso giusto

Quasi nessuna decisione di prodotto è una scelta tra giusto e sbagliato. Quasi tutte sono compromessi: tra velocità e solidità, tra completezza e semplicità d’uso, tra la soluzione elegante e quella che possiamo mantenere.

Con l’AI questo è ancora più vero. Le soluzioni possibili sono tante, arrivano in fretta, e sembrano funzionare quasi tutte. Il lavoro è capire quale sia la soluzione giusta per questo progetto, con queste persone e queste risorse.

Fare quanto di meglio possibile tenendo conto dei vari vincoli e della direzione che si immagina per il progetto è la parte difficile.

In ogni ciclo di lavoro

Arriviamo a qualcosa di concreto da guardare o usare.

Rivediamo insieme quello che abbiamo imparato.

Decidiamo cosa cambiare, cosa tenere e cosa non vale più la pena fare.

Poi ripartiamo.

La durata del ciclo non è una regola. Due settimane possono avere senso, ma non sono un’unità di misura sacra. Quando possiamo prendere una decisione utile prima, non aspettiamo il calendario.

Come lavoriamo insieme

Cambiare idea costa meno

Quando rifare un pezzo di software costava settimane, ogni richiesta di modifica diventava una trattativa. Anche il fornitore migliore imparava a difendere il piano.

Oggi Oggi ricostruire costa poco, e questo cambia il rapporto: un cambio di direzione non è più una minaccia al progetto, è un’informazione in più su cosa serve davvero. Possiamo permetterci di incoraggiarlo.

Per chi lavora con noi significa un’esperienza diversa: meno battaglie sulle specifiche, più conversazioni su quello che il software sta facendo.

Il cliente è dentro al progetto

Non lavoriamo per settimane per poi tornare con una sorpresa.

Chi ci affida il progetto vede cosa sta succedendo, prova quello che costruiamo e partecipa alle decisioni mentre sono ancora facili da cambiare.

Questo serve a costruire un prodotto migliore, ma ha anche un altro effetto: mentre il software cresce, cresce la conoscenza che il cliente ha del proprio prodotto.

Le decisioni non restano chiuse nella testa del fornitore. Le ragioni dietro a un flusso, una priorità o una scelta tecnica diventano patrimonio condiviso.

Alla fine il cliente non riceve soltanto del software che sa usare. Conosce meglio ciò che è stato costruito e ha più strumenti per decidere come farlo evolvere.

E chi vuole andare oltre può farlo: formiamo le persone del cliente perché arrivino a evolvere il software in autonomia.

Il progetto definisce come lavoriamo

Non mettiamo cinque persone su un progetto che ne richiede una. E non proviamo a gestire con una persona un progetto che ha bisogno di architetture, integrazioni e infrastrutture particolari.

Il team cresce, si restringe e cambia composizione in base al lavoro da fare.

Setup leggero Su alcuni progetti una persona di prodotto può lavorare molto vicina al cliente, costruire rapidamente le prime versioni e coinvolgere gli sviluppatori per review e passaggi critici.

Team strutturato Su altri serve da subito un team strutturato.

Contesti regolati E ci sono contesti in cui più passaggi, più documentazione e più controllo non sono burocrazia inutile: sono semplicemente necessari.

Il metodo sta anche nel capire la differenza.

Velocità e durata

Quanto leggeri si può partire

L’AI ci permette di produrre codice, interfacce e prime versioni molto più velocemente di qualche anno fa.

La differenza arriva subito dopo.

Il vantaggio Questo rende possibili approcci molto leggeri, e rende sensati progetti che fino a poco tempo fa non stavano economicamente in piedi. Lo si può chiamare vibe coding, ma in un ambiente controllato e strutturato. Quando il perimetro del progetto lo permette, questo diventa un modo di organizzare il lavoro a sé: BitBoss AI.

Le possibilità di crescita Anche se un progetto parte leggero, il software deve poi poter essere letto, revisionato, corretto e fatto evolvere da un team di sviluppatori. Dai nostri per primi. La leggerezza iniziale non deve condannarlo a essere buttato via appena cresce. È qui che entrano esperienza tecnica, stack che conosciamo bene, review e scelte architetturali.

Quando finisce?

Quando il software fa abbastanza bene quello per cui è nato.

Per alcuni progetti significa arrivare a una prima versione, metterla nelle mani degli utenti e capire cosa succede. Per altri significa accompagnare per anni un prodotto che continua a cambiare insieme all’azienda.

Non consideriamo l’evoluzione un’eccezione da gestire dopo la consegna. Fa parte del problema fin dall’inizio.

Per questo cerchiamo di costruire software che possa cambiare senza rendere ogni modifica una battaglia.

I dettagli
fanno la
differenza

La velocità con cui oggi si può costruire software rende ancora più facile costruire la cosa sbagliata.

Per questo continuiamo a stressare le idee prima e durante lo sviluppo: dal punto di vista del prodotto, dell’esperienza di chi lo userà e della tecnologia che dovrà sostenerlo.

A volte significa proporre una strada diversa. A volte togliere una funzionalità. Oppure fermarsi su un dettaglio che sembrava secondario e che invece cambia tutto.

Scrivere codice costa meno di prima. Scegliere bene cosa fare continua a essere il nostro lavoro.

Parliamo
del tuo progetto?