Digital revolution: trasformare le aziende in ecosistemi digitali

Avvertenza

Questa storia non è proprio vera. Ma non è affatto finta.

È il resoconto verosimile di un processo di trasformazione aziendale e organizzativa basato su fatti ed eventi reali che però sono stati opportunamente modificati, adattati e combinati per far loro assumere un significato più generale e per dare al racconto anche un valore “didattico”: la narrazione di una trasformazione organizzativa ispirata ai principi e alle pratiche Lean/Agile e alle conoscenze e alle tecniche dell’Organisational Design.

Pertanto i nomi, l’azienda, i luoghi non fanno riferimento a elementi precisamente identificabili e i personaggi sono da intendersi come di fantasia. Anche se poi magari qualche persona potrà riconoscersi in essi.

La storia comincia nei primissimi mesi del 2021 ed è tuttora in svolgimento…

Barn raising e conoscenza collaborativa

Tanti anni fa, rimasi colpito nello scoprire una pratica diffusa nell’America rurale tra XVIII e prima metà del XX secolo, quella del barn raising, letteralmente “innalzamento del fienile”. Si trattava di un evento durante il quale una comunità di persone, il villaggio o il gruppo di case sparse di un certo territorio, si riuniva per lavorare insieme alla realizzazione di un edificio rurale (un “fienile”, appunto, o genericamente un magazzino) per una famiglia del gruppo o per tutta la comunità.

L’idea mi piacque perché da essa derivavano tante considerazioni sulla conoscenza collaborativa, ossia sul fatto che lavorare insieme a qualche progetto fa crescere il bagaglio di competenze di tutti coloro che si mettono insieme per svolgere quel compito.

L’ultima volta che sono stato da Alessio abbiamo parlato a lungo di sistemi antifragili con lo scopo di provare a portare qualche esperimento da loro. L’idea è ambiziosa e non so realmente se poi riusciremo a mettere in pratica qualcosa. Di fatto questa cosa dei sistemi “auto-assemblanti” e delle composable application che si riparano da sole è una cosa che mi ha appassionato da sempre. Realisticamente devo ammettere che potremmo concentrarci su questa “rivoluzione” solo dopo aver lavorato sul modello organizzativo dell’azienda e sulla piattaforma tecnologica nell’ottica di prepararla ad accogliere l’ecosistema digitale. Per questo motivo ho proposto ad Alessio di rivedersi con il preciso scopo di iniziare a lavorare sul tema Organizational Design e per farlo ho pensato che sarebbe stato utile invitare qualche collega. Alessio ha accolto con piacere questa mia proposta, quasi fosse in attesa che fossi io ad accennare all’argomento. Oltre al suo consueto, sano e positivo spirito critico che tanto ci ha aiutato a mettere a punto le iniziative fin qui realizzate, questa volta mi è sembrato che la sua preoccupazione non fosse tanto per l’edificio concettuale che stiamo costruendo, né per le pur notevoli questioni tecniche, quanto piuttosto per tutta quella serie di vincoli normativi, finanziari, procedurali che un’organizzazione grande si trova necessariamente ad avere. E questo in fin dei conti è una cosa positiva, i tempi sono maturi.

Un esperto di team e di organizzazioni digital

Per questo ho mandato un messaggio ad Alessandro Giardina [1] che fa parte indirettamente parte del mio staff e che conosco da tanto tempo. Alessandro è una delle persone giuste da coinvolgere se si vogliono affrontare tematiche di progettazione organizzativa.

