L’equilibrio specialista-generalista

Qual è il problema allora?#section1

Considerate il seguente scenario di progetto: qualcuno nel marketing ha un’idea. Ne discute con un designer, che ne fa un mockup in Photoshop. Il designer lo consegna al front-end developer, che si lamenta che il designer non ha considerato quanto sia difficile implementare X senza un oneroso hack di JavaScript. Finisce il suo lavoro e lo gira al backend developer, che dà fuori di testa perché il front-end developer non ha prestato la minima attenzione al modo in cui Y funzionerà con il CMS aziendale.

Vi suona familiare?

Creare piccoli gruppi di specialisti divide i team e restringe il modo in cui lavoriamo insieme. Nel suo articolo “Development is Design”, Brad Frost descrive questo gap come un recinto al di là del quale gli specialisti tirano i propri pezzi di lavoro destinati ad altri specialisti che ci lavoreranno. Non è raro vedere team individuali di “specialisti” che si siedono tutti lontani gli uni dagli altri. Più l’azienda diventa grossa, più verranno aggiunte postazioni per gli specialisti, ciascuno con i propri task da completare e la maggior parte di questi lavorerà isolatamente. Isolamento che genera ambienti poco sani, restringe la collaborazione e crea dei silos.

La chiave sta nel trovare il giusto equilibrio tra specialisti e generalisti nel vostro team: usare entrambe perché se ne traggano vantaggi e favorire ambienti salutari e produttivi. In ultima analisi, la domanda è: come possono gli esperti collaborare meglio insieme?

Equilibrare il team#section2

Il fascino dei generalisti#section3

Nei miei anni di formazione, ho lavorato come sviluppatore in una piccola software agency. C’era completa libertà, assoluta fiducia e nessuna burocrazia. Se uno dei siti live aveva un bug, avevo carta bianca per entrare nel server live e consultare i log o controllare il file di configurazione per trovare gli errori. Non solo ne avevo il permesso, ma spesso mi era richiesto fare qualunque cosa. Era un’azienda talmente piccola che semplicemente non c’erano specialisti.

In questo modo, ho appreso delle nozioni rudimentali di design, ho imparato a muovermi su un server e in un database e sono diventato abbastanza sicuro di me stesso nello sviluppo lato client.

Questo tipo di approccio generalista allo sviluppo di siti web ha chiaramente dei vantaggi: i generalisti imparano come tutti i componenti funzionano gli uni con gli altri, sviluppano una comprensione e un giudizio critico sull’intero processo, e semplicemente sono anche bravi a fare cose perché ad esempio non aspettano che uno specialista faccia il lavoro sul database al suo posto.

I generalisti sanno mettere le mani sulla maggior parte delle cose ma non saranno mai dei master di tutto. A volte, avere qualcuno che sa a spanne come muoversi in qualcosa non è sufficiente.

Se avete una rock band composta da membri che sanno suonare “Smoke On The Water” su tutti gli strumenti, ma non avete qualcuno che sappia suonare a tutto volume un assolo di Slash o che sappia suonare la batteria come John Bonham, allora non riuscirete mai a fare il tutto esaurito nelle sale da concerto.

Ottenere il meglio dagli specialisti#section4

Gli specialisti sono gli esperti del loro settore. Hanno passato la loro carriera ad affinare le proprie capacità su un dato soggetto e quindi saranno per forza migliori di chiunque altro non abbia un’expertise equivalente.

Ma sfruttarli male risulterà in barriere alla collaborazione forte nel team. Per esempio, una volta in una grande azienda di software, mi fu dato il compito di indagare sul perché la build del nostro team non funzionava più. Ho capito che il problema era un riferimento mancante a una dipendenza nella definizione del build. Quindi, semplice da sistemare, no? Recupera la build definition e sistema le dipendenze. Però poi ho realizzato di non avervi accesso. Non potevo modificare direttamente la definizione della build e mi è stato detto che avevo bisogno di un “configuration specialist” per implementare la fix.

Quella che sarebbe stata una rapida modifica finì con il prendermi ore mentre aspettavo uno specialista di un altro team per sistemare un problema che sapevo come risolvere. Sfortunatamente, si tratta di uno scenario comune: piuttosto che collaborare con il resto dell’azienda, a gruppi isolati di specialisti viene data la proprietà unica di alcuni task.

Gli specialisti sono posizionati meglio in ruoli in cui lavorano insieme ad altri membri del team piuttosto che separatamente. Come dice Henrik Kniberg di Spotify: “È come una jazz band: sebbene ogni musicista sia autonomo e suoni il suo strumento, si ascoltano gli uni con gli altri.”

