Frankensteinizzazione del software in Supply Chain

00:00:04 Introduzione alla Frankensteinizzazione del software.
00:00:35 Impatto della Frankensteinizzazione del software sul software B2B.
00:01:31 Come le richieste dei clienti influenzano la Frankensteinizzazione del software.
00:02:32 Le ‘cicatrici’ sul software e le loro implicazioni.
00:05:33 Costi di manutenzione della Frankensteinizzazione del software.
00:08:00 Sfide e costi delle nuove funzionalità software.
00:08:57 Funzionalità senza complessità: approfondimenti B2C.
00:10:36 Problemi dell’approccio B2B alle soluzioni software.
00:13:18 L’esperienza di Lokad: giusto vs veloce e debito tecnologico.
00:15:14 Envision: la soluzione di Lokad alla complessità.
00:16:30 Scripting specifico per il dominio: evitare limiti e conflitti.
00:17:43 Affrontare il bloatware software nelle supply chain.
00:18:01 Strategie per semplificare il software complesso.
00:20:54 Gestire la ‘massa tecnologica’ nei sistemi software.
00:22:00 Sinergia tra IT, supply chain e marketing nei cambiamenti di sistema.
00:22:43 Problemi dovuti a una personalizzazione software eccessiva.
00:23:48 Testare l’integrità del fornitore di software attraverso la personalizzazione.
00:24:00 Ottenere influenza sulla strategia di sviluppo del prodotto.
00:26:08 Scegliere un software snello e mirato per evitare personalizzazioni eccessive.

Riassunto

Su Lokad TV, Joannes Vermorel introduce il concetto di Frankensteinizzazione del software, riferendosi al modo in cui il software B2B evolve attraverso modifiche casuali che non sono in linea con il suo design originale. Egli paragona questi cambiamenti a delle “cicatrici”, contribuendo alla creazione di un sistema software composito ed evoluto. ERPs vengono presentati come esempio, evidenziando il dilemma tra il mantenimento dell’architettura software e il soddisfacimento delle nuove esigenze. Vermorel mette in guardia dalle decisioni affrettate, che secondo lui spesso portano a cicatrici software e a un aumento dei costi di manutenzione. Pur riconoscendo la complessità inevitabile nella gestione del software, Vermorel sottolinea l’importanza di apprendere dai modelli B2C per controllare le interazioni tra le funzionalità. La risposta di Lokad a questo problema è “Envision”, un linguaggio di programmazione specifico per dominio che separa i problemi infrastrutturali da quelli specifici del dominio.

Riassunto Esteso

Nel recente episodio di Lokad TV, la conversazione ruota attorno al concetto di Frankensteinizzazione del software, un termine coniato da Joannes Vermorel, il fondatore di Lokad. Egli utilizza questo termine per descrivere la trasformazione del software B2B nel tempo, in particolare il software a lunga vita e quello per supply chain, che evolve attraverso continue negoziazioni e grandi accordi tra software vendors e i loro clienti.

Vermorel spiega che la Frankensteinizzazione del software si verifica quando vengono apportate modifiche al software in risposta alle richieste dei clienti. Questi cambiamenti sono spesso in contrasto con l’architettura, la filosofia e il design originali del software. Di conseguenza, il software accumula queste alterazioni, o “cicatrici”, nel tempo, trasformandosi in quello che Vermorel descrive come un “mostro Frankenstein” - un sistema software composito ed evoluto in modo strano.

Inoltre, egli sottolinea che questo fenomeno è particolarmente marcato nel software per supply chain, ma è comune anche in molti tipi di software B2B. Tuttavia, chiarisce che il termine “cicatrice” non va interpretato come intrinsecamente negativo. Queste modifiche possono migliorare il software aggiungendo nuove funzionalità, incrementandone così la funzionalità.

Vermorel fornisce l’esempio del software di Enterprise Resource Planning (ERP), che presume che la stagionalità possa essere catturata utilizzando profili fissi di 52 settimane. Questo design funziona bene finché non si presenta una richiesta che non rientra in questo schema, come modellare il Capodanno Cinese, il Ramadan o la Pasqua, che seguono calendari diversi e con date che variano annualmente.