Partito diversi anni fa da un ruolo tecnico - da quel mondo non si è comunque distaccato - ha svolto un percorso che lo ha portato a “lavorare con le persone” e con i team di sviluppo. Negli ultimi tempi si sta dedicando in modo particolare per far loro scoprire il modo di apprendere, collaborare, realizzare gli obiettivi nella maniera meno conflittuale possibile e più positiva per i singoli, i team, l’intera organizzazione. Alessandro non ci ha messo tanto a rispondermi e dopo qualche scambio in chat, incrociando i nostri calendari fissiamo la data per la video call. Dopo qualche giorno siamo collegati in video e inizio a descrivergli le ultime evoluzioni del caso che sto seguendo. Alessandro ascolta con attenzione quanto ho da raccontargli. Non ha problemi a entrare nel progetto che sto gestendo e a comprendere come stiamo procedendo con il tema degli ecosistemi digitali: è un argomento che conosce bene dal punto di vista organizzativo e non si intimidisce certo quando passiamo a parlare degli aspetti tecnici più approfonditi. A un certo punto arrivo a spiegare ciò che ho percepito nella conversazione con Alessio: qui ci fermiamo un po’ per chiarire alcuni aspetti “sociali” del percorso che sto guidando. E’ l’occasione per iniziare a confrontarmi sui miei principali dubbi. “Quindi Alessandro che ne pensi…. ho la sensazione che in questo percorso di transizione verso un'economia a ecosistemi digitali, sia giunto il momento di lavorare sugli aspetti culturali dell’organizzazione”. “Spiega meglio, cosa stai vedendo?” “Beh da un lato mi pare che i tempi siano maturi per iniziare a fare il cambio tecnologico e al contempo i miei interlocutori comprendono che anche i processi necessitano di una radicale rivisitazione per adeguarsi ai nuovi scenari di business”. “Beh, bene direi, no?”. “Si bene, il primo passo forse è fatto. Ad oggi si è ormai compreso che per allineare l’azienda ai nuovi scenari di business in cui opera, sia necessario un nuovo paradigma applicativo, quello degli ecosistemi appunto. Osservo però che ancora non sia del tutto chiaro come l’implementazione di questo nuovo paradigma richieda anche un cambio al modello organizzativo che in molti casi è sempre più anacronistico rispetto al mondo esterno”.

Come funzionano le organizzazioni (grandi)

Con il suo tipico tono pacato, Alessandro comincia: “Si probabilmente hai colto il punto essenziale. "Anche io vedo aziende che, quando crescono sopra una certa dimensione, si burocratizzano, creando silos funzionali, come dipartimenti o uffici di competenza. Diventa una vera sfida mantenere i gruppi di lavoro allineati al flusso di valore che producono per l'utente e per l'azienda. L'allineamento al flusso di valore è fondamentale per conservare l'efficienza operativa e l'efficacia nella consegna del valore al cliente. Questo approccio sottolinea quanto sia importante che le attività e i processi dell'organizzazione contribuiscano direttamente alla creazione di valore per l'utente finale, minimizzando gli sprechi e migliorando il flusso di lavoro. Nelle grandi organizzazioni, il formarsi di silos funzionali può interrompere questo flusso. Ogni dipartimento può diventare troppo focalizzato sui propri obiettivi specifici, perdendo di vista come il loro lavoro supporti la creazione di valore finale per gli utenti. Non c’è bisogno che ti spieghi il concetto di team end-to-end, ormai è una roba arci nota nel nostro ambiente. Ma non voglio essere originale per forza.

“Be’, sì, è qualcosa che sperimentiamo tutti” aggiungo, più per confermare ad Alessandro che proprio questo è il punto di partenza del nostro discorso che per dire qualcosa di particolarmente brillante… “Se ci pensi il processo di evoluzione delle aziende è piuttosto tipico e per certi versi paradossale”. riprende Alessandro. “Nel piccolo, le startup funzionano molto bene proprio perché il team è tutto lì, focalizzato a creare valore: è già per forza di cose stream-aligned. Ma poi, quando crescono, riescono a mantenere un team tutto focalizzato sullo stream di valore? Purtroppo la risposta, nella maggior parte dei casi è ‘no’. Le aziende quando crescono finiscono per adottare, strano a dirsi, vecchi modelli di organizzazione, vuoi di tipo piramidale, vuoi basati su team specializzati e separati. E alla fine degenerano nel proverbiale ‘carrozzone burocratico’. Chi più e chi meno, ma insomma…”. “Sembra che certi canti di sirena siano irresistibili” “Bah no so…. forse è semplicemente che sono tanti anni, dal dopoguerra in poi, che noi ci organizziamo in questo modo, che ci dividiamo in unità di lavoro fra pari e che poi ci affidiamo a un capo che ci guida. Il modello del team auto-organizzato è relativamente nuovo, ci vorrà del tempo. “si anche se poi sappiamo che il modello socio-organizzativo che siamo ricercando probabilmente è proprio quello che la rivoluzione industriale ha demolito… “Stai pensando alla Vasca di bagno di Taylor?” mi guarda con un sorriso Alessandro. “ah ah, si, quel disegno è quanto mai esemplificativo". “Le sfide che si parano di fronte a chi vuole realizzare quelle che tu chiami applicazioni cross-dipartimentali all’interno della stessa azienda (I-O) o fra aziende differenti (X-O) sono le stesse che si combattono ogni giorno da anni all’interno di una grande azienda. Il tema dei gruppi separati che devono collaborare, vale all’interno delle singole organizzazioni e a maggior ragione finisce per impattare quando si vogliono far lavorare insieme organizzazioni diverse”. “Sì,” lo assecondo“ è quello che rende più difficili le interazioni di tipo Cross Organisations, o X-O come siamo soliti dire noi”. “È una sfida importante”, riprende Alessandro, “e non la scopriamo noi adesso: si tenta di affrontarla con approcci un po’ diversi, ma i tentativi ci sono. È una sfida organizzativa, ma soprattutto culturale”.