Tirate giù i muri#section5

Rimuovere gli ostacoli a una cultura di grande performance è il modo in cui avviene l’innovazione in un’azienda.

Adrian Crockroft, Netflix

La collaborazione è l’obiettivo finale quando si forma un team, dal momento che permette alle idee di scorrere liberamente e incoraggia l’innovazione. Creare gruppi di specialisti con la proprietà totale e poca o nessuna comunicazione tra team farà innalzare delle barriere non necessarie per la collaborazione. Quindi, come identifichiamo e rimuoviamo queste barriere?

Togliere i colli di bottiglia#section6

Una volta, ho lavorato in un’azienda in cui il team di sviluppo generalista batteva gli specialisti per quindici membri a uno. Quando gli sviluppatori richiedevano delle modifiche ad una build creata in automatico, dovevano aprire un ticket così che uno specialista potesse occuparsene. A un certo punto, gli sviluppatori aprivano ticket più velocemente di quelli che gli specialisti riuscivano a risolvere, causando un collo di bottiglia nel workflow.

Se gli sviluppatori fossero stati in grado di gestire da soli le build automatizzate, si sarebbe potuto evitare il collo di bottiglia. La conoscenza che aveva il configuration team avrebbe potuto essere condivisa tra gli sviluppatori, creando un approccio più generalista ed eliminando un silo.

Per identificare ed eliminare i vostri colli di bottiglia, chiedetevi:

• Quale parte del processo è la più lenta e perché?
• Fate affidamento su una singola persona per fare tutto il vostro sviluppo front-end? Perché?
• Ci sono altre persone nel team che hanno capacità simili o che mostrano un’attitudine all’apprendimento di quelle capacità?
• I titoli di lavoro restrittivi impediscono che le persone beneficino delle capacità e dell’esperienza reciproche?

Incoraggiate la comunicazione#section7

Ho visto aziende i cui i tester del software e gli sviluppatori erano team completamente indipendenti. I tester venivano spesso tirati in ballo solo alla fine del processo di sviluppo, quando ricevevano un modulo di test basato sui requisiti originali. Ma i requisiti possono cambiare e in effetti cambiano durante il processo di sviluppo, il che, quando i team operano completamente indipendentemente, può portare a molte incomprensioni e a una perdita di produttività.

Includere i tester durante il processo di sviluppo avrebbe migliorato la comunicazione e la performance. Al contrario, come conseguenza della separazione dei team, le release dei progetti avevano sofferto.

Ci sono dei modi per limitare questi tipi di divisioni e per promuovere la comunicazione nei team:

• Cercate di sistemare gli spazi di lavoro così che i team del progetto possano sedersi insieme. Se non potete farli sedere tutti insieme, assicuratevi che abbiano almeno una conversazione al giorno riguardante il progetto.
• Il lavoro da remoto è un privilegio ma è possibile solo se vi rendete disponibili alle discussioni. Un gran beneficio derivante dal lavorare in ufficio è essere in grado di andare alla scrivania di un collega e semplicemente chiedergli qualcosa. Il lavoro da remoto dà l’impressione che le persone siano irraggiungibili. Se dovete lavorare da remoto, allora assicuratevi che i vostri colleghi si sentano a loro agio a contattarvi.
• Scrum è un grande tool per incoraggiare la comunicazione, specialmente gli stand-up giornalieri, durante i quali ogni membro del team descrive quello a cui sta lavorando e se ci sono problemi per cui ha bisogno d’aiuto.

Riempite le mancanze di capacità#section8

Al vostro team mancano le skill necessarie per completare un progetto o terminarlo in maniera efficiente? Il team non ha familiarità con un particolare approccio o con una determinata tecnologia? Gli manca la sicurezza richiesta per superare con successo un problema? Usate gli specialisti come mezzo per educare il vostro staff:

• Fate venire uno specialista da qualche altro settore dell’azienda o, se le skill non ci sono internamente, assumete un consulente.
• Non permettete agli specialisti di risolvere il problema in isolamento. Date ai membri del team l’opportunità di lavorare a stretto contatto con loro, di imparare dalla loro esperienza e di cominciare a crearsi le capacità che a loro mancano.
• Incoraggiate i vostri specialisti ad organizzare dei workshop. I workshop sono anche un modo carino per instaurare una relazione interattiva tra gli specialisti e i generalisti, poi aprite la comunicazione e favorite un ambiente di condivisione della conoscenza.

Promuovete la condivisione della conoscenza#section9

