Rilasciare in produzione è una competenza

La maggior parte degli sviluppatori che conosco è brava a scrivere codice. Molti meno sono bravi a rilasciarlo.

Una volta questa cosa mi confondeva. Il divario tra "sto lavorando a un progetto" e "le persone lo usano" dovrebbe essere piccolo. Scrivi il codice, lo metti in produzione, hai finito. Ma in pratica, quel tratto finale — la parte in cui effettivamente concludi — è dove muoiono la maggior parte dei progetti. Non per problemi tecnici. Per una serie di competenze diverse di cui si parla poco.

Rilasciare in produzione è una competenza. Si impara. E se non riesci sistematicamente a finire le cose, vale la pena guardarlo direttamente.

La trappola della perfezione

Il motivo più comune per cui i progetti si bloccano è che chi li costruisce non riesce ad accettarne l'imperfezione.

C'è sempre qualcosa che non va del tutto bene. L'interfaccia non è abbastanza rifinita. La gestione degli errori è incompleta. L'architettura scelta sei settimane fa sembra peggiore ora che capisci meglio il dominio. Il README è imbarazzante. C'è un refactor che hai rimandato e che renderebbe tutto più pulito prima di mostrarlo a qualcuno.

Niente di questo è il vero problema. Il vero problema è che stai usando le preoccupazioni sulla qualità come scusa per evitare l'esposizione che viene con il lancio. Mettere qualcosa davanti agli utenti reali è scomodo. Può fallire. Le persone possono non usarlo, o usarlo e non importarsene, o usarlo e trovarlo peggio di quanto speravi. Restare indefinitamente in fase di sviluppo è un modo per evitare di scoprirlo.

L'antidoto non è abbassare i propri standard. È essere onesti su a cosa servono davvero.

Lo scope è la variabile

Ogni progetto che ho rilasciato, ho tagliato qualcosa. Di solito molte cose. Le funzionalità che sembravano essenziali durante la pianificazione si sono rivelate negoziabili quando fissavo una scadenza che avevo fissato io stesso.

Questo è intenzionale. Non definisco un perimetro del progetto e poi cerco di rilasciarlo. Lo definisco sapendo che taglierò delle cose, e cerco di identificare in anticipo cosa può andare. Non cosa voglio tagliare — cosa il progetto può sopravvivere senza, rimanendo comunque utile a chi lo usa.

C'era una versione di Barba Studio che avevo pianificato con dashboard analitiche, supporto multi-sede, un widget di prenotazione per i clienti con branding personalizzato e un sistema di fidelizzazione integrato. Niente di questo è uscito nella prima versione. La prima versione aveva le prenotazioni, un calendario e un modo per inviare promemoria degli appuntamenti. Era tutto.

Se avessi aspettato di rilasciare la visione completa, non sarebbe mai stato lanciato.

La definizione di fatto

Prima di iniziare qualcosa di significativo, scrivo cosa significa finito. Non una specifica completa — una frase o due. "Questo è fatto quando un barbiere può creare un account, aggiungere i propri servizi e ricevere la prima prenotazione." Tutto qua. Il resto è versione due.

Sembra ovvio. In pratica non succede quasi mai.

Senza una definizione di finito, un progetto non ha un punto di arresto naturale. Cresce, indefinitamente, mentre impari di più sul problema e accumuli idee su cosa potrebbe diventare. Va bene per un progetto di ricerca. È fatale per qualcosa che vuoi rilasciare.

La definizione di fatto non deve essere minimalista. Deve essere specifica. "Fatto quando il flusso principale funziona end-to-end senza bug critici" è un obiettivo che puoi effettivamente raggiungere. "Fatto quando è buono" non lo è.

Momentum e costo di rientro

Una cosa che ho imparato costruendo nei margini — nell'ora prima del lavoro, il sabato mattina, negli spazi di un'agenda piena — è che il momentum vale più di quanto pensassi.

Rilasciare richiede di portare un progetto da dove si trova a finito. Più tempo ci vuole, più si accumula il costo di rientro. Ogni volta che riprendi il progetto, passi del tempo a ricordare dove eri, cosa avevi deciso, perché. Tempo che non stai usando per costruire.

I progetti che ho finito hanno quasi tutti avuto una fase verso la fine in cui ho spinto più del solito — non perché stessi esaurendo le energie, ma perché vedevo il traguardo e sapevo il costo di trascinarlo. Due settimane intense per chiudere qualcosa sono quasi sempre meglio di sei settimane rilassate che finiscono nello stesso punto.

Quella spinta finale non è un tratto caratteriale. È una decisione.

Cosa impari davvero rilasciando

C'è un tipo di conoscenza che si ottiene solo mettendo qualcosa davanti a utenti reali. Non ipoteticamente — realmente.

Quali funzionalità usano e quali ignorano. Dove si confondono. Di cosa si lamentano che non ti aspettavi. Di cosa non si lamentano su cui hai agonizzato.

Tutta quella è informazione che non puoi ottenere in nessun altro modo. E la ottieni solo rilasciando.

Il feedback di un utente reale nella prima settimana di un prodotto vale più di mesi di raffinamento interno. Non perché il tuo raffinamento sia inutile — ma perché l'utente ti dice cosa raffinare. Costruire nel vuoto, senza quel segnale, è per lo più fare supposizioni.

La versione onesta

Alcuni progetti non sono destinati a essere rilasciati. Esperimenti, esercizi di apprendimento, cose costruite per capire qualcosa — hanno criteri di successo diversi, ed è giusto così.

Ma se stai trattando qualcosa come un prodotto — se ti sei detto che sarà reale, che aiuterà qualcuno, che esisterà nel mondo — allora non rilasciarlo è un tipo specifico di fallimento. Non un fallimento morale. Un fallimento di competenza. Il che significa che è correggibile.

Scrivi cosa significa fatto. Taglia tutto quello che non rientra in quella definizione. Fai la spinta finale. Rilascia la cosa.

La seconda versione sarà migliore comunque.