Tra Team Topologies e unFIX

“Quello che ha fatto Team Topologies [2] è di razionalizzare e spiegare perché i team che sono stream-aligned hanno valore e quindi trovare un modo per organizzarsi con questi stream team e una serie di altri attori che sono a supporto. Jurgen Appelo, dal canto suo, con unFIX [3], fa un passo ulteriore: pur ispirandosi a Team Topologies e a diversi altri modelli organizzativi, include nel suo framework organizzativo una serie di altri attori, di altre strutture ‘di supporto’ — come il management, gli aspetti legal, le funzioni HR — che in effetti esistono nell’organizzazione e che non vanno eliminate concettualmente.

La tendenza degli ultimi venti anni è stata quella di ridurre le dipendenze, e concentrare all’interno del singolo team tutte le competenze necessarie a fare qualcosa — l’ormai canonico cross-functional team. Jurgen Appelo invece ci dice che le dipendenze ci sono, non è possibile eliminarle e anzi possono anche essere una cosa buona, a patto che ve ne sia consapevolezza e si sappia come governarle”.

Per un attimo rifletto su quante idee, quanti modelli organizzativi, quanti approcci diversi ho visto proporre in questi ultimi venti anni nell’ambito organizzativo delle aziende digitali, e non solo. Vorrei fare una serie di considerazioni: quanti di essi hanno goduto di un periodo di assoluto splendore per poi cadere nell’oblio? Quante enunciazioni di cui eravamo tutti entusiasti hanno retto la prova del campo? E, in positivo, quante “scoperte” abbiamo fatto nel continuo confronto con le realtà aziendali che poi abbiamo ritrovato nell’opera di qualche bravo imprenditore / manager / gruppo di studio che le ha proposte nelle maggiori conferenze internazionali? È stato, questo primo quarto di secolo del secondo millennio, un periodo di trasformazioni incredibili, non tutte positive, non tutte negative. Dobbiamo imparare a navigare in questo mare agitato della digital revolution. Ma mentre formulo rapidamente questi pensieri tra me e me, Alessandro ha già ripreso il filo del discorso: “E queste proposte che ad esempio fa Jurgen Appelo sono tutte belle e tutte valide. Ma poi… quando vai a implementarle in un’organizzazione… arriva il difficile, perché ci sono tanti casi diversi e tanti contesti differenti”. “Sì, ti seguo” faccio io.

Qualche caso reale

