Riconoscere il ruolo di front-end developer

Quando ho cominciato a lavorare come web developer nel 2009, passavo la maggior parte del mio tempo a realizzare layout HTML/CSS dai design comp. Il mio lavoro era lo step finale di un processo lineare nel quale designer, clienti e altri stakeholder prendevano virtualmente tutte le decisioni.

L’articolo prosegue sotto

Sia che lavorassi per un’agenzia sia come freelancer, non c’era spazio per l’input di un developer sul lavoro del cliente, al di là di quando eravamo chiamati a rispondere a domande tecniche specifiche. La maggior parte del tempo mi veniva chiesto di confermare che fosse possibile avere una semplice feature, come aggiungere uno slide di contenuti o adattare un’immagine caricata dal CMS.

Negli anni seguenti, man mano che lo sviluppo front-end si faceva sempre più impegnativo, le skill dei developer hanno cominciato ad evolversi, portando a più frustrazione. Molte organizzazioni, incluse quelle per cui lavoravo, seguivano un approccio a cascata tradizionale, che ci teneva al buio fino a che il progetto non era pronto per la scrittura del codice. Tutto ricadeva sulle nostre spalle, spesso in là nel calendario, senza spazio perché potessimo aggiungerci del nostro. Anche se spesso eravamo tenuti in gran considerazione dai nostri compagni di team, non c’era ancora modo per noi di contribuire ai progetti all’inizio del processo. Ogni volta che condividevamo un’idea o segnalavamo un problema, era già troppo tardi.

Quasi dieci anni dopo, ne abbiamo fatta di strada come front-end developer. Dopo anni in cui abbiamo lavorato sodo per diventare professionisti migliori e avere un impatto maggiore sui progetti, molti sviluppatori sono ora in grado di occupare una versione più soddisfacente del ruolo.

Ma c’è ancora del lavoro da fare: sfortunatamente, alcuni sviluppatori front-end con delle skill incredibili sono ancora limitati al lavoro “PSD-to-HTML”. Altri si trovano in una posizione migliore all’interno dei propri team, ma spingono ancora per un ruolo più prominente in cui le loro idee possano essere adottate.

Sebbene sia orgoglioso di credere di fare parte del gruppo che si è evoluto con il ruolo, continuo a combattere per la nostra sedia al tavolo. Spero che condividere la mia esperienza aiuterà altri a combattere con me.

La mia strada per guadagnarmi una sedia al tavolo#section1

Il mio ruolo ha cominciato a cambiare il giorno che ho guardato un’ispirante talk di Seth Godin, che mi ha aiutato a realizzare di avere il potere per cominciare a fare dei cambiamenti per rendere il mio lavoro più appagante. Con la sua raccomandazione a pretendere responsabilità sia che si lavori per un capo sia per un cliente, Godin mi ha dato la spinta di cui avevo bisogno.

Non mi aspettavo di fare un passo da gigante: il giusto per sentirmi come se fossi in marcia sulla strada giusta.

Fare piccoli passi all’interno di un piccolo team<#section2

La mia prima occasione per testare le acque è stata ideale. Mi ero appena messo in società con un piccolo studio di design ed eravamo un team di cinque persone. Dal momento che sono sempre stato aperto riguardo al mio debole per il buon design, non era difficile vendergli l’idea di farmi cominciare ad essere un po’ più coinvolto nel processo di design e cominciare a dare un feedback tecnico prima che i comp fossero presentati al cliente.

I risultati sono stati sorprendentemente incredibili e hanno avuto un impatto positivo sul lavoro di tutti. Ho cominciato ad avere gli hand-off di design che approvavo da un punto di vista tecnico e con cui avevo anche una maggior connessione personale. Dal canto loro, i designer hanno notato con gioia che i siti web che lanciavamo erano rappresentazioni più accurate dei comp che mi avevano girato.

Dopo alcuni mesi, ho cominciato a sentire che le mie skill stavano finalmente avendo un impatto sui progetti del mio team. Ero soddisfatto del mio ruolo all’interno del team, ma sapevo che non sarebbe durato per sempre. Alla fine era ora per me di imbarcarmi in un viaggio che mi avrebbe riportato al classico ruolo di front-end developer, più vicino alla base della cascata.

Passare al grande palcoscenico#section3

