{"id":551,"date":"2015-08-26T14:04:38","date_gmt":"2015-08-26T12:04:38","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/equilibrio-specialista-generalista\/"},"modified":"2015-08-26T14:04:38","modified_gmt":"2015-08-26T12:04:38","slug":"equilibrio-specialista-generalista","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/equilibrio-specialista-generalista\/","title":{"rendered":"L’equilibrio specialista-generalista"},"content":{"rendered":"

Un paio di anni fa ho passato un momento di crisi. C’era una netta divisione tra le discipline nella mia azienda: ero stato etichettato \u201cbackend developer\u201d e la definizione cominciava a starmi stretta. Non era l’etichetta ad essere sbagliata: la maggior parte delle mie ore lavorative le passavo scrivendo codice server-side. Mi piaceva ed ero bravo, ma non era tutto<\/em> quello che potevo fare.<\/p>\n

Ho sempre pensato di avere un insieme di capacit\u00e0 piuttosto generali e mettermi addosso un’etichetta significava che non mi era permesso lavorare ad altro che non ricadesse nel mio ambito di competenza come backend developer. Sentivo di avere un unico ruolo e, sfortunatamente, non si tratta di una divisione che ho trovato esclusivamente nella mia azienda: \u00e8 onnipresente nel settore.<\/p>\n

\n

Qual \u00e8 il problema allora?<\/h2>\n

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\u00e0 fuori di testa perch\u00e9 il front-end developer non ha prestato la minima attenzione al modo in cui Y funzioner\u00e0 con il CMS aziendale.<\/p>\n

Vi suona familiare?<\/p>\n

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

La chiave sta nel trovare il giusto equilibrio tra specialisti e generalisti nel vostro team: usare entrambe perch\u00e9 se ne traggano vantaggi e favorire ambienti salutari e produttivi. In ultima analisi, la domanda \u00e8: come possono gli esperti collaborare meglio insieme?<\/p>\n<\/div>\n

\n

Equilibrare il team<\/h2>\n

Il fascino dei generalisti<\/h3>\n

Nei miei anni di formazione, ho lavorato come sviluppatore in una piccola software agency. C’era completa libert\u00e0, 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<\/em> fare qualunque cosa. Era un’azienda talmente piccola che semplicemente non c’erano specialisti.<\/p>\n

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.<\/p>\n

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\u00e9 ad esempio non aspettano che uno specialista faccia il lavoro sul database al suo posto.<\/p>\n

I generalisti sanno mettere le mani sulla maggior parte delle cose ma non saranno mai dei master di tutto<\/em>. A volte, avere qualcuno che sa a spanne<\/em> come muoversi in qualcosa non \u00e8 sufficiente.<\/p>\n

Se avete una rock band composta da membri che sanno suonare \u201cSmoke On The Water\u201d 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.<\/p>\n

Ottenere il meglio dagli specialisti<\/h3>\n

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

Ma sfruttarli male risulter\u00e0 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\u00e9 la build del nostro team non funzionava pi\u00f9. 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\u00f2 poi ho realizzato di non avervi accesso. Non potevo modificare direttamente la definizione della build e mi \u00e8 stato detto che avevo bisogno di un \u201cconfiguration specialist\u201d per implementare la fix.<\/p>\n

Quella che sarebbe stata una rapida modifica fin\u00ec 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\u00e0 unica di alcuni task.<\/p>\n

Gli specialisti sono posizionati meglio in ruoli in cui lavorano insieme<\/em> ad altri membri del team piuttosto che separatamente. Come dice Henrik Kniberg di Spotify<\/a>: \u201c\u00c8 come una jazz band: sebbene ogni musicista sia autonomo e suoni il suo strumento, si ascoltano gli uni con gli altri.\u201d<\/p>\n<\/div>\n

\n

Tirate gi\u00f9 i muri<\/h2>\n
\n

Rimuovere gli ostacoli a una cultura di grande performance \u00e8 il modo in cui avviene l’innovazione in un’azienda.<\/p>\n

Adrian Crockroft, Netflix<\/a><\/p><\/blockquote>\n

La collaborazione \u00e8 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\u00e0 totale e poca o nessuna comunicazione tra team far\u00e0 innalzare delle barriere non necessarie per la collaborazione. Quindi, come identifichiamo e rimuoviamo queste barriere?<\/p>\n

Togliere i colli di bottiglia<\/h3>\n

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\u00ec che uno specialista potesse occuparsene. A un certo punto, gli sviluppatori aprivano ticket pi\u00f9 velocemente di quelli che gli specialisti riuscivano a risolvere, causando un collo di bottiglia nel workflow.<\/p>\n

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\u00f9 generalista ed eliminando un silo.<\/p>\n

Per identificare ed eliminare i vostri colli di bottiglia, chiedetevi:<\/p>\n