Alessandro continua: “Anzitutto sgombriamo il campo dall’idea che tutte le organizzazioni anche grandi siano sempre disfunzionali: a me è capitato di operare in situazioni di massimo ‘splendore’, con aziende che rilasciavano un flusso di valore costante. Ma anche questi casi poi possono ‘degenerare’ per tante ragioni: un caso tipico è che l’azienda viene acquisita da una più grande o, viceversa, incorpora altre realtà con i loro prodotti. Oppure pensa all’azienda che si quota in Borsa e allora deve seguire tutta una serie di norme legali particolari, oltre a tipiche pratiche che non sono neanche leggi, ma che devono comunque in qualche modo essere seguite. E qui iniziano a emergere delle differenze ‘culturali’, nel senso di cultura aziendale, che a volte sono solo diversità, in altri casi diventano fonte di conflitto… Poi va detto anche che, nonostante certe difficoltà, tutto sommato è possibile far lavorare abbastanza bene insieme le persone a livello di team, anche di team di aziende diverse. Le persone coinvolte spesso trovano dei working agreements e seguono delle pratiche agili come la review o le retrospettive che tutte quante facilitano sicuramente l’interazione. Ma poi, a un certo punto, arrivano dall’alto alcune ‘imposizioni’ che dipendono dalla cultura dell’azienda a cui si afferisce, e questo complica la vita dei team Cross-Organisation”. “Sì, è vero”, gli faccio eco. “Quando entri in un’azienda in cui non sei mai stato, dopo poco tempo riesci a riconoscere certi problemi tipici o comportamenti disfunzionali. In questo ci aiuta certamente l’esperienza, l’aver visto tanti scenari differenti ma simili fra loro, ma ci aiuta ancora di più il fatto di essere ‘attori esterni’ all’organigramma, cosa che ci conferisce quel giusto distaccamento (o non coinvolgimento emotivo e cognitivo) utile per vedere le cose con più oggettività”.

“Guarda,” riprende Alessandro, “ti faccio un po’ di esempi di situazioni tipiche, che tu avrai sicuramente sperimentato e che di certo non ti suoneranno nuove. Sono casi tipici che ben spiegano quali sono i problemi reali. Cominciamo con una questione quasi banale, ma che invece diventa cruciale, quella delle ferie”. “Sì,” lo assecondo ridendo, “noi questa ormai in certi casi la consideriamo un benchmark”. “Eh, appunto”, continua Alessandro. “Che cosa succede di solito? Che i team che devono lavorare su un prodotto, se sono formati e hanno una certa maturità, sanno auto-organizzarsi. E quindi sanno anche quando è il momento di andare in ferie compatibilmente con l’andamento del progetto. Ora però succede che, per policy proprie dell’azienda A, il loro ramo HR decida che le persone debbano andare in ferie, che so, tra fine aprile e inizio maggio, quando ci sono i ponti. E però le persone dell’Azienda B dovrebbero continuare a lavorare senza che i loro colleghi siano a disposizione. Immaginiamo che nel team dell’Azienda A ci sia, per esempio, il responsabile Quality Assurance del gruppo. Che fanno gli altri? Possono continuare a lavorare? Arriviamo a paradossi per cui il QA del team dell’Azienda A, che è ben consapevole di cosa vuol dire la sua assenza, va dal suo HR e lo prega di non mandarlo in ferie!” Ridiamo entrambi. In effetti la situazione è divertente, ma molto comune.

Alessandro riprende: “Oppure, un altro caso tipico del come sia possibile intralciare dall’alto il lavoro dei team di aziende diverse che si svolge più ‘in basso’ è quello dei permessi, nel senso di chi è autorizzato a fare determinate cose. Il dipartimento IT dell’Azienda A non vuol autorizzare dipendenti dell’azienda B a operare su sistemi della propria azienda: soltanto le persone dell’Azienda A hanno il diritto di modificare le pipeline perché per fare quello ci vogliono dei permessi particolari. Eh, ma poi succede che l’esperto di pipeline dei team X-O appartenga proprio all’Azienda B e non possa quindi ricevere tali permessi particolari dall’IT dell’Azienda A. Poi i team si autoorganizzano e quindi si arriva a situazioni tipo videochiamate con il Team A che condivide lo schermo del proprio tool di pipeline con il Team B e l’esperto dell’Azienda B, privo dei permessi, che dice ai colleghi del Team A di premere quel pulsante, far vedere quella pagina, scrivere quel codice, eseguire quel comando e così via”. Mi viene ancora da ridere, ma la situazione reale è proprio quella che sta descrivendo Alessandro nel raccontare questi casi vissuti. “La cosa che faccio io” riprende, “è proprio questa, vale a dire cercare di persuadere le organizzazioni a rilasciare un po’ certi vincoli, spiegandone i motivi. Ma più l’azienda con cui lavori è grossa, più queste cose sono difficili”.