Una volta ho lavorato in un team che sosteneva l’identificazione dei silos. Eravamo incoraggiati a lavorare con l’intero sistema e nessun singolo sviluppatore possedeva una specifica area, sebbene le persone avessero le proprie preferenze: io gravitavo più verso il client-side, mentre un collega preferiva i web services.

Quando ho ammesso di non aver familiarità con il modo in cui funzionavano i web services interni all’azienda perché non ci avevo lavorato molto, i miei colleghi ed io decidemmo di alternarci tra il lavoro client-side e i web service durante lo sprint successivo, condividendo in questo modo la nostra conoscenza.

Ci sono molti modi per promuovere questo tipo di condivisione della conoscenza, che è fondamentale per l’innovazione e per una cultura collaborativa.

Portatevi il pranzo al lavoro#section10

Nella mia attuale azienda facciamo regolarmente dei pranzi in cui tutti portano il proprio pasto da casa da mangiare mentre un collega fa una talk informale su un argomento che ci interessa. Il pranzo da casa spesso genera interessanti discussioni tra i partecipanti: mi ricordo di alcune occasioni in cui una feature tecnica o una procedura si è fatta strada nei nostri processi formali in seguito ad un fervente pranzo di questo tipo.

Scott Hanselman di Microsoft suggerisce che le aziende “facciano dei pranzi tecnici di questo tipo almeno due volte al mese ed incoraggino tutti a presentare almeno una volta all’anno.” È una buona opportunità per incoraggiare un dibattito salutare tra colleghi con i quali non si collaborerebbe necessariamente su base regolare.

Corporazioni#section11

Nel suo articolo “Scaling Agile at Spotify with Tribes, Squads, Chapters and Guilds” (PDF), Henrik Kniberg definisce una corporazione come “un gruppo di persone che vogliono condividere conoscenza, strumenti, codice e pratiche.” Spotify usa le corporazioni per colmare i divari tra i team dell’azienda. Per esempio, uno sviluppatore probabilmente incontrerà un problema che un altro sviluppatore all’interno dell’azienda ha già risolto. Che senso ha duplicare il lavoro?

Formare una corporazione fa sì che le soluzioni comuni vengano comunicate. È un’opportunità per condividere esperienze tra i team.

Nella mia azienda attuale, ogni team ha almeno un tester; i tester appartengono anche a corporazioni di QA separate, così da poter mettere insieme le proprie conoscenze. È stato un enorme successo: le procedure di test sono state standardizzate tre i team e le tecnologie come Selenium sono state introdotte nello stack di test.

Modelli open-source interni#section12

Limitate la percezione di possesso introducendo dei modelli interni di open source. Date a tutti la possibilità di contribuire al vostro codice sorgente o ai vostri design sostituendo i sistemi basati su ticket con un modello simile alle pull request di GitHub. Se siete competenti e a vostro agio nel fare un cambiamento ad una codebase che si trova nell’“area” tra due team, allora perché non dovreste? L’altro team può agire come curatore del progetto rivedendo ogni invio di codice e ogni feedback, ma indovinate un po’… Adesso state collaborando!

Hack days#section13

I progetti su cui state lavorando sembrano un po’ stantii? Provate a fare una gara come azienda oppure organizzate un hack day per rimettere in moto le idee:

• Organizzate un Ludum Dare aziendale, in cui il miglior gioco realizzato alla fine dell’hack day vince.
• Non è necessario che sia solo un giorno. Spotify fa regolarmente delle hack week. Potreste addirittura trovare qualcosa che potete presentare all’azienda o a un cliente.
• The National Health Service fa annualmente degli hack days in UK, a cui i professionisti digitali locali sono incoraggiati a partecipare. Lavorano per risolvere il problema presentato dai dottori e dallo staff del NHS con qualsiasi tecnologia abbiano tra le mani. È incredibilmente incoraggiante e si tratta di un’opportunità incredibile per restituire qualcosa a un’organizzazione così importante.

Gli hack days non devono essere collegati all’IT: incoraggiate le persone al di fuori del team di sviluppo a prenderne parte seguendo il modello del NHS. Gli hack days permettono alle persone di lavorare con i colleghi con cui normalmente non lavorerebbero, in una situazione in cui vengono incoraggiate nuove idee e viene premiata l’innovazione.

Andate avanti e collaborate#section14

Una forte collaborazione è cruciale per creare un team di successo e la collaborazione è favorita dalla rottura di barriere. Fate buon uso dei vostri specialisti integrandoli con i vostri generalisti e posizionandoli a guidare, insegnare e instillare passione nei vostri team.

Illustrazioni: {carlok}