In tali casi, il fornitore di software si trova di fronte a un trade-off. Può soddisfare la nuova richiesta integrando una soluzione “hackish”, che non si integra perfettamente nell’architettura del software ma fornisce la funzionalità richiesta. Tuttavia, questo approccio porta spesso a ulteriori “cicatrici”, contribuendo alla Frankensteinizzazione del software.

Sottolineando il ritmo rapido delle negoziazioni con i clienti chiave nel settore del software, Vermorel avverte che l’urgenza può involontariamente portare a “cicatrici software”. Egli definisce questo processo come quello in cui funzionalità implementate frettolosamente aumentano la complessità e il costo di manutenzione del software nel tempo.

Spiegando le complessità dell’architettura del software, Vermorel osserva che ogni linea di codice o funzionalità necessita di manutenzione. Man mano che vengono aggiunte più funzionalità, le interconnessioni diventano più complesse, portando a un “problema di complessità quadratica”. Essenzialmente, le interazioni potenziali aumentano esponenzialmente con l’incremento del numero di componenti, causando una varietà di problemi come bug, crash e minacce alla sicurezza.

Vermorel sottolinea l’importanza di un’architettura software meticolosa per controllare il numero di interazioni tra le funzionalità. Egli spiega che l’obiettivo dovrebbe essere di raddoppiare soltanto il carico di manutenzione necessario se il numero di funzionalità raddoppia, invece di moltiplicarlo per quattro o più, come spesso accade quando lo sviluppo è affrettato.

Quando gli viene chiesto come le aziende di software possano introdurre nuove funzionalità senza aumentare eccessivamente la complessità, Vermorel suggerisce di imparare dalle aziende di software B2C come Google e Netflix. Queste dedicano tempo a comprendere i problemi specifici che cercano di risolvere e a progettare soluzioni che affrontino un’ampia categoria di problemi simili. Egli contrappone questo approccio al mondo B2B, dove i clienti spesso presentano non solo i problemi ma anche le proprie soluzioni proposte.

Per quanto riguarda come Lokad gestisca questi problemi, Vermorel rivela la loro iniziale difficoltà nel bilanciare il fare le cose correttamente e nell’accogliere rapidamente le richieste dei clienti. Hanno notato un aumento del debito tecnologico nei primi anni, che Vermorel riconosce essere dannoso. Hanno compreso che, pur aggiungendo funzionalità per soddisfare i singoli clienti, può sembrare vantaggioso nel breve termine, ma porta a un prodotto complesso, incoerente e difficile da gestire nel lungo termine.

In reazione a questa constatazione, Lokad ha ideato una soluzione unica: un linguaggio di programmazione specifico per dominio chiamato “Envision”. Lo scopo di Envision è separare i problemi infrastrutturali da quelli specifici del dominio, permettendo a Lokad di gestire l’aggiunta e la manutenzione di nuove funzionalità in modo più efficace senza aumentare eccessivamente la complessità.

Vermorel continua ad approfondire come i prodotti software, in particolare nell’l’industria della supply chain, si trovino frequentemente ad affrontare problemi di bloatware a causa di un’estesa personalizzazione per ogni cliente. Pur essendo la personalizzazione finalizzata a fornire soluzioni su misura, spesso risulta in un sistema complesso e difficile da gestire, che richiede notevoli sforzi per essere mantenuto e aggiornato. Per evitare ciò, Vermorel spiega come Lokad utilizzi uno script specifico per dominio, Envision, per creare soluzioni fortemente personalizzate, ma al contempo gestibili per i loro clienti.

Affrontando il tema della complessità del software, Chandler chiede cosa possano fare le aziende di software per evitare il bloatware. Vermorel risponde che lo scenario dipende dal fatto che un’azienda abbia o meno accesso al proprio software. In caso contrario, l’azienda deve convivere con la complessità del software acquisito. Tuttavia, se l’accesso è garantito, il software può essere semplificato identificando e rimuovendo gli elementi non utilizzati, riducendo notevolmente la complessità.

Spostando l’attenzione sulle responsabilità del reparto IT e degli supply chain executives, Vermorel osserva che mentre il personale IT solitamente possiede le competenze tecniche, spesso manca la comprensione del valore aziendale di determinate funzionalità. Ciò porta a una disconnessione tra funzionalità necessarie e non necessarie. Pertanto, i decisori aziendali devono collaborare strettamente con l’IT per guidare la definizione delle priorità e la semplificazione del sistema.