Disaccoppiamento, composizione, piattaforme

Quanto mi dice Alessandro è molto chiaro e condivisibile. Cerco a mia volta di proporre una possibile soluzione: “Ma, a questo punto, non sarebbe meglio evitare di ‘costringere’ le due organizzazioni a lavorare insieme con dei team X-O e seguire un’altra strategia? Cioè si potrebbe ipotizzare che l’Azienda A e l’Azienda B producano dei servizi disaccoppiati, esposti su una piattaforma secondo certe regole e poi sarà l’Azienda C o il Team C che li utilizza, creando delle composable application e superando così quelle dipendenze e quei vincoli di cui stavamo parlando”.

Sempre la Legge di Conway

Alessandro mi risponde: “Sì, certo, come architettura è giusta, come sono spesso buone le soluzioni che vengono proposte dai tecnici. Ma il fatto è che qui noi parliamo di organizzazioni e dobbiamo confrontarci con la cosiddetta Legge di Conway [4] la quale afferma che le organizzazioni che devono progettare un’architettura (tecnologica o informativa) finiscono per produrre schemi copie della propria struttura organizzativa interna. In realtà dovresti fare l’esatto contrario, ossia creare organizzazioni a partire da un’architettura funzionale… ma poi c’è HR, c’è il Top Management e così via”. Insisto: “Tutto questo è chiaro, ma la mia idea era proprio di svincolarsi da questo creando appunto delle composable applications a partire da quello che l’azienda espone sulla sua piattaforma…” “Sì…” riprende Alessandro, “ma già convincere l’Azienda A e B a creare una piattaforma i cui servizi poi saranno sfruttati da un’Azienda C potrebbe risultare molto difficile. Ti potrebbero chiedere perché mai realizzare questa piattaforma se è qualcosa che non vendo e non posso fatturarla". “Eh” rispondo, “è proprio questo il discorso: devi venderlo, devi fatturarlo”.Alessandro continua: “Certo, ma questa idea che sia qualcosa di profittevole la devi far passare, verso il top management, e devi trovare il modo di parlare e convincere, il che potrebbe essere anche complicato”. “Sì” continuo io, “ma pensa a questo esempio: se io propongo non tanto un database o qualcosa del genere, ma un vero e proprio servizio ‘calcola prezzo’, questo potrà essere acquistato da qualcuno che da me compra questo, da un altro compra il servizio ‘carrello’ o quel che è, per comporre un’applicazione. Forse ho una visione troppo da Product Owner, o da imprenditore, ma non pensi che possa funzionare?”. “Sì” risponde Alessandro, “ma va fatto capire, tenendo ben presenti anche certe problematiche culturali e organizzative di cui abbiamo parlato. Ti racconto un altro caso reale”.

Piattaforme ed eccezioni

