Sono stato responsabile tecnico di un complesso progetto multi-team con un altro collega nell'ultimo anno e mezzo. I giorni tipici vanno dalla navigazione tranquilla al caos assoluto, con più fuochi che bruciano contemporaneamente. Di seguito sono riportate alcune lezioni che ho imparato e alcuni suggerimenti che mi hanno mantenuto sano di mente e ci hanno aiutato a consegnare in tempo.

L'architettura e il codice saranno imperfetti

Una delle mie difficoltà è stata rimanere bloccata nel pensare a come avrei potuto migliorare la nostra base di codice e l'architettura dell'applicazione. In qualità di sviluppatore, sono orgoglioso della maestria e della qualità del software. Ho costantemente misurato la qualità del lavoro rispetto al mio standard e ho dimenticato che la valutazione proveniva da anni di esperienza nel design e nello sviluppo. Le intuizioni che vengono naturalmente con l'esperienza non sono sempre intuitive per un team di giovani sviluppatori. Di conseguenza, ho perso di vista i notevoli miglioramenti apportati dal mio team.

I requisiti e le priorità cambiano. L'architettura e il codice "perfetti" di oggi potrebbero non essere rilevanti la prossima settimana. Questi artefatti sono un mezzo per raggiungere gli obiettivi organizzativi, quindi dovrebbero essere evolutivi. Fintanto che mantengono una certa modularità e sono per lo più liberamente accoppiati e riutilizzabili, va bene se le soluzioni non hanno la forma esatta che abbiamo in mente per essere in grado di fornire. Invece di soffermarsi sulla qualità in aree meno critiche, è più scalabile guidare e fidarsi del team per capire come.

In qualità di collaboratore individuale, non ho alcuna autorità di gestione ufficiale, ma sono comunque responsabile del risultato delle persone con cui lavoro e della corretta consegna di un progetto. Nel frattempo, il mio output personale, se misurato dalle richieste pull unite, era stato il più basso da quando ero diventato uno sviluppatore. Mi ci è voluto un po' per realizzare quel detto: “Hai capito. Ecco le risorse e le informazioni di cui hai bisogno. Sarò qui se hai bisogno di aiuto. consente agli altri di apprendere e agire. Quando finalmente le cose iniziano ad andare nella giusta direzione per allinearsi con la nostra visione tecnica, è in qualche modo commovente.

L'autonomia è un vantaggio, ma l'overcommit non lo è

Essere fidato di creare il mio magico arretrato di lavoro basato sulle attuali priorità del prodotto è soddisfacente. Ma sapere cosa ha un impatto e scegliere l'ambito e la granularità adeguati su cui concentrarsi è difficile.

Il mio archetipo nell'attuale team con cui lavoro è un mix di responsabile tecnico, architetto e risolutore. Il team di progetto è composto da due team di due persone, entrambi relativamente poco familiari con lo stack tecnologico . Alcuni membri erano nuovi nell'organizzazione. Il sistema di appartenenza legacy che stiamo modernizzando gestisce una parte fondamentale dell'attività di AMA. Molte applicazioni che si estendono su più domini all'interno del dipartimento si integrano con esso per operazioni aziendali specifiche.

Con uno spazio problematico così intricato, ogni giorno vengo trascinato in un milione di direzioni. Tutto ha un costo opportunità: dedicare tempo alla preparazione di una proposta per migliorare la robustezza e la scalabilità della nostra architettura software sottrae tempo alle revisioni delle pubbliche relazioni e sblocca il team. Ma se diventassi troppo zelante con la direzione tecnica e il controllo, il mio team perderebbe preziose esperienze di apprendimento.

A volte è difficile decidere quando intervenire o restare al di sopra dell'acqua.

In qualità di collaboratore individuale veterano, sono consapevole delle cose non ottimali intorno a me: architetture che non si adattano, processi dannosi per la salute del team, opportunità di provare qualcosa di nuovo ecc. Tuttavia, fare tutto non è sostenibile. Punta di cappello al mio manager per avermi ricordato che il mio tempo è prezioso: fa miracoli per la mia salute delegare quando appropriato e concentrarmi su cose su cui sono in una posizione unica per lavorare. La delega è difficile perché risolvere qualsiasi problema è stato il mio strumento predefinito. Quindi questo è uno dei miei obiettivi di carriera per l'anno.

Le sfide tecniche sono lungi dall'essere l'unico problema

I miei anni di consulenza mi hanno insegnato bene un concetto: niente è mai solo un progetto informatico. I consulenti spesso indossano molti cappelli per aiutare i clienti ad avere successo, ed essere un capo tecnico amplifica questa nozione. Contrariamente ai concerti di consulenza, i progetti o le iniziative non "finiscono". C'è sempre più lavoro di manutenzione, più contesto generale da assorbire e ancora più terreno accidentato da percorrere.

Scrivere codice e creare soluzioni brillanti sono solo una parte della storia di successo di un progetto interdisciplinare di lunga data.

Ulteriori preoccupazioni includono garantire che le storie degli utenti abbiano il giusto livello di dettaglio tecnico, spiegare come determinate decisioni architettoniche si inseriscano nella visione generale, convincere altri gruppi con obiettivi concorrenti delle nostre priorità o collaborare con i leader del team per identificare i processi necessari e i cambiamenti culturali.

Purtroppo, a differenza del debugging, ottenere feedback sull'effetto del mio lavoro può richiedere settimane o mesi. Tuttavia, sono responsabile del risultato finale come responsabile tecnico. Ciò significa che devo considerare l'intero problema e svolgere altri compiti che porteranno avanti le cose ma cadranno nelle fessure se nessuno si fa avanti per attirare l'attenzione su di loro.

Pensieri finali

Il mio viaggio per diventare un leader tecnologico è stato pieno di sfide entusiasmanti e sono fortunato ad avere un ottimo sistema di supporto di leader e colleghi al lavoro. Inoltre, vedere una squadra prosperare ed essere riconosciuta per aver raggiunto traguardi vitali è incredibilmente edificante, in quanto dimostra la mia perseveranza e i capelli grigi sulla mia testa hanno davvero dato i loro frutti.

Winnie Ho è una Senior Software Developer presso l'Alberta Motor Association che ha un desiderio insaziabile di imparare, leggere e scrivere su tutto ciò che riguarda AWS e il web.