Dave Hendricksen, software architect di successo, lavora da diversi anni alla
Thomson-Reuters e si occupa del ciclo di sviluppo di molti dei software che prendono vita in questa azienda.
Gli argomenti trattati nel suo libro sono suddivisi in 4 gruppi di competenze: le
technical skill, che Hendricksen ritiene scontate, le
relationship skill, le
personal skill e per ultime le
business skill. L'autore, attraverso questi quattro pilastri, costruisce una piramide composta da
12 competenze essenziali per diventare un buon software architect, e a ognuna dedica un intero capitolo.
L'autore imbastisce così una struttura narrativa semplice e schematica, ma allo stesso tempo analitica, adatta al linguaggio di ogni programmatore.
Nel
primo capitolo l'autore parla di una delle competenze relazionali che un software architect dovrebbe possedere: un
comportamento affabile con gli altri. Un bravo team leader dovrebbe sempre chiedersi "Come ti descriverebbero gli altri?". Da questo cambiamento di prospettiva si acquisice un approccio relazionale positivo con colleghi e collaboratori.
Successivamente, nel secondo capitolo si parla di
comunicazione, indicando: strategie, principi e modi in cui relazionarsi con la direzione aziendale. Citando
Epitteto, il filosofo greco, Hendricksen sostiene che "noi abbiamo due orecchie e una bocca quindi dovremmo ascoltare di più e parlare di meno". E' chiaro come l'autore sposti il baricentro della comunicazione verso l'ascolto.
Nel
terzo capitolo Hendricksen sposta poi la sua attenzione sulla capacità di
negoziazione, indispensabile nel lavoro quotidiano; strappa così un sorriso al lettore sostenendo che:
"Se non riesci ad accontentarli tutti, rendi tutti leggermente infelici". Il tema della negoziazione viene diviso in quattro concetti principali: il principio della negoziazione, le strategie, la preparazione al lavoro (tastando il terreno) e la difesa delle proprie decisioni.
L'autore prosegue illustrando il tema della
leadership: come diventare un buon leader, come sfruttare ogni opportunità e quando approfittare del momento buono. Anche in questo capitolo vengono delineate quattro linee guida: i principi della leadership, le strategie, l'organizzazione del tempo e come guidare gli altri. Il concetto che sta alla base di quest'ultimo passaggio è il
lavoro collaborativo e motivante: il buon team leader deve diventare una sorta di guida turistica che accompagna i propri collaboratori in un viaggio condiviso.
L'ultimo capitolo della sezione riguardante le capacità relazionali, inserisce nel ruolo del software architect tutte le caratteristiche
politiche che vanno sfruttate per poter trovare dei compromessi nel quotidiano. La politica è quindi al centro di questo capitolo e non è vista come un fattore necessariamente negativo nel lavoro del software architect. Partendo, infatti, dalla definizione letterale, secondo cui "la politica è un processo dove gruppi di persone prendono decisioni collettive", i concetti principali da tenere a mente sono: capire qual è la politica e la natura del mercato, identificarne il contesto, i principi, le strategie e le tempistiche.
Con il
sesto capitolo, inizia la sezione del libro dedicata alle
personal skill. L'autore affronta il tema della
trasparenza, approfondendo tutti gli aspetti ad essa legati. La strada per diventare "un architetto trasparente" si basa su questi step: rendersi conto che gli architetti vivono in una casa di vetro, essere trasparenti con se stessi, portare trasparenza nei propri progetti e nel rapporto con gli altri.
Nel
settimo capitolo, l'autore descrive il modo per diventare un architetto appassionato e come veicolare questa
passione per far sì che diventi un esempio per gli altri. Il percorso da seguire, secondo Hendricksen, è composto da questi punti: capire cos'è la passione, scoprirla, usarla come guida, proteggerla, inseguirla da subito e impare a farti coinvolgere lasciandoti trasportare.
"Becoming an architect who embraces passion means navigating a road filled with exitement, wonder, and a positive outlook".
Il capitolo successivo, l'
ottavo, tratta la necessità di un software architect di riuscire a
cambiare argomento molto rapidamente e di come, per questo, il suo punto di vista cambi continuamente: da una visione prevalentemente tecnica a una visione più indirizzata al business; da una visione molto dettagliata di alcuni (pochi) progetti a una visione molto più superficiale di molti progetti. Per diventare bravi software architect bisogna quindi essere competenti in diversi contesti e agire su diversi livelli.
Il
nono capitolo, segna l'ingresso nella terza e ultima sezione del libro dedicata alle
business skill e spiega la capacità di
comprendere il linguaggio del business nel momento in cui si dovrà prendere una decisione difficile per consentire all'azienda di crescere. Diventare un architetto attento al business significa capire il business, la propria azienda e i propri clienti, comprendere il contesto di business in cui agire, aiutare l'azienda a intendere meglio la tecnologia.
Il
decimo capitolo parla di
innovazione, e descrive in che modo scegliere tecniche o tecnologie innovative che non siano solo alla moda, ma che permettano all'azienda di crescere in maniera sostenibile. Partendo dalla definizione di innovazione, Hendricksen vuole che il software architect abbatta i confini e incoraggi tutti a essere aperti all'innovazione, che segua una propria direzione mescolando concetti essenziali e nuovi all'insegna della semplicità.
L'autore, nel penultimo capitolo, sostiene che il
pragmatismo è la giusta dose di realtà che deve essere introdotta nelle decisioni quotidiane relative all'architettura: "è facile sognare architetture di torri d'avorio, design elegante e un universo libero da costrizioni finanziarie. Tuttavia, il lavoro dell'architetto è di tenere il sogno in una mano e la realtà nell'altra per poi metterli insieme". Per diventare un architetto pragmatico, oltre alla nozione di architettura pragmatica, si deve avere visibilità su tutto quello che riguarda le decisioni di business, saper affrontare i rischi ed essere in grado di comunicare tutto questo.
Il libro, si chiude con un capitolo dedicato al concetto di
vision: "Vision è la danza con il futuro". Un buon software architect infatti deve sempre interpretare il volere dell'azienda e aiutare a formulare una proiezione di dove l'azienda potrebbe andare navigando nelle acque infide dei progetti tecnologici. Dopo aver familiarizzato con la definizione di
vision, un software architect deve trovare e stabilire una destinazione e una roadmap, scoprire quali sono i collaboratori che lo possono appoggiare e mettere in pratica la vision attraverso lo sviluppo di un obiettivo chiaro.
Nonostante sia stato scritto attraverso il punto di vista di un software architect, questo libro è adatto a tutti quelli che vogliono migliorare le proprie capacità comportamentali, relazionali e manageriali. La maggior parte degli sviluppatori software professionisti si pone come unico obiettivo quello di coltivare le proprie competenze tecniche tralasciando le competenze comportamentali che un vero leader dovrebbe invece possedere.
Nell'ambiente agile di oggi queste competenze stanno diventando sempre più importanti: vale quindi la pena non leggere questo libro tutto d'un fiato, ma consultarlo volta per volta e lasciar sedimentare i concetti, perché queste competenze non vanno semplicemente apprese, ma vanno interiorizzate e tradotte nel lavoro quotidiano e nella vita di tutti i giorni.