“C’è un’azienda che, per anni, ha dato grande libertà ai propri team non solo di creare prodotti, ma anche di definire il modello di business con cui vendere questo prodotto e di rilasciarlo ai loro clienti, occupandosi anche della messa in produzione. È chiaro che ognuno di questi prodotti ha un modello di business diverso, un sistema di pricing diverso, una base clienti diversa. Ci sono prodotti venduti a licenza, altri a consumo con dei token, altri con sistemi diversi. E poi ci sono prodotti che, per esempio, hanno un abbonamento base e uno avanzato, altri che hanno tre livelli di prezzo, altri che magari hanno gli stessi livelli ma li chiamano in modo diverso, che so ‘Pro’ ed ‘Expert’. Di certo, non siamo in presenza di un carrozzone centralizzato. Poi cosa è successo? Questa azienda è cresciuta facendo delle acquisizioni di concorrenti, in certi casi perché il loro prodotto era migliore e puntavano ad averlo; in altri casi, semplicemente per togliere di mezzo un competitor perché poi il prodotto dopo un po’ veniva chiuso. Ma, di fatto, tutto questo ha portato a un caos con decine e decine di prodotti, alcuni dei quali tendono a sovrapporsi. Allora hanno chiamato noi affinché realizzassimo una piattaforma in grado di gestire tutta questa complessità: un punto centralizzato in cui trovare la documentazione del cliente, la tipologia di contratto, se a consumo o ad abbonamento per esempio, la situazione di consumo / rinnovo di ciascun cliente e così via. Oltre a questo, si desiderava una uniformazione, ad esempio, del tipo di licenze vendute, sia nei livelli che anche nel nome”. Stavolta non ho capito dove vuole arrivare Alessandro, ma il suo racconto mi sta interessando e mi riporta alla mente vari casi simili a cui ho assistito. Alessandro continua: “A questo punto, dicevo, arriva il nostro intervento per sviluppare questa piattaforma; in fin dei conti un lavoro non difficile dal punto di vista tecnico. C’è un database normalizzato dei clienti, bisogna capire chi ha cosa e con quale formula (abbonamento? consumo?), organizzare le scadenze e i rinnovi oppure contare il consumo e provvedere alla vendita di pacchetti di token. Oltre a uniformare, come ti dicevo, i livelli delle varie formule di acquisto. Bene… Sai che succede? Succede che ci sono delle resistenze incredibili da parte dei singoli team che curavano i vari prodotti”. Mi inserisco: “Eh, ma in questi casi ci sono moltissimi aspetti che influiscono: dietro ognuno di questi prodotti c’è una responsabilità, c’è un valore, c’è anche una gelosia…” “Dici bene” mi fa eco Alessandro. “C’è una gelosia, ma c’è anche il fatto che in effetti è il team quello che conosce meglio il prodotto e sa qual è la base di clienti e il modello di business migliore per venderlo. E su questa cosa hanno probabilmente anche ragione a fare qualche resistenza. Ma, dall’altra parte il top management dice che la piattaforma va fatta con i criteri di armonizzazione dei vari prodotti, per porre fine a quel caos che il continuo accumulo di soluzioni diversificate ha prodotto. Bene, vuoi sapere come va a finire?” “E certo”, faccio io. “Va a finire che vincono i team di prodotto sul top management: le regole della piattaforma armonizzante restano un po’ dei sogni e il backlog del gruppo di lavoro che la sta realizzando è composto tutto da item del tipo ‘realizza l’eccezione per il sistema di licensing’, ‘realizza l’eccezione per le tipologie di livello di contratto’ e così via”. Ridiamo entrambi. Ma devo chiedere per forza qualcosa.

Soluzioni organizzative e tecniche

