Riflessioni su un’estate di sviluppo software #2

L’anno scorso, in questo periodo, ho scritto il post Riflessioni su un’estate di sviluppo software.

Era la prima volta che decidevo di rinunciare alle vacanze estive per concentrarmi sul lavoro ma, in quel momento, era la scelta più logica da fare.

In quel post (se ve lo foste persi ne consiglio la lettura, tanto è veloce) ripercorrevo un episodio avvenuto durante il mio periodo universitario e descrivevo come gli anni passati a coltivare, più o meno inconsciamente, alcune skill (capacità di risolvere problemi complessi, resistenza fisica e mentale e creatività) fossero risultati utili per affrontare lunghi periodi lavorativi così intensi.

Insomma, la scorsa estate è passata e i mesi successivi si sono rivelati ancora più intensi, ma la spinta che abbiamo dato insieme al team durante quell’estate ci ha aiutato a porre le basi per il Crono che conosciamo oggi, transformando il nostro MVP, che avevo sviluppato praticamente da solo nell’anno precedente, in un prodotto comparabile a quello dei più grandi competitor e utilizzato quotidianamente da centinaia di utenti.

Ho pensato di scrivere un secondo capitolo di questo post perché per un’altra volta mi sono trovato a trascorrere un’estate di sviluppo software e ho scoperto che in fondo in fondo non è così male.

SPOILER: quest’estate andrò in vacanza, mi godrò una settimana di mare e, ad onore del vero, a fine marzo 2024 ho avuto l’opportunità di recuperare le vacanze estive del 2023.

Appunto da marzo 2024 so che posso prendermi qualche giorno di vacanza (quando serve) e che posso contare sugli altri membri del team che sono in grado di intervenire qualora ci fosse qualche urgenza.

Quando inizi un progetto di questo tipo (una startup in ambito software) non si ha la capacità di quantificare la durata e l’impegno necessario prima di potere dire: “adesso la macchina può andare avanti anche senza di me”, specialmente se sei il responsabile tecnico (CTO).

Ingenuamente nel mio periodo da sviluppatore freelance trovavo noioso dovere ripartire sempre da zero con nuovi progetti per guadagnare nuovi soldi. Dicevo a tutti che volevo sviluppare un prodotto mio, così che l’avrei sviluppato una volta e poi venduto mille volte. Dopo più di due anni sto ancora sviluppando, anzi adesso siamo in 5 a farlo, e non vedo come ci potrà mai essere una fine ai nuovi sviluppi.

Ma è un bel viaggio, ci stiamo divertendo :D.

Quando capisci che ti trovi davanti ad un gioco infinito ti rendi conto che qualche volta c’è bisogno di ricaricare le batterie, lasciare un po’ andare i problemi del quotidiano, piccoli o grandi che siano, e liberare la mente per permettere a nuove idee di fiorire. Per raggiungere questo scopo non c’è niente di meglio di una bella vacanza.

Certo per arrivare al punto in cui ho potuto staccare una settimana senza avere paura che si rompesse tutto in mia assenza ho dovuto investire molto sulla crescita del team e sulla responsabilizzazione dei componenti.

Non è stato un lavoro facile. Bisogna innanzittutto trovare le persone giuste e non sempre si riesce al primo colpo.

Come secondo passo ho dovuto imparare a fare un grande switch mentale nel corso dell’ultimo anno:
inizialmente preferivo prendermi carico delle attività più lunghe e complesse perché mi sentivo il più veloce a svolgerle.

Da un canto ovviamente riuscivamo ad andare più veloce, da un altro continuavo ad accentrare conoscenza e responsabilità su di me, diventando un’inevitabile collo di bottiglia per tutto il processo di sviluppo che dipendeva da tutte le cose che cercavo di portare avanti in parallelo.

Man mano che i componenti del team aumentavano mi sono reso conto che più che velocizzare lo sviluppo lo stavo inevitabilmente rallentando.

Ho capito quindi che avrei dovuto investire più tempo nella formazione dei componenti del team: spiegare a loro i vari moduli del codice che erano stati sviluppati prima che iniziassero a lavorare per Crono, arricchire la documentazione, creare procedure utilizzabili da altri. In poche parole dovevo iniziare a trasferire e distribuire la mia conoscenza.

Certo, rileggendolo ora mi sembra un passaggio molto lineare che avrei dovuto fare prima ma non è facile rendersi conto di queste situazioni mentre le stai affrontando, specialmente considerando le urgenze e le deadline che lo sviluppo di una piattaforma tecnologica per una startup richiede.

D’altronde non esiste una ricetta per diventare un buon CTO, esistono certamente molte risorse come libri, newsletter o best practice, ma mi sto convincendo che il modo migliore per imparare sia sulla propria pelle, sbagliando ed imparando.

Lo stesso processo devono affrontarlo i membri del team, specialmente se sono giovani. Non basta formarli, bisogna dargli tempo per apprendere e consolidare le competenze. Devono fare esperienza ed inevitabilmente questo si può tramutare in commettere errori. Ma finché non passano da questo processo non guadagneranno mai la sicurezza necessaria per prendersi in carico le responsabilità e ridurre i colli di bottiglia.

