{"id":851,"date":"2018-07-30T11:07:33","date_gmt":"2018-07-30T09:07:33","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/riconoscere-il-ruolo-di-front-end-developer\/"},"modified":"2018-07-30T11:07:33","modified_gmt":"2018-07-30T09:07:33","slug":"riconoscere-il-ruolo-di-front-end-developer","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/riconoscere-il-ruolo-di-front-end-developer\/","title":{"rendered":"Riconoscere il ruolo di front-end developer"},"content":{"rendered":"

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

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

Negli anni seguenti, man mano che lo sviluppo front-end si faceva sempre pi\u00f9 impegnativo, le skill dei developer hanno cominciato ad evolversi, portando a pi\u00f9 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\u00e0 nel calendario, senza spazio perch\u00e9 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\u00e0 troppo tardi.<\/p>\n

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\u00f9 soddisfacente del ruolo.<\/p>\n

Ma c’\u00e8 ancora del lavoro da fare: sfortunatamente, alcuni sviluppatori front-end con delle skill incredibili sono ancora limitati al lavoro \u201cPSD-to-HTML\u201d. Altri si trovano in una posizione migliore all’interno dei propri team, ma spingono ancora per un ruolo pi\u00f9 prominente in cui le loro idee possano essere adottate.<\/p>\n

Sebbene sia orgoglioso di credere di fare parte del gruppo che si \u00e8 evoluto con il ruolo, continuo a combattere per la nostra sedia al tavolo. Spero che condividere la mia esperienza aiuter\u00e0 altri a combattere con me.<\/p>\n

La mia strada per guadagnarmi una sedia al tavolo<\/h2>\n

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

Non mi aspettavo di fare un passo da gigante: il giusto per sentirmi come se fossi in marcia sulla strada giusta.<\/p>\n

Fare piccoli passi all’interno di un piccolo team<<\/h3>\n

La mia prima occasione per testare le acque \u00e8 stata ideale. Mi ero appena messo in societ\u00e0 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\u00f9 coinvolto nel processo di design e cominciare a dare un feedback tecnico prima che i comp fossero presentati al cliente.<\/p>\n

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\u00f9 accurate dei comp che mi avevano girato.<\/p>\n

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\u00f9 vicino alla base della cascata.<\/p>\n

Passare al grande palcoscenico<\/h3>\n

Man mano che la mia carriera cominciava a decollare, mi sono trovato molto lontano da quell’ufficio con cinque scrivanie in cui tutto \u00e8 cominciato. Adesso stavo lavorando con un team molto pi\u00f9 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\u00e0 dei design con cui dovevo lavorare. In effetti, durante i miei primi mesi, ero costantemente spinto fuori dalla mia \u201ccomfort zone\u201d e le mie capacit\u00e0 erano messe sotto la massima pressione.<\/p>\n

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

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

Ero affascinato dal concetto \u201cdeath to the waterfall\u201d di Brad Frost<\/a>: l’idea che i team di UX, visual design e development dovessero lavorare in parallelo, permettendo un livello pi\u00f9 alto di iterazione durante il progetto.<\/p>\n

Facendo pressione per muoversi progressivamente verso un workflow collaborativo, tutti nel mio team hanno cominciato a condividere pi\u00f9 responsabilit\u00e0 e scambiarsi pi\u00f9 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).<\/p>\n

Anche se pu\u00f2 suonare come se fosse una transizione tranquilla, ha richiesto una gran quantit\u00e0 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 \u201ccomfort zone\u201d e dai nostri vecchi processi.<\/p>\n<\/div>\n

\n

Come potete fare pressione per un posto al tavolo<\/h2>\n

Per quella che \u00e8 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.<\/p>\n

Quelli che seguono sono ulteriori dettagli su quello che ha funzionato per me e potrebbe anche funzionare per voi.<\/p>\n

Fare dei cambiamenti come developer<\/h3>\n

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