Man mano che la mia carriera cominciava a decollare, mi sono trovato molto lontano da quell’ufficio con cinque scrivanie in cui tutto è cominciato. Adesso stavo lavorando con un team molto più grande e le sfide erano molto diverse. Sulle prime, ero sbalordito da come approcciassero il processo: l’intero team aveva un forte background tecnico, a differenza di ogni team con cui avessi mai lavorato, il che rendeva molto efficiente la collaborazione. Non avevo lamentele sulla qualità dei design con cui dovevo lavorare. In effetti, durante i miei primi mesi, ero costantemente spinto fuori dalla mia “comfort zone” e le mie capacità erano messe sotto la massima pressione.

Dopo che ho cominciato a sentirmi più a mio agio con le mie responsabilità, però, mi sono presto trovato la mia nuova sfida: aiutare a costruire una connessione più forte tra i team di design e di sviluppo. Sebbene collaborassimo regolarmente per produrre lavoro di alta qualità, questi team non parlavano sempre la stessa lingua. Per fortuna, l’azienda stava già facendo uno sforzo per migliorare la conversazione tra creativi e sviluppatori, quindi avevo tutto il supporto necessario.

Come team di sviluppo, ci eravamo spostati sulle moderne librerie di JavaScript, il che ci aveva condotto a lavorare alle nostre applicazioni usando un approccio strettamente “component-based”. Ma sebbene avessimo lentamente cambiato il nostro modo di ragionare, non avevamo cambiato i modi di collaborare con i nostri colleghi creativi. Non avevamo condiviso la nostra nuova vision in maniera appropriata. Il mio nuovo obiettivo era diventato la creazione di quella connessione.

Ero affascinato dal concetto “death to the waterfall” di Brad Frost: l’idea che i team di UX, visual design e development dovessero lavorare in parallelo, permettendo un livello più alto di iterazione durante il progetto.

Facendo pressione per muoversi progressivamente verso un workflow collaborativo, tutti nel mio team hanno cominciato a condividere più responsabilità e scambiarsi più feedback in ogni progetto. Gli sviluppatori hanno cominciato ad essere coinvolti nei progetti durante la fase di design, segnalando ogni questione tecnica che riuscivano ad anticipare. I designer si assicuravano di fornire input e indicazioni dopo che i progetti cominciavano a venire alla luce durante lo sviluppo. Una volta cominciato, abbiamo rapidamente cominciato a vedere risultati positivi e produrre lavoro gratificante (e premiato).

Anche se può suonare come se fosse una transizione tranquilla, ha richiesto una gran quantità di duro lavoro e dedizione da parte di tutti nel team. Non solo volevamo tutti produrre un lavoro migliore ma avevamo anche bisogno di allontanarci molto dalle nostre “comfort zone” e dai nostri vecchi processi.

Come potete fare pressione per un posto al tavolo#section4

Per quella che è la mia esperienza, fare progressi reali ha richiesto una combinazione di perfezionamento delle mie skill come front-end developer e di spingere il team a migliorare i nostri processi.

Quelli che seguono sono ulteriori dettagli su quello che ha funzionato per me e potrebbe anche funzionare per voi.

Fare dei cambiamenti come developer#section5

Anche se il cambiamento reale nel vostro ruolo potrebbe dipendere dalla vostra organizzazione, a volte le vostre singole azioni possono contribuire a far partire il cambiamento:

  • Dite la vostra. Nei team multidisciplinari, i developer sono noti per essere quelli molto metodici, critici e logici, ma non sempre i più comunicativi del branco. Ho visto molti che si sono lamentati sommessamente e hanno dichiarato di avere idee migliori su come le cose sarebbero dovute essere gestite, ma hanno abbandonato quei pensieri e sono passati a un altro lavoro. Dopo che ho cominciato a dar voce alle mie preoccupazioni, proponendo nuove idee, e vedendo piccoli cambiamenti all’interno del mio team, ho provato un’inaspettata spinta nella mia motivazione e ho notato che altri hanno cominciato a vedere il mio ruolo in maniera diversa.
  • Siate sempre coscienti di quello che sta facendo il resto del team. Uno degli errori più comuni che tendiamo a fare è di concentrarci solo sul nostro mestiere. Per connetterci con il nostro team e migliorare nel nostro ruolo, dobbiamo capire gli obiettivi dell’organizzazione, l’insieme di skill dei nostri colleghi, i nostri clienti e praticamente ogni altro aspetto del nostro settore che di solito pensavamo non fosse degno del tempo di un developer. Una volta che ho cominciato a capire meglio il processo di design, la comunicazione con il mio team ha cominciato a migliorare. Lo stesso vale per i designer che hanno cominciato a imparare di più sui processi che usiamo come front-end developer.
  • Tenete in forma le vostre skill principali. Oggi le nostre responsabilità sono più ampie e ci viene costantemente chiesto di guidare i nostri team attraverso tecnologie non scoperte. Come front-end developer, non è insolito che ci venga chiesto di fare ricerca su tecnologie come WebGL o VR e di introdurle al resto del team. Dobbiamo rimanere aggiornati sulle ultime pratiche nelle nostre aree tecniche di pertinenza. La nostra credibilità è messa in gioco ogni volta che serve il nostro input, quindi dobbiamo sempre cercare di essere i migliori developer sul mercato.