Vermorel offre consigli per gli supply chain executives che intendono investire in nuovo software. Avverte di non richiedere una personalizzazione eccessiva, poiché può generare ulteriori problemi. Invece, i dirigenti dovrebbero mantenere un contatto regolare con i product manager o i CTO del fornitore per comunicare direttamente le loro esigenze. Piuttosto che imporre funzionalità specifiche in un contratto, l’obiettivo dovrebbe essere quello di presentare i problemi a chi è in grado di progettare soluzioni.

Infine, Vermorel consiglia alle aziende di scegliere un software che eccelle in un’unica area, anziché optare per soluzioni complete. Questo approccio mirato facilita i miglioramenti e riduce la complessità causata da una pletora di funzionalità interconnesse. Restando vicini a chi controlla la roadmap e scegliendo software fortemente focalizzati, le aziende possono gestire meglio la complessità e migliorare la produttività.

Trascrizione Completa

Kieran Chandler: Oggi affronteremo il tema della Frankensteinizzazione del software. Quindi, Joannes, questo è un argomento abbastanza difficile da pronunciare, così probabilmente te lo lascio. Presumo che oggi non stiamo parlando di un grande mostro verde. Di cosa stiamo parlando esattamente?

Joannes Vermorel: Stiamo parlando di un processo che guida l’evoluzione del software, in particolare il software B2B, e ancora più specificamente, il software per supply chain. Si applica principalmente al software B2B a lunga vita. Questo processo, che io chiamo “Frankensteinization”, fa evolvere il software nel corso degli anni con un flusso continuo di grandi accordi negoziati tra i fornitori di software e i loro clienti. La cosa interessante, da cui deriva la parte di “Frankensteinization”, è che ogni grande accordo negoziato tra il fornitore e uno dei suoi grandi clienti è destinato a lasciare una cicatrice nel software.

È un processo graduale in cui un fornitore negozia con una grande azienda. La grande azienda ha delle richieste, e per soddisfarle vengono apportati aggiustamenti al software che non si adattano all’architettura, alla filosofia o al design originale. La funzionalità viene aggiunta, ma in modo alquanto “hackish”. Quella è una cicatrice. Il problema è che se ripeti questo processo per anni, quello che ottieni in termini di software è, in un certo senso, un mostro Frankenstein. È una bestia fatta di molte cicatrici che appaiono alquanto brutte e estremamente composite. Evolvono in modi strani, ed è così che si finiscono per avere questi mostri software Frankenstein. Questo è qualcosa che accade nella maggior parte dei database, ma nel software per supply chain è come se fosse sotto steroidi.

Kieran Chandler: Parliamo di queste cicatrici, come le chiami. Che aspetto hanno? Voglio dire, migliorano il software, giusto? Aggiungono funzionalità extra. È davvero una cosa così negativa?

Joannes Vermorel: Sì, ovviamente quello è il compromesso. Vuoi migliorare il tuo software, ma un piece of software è un oggetto molto complicato. Non è come un edificio in cui puoi semplicemente aggiungere un piano o espanderti in modo ordinato. Il software viene fornito con molte ipotesi di design inviolabili fatte in una fase molto precoce che conferiscono al software una certa integrità—un’integrità architettonica.

Prendiamo ad esempio molti ERP, che sono stati costruiti intorno all’idea di catturare la stagionalità con profili composti esattamente da 52 settimane, rappresentando un dato anno. Quindi, hai letteralmente una tabella con 52 colonne, una per ogni settimana, e hai tutti questi profili di stagionalità che puoi applicare a qualsiasi articolo produci o vendi. Ma cosa succede se vuoi modellare qualcosa come il Capodanno Cinese? Non si adatta a questa griglia di 52 settimane perché passerà da un anno all’altro secondo il calendario tradizionale cinese, non quello gregoriano. Affronterai problemi simili con il Ramadan o addirittura con la Pasqua.

Hai questa bella ipotesi che può crollare quando ti trovi di fronte a una richiesta che non rientra nel tuo schema. E ciò può manifestarsi in molte forme. Il problema è che, in quanto fornitore di software, non hai davvero il tempo di riscrivere l’intera pila del software affinché queste nuove funzionalità si integrino nella tua architettura in modo completamente nativo. Alla fine, è un po’ hackish.

