Le organizzazioni possono cercare soltanto le competenze che hanno imparato a nominare
Parlo spesso di Product Manager.
Probabilmente perché li ho incontrati molto prima di conoscere questo nome.
Fin da piccolo sono stato fortemente influenzato da mio padre e mio zio. Insieme univano due sensibilità diverse.
Uno aveva una grande empatia verso il cliente: cercava di capire ciò che desiderava e quale prezzo fosse giusto per lui.
L’altro aveva la stessa empatia verso la realtà tecnica ed economica del prodotto: che cosa fosse possibile realizzare, come costruirlo e a quali condizioni potesse reggere.
Lo facevano inconsciamente, senza definizioni o framework.
Ma insieme tenevano unita l’intera equazione del prodotto.
Serve un cliente.
Serve qualcosa che abbia valore per lui.
Serve un prezzo che ritenga giusto e che l’impresa possa sostenere.
Tutto il resto è rumore.
Non ho seguito un percorso universitario. Ho costruito molta della mia conoscenza con le mani dentro prodotti, clienti, aziende e problemi reali.
La pratica mi ha dato le domande.
Lo studio, nel tempo, mi ha permesso di trovare principi e parole capaci di spiegare ciò che avevo vissuto.
Forse è anche per questo che ho riconosciuto facilmente il Product Manager. Quel ruolo assomigliava a qualcosa che conoscevo già.
Con i System Architect è andata diversamente.
Non li ho ignorati perché li considerassi poco importanti.
Li ho ignorati perché ne sapevo troppo poco per riconoscerli.
Prima arriva il problema. Poi cerchiamo le parole.
Nelle organizzazioni accade spesso la stessa cosa.
Prima osserviamo ritardi, rilavorazioni, conflitti tra funzioni, modifiche che producono effetti imprevisti e decisioni che devono essere continuamente ricomposte.
Vediamo molti problemi separati.
Se li interpretiamo come difficoltà di coordinamento, cerchiamo qualcuno che pianifichi meglio le attività.
Se li interpretiamo come mancanza di controllo, aggiungiamo verifiche e approvazioni.
Se li interpretiamo come problemi di esecuzione, chiediamo alle persone di fare più attenzione.
Poi, qualche volta, ci accorgiamo che la radice è diversa.
Le parti del sistema sono state progettate senza rendere abbastanza chiari i confini, le relazioni e le dipendenze.
A quel punto il problema cambia nome.
Non è più soltanto coordinamento.
È architettura.
Solo dopo aver riconosciuto il problema iniziamo a cercare le parole per descriverlo. E soltanto quando possediamo quelle parole possiamo riconoscere le competenze necessarie per affrontarlo.
La selezione delle persone arriva alla fine di questo percorso, non all’inizio.
Una richiesta semplice può attraversare tutto il prodotto
Immaginiamo una richiesta apparentemente piccola: aggiungere una nuova funzione a una macchina.
Per il cliente può essere un pulsante in più.
Dentro l’organizzazione può significare modificare un componente meccanico, aggiungere un sensore, aggiornare il software, cambiare un collegamento elettrico, rivedere i test, aggiornare la documentazione e gestire nuovi ricambi.
La richiesta è una.
Le conseguenze attraversano l’intero sistema.
Il Product Manager deve comprendere se quella funzione risolve un problema reale, quale valore produca e quanto debba essere prioritaria.
Il System Architect deve osservare come quella scelta attraverserà il prodotto.
Quali parti coinvolgerà?
Quali dipendenze farà emergere?
Dove serviranno interfacce più chiare?
Quali vincoli dovranno essere rispettati?
Quali decisioni potranno essere cambiate in seguito e quali condizioneranno il futuro?
Il Product Manager governa soprattutto il valore e la direzione.
Il System Architect mantiene coerente ed evolutivo il sistema che dovrà realizzarli.
Non sono due ruoli in competizione.
Sono due responsabilità che devono parlarsi.
Un Product Manager senza una capacità architetturale vicina rischia di produrre promesse che il sistema farà fatica a sostenere.
Un System Architect senza orientamento al prodotto rischia di costruire soluzioni tecnicamente eleganti che non risolvono un problema abbastanza importante.
Il prodotto nasce quando valore, tecnica ed economia riescono a stare insieme.
Esattamente ciò che, senza chiamarlo così, avevo visto fare fin da bambino.
Il pensiero computazionale non è saper programmare
Alla base della capacità architetturale troviamo anche una competenza di cui in Italia si parla ancora poco fuori dalla scuola e dall’informatica: il pensiero computazionale.
Il nome può trarre in inganno.
Non significa pensare come un computer.
Non significa neppure saper programmare.
Significa affrontare un problema complesso cercando di separare ciò che è essenziale da ciò che è occasionale, scomporlo in parti comprensibili, rendere chiare le relazioni, riconoscere schemi e trasformare un’intenzione in qualcosa che possa essere realizzato e verificato.
Nel suo celebre contributo del 2006, Jeannette Wing collegava il pensiero computazionale proprio all’astrazione e alla scomposizione necessarie per affrontare attività e progettare sistemi complessi. Nasce dall’informatica, ma non rimane confinato al codice. Communications of the ACM
In Italia Antonio Camerlengo ha contribuito a portare il concetto dallo studente fino al manager informatico. Un passaggio importante, perché questa capacità riguarda anche chi deve progettare, decidere e governare, non soltanto chi deve programmare. Il pensiero computazionale
Il pensiero computazionale non coincide completamente con la capacità architetturale.
Ma ne costituisce una base importante.
E può essere stato sviluppato sul campo anche da persone che non hanno mai incontrato questa definizione.
I processi di selezione cercano sostantivi
Nei curriculum cerchiamo soprattutto elementi facilmente classificabili:
ruolo ricoperto, titolo di studio, anni di esperienza, certificazioni, strumenti e tecnologie conosciute.
Sono informazioni utili.
Ma non raccontano necessariamente come una persona pensa davanti a un problema complesso.
Un professionista può avere molti anni di esperienza tecnica ed essere bravissimo nel proprio ambito, senza riuscire a vedere le conseguenze che una scelta produce sulle altre parti del sistema.
Un altro può avere un percorso meno lineare e aver sviluppato una naturale capacità di collegare tecnologia, prodotto, processo ed economia.
I processi di selezione cercano sostantivi.
Le competenze, invece, si manifestano nei verbi.
Una persona dotata di pensiero architetturale:
- cerca di comprendere il problema prima di proporre una soluzione;
- scompone senza perdere la visione dell’insieme;
- distingue il principio dalla circostanza;
- rende visibili dipendenze, vincoli e ipotesi;
- spiega che cosa si guadagna e a che cosa si rinuncia;
- cerca un modo rapido per verificare ciò che ancora non sa;
- protegge le possibilità future senza complicare inutilmente il presente.
Queste capacità non emergono chiedendo soltanto:
“Quali strumenti conosci?”
Per osservarle serve mettere la persona davanti a un problema realistico, non completamente definito, e ascoltare il modo in cui cerca di comprenderlo.
Le funzioni HR non devono diventare esperte di architettura.
Devono costruire, insieme a chi conosce il prodotto e il dominio tecnico, situazioni nelle quali questa capacità possa manifestarsi.
Gli strumenti per descrivere e valutare queste competenze esistono.
Il problema è che sono ancora poco conosciuti e raramente tradotti nel linguaggio quotidiano delle organizzazioni.
Potrebbero essere già dentro le nostre aziende
Non tutte le imprese devono inserire immediatamente in organigramma un ruolo chiamato System Architect.
Ogni organizzazione che sviluppa prodotti complessi deve però presidiare la capacità architetturale.
E potrebbe scoprire di avere già al proprio interno persone che la esercitano senza un riconoscimento formale.
Spesso sono quelle che vengono chiamate quando qualcosa non funziona.
Conoscono la storia delle decisioni.
Vedono collegamenti che agli altri sfuggono.
Riescono a parlare con funzioni diverse.
Sanno che una modifica apparentemente locale può produrre conseguenze molto lontane.
Le coinvolgiamo per ricomporre il sistema dopo un problema.
Dovremmo imparare a coinvolgerle prima, quando il sistema viene progettato.
Perché la crescita aumenta il numero delle relazioni, delle dipendenze e delle conseguenze possibili.
A quel punto non riconoscere la capacità architetturale non è più una semplice lacuna terminologica.
Diventa fragilità organizzativa.
Anche il modo in cui è nato questo articolo dice qualcosa
Per costruire questo articolo ho utilizzato l’intelligenza artificiale come strumento di ricerca e confronto, non come fonte.
Mi ha permesso di raggiungere e mettere in relazione contributi diversi, facendo emergere un vuoto: gli strumenti esistono, ma sono ancora poco tradotti nel linguaggio delle organizzazioni italiane.
All’inizio pensavo di aver dimenticato un ruolo.
Adesso credo che il problema sia più profondo.
Mi mancava la parola che mi avrebbe permesso di riconoscerlo.
Il Product Manager indica dove deve nascere il valore.
Il System Architect mantiene il sistema capace di arrivarci.
Prima ancora di cercarli, dobbiamo imparare a riconoscerli.
Enrico Bonetto 