In questi mesi mi sono assicurato che il team potesse crescere e acquisire competenze ed esperienza. Il mio ruolo non è più soltanto quello di sviluppare software ma è assicurarmi che le altre persone possano farlo insieme a me in modo efficiente ed armonico al fine di consentire il miglioramento continuo del prodotto nel rispetto della strategia definita.

Fortunatamente siamo riusiciti a trovare dei ragazzi giovani, brillanti, veloci nell’apprendimento e con tanta energia da investire sul progetto, consapevoli allo stesso tempo della grande esperienza che possono acquisire in una startup. Ovviamente ognuno è diverso dall’altro e di conseguenza hanno bisogno di un percorso specifico per espandere le loro soft e hard skill.

Conoscere e comprendere ognuno di loro, al fine di supportarli nella crescita, è un processo tanto necessario quanto affascinante. Perché un po’ stai insegnando e un po’ stai imparando, specialmente cose che riguardano te stesso. Diventano fondamentali gli allineamenti con i componenti del team, come ad esempio i colloqui 1-1 con cadenza mensile.

Sono i momenti più adatti per andare oltre alle complessità del quotidiano, per conoscere meglio i propri compagni di squadra e per instaurare un rapporto di fiducia.

Recentemente, durante uno di questi incontri, mi è stata posta una domanda che mi ha sorpreso e che mi ha fatto molto riflettere. Ho pensato di condividerla in questo post perché l’analisi della risposta può essere interessante.
Purtroppo non ricordo precisamente le parole, cerco di riportare la domanda nella sua forma più verosimile:

Ho letto che per essere un buon CTO e avere successo con la tua startup devi essere innamorato del tuo prodotto, è così anche per te?

Sono saltato dalla sedia. Non avevo mai fatto una riflessione di questo tipo. Prima di cominciare Crono non avevo idea di come funzionasse l’outbound sales. Conoscevo i CRM più famosi e ne avevo utilizzati ancora in passato, ma non conoscevo i software specializzati nella vendita outbound. Come potevo essere innamorato del prodotto? Ero forse un cattivo CTO?

Poi ho riflettuto un attimo e ho pensato a cosa è diventato Crono ora.

Come dicevo all’inizio, l’estate scorsa l’abbiamo investita per costruire il Crono che vendiamo oggi. Fino ad allora c’erano stati pochi utenti che l’avevano più che altro testato in modo sporadico, incuriositi dall’idea. Da settembre 2023 la nuova soluzione ha iniziato ad attirare clienti che si fidelizzavano in fretta: Crono ha iniziato ad esistere.

I vari componenti che costituiscono il prodotto e che abbiamo assemblato pezzo dopo pezzo sono funzionali per permettere alla macchina di muoversi. Gli utenti che lo utilizzano tutti i giorni alimentano il flusso delle interazioni tra questi componenti e ne traggono beneficio per il loro lavoro quotidiano.

Crono è vivo e il team di sviluppo si adopera per assicurarsi che possa continuare ad esserlo e a crescere allo stesso tempo. Ci sono dei parametri che permettono di capirne lo stato di salute: l’utilizzo da parte degli utenti, lo stato dell’infrastruttura, la velocità di sviluppo del software, i bug, le richieste degli utenti e tanti altri ancora.

Il mio lavoro è quello di assicurarmi che tutta questa macchina funzioni e che continui a muoversi, sempre di più.

A questo punto, per ritornare alla domanda iniziale che ha scaturito questo ragionamento, mi sono chiesto: come posso non essere innamorato del prodotto e di quello che faccio? L’ho visto nascere e ne conosco tutti i suoi segreti, c’è tanto di me dentro Crono così come c’è tanto di Crono dentro me.

Mi sono risposto che è vero: per essere un buon CTO bisogna essere innamorati del prodotto così come un buon padre è innamorato del proprio figlio e vuole vederlo crescere e trovare il successo nella vita.

Riflessioni dopo una seconda estate di sviluppo software insieme ai miei compagni di viaggio in Crono.
Kobe sempre pronto ad aiutarmi anche con 35 gradi, unico vero CTO di Crono

Ritornando alla seconda estate di sviluppo software e tirando le fila di questo post un po’ sconclusionato. Lavorare ad Agosto non è affatto male, tanti clienti sono in ferie e si ha molto più tempo per consolidare l’esistente e concentrarsi sui nuovi sviluppi.

Durante quest’anno ho lavorato per far sì che ogni componente del team acquisisse conoscenza e responsabilità su specifiche componenti della macchina, in modo tale da non essere l’unico in grado di sapere dove mettere le mani qualora ci fosse un problema urgente da risolvere.

La macchina ormai si sta muovendo, non si può più spegnere, ma per fortuna quest’anno ci sono altre persone che possono darmi una mano se necessario.

Anche questa volta sono andato un po’ lungo ora è meglio che stacco. Devo ancora preparare le valigie e caricarle in macchina, oggi parto anch’io per le vacanze.

Buona estate di sviluppo software a tutti.

Toplus

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *