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.

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.