Intervista a Gian Marco Toso - Ingegnere del software e consulente Nephila
Oltre alle persone che fanno parte della squadra Nephila - puoi dare un'occhiata nella sezione team del nostro sito -, attorno alla nostra realtà gravitano una serie di professionalità esterne, con cui collaboriamo attivamente, che ci aiutano nello svolgimento del nostro lavoro. Queste figure entrano in gioco, ad esempio, quando dobbiamo formarci su nuove tecnologie, se dobbiamo rispondere ad esigenze specifiche di clienti in cui non abbiamo competenze specifiche, o ancora se abbiamo bisogno di supporto, a vari livelli, nello sviluppo di un progetto. Queste esigenze possono convergere e manifestarsi nello stesso momento. Ad esempio, la necessità di formazione su tecnologie specifiche può presentarsi insieme all’esigenza di supporto su progetti specifici. In questi casi, riusciamo a creare percorsi di collaborazione strutturata, e duratura nel tempo, come quella che stiamo per raccontarti.
Creare rapporti di collaborazione sinergica è una componente essenziale del nostro modo di lavorare. Per questo, vogliamo farti conoscere queste figure professionali e raccontarti come sono nate queste collaborazioni. Per farlo, abbiamo deciso di inaugurare un nuovo format sul nostro blog: le interviste.
Da chi partiamo? Gian Marco Toso, Ingegnere del software che si occupa principalmente di architetture software, ma non solo. Siamo entrati in contatto con lui perché avevamo bisogno di fare formazione su React e di avere supporto su un progetto che prevedeva l’utilizzo di questa tecnologia. Gian Marco ha fatto formazione a tutto il team Nephila su React, e ha gestito un processo di training on the job nello specifico progetto, in cui ha seguito le persone del team coinvolte, sia a livello di code review che di ricerca di soluzioni da implementare. Ci siamo trovati benissimo, tanto che la collaborazione è proseguita. Ultimamente, ad esempio, lo abbiamo coinvolto in un progetto interno - ACME Board, - di cui parleremo in un blog post dedicato -, che ha riguardato la formazione del team nell'ambito dell'analisi software (raccolta di requisiti, definizione di soluzioni, scrittura di un documento di analisi) e della gestione "tecnica" di un progetto (stima degli impieghi e dei tempi).
Gian Marco per noi è un consulente strategico. Ci dà un grande supporto in area frontend, sia a livello di sviluppo, sia in merito ad analisi e stime, oltre ad essere una figura chiave per la formazione del nostro team frontend.
Fatte le dovute premesse, lasciamo a lui la parola per raccontarci chi è, di cosa si occupa, come è nata la nostra collaborazione e il suo punto di vista su argomenti che lo riguardano da vicino. Partiamo!
***
Ciao Gian Marco, vuoi dirci chi sei e di cosa ti occupi?
Ciao! Sono un Ingegnere del Software e da più di dieci anni faccio il consulente libero professionista, occupandomi principalmente di architetture software; mi occupo di supportare le aziende nella progettazione e nello sviluppo di applicativi web sia ad uso interno che per i loro clienti, e opero sia con tecnologie server-side che tecnologie client-side.
Per Nephila, sei un consulente tecnico. Qual è il tuo ruolo esattamente?
Il mio ruolo in Nephila è, oggi, quello di supportare il team di sviluppo interno sia da un punto di vista tecnico e pratico che da un punto di vista più ad alto livello: aiuto sì nella progettazione e nello sviluppo, ma sto anche contribuendo alla crescita del team con azioni di mentorship mirate al miglioramento delle loro soft skill.
In che modo hai collaborato con Nephila? Su cosa vi siete focalizzati e a quale scopo?
La collaborazione con Nephila è iniziata con il progetto CCMS*, sul quale sono stato coinvolto per portare le mie forti competenze su React prima in termini di formazione e poi in termini di progettazione architetturale e sviluppo. Oggi collaboro su progetti che hanno esigenze sul frontend con React, oltre a fornire supporto alla formazione delle soft skill del team interno.
*Si tratta di un software per l'industria delle vernici chiamato Colour Creations Management System che regola il funzionamento dei distributori di vernici (tintometri) all’interno dei punti vendita. Ci siamo occupati dello sviluppo backend e frontend.
È così difficile rendere autonomo un team? Quali sono le difficoltà che incontri maggiormente e su cui le aziende ti chiedono supporto?
Se il team non è autonomo, normalmente è perché la tecnologia che vogliono o devono usare per loro è assolutamente nuova, e hanno bisogno di essere orientati nella direzione giusta per poterla sfruttare al meglio. Spesso non è solamente questione di imparare ad usare una libreria, un framework o un linguaggio di programmazione quanto piuttosto di capire quali sono i contesti in cui va usata e quali sono le pratiche più consolidate che si adottano per risolvere certi problemi spesso molto comuni: la formazione aiuta ad imparare ad usare uno strumento, ma quando, come e perché usarlo sono cose che arrivano dall’esperienza; il mio intervento è richiesto, oltre che per il percorso di formazione, proprio per affiancare un team su un progetto specifico e aiutare i suoi membri ad affinare la tecnica. Spesso sono le figure più senior a cogliere per prime certe sfumature, che vengono poi naturalmente trasmesse ai ruoli più junior, ma ho visto succedere anche il contrario!
La difficoltà più grossa è quella di sradicare delle abitudini ormai profondamente consolidate, che vanno in conflitto con alcuni paradigmi più “moderni” che prevedono un approccio completamente diverso ad un certo tipo di problem solving. In quel caso, una buona soluzione, oltre all’affiancamento diretto, è la code review del codice scritto dalle persone del team, in cui cerco di incoraggiare chi fa parte del team stesso a revisionare il codice dei loro colleghi con la mia supervisione, in maniera da cercare di farli entrare nell’ottica giusta.
A questo proposito, vuoi raccontarci la tua esperienza sul Progetto ACME Board che abbiamo realizzato insieme e come hai supportato/guidato il nostro team?
ACME è stato un esperimento molto interessante nel quale abbiamo fatto gestire al team un intero progetto a partire dal contatto con il cliente e dall’offerta commerciale. Sebbene non sia compito del team di sviluppo occuparsi di certi aspetti, è comunque importante riuscire ad avere un’idea di massima di come possa funzionare il processo nella sua totalità e soprattutto essere in grado di fare delle stime realistiche sui tempi necessari per la progettazionee la realizzazione di un progetto a partire dalle specifiche del cliente, che possono essere anche molto fumose!
Con ACME abbiamo intavolato un gioco di ruolo in cui un progetto interno è stato affrontato come se arrivasse da un cliente esterno; il team ha proposto una call conoscitiva, durante la quale ha raccolto i primi requisiti, usandoli poi per produrre un preventivo di massima e proporre la stesura di un documento di progetto, ad un “prezzo” concordato e facente comunque parte dell’output finale del lavoro. Verificata la bontà del progetto con “il cliente” e fatto qualche aggiustamento, è stata sostanzialmente confermata la stima iniziale ed il progetto è potuto entrare nel vivo dello sviluppo.
Durante la fase di sviluppo il team ha prodotto quanto richiesto dal cliente adottando la metodologia già consolidata all’interno di Nephila, ed il mio contributo è stato semplicemente a livello di code review, con qualche suggerimento su come procedere su alcuni piccoli aspetti, ed una volta ultimato il progetto è stata fatta una retrospettiva per valutare cosa ha funzionato e cosa poteva andare meglio, e siamo rimasti tutti molto soddisfatti dall’esito dell’esperimento!
Con quali tecnologie lavori?
Nel corso degli anni ho avuto modo di lavorare con diverse tecnologie, alcune delle quali ho abbandonato lungo il percorso ed altre che ho invece coltivato ed uso tuttora. A livello di linguaggi lavoro principalmente con JavaScript/TypeScript sul frontend, mentre sul backend lavoro sia con JS/TS che con PHP. Faccio anche consulenze su tecnologie blockchain in ambito industriale, ed in quel caso utilizzo Solidity se risulta necessario implementare Smart Contract. A livello di framework e librerie ho molta esperienza con React lato frontend e con NestJS e Laravel lato backend.
In che modo ti occupi di supportare l’area sviluppo frontend del nostro team?
Inizialmente il mio intervento è stato quello di formare il team all’utilizzo di React, che era richiesto per lavorare su un progetto specifico; una volta completato il corso di formazione ho però continuato a supportare il team su quel progetto proponendo inizialmente una struttura architetturale per il frontend, e successivamente dando una mano per lo sviluppo delle parti più complesse e validando il lavoro svolto attraverso code review. Questo tipo di intervento di supporto è quello con cui ad oggi ancora supporto il team.
Ti occupi anche di formazione e per il nostro team, tra le tante attività, hai tenuto un corso su React. Come sono strutturati i tuoi corsi di formazione?
I miei corsi sono normalmente divisi in moduli che, sebbene siano potenzialmente autocontenuti, vanno spesso a costruire un percorso formativo attraverso una “narrativa” progettata nel corso degli anni sulla base dell’esperienza che ho raccolto formando numerosissimi team in tutta Italia. Ho peraltro diversi corsi attivi, e cerco di tenerne il programma e la struttura aggiornati e disponibili sul mio sito web personale.
Per una persona che si occupa di sviluppo web, destreggiarsi tra flussi, processi, scrittura di task può essere difficile. Fai formazione anche su questo? In che modo?
In questo contesto il lavoro di formazione è meno strutturato e più costruito su misura per le persone che devono seguire il percorso: non tutti hanno la stessa esperienza e, soprattutto, non tutti hanno la stessa indole e la stessa propensione nell'affrontare certi tipi di problematiche, quindi è importante cercare il più possibile di costruire un percorso formativo che sia focalizzato sui punti di forza della persona e che cerchi di farlo crescere, anche uscendo un po’ dalla comfort zone.
Quanto è importante la formazione per un team di sviluppo? Ed è più importante la formazione sulle hard skill o sulle soft skill?
In un team di sviluppo la formazione, a mio avviso, è importantissima, al punto che la ritengo un passaggio fondamentale attraverso il quale ogni team dovrebbe passare. Essere formati su uno strumento vuol dire non soltanto saperlo usare, ma comprenderne anche alcune sfumature che possono fare la differenza tra un lavoro funzionante ed un lavoro fatto allo stato dell’arte.
Le hard skill sono sicuramente importanti all’interno di un team di sviluppo, ma le soft skill non devono mai essere sottovalutate. Il lavoro di chi sviluppa software non è solo quello di scrivere codice, ma quello di raccogliere requisiti e risolvere problemi attraverso la progettazione di soluzioni che siano non solo corrette in senso generico, ma anche nel contesto specifico in cui vengono applicate, e saper apprezzare questi aspetti e applicarli nello sviluppo di un software, indipendentemente dalla sua complessità, può fare un’enorme differenza sia nella qualità del risultato finale che nel grado di soddisfazione finale del cliente.
Qual è l’ingrediente segreto per un buon percorso di formazione?
La pratica! Seguire un corso puramente frontale può essere utile per alcuni, ma mettere in pratica immediatamente quello che si è imparato permette di assorbire meglio i concetti appresi, e capire subito dove è necessario intervenire se ci sono dei problemi di comprensione.
Ti occupi anche di analisi e costruzione della soluzione. Allora vogliamo approfittarne per chiederti, quali sono gli elementi essenziali, secondo te, di un buon documento tecnico di requisiti?
Il requisito essenziale è quello di saper parlare con chi commissiona il lavoro. Ad essere diverse non sono solamente i progetti e le situazioni in cui vengono applicati, ma le persone che hanno la necessità di portarli avanti: saper riconoscere quale tipo di persona si ha davanti, e quali domande fare per ottenere una visione d’insieme più chiara e più completa è l’ingrediente fondamentale per produrre dei documenti che rispecchino quanto richiesto dal cliente.
Da un punto di vista più pratico, invece, trovo sia sempre necessario evidenziare all’interno dei documenti:
- Da dove si è partiti
- Quali erano le criticità iniziali
- Dove si è ora
- Quali sono le criticità oggi
- Dove si vuole arrivare
- Quali sono le possibili criticità di domani
Descrivere questi aspetti permette di avere la piena padronanza del progetto, e di discutere in anticipo di quelli che sono i punti nevralgici sui quali è necessario intervenire, e capire quali saranno le difficoltà che andranno affrontate in futuro.
Come ti trovi a collaborare con Nephila? Cosa apprezzi di più di questa collaborazione?
La collaborazione con Nephila per me è stata un’esperienza solamente positiva: ho trovato un team estremamente preparato ed efficiente, una filosofia remote-first che paga enormi dividendi sull’efficienza del team e, cosa a cui tengo molto, una grande vicinanza al mondo dell’open source che non si limita all’utilizzo ma anche alla contribuzione. L’unica cosa che manca è andare a trovare il team al prossimo meetup a Firenze!
***
Siamo arrivati alla fine della nostra chiacchierata con Gian Marco. Adesso, manca soltanto che venga a trovarci al prossimo retreat aziendale!
Se vuoi approfondire ancora meglio le attività di Gian Marco o entrare in contatto con lui, puoi consultare il suo sito web oppure aggiungerlo su Linkedin.
Adesso, tocca a te. Hai domande, riflessioni, spunti da condividere? Ti aspettiamo nei commenti.
Alla prossima intervista! 😉