Ripensare la professione all’interno dell’azienda#section6

Per trarre il massimo dal vostro ruolo di developer, dovrete persuadere la vostra organizzazione a fare dei cambiamenti chiave. Ciò potrebbe essere difficile da ottenere, dal momento che tende a richiedere a tutti i membri del vostro team di abbandonare le proprie comfort zone.

Per me, quello che ha funzionato sono state delle lunghe chiacchierate con i miei colleghi, inclusi designer, management e compagni sviluppatori. È duro per un manager rifiutare quando proponete un’idea per migliorare la qualità del vostro lavoro e chiedete in cambio solo dei piccoli cambiamenti. Una volta che il resto del team è a bordo, dovete lavorare duro e cominciare a implementare quei cambiamenti per continuare a far girare la palla:

  • Coinvolgete i developer nei progetti fin dall’inizio. Molte aziende hanno degli alti standard quando si tratta di assumere degli sviluppatori ma non traggono pieno vantaggio dal loro talento. Tendiamo ad essere dei pensatori logici, quindi di solito è una buona idea coinvolgere i developer in molti aspetti dei progetti su cui lavoriamo. Spesso ho dovuto fare il primo passo per essere invitato ai kickoff di progetto, ma una volta che ho cominciato a fare lo sforzo di fornire un input di valore, il mio team ha automaticamente cominciato a coinvolgere me e altri sviluppatori durante la fase creativa di nuovi progetti.
  • Programmate delle team review. Frequentemente sorgono dei problemi quando i team si presentano ai clienti senza aver tutti lavorato a turno sul progetto. Una volta che il cliente firma per qualcosa, può essere rischioso introdurre nuove idee, anche se aggiungono valore. Gli sviluppatori, i designer e altri giocatori chiave devono radunarsi per le team review prima di consegnare il lavoro. Come developer, a volte potreste dover alzare la mano e investire parte del vostro tempo per aiutare i vostri colleghi di team a revisionare il loro lavoro prima che lo presentino.
  • Fate lavorare insieme le persone. Ogni qualvolta sia possibile, mettete insieme le persone in una stessa stanza. Tendiamo a fare affidamento sulla tecnologia e spingiamo per comunicare solo via chat e email, ma c’è un valore reale nel tempo passato insieme di persona. È sempre una buona idea avere diversi membri del gruppo seduti insieme o almeno sufficientemente vicini per delle conversazioni di persona regolari, così che possano condividere il feedback più facilmente durante i progetti. Se il vostro team lavora da remoto, dovete cercare delle alternative per ottenere lo stesso effetto. Delle video chat occasionali e lo screen sharing possono aiutare i team a condividere feedback e a interagire in real time.
  • Riservate del tempo per l’istruzione. Di tutti i team in cui ho lavorato, quelli che coltivano una cultura di condivisione della conoscenza tendono a lavorare in maniera più efficiente. Delle presentazioni semplici e casual tra colleghi di diverse discipline possono essere vitali per creare una varietà di skill senza soluzione di continuità nel team. Quindi, è importante incoraggiare i membri del team a insegnare e imparare a vicenda.
    Quando abbiamo preso la decisione di usare solo un’architettura “component-based”, abbiamo preparato una semplice presentazione per il design team che desse loro una panoramica di come avremmo tutti tratto beneficio dal cambiamento nel nostro processo. Poco dopo, il team ha cominciato a consegnarci dei comp di design che erano allineati al nostro nuovo approccio.

È giusto dire che lo sviluppatore moderno non può semplicemente nascondersi dietro alla tastiera e aspettarsi che il resto del team gestisca tutte le decisioni importanti che definiscono il nostro workflow. Il nostro ruolo richiede che si vada oltre il codice, si condividano le nostre idee e si combatta duramente per migliorare i processi in cui siamo coinvolti.

Sull’autore

Ronald Méndez

Ronald Méndez è un developer Venezuelano che vive in Argentina, dove lavora come Front-End Lead per MediaMonks. Sostiene di essere un ingegnere con una grande sensibilità per design e animazione, il che, in qualche modo, gli ha fatto guadagnare un posto come membro della giuria di FWA.

Nessun commento

Lascia un commento

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

Altro da ALA