“Alessandro, per una situazione come questa, ci saranno anche delle soluzioni, no?”.“Certo” mi risponde. “Anche tu ne avrai provate”. “Sì”, faccio io. “Ma mi piacerebbe sentire prima le tue, per vedere se corrispondono”. Alessandro si ferma un attimo e poi, con tono quasi solenne afferma: “Alle sprint review e sprint planning del team che realizza la piattaforma, invitiamo anche i responsabili dei vari team di singolo prodotto, affinché si rendano conto del delirio che stanno causando”. Scoppio a ridere: “Non è esattamente quello a cui stavo pensando, ma mi pare comunque efficace…” “Sì”, riprende Alessandro. “Chiaramente non c’è solo questo. Per esempio, andiamo a cena tutti insieme? Invitiamo il manager dell’HR insieme al CTO e li mettiamo in condizione di avere una conversazione e uno scambio di pareri in un contesto rilassato e informale. Cosa che in azienda non farebbero mai perché la gerarchia dell’organizzazione e il modo in cui essa è strutturata non li fanno mai dialogare. In questo modo anche loro potranno sperimentare i problemi — feel the pain — e tentare di trovare dei compromessi, cosa che nella rigida struttura dell’organizzazione sarebbe ben più difficile”. Torno a riproporre la mia idea sulle composable application mettendo in luce che, nel momento in cui il modello di business rende vantaggioso anche in termini economici la “vendita” di determinati servizi su piattaforma, poi tutti avrebbero interesse a sviluppare un tale modello, sia chi offre i servizi, perché guadagna, sia chi li utilizza per costruire applicazioni. Alessandro è d’accordo, ma ha qualcosa da aggiungere: “È vero… pensa che la piattaforma di cui ti parlavo utilizza dei servizi combinandoli insieme. Per esempio usa Kong [5] come gateway, o Chargebee [6] come sistema per la gestione del licencing, e anche molti altri elementi. Ecco questi prodotti, queste tecnologie ti forniscono dei pezzetti di piattaforma realizzati con estrema cura, molto affidabili e performanti, a un prezzo equo, che sia in abbonamento o in pay per use. Poi è anche vero che ognuno si potrebbe scrivere la propria logica per il gateway o per il controllo degli accessi o per la gestione delle licenze, ma magari otterrebbe un risultato peggiore con sforzi maggiori. Invece ha già pronti questi componenti di alta qualità che gli servono e non deve far altro che assemblarli. Quindi, se già nell’azienda gli sviluppatori, a un livello tecnico, fanno questa cosa che funziona, perché non dovrebbe essere possibile farlo anche a livelli più elevati per i prodotti di punta?”. “La sfida diventa trovare un marketplace in cui vendere i propri servizi che altri potranno usare per fare qualcosa, no?” chiedo io. “La sfida è smettere di realizzare soluzioni in cerca di un problema e capire invece qual è il reale problema che vogliamo risolvere.” sentenzia Alessandro. “E questo vale in generale, ma ancor più in Italia. Tornando a quanto dicevo prima, ai vari Kong e Chargebee usati nella piattaforma, quello è un bel modo per creare componenti che possano vivere in un ecosistema digitale. Occorre che le aziende, in particolar modo le startup, si liberino di quella dimensione troppo sognatrice che poteva andar bene venti anni fa. È abbastanza insensato continuare a pensare di creare il prodotto Business-to-Consumer che rovescia tutto quanto: l’iPhone è arrivato quasi venti anni fa e non siamo tutti degli Steve Jobs. Invece, creare dei componenti Business-to-Business, tipo quelli che citavamo, capaci di risolvere un problema specifico, molto curati e ben performanti… be’, non sarà di sicuro esaltante come cercare qualcosa di analogo all’iPhone, ma di certo è un lavoro che porta valore a tante persone risolvendo dei problemi e che si colloca bene su un mercato. Certo dire di aver fatto una buona piattaforma di licencing grazie alla quale le aziende possono vendere le loro licenze non è esaltante o affascinante come inventare lo smartphone, ma è estremamente importante: un ecosistema fatto di composizione, di piccoli pezzi molto specializzati che funzionano benissimo richiede un cambiamento di mentalità in senso pragmatico e di cultura della product ownership”.

Una questione di product ownership

Quel che Alessandro ha appena detto mi risuona molto. In definitiva torniamo sempre al tema del prodotto e del valore. La sfida è fare bene il lavoro del product owner, identificando i bisogni e risolvendo i problemi. La differenza qui è la scala: non stiamo più sviluppando la singola app, ma un servizio che viene utilizzato in un contesto più ampio. Tenendo a mente anche che qui stiamo lavorando in un’ottica di collaborazione tra le aziende, dove vanno tenute presenti componenti anche molto variate e diversificate. So che potrà aggiungere ulteriori riflessioni, e mi congedo da lui solo temporaneamente. “Non credere di essertela cavata con queste ‘storielle’ e basta”, gli dico scherzando. “Ho capito che ti piacciono le storie di vita vissuta e ne ho diverse altre da raccontarti, alcune delle quali proprio relative al mondo automotive in cui stai operando attualmente”. “Grazie Alessandro. Ci sarà sicuramente l’occasione. E credo anche presto, visto come si stanno muovendo le cose”.

Riferimenti

• [1]
• [La scheda personale di Alessandro Giardina sul sito Intré](https://www.intre.it/author/ale_giardina/).

• [2] Matthew Skelton – Manuel Pais,
• [*Team Topologies: Organizing Business and Technology Teams for Fast Flow*](https://teamtopologies.com/book). IT Revolution, 2019.

• [3]
• [*unFIX. Organization design for continuous innovation & better human experience*](https://unfix.com/).

• [4] Melvin Conway,
• [*How do committees invent?*](https://www.melconway.com/Home/pdf/committees.pdf). Datamation, April 1968.

• [5]
• [Kong API Gateway](https://konghq.com/products/kong-gateway).

• [6]
• [Chargebee, sistema di gestione del licencing](https://bit.ly/3PiwAwp).