Kieran Chandler: Stai negoziando con un cliente importante, quindi non hai anni per concludere l’affare. E poi, non hai anni per consegnare il futuro. Quindi, le cose devono essere fatte in una relativa emergenza ogni volta, proprio perché si tratta di una negoziazione più grande del solito per chiudere una vendita. Le cose vengono fatte in fretta quasi per necessità. Ma quando qualcosa diventa una cicatrice e quando invece diventa una buona funzionalità? Perché tutti questi software devono evolversi, devono cambiare, devono funzionare per i loro clienti. Quindi, cosa differenzia i due? Come fai a sapere che qualcosa che stai sviluppando non diventerà una cicatrice?

Joannes Vermorel: La domanda è quanto costerà in termini di manutenzione. Ogni singola riga di codice presente nel tuo grande software aziendale è qualcosa che dovrai mantenere. Una cosa che le persone non si rendono sempre conto, anche i professionisti del software, è che il software è come un macchinario intricato in cui ogni singolo componente deve interagire in qualche modo con tutte le altre parti. Hai un problema di complessità quadratica.

Che cosa significa? Significa che se ho dieci componenti, ho sostanzialmente circa 100 potenziali interazioni, insomma, 10 x 10. Se ho mille componenti e tutte interagiscono, allora ho 1.000 per 1.000 interazioni. Ogni interazione potenziale è una ricetta per ogni sorta di problemi: problemi di sicurezza, bug, crash, risultati errati o semplicemente enormi rallentamenti del software.

Quando aggiungi più componenti, aumenti il numero di interazioni potenziali tra le parti del tuo software, e questo numero cresce molto più rapidamente del numero di componenti. E quando dico componenti, puoi pensare a funzionalità, capacità, schermate, opzioni di dati o voci.

Se sei molto attento all’architettura del tuo software, puoi preservare il numero di interazioni tra le funzionalità per tenerlo sotto controllo. Se raddoppi il numero di funzionalità nel tuo software, non vuoi moltiplicare per 4 il numero di interazioni, perché ciò significa che, raddoppiando le funzionalità, quadruplichi in realtà la quantità di manutenzione necessaria.

Ma è molto difficile. Quando sei di fretta, quando raddoppi il numero di funzionalità, in realtà moltiplichi per 4 o addirittura di più lo sforzo che devi investire nella manutenzione. Col tempo, il costo della manutenzione schizza alle stelle e la tua capacità di lanciare nuove soluzioni diminuisce sempre di più. Ogni volta che introduci una nuova funzionalità, essa innesca un’ondata intera di incompatibilità e bizzarre interazioni indesiderate tra le diverse parti, perché non è stata completamente pianificata. Il dolore aumenta nel tempo.

Kieran Chandler: Ok, quindi riflettiamo dal punto di vista di quella società di software. Come possono introdurre queste nuove funzionalità? Come possono implementarle per mantenere felici i loro clienti, senza introdurre questo ulteriore strato di complessità? Cosa possono fare?

Joannes Vermorel: Penso che la lezione derivi dal mondo del software B2C. Google non introduce nuove funzionalità per Google Search, e nemmeno Netflix per Netflix, solo perché stanno acquisendo un nuovo cliente. Non prendono nuovi clienti e iniziano a discutere con loro dicendo: “Oh, se non abbiamo queste funzionalità, allora non ti iscriverai da noi, quindi dobbiamo farlo subito.”

Non funzionano in quel modo. Pensano a qual è il dominio, qual è il problema specifico che stanno cercando di risolvere. Cercano di avere una visione molto ampia di questo problema e poi riflettono.

Kieran Chandler: Stai parlando di un approccio che mira a generare soluzioni per un’intera categoria di problemi, piuttosto che per un singolo microproblema. Ciò richiede di riprogettare il software per affrontare un ampio spettro di problemi simili. E questo accade continuamente. Quando interagisci con i clienti, ascolti i loro problemi, non le soluzioni che propongono. Al contrario, nel mondo B2B, i clienti tendono a presentare non solo il problema, ma anche una soluzione. Questa soluzione può o meno inserirsi nel tuo stack software esistente o nell’evoluzione di tale problema. Quindi, si tratta di non ascoltare davvero?

Joannes Vermorel: Esattamente, si tratta piuttosto di capire veramente il problema centrale invece di fissarsi su una soluzione particolare. Grandi aziende come Google e Netflix sono ottimi esempi di questo.

Kieran Chandler: Quindi, stai dicendo che le aziende non ascoltano davvero. Ma che dire di quei fastidiosi pop-up che chiedono feedback? Qualcuno li sta davvero osservando?

Joannes Vermorel: I pop-up a cui ti riferisci sono tipicamente funzionalità indesiderate. Però va dato credito ad aziende come Google. Questi pop-up, in cui devi accettare i termini, non sono stati una loro scelta. Sono stati implementati per obbligo a causa di vincoli normativi. Quindi, anche se può sembrare una funzionalità bizzarra, non è opera loro. Inoltre, se guardi chi ha conquistato il web, non sono state le aziende con pubblicità super fastidiose. Sono state quelle come Google, che avevano annunci puliti e discreti. Pensavano ai loro clienti invece di svalutare il prodotto con qualcosa di così irritante. Si prendono il tempo per riflettere sulle loro funzionalità.

Kieran Chandler: Nelle aziende di software B2B, in particolare nel supply chain, c’è molta diversità. Possono esserci centinaia di scenari e, spesso all’ultimo minuto, le persone negoziano numerose funzionalità che quasi sempre si rivelano essere cattive idee sei mesi dopo. Quindi, sei d’accordo che la Frankensteinizzazione del software sia una cosa negativa? E in tal caso, cosa avete fatto diversamente a Lokad per evitare questo problema?

Joannes Vermorel: Assolutamente, la Frankensteinizzazione del software è un problema. Nei primi anni a Lokad, abbiamo affrontato proprio questo problema. È stato un compromesso difficile. Se vuoi farlo bene, può richiedere uno o due anni, cosa troppo lenta. Se invece non lo fai nel modo giusto, puoi concludere in poche settimane o mesi, ma ti ritrovi con una grande cicatrice, un brutto hack. Finisci per accumulare debito tecnico. Quindi, nei primi anni di Lokad, non avevamo una soluzione, ma diventavamo sempre più consapevoli del problema. Anche da startup, il debito tecnologico aumentava, situazione preoccupante. Fu in quel momento che compresi che la tendenza era sfavorevole. Guardando a un paio di decenni nel futuro, vedevo come i concorrenti, con il loro software ingombrante per l’ottimizzazione del supply chain, aggiungessero sempre più funzionalità senza coerenza.

Kieran Chandler: Sembra che le aziende di software aggiungano sempre nuove funzionalità e che il risultato finale possa essere un prodotto confuso e ingombrante. Puoi parlare del vostro approccio a questo problema a Lokad?

Joannes Vermorel: Assolutamente. Il modo in cui il software tende a diventare ingombrante è aggiungendo una funzionalità sbagliata alla volta. Se prosegui per 20 anni su questa strada, finisci con un prodotto mostruoso. Non è che gli sviluppatori siano incompetenti o sciocchi, stanno semplicemente facendo un buon lavoro in modo incrementale, cercando di conquistare un cliente alla volta. Tuttavia, questo approccio “scava” il software un cliente alla volta, e il risultato finale è tipicamente molto, molto negativo.

Quindi, abbiamo deciso di adottare un approccio completamente diverso a Lokad, e questo ha portato alla nascita di Envision, il nostro linguaggio di programmazione specifico per il dominio. Con Envision, abbiamo effettivamente diviso tutti i problemi. Abbiamo separato l’infrastruttura, l’infrastruttura dei dati e l’infrastruttura machine learning. Questi sono prodotti a lungo termine che vogliamo mantenere e aggiornare, e ogni volta che decidiamo di cambiarli e aggiornarli richiede uno sforzo pluriennale.

Successivamente, per ogni singolo cliente, creiamo un’implementazione completamente personalizzata scritta in script con Envision. Poiché Envision è progettato specificamente per l’ottimizzazione del supply chain, possiamo scrivere qualcosa di completamente su misura per ogni cliente, con elevata produttività, rendendolo completamente personalizzato.

Quindi, partiamo da una pagina bianca, la personalizziamo completamente e poi non dobbiamo affrontare una situazione in cui il cliente ci richiede qualcosa che non supportiamo. Grazie alle capacità programmatiche di Envision, se dobbiamo fare qualcosa di speciale per un cliente, nel peggiore dei casi lo script che scriviamo non sarà così compatto come al solito. Tuttavia, possiamo comunque beneficiare di un’infrastruttura progettata per facilitare la risoluzione di determinati tipi di problemi.

Se introduci capacità programmatiche avanzate specifiche per il dominio nella tua piattaforma, improvvisamente non devi correre una negoziazione che potrebbe lasciare il segno negativo sul tuo prodotto. Puoi fare la personalizzazione nel tuo ambiente programmatico, su misura per ogni singolo cliente, e poi continuare a implementare aggiornamenti per la tua piattaforma secondo il tuo programma, che molto probabilmente non coinciderà con quello dei tuoi clienti.

Kieran Chandler: Hai individuato questo problema piuttosto presto. Che consiglio daresti ad altre aziende di software che stanno affrontando questo tipo di bloatware? Possono fare qualcosa per risolverlo? Dovrebbero cominciare a rimuovere alcune di queste funzionalità per semplificare le cose?

Joannes Vermorel: La situazione dipende da diversi fattori. Se sei una grande azienda che possiede il software, come un WMS, ERP, MRP, ecc., potresti non avere nemmeno accesso al software stesso, potrebbe essere semplicemente un prodotto del fornitore. Se non hai accesso al prodotto, allora sei costretto ad accettare la complessità del software che hai acquisito.

Se invece hai accesso al software e vuoi semplificarlo, allora sì, dovresti cominciare a eliminare aggressivamente tutto ciò che non usi. Molte persone sono solitamente preoccupate di rimuovere parti di un software esistente perché temono di perdere determinate funzionalità. È vero che, se rimuovi funzionalità, le perdi. Tuttavia, se rimuovi qualcosa che viene quasi mai utilizzato, puoi anche eliminare intere classi di problemi causati dalla sola presenza di quella piccola funzionalità.

Spesso a Lokad vediamo implementazioni ERP con letteralmente migliaia di tabelle. Puoi avere un ERP con, diciamo, cinquemila tabelle. Ogni tabella può avere da 10 a 200 campi, generando una complessità enorme. Anche solo eseguire il backup dell’ERP può risultare incredibilmente complicato.

Kieran Chandler: Poiché hai così tante tabelle, ti serve una tabella per memorizzare l’elenco delle tabelle e cose simili. Quella è il tipo di situazione in cui, se riesci a identificare un sacco di tabelle che non vengono più usate, o schermate che non sono più utilizzate, rimuovendole semplicemente semplifichi tutto.

Joannes Vermorel: Esattamente, per esempio, se devi aggiornare da una versione del tuo database a un’altra, uno dei problemi che puoi incontrare è dover aggiornare parti di logica che non vengono più usate da nessuno. Ogni singola riga di codice esistente, sia che si tratti di Java, C Sharp, SQL o altro, è qualcosa che devi mantenere finché quella riga esiste. Se la rimuovi, significa che durante la prossima integrazione o migrazione, le persone non dovranno più chiedersi come migrare quella cosa alla versione successiva del sistema o a un sistema completamente nuovo.

E questo è qualcosa su cui i supply chain executives devono riflettere. Quando acquistano software, dovrebbero davvero aderire al principio della parsimonia: se non ne hai veramente bisogno, è meglio non avere quella parte del sistema. Sarà solo un peso. È vitale prestare costantemente attenzione alla massa tecnologica della soluzione che stai acquisendo e gestendo.

Questa massa tecnologica non viene gratis. Se hai più schermi, hai bisogno di più persone per formarle. Se riesci a rimuovere un paio di schermi, significherà meno formazione, meno bug segnalati, meno conflitti con l’IT e via dicendo. Si tratta di gestire la complessità dell’IT, ma la parte difficile è che, tipicamente, l’IT non ha idea di questo perché non ha accesso al valore aziendale. Non riescono a differenziare tra funzionalità veramente necessarie e funzionalità non strettamente indispensabili. Non sanno tradurre tabelle, campi, schermate o capacità in euro o dollari. Questo è qualcosa che solo le persone del supply chain o del marketing, se consideri un sistema diverso, possono fare. Ecco perché l’IT ha bisogno del supporto di queste persone, dei decisori nell’azienda, per guidare la definizione delle priorità e il cambiamento verso la semplificazione del sistema.

Kieran Chandler: E quindi, per concludere, hai menzionato che se sono un supply chain executive che vuole investire in un nuovo software per la mia azienda, sembra che non dovrei chiedere troppa personalizzazione perché ciò introduce problemi. Quindi, cosa dovrei cercare?

Joannes Vermorel: Sì, chiedere personalizzazioni o funzionalità speciali è come una ricetta per generare problemi. Se il tuo fornitore di software non aveva già abbastanza problemi suoi, stai semplicemente creando altri problemi che peggioreranno la situazione. Quindi, davvero, non dovresti farlo. Se riesci a chiedere una personalizzazione, anche solo come test, perché se il fornitore si impegna volentieri nella discussione sulla personalizzazione, significa che quel fornitore non ha integrità. Ciò implica che lo fa con ogni singolo altro cliente, il che vuol dire che, anche se il prodotto è buono oggi, tra cinque anni sarà un incubo.

Innanzitutto, se chiedi una personalizzazione, è giusto chiedere e dovresti davvero aspettarti che tale richiesta venga negata. Altrimenti, c’è un problema.

Kieran Chandler: Una cosa che le persone dovrebbero richiedere sono funzionalità speciali, giusto? Voglio dire, se c’è una cosa da chiedere, potrebbe essere l’accesso al CTO o al product manager del fornitore. Includerlo come parte del contratto, magari? Tipo, voler avere un incontro con questa persona per due ore una volta al mese. Perché?

Joannes Vermorel: Se negozi di avere accesso diretto alle persone che stanno definendo la roadmap del fornitore, puoi semplicemente presentare le tue modifiche. Non devi imporre loro la tua soluzione; presenta semplicemente il tuo problema. Perché, in quanto ingegneri, cosa fanno quando viene loro presentato un problema? Cominciano a lavorare su una soluzione. Se hai un incontro di routine in cui presenti i tuoi problemi, non devi negoziare per funzionalità specifiche nel contratto. In un paio d’anni, inizieranno ad apparire nel prodotto funzionalità che sembrano combaciare esattamente con il problema che hai esposto.

Kieran Chandler: Puoi spiegare un po’ meglio questo punto?

Joannes Vermorel: Se fai i conti, considera il CTO di una società di software. Quante riunioni può avere questa persona con i clienti in un dato mese? Diciamo che ha al massimo 20 riunioni. Se hai una riunione al mese, stai essenzialmente ottenendo circa il cinque per cento della capacità mentale del CTO, che guida lo sviluppo tecnologico del fornitore con cui lavori. Questo significa che i tuoi problemi ricevono una notevole attenzione.

Kieran Chandler: Quindi, qual è il tuo suggerimento?

Joannes Vermorel: Il mio suggerimento, se vuoi giocare d’astuzia, è di avvicinarti alle persone che controllano la roadmap. È più intelligente che negoziare frettolosamente funzionalità difettose che probabilmente scarterai in sei mesi perché la tua soluzione non era adeguata o il tuo problema è cambiato. Inoltre, un altro consiglio è quello di evitare software che fanno troppo. Vuoi pensare a un software che faccia una sola cosa e lo faccia bene, piuttosto che a un software con capacità estese che finisce per fare tutto male.

Kieran Chandler: Puoi approfondire meglio questo punto?

Joannes Vermorel: È più facile migliorare un software fortemente focalizzato che tentare di perfezionare un framework gigantesco che fa tutto. Ogni volta che devi apportare una modifica, pensa al numero quadratico delle interazioni. Se hai mille funzionalità e ne aggiungi una, devi considerare tutte le interazioni con le 1.000 funzionalità preesistenti. Quindi, se introduci una funzionalità, devi valutare tutte le 1.000 interazioni. Tuttavia, se hai solo dieci funzionalità e ne aggiungi un’undicesima, ci sono solo dieci interazioni da rivedere. Quindi, ancora una volta, concentrati su qualcosa di snello e fortemente mirato al problema specifico che stai cercando di risolvere.

Kieran Chandler: Grande! Temo che oggi dovremo lasciarci qui, ma immagino che ci siano alcuni CEO là fuori che probabilmente non ti ringrazieranno troppo per questo, probabilmente ricevendo qualche altra telefonata adesso. Bene, questo è tutto per questa settimana. Torneremo la prossima settimana con un altro episodio. Fino ad allora, abbi cura di te.

Joannes Vermorel: Grazie.