Ingegneria del software per la supply chain - Lezione 4.6

00:02 Introduzione
01:43 Meccanizzazione
07:34 Oltre il paradosso
12:14 La storia finora
14:32 Sottomoduli di oggi
16:24 Requisiti (mainstream 1/5)
20:12 Progettazione (mainstream 2/5)
25:37 Costruzione (mainstream 3/5)
30:29 Test (mainstream 4/5)
34:09 Manutenzione (mainstream 5/5)
41:12 Identità (trincea 1/8)
46:35 Curriculum (trincea 2/8)
51:43 Pratiche (trincea 3/8)
56:47 Bastioni (trincea 4/8)
01:02:00 Scrittori di codice (trincea 5/8)
01:06:23 Tolleranza al dolore (trincea 6/8)
01:14:55 Produttività (trincea 7/8)
01:21:37 L’ignoto (trincea 8/8)
01:27:00 Conclusioni
01:29:55 4.6 Ingegneria del software per la supply chain - Domande?

Descrizione

Domare la complessità e il caos è la pietra angolare dell’ingegneria del software. Considerando che le supply chain sono complesse e caotiche, non dovrebbe sorprendere troppo il fatto che la maggior parte dei problemi di software aziendale affrontati dalle supply chain si riduca a una cattiva ingegneria del software. Le ricette numeriche utilizzate per ottimizzare le supply chain sono software e, quindi, soggette allo stesso identico problema. Questi problemi aumentano di intensità insieme alla sofisticazione delle ricette numeriche stesse. L’ingegneria del software adeguata per le supply chain è ciò che l’asepsi è per gli ospedali: da sola non fa nulla - come il trattamento dei pazienti - ma senza di essa, tutto crolla.

Trascrizione completa

Benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel e oggi presenterò “Ingegneria del software per la supply chain”. Il software è la base di una moderna pratica di supply chain, eppure la maggior parte dei manuali di supply chain sottolinea molto poco il ruolo del software nella supply chain. Il software per la supply chain non è solo un requisito come l’accesso ai mezzi di trasporto; è molto di più. Dal punto di vista dei professionisti della supply chain, la maggior parte del lavoro è guidata dal software, dai bug del software o dalle limitazioni del software e dalle preoccupazioni legate al software.

L’ingegneria del software è la disciplina che ha l’ambizione di aiutare le persone a creare un software migliore, ottenere di più dal software, creare questo software più velocemente e spendere meno per ottenere di più. Lo scopo di questa lezione è capire di cosa si tratta l’ingegneria del software e capire la sua rilevanza principale per la supply chain. Lo scopo di questa lezione è anche capire cosa puoi fare come professionista della supply chain per evitare di compromettere la tua supply chain sia attraverso azioni che inazioni che, sfortunatamente, hanno avuto l’effetto di ostacolare i tuoi progetti software.

Il XX secolo è stato il secolo della meccanizzazione della forza lavoro. Grandi aziende e grandi supply chain, come le conosciamo oggi, sono emerse nel XX secolo, e il progresso ottenuto grazie alla meccanizzazione della forza lavoro è stato incredibile. Nel corso dell’ultimo secolo, per quasi ogni attività intensiva di lavoro che è rilevante per la supply chain, come la produzione o la distribuzione, la produttività è aumentata di cento volte.

Al contrario, credo che il XXI secolo sia e sarà il secolo della meccanizzazione del lavoro intellettuale, e questa transizione è molto difficile da comprendere. Il tipo di intuizione che si applica quando passiamo dalla meccanizzazione della forza lavoro fisica non si traduce affatto nel tipo di intuizione che si applica quando passiamo alla meccanizzazione del lavoro intellettuale. Non sto dicendo che la transizione sia meno drammatica, ma la realtà è che a questo punto nel tempo, la transizione verso l’eliminazione della forza lavoro che si occupava di compiti molto intensivi dal punto di vista del lavoro è già alle nostre spalle.

Nel 2020 in Francia c’erano 27 milioni di persone con lavori da impiegati - essenzialmente impiegati d’ufficio - mentre c’erano meno di un milione di persone che erano rimaste operai. Il rapporto è di 27 a 1. Quando iniziamo a guardare a cosa comporta la meccanizzazione del lavoro intellettuale, è molto sorprendente ed è anche molto legato a un paradosso noto come paradosso di Moravec.

Hans Moravec, un informatico, ha osservato nel 1980 che per quanto riguarda l’informatica, i compiti che sembravano più difficili per la mente umana, come diventare un grande maestro degli scacchi, erano in realtà i tipi di compiti più facili da affrontare con i computer. Al contrario, se guardiamo a compiti che sembrano estremamente facili per gli esseri umani, come stare in piedi su due gambe, quei compiti si rivelano incredibilmente sfidanti per i computer. Questa è l’essenza del paradosso di Moravec: la nostra intuizione su ciò che è difficile da realizzare in termini di compiti intellettuali con i computer è molto ingannevole.

Una cosa che complica ulteriormente il problema è che improvvisamente, quando parliamo dell’automazione dei dipendenti d’ufficio, è fatta dagli stessi dipendenti d’ufficio. Questo non era il caso degli operai di fabbrica; non erano loro a decidere che la fabbrica sarebbe stata meccanizzata ulteriormente e che i loro posti di lavoro sarebbero stati eliminati. Eppure, è ciò che sta accadendo con i lavori d’ufficio. Abbiamo quindi una sfida in cui il processo di meccanizzazione non solo è profondamente controintuitivo a causa del paradosso di Moravec, ma anche la gestione delle persone incaricate di implementare questa meccanizzazione, ovvero gli ingegneri del software, è di per sé molto controintuitiva. Questa è probabilmente una delle sfide più grandi per la supply chain: la gestione delle persone che saranno responsabili, in un modo o nell’altro, di affrontare questa meccanizzazione.

Qui, non posso fare a meno di osservare che molte supply chain e aziende associate sono ancora saldamente ancorate a una mentalità del XX secolo, in cui si affronta il mondo aziendale come se avessi persone d’ufficio che svolgono il lavoro intellettuale, e poi loro trovano la soluzione o il piano, che viene consegnato agli operai per l’esecuzione. Tuttavia, con un rapporto di 27 persone a una quando si tratta di lavori d’ufficio rispetto ai lavori di fabbrica in Francia, e statistiche probabilmente simili nella maggior parte dei paesi sviluppati, non è così che funziona ora. Si tratta letteralmente di automatizzare il proprio lavoro, e significa che in questo mondo del XXI secolo, i migliori dipendenti d’ufficio sono quelli che riescono costantemente a automatizzarsi, a rendere obsoleti se stessi e poi passare a qualcos’altro. Questo è molto impegnativo per molte aziende che sono ancora molto radicate nella mentalità del XX secolo.

Le opinioni divergono ampiamente sulla stessa nozione di ingegneria del software. Una delle critiche più forti è stata fatta da Edsger Dijkstra, uno dei padri fondatori dell’informatica. Secondo il suo punto di vista, l’ingegneria del software non è nemmeno possibile come disciplina o campo di ricerca, e ha detto che si riduce o degenera in una sorta di “come programmare se non puoi”, una sorta di ricetta. La critica di Dijkstra, che è molto interessante, è che l’ingegneria del software degenera in una sorta di narrativa di auto-aiuto che non può avere successo. Infatti, se proponiamo che l’obiettivo dell’ingegneria del software sia garantire il successo nella creazione di software utile e superiore, allora l’ingegneria del software è per lo più condannata. Il successo nel software è incredibilmente difficile; è difficile quanto il successo nella scienza. Richiede una scintilla di genio, parecchia fortuna, e non esiste una ricetta per questo. Inoltre, ogni singolo successo tende a consumare l’opportunità stessa che è stata necessaria per raggiungere questo successo, e quindi l’intera cosa diventa non replicabile.

Tuttavia, non sono d’accordo con la visione secondo cui l’ingegneria del software è condannata. Credo che il problema principale sia definire l’ambizione dell’ingegneria del software. Se decidiamo che l’ambizione dell’ingegneria del software è il successo nella creazione di software, allora è vero che è condannata. Tuttavia, se decidiamo di affrontare l’ingegneria del software come un sottobranchia ristretto della psicologia sperimentale, credo che possiamo raccogliere, attraverso questo punto di vista, spunti molto preziosi e pratici, e questa è la prospettiva che adotterò oggi in questa lezione. Quindi, l’ingegneria del software riguarda gli stessi ingegneri del software e le loro interazioni. Concentrarsi sugli ingegneri del software è un buon punto di partenza perché la natura umana è stabile nel tempo, a differenza della tecnologia del software, che cambia costantemente. La natura delle persone che stanno lottando con questa tecnologia non lo è; la natura umana è stata molto stabile per molto tempo.

Se guardiamo ad altri campi, come la scienza, possiamo vedere che avvicinarsi a un campo attraverso l’ispezione di ciò che i suoi praticanti stanno facendo può essere molto fruttuoso. Ad esempio, nella scienza, è ormai ampiamente stabilito che un conflitto di interessi porta a una cattiva scienza e a una corruzione della conoscenza. Questo punto è stato già affrontato nella lezione intitolata “Ricerca di mercato avversaria per il software aziendale”. Da questa prospettiva, vediamo che è possibile raccogliere spunti di ampia applicabilità e rilevanza se ci concentriamo sugli stessi praticanti. Quindi, l’ingegneria del software riguarda le persone che si occupano di tecnologia del software, le loro difficoltà e i loro processi, e non tanto la tecnologia stessa.

Oggi è la sesta lezione dei quattro capitoli. Questo capitolo è dedicato alle scienze ausiliarie della supply chain. Queste scienze ausiliarie rappresentano elementi che ritengo di fondamentale importanza per una pratica moderna della supply chain, ma non sono strettamente elementi della supply chain. Sono più come elementi di supporto per la tua pratica della supply chain.

Finora, in questo quarto capitolo, abbiamo iniziato con la fisica dell’informatica, occupandoci di computer moderni, e poi siamo saliti attraverso una scala di astrazioni. Siamo passati dai computer agli algoritmi, che rappresentano i più piccoli e più interessanti elementi del software. Poi siamo passati all’ottimizzazione matematica, che è di interesse per la supply chain ma anche per molte altre attività software rilevanti, come il machine learning. Abbiamo visto che l’ottimizzazione matematica è direttamente interessante per la supply chain, ma è anche direttamente interessante per il machine learning, che a sua volta è interessante per la supply chain.

Per quanto riguarda l’ottimizzazione matematica e il machine learning, la maggior parte dei concetti e dei paradigmi interessanti al giorno d’oggi sono di natura programmatica. Non si tratta solo di semplici algoritmi; è qualcosa di incredibilmente espressivo e deve essere affrontato attraverso la lente dei linguaggi di programmazione. Ecco perché l’ultima lezione riguardava i linguaggi e i compilatori.

Oggi, continuiamo a salire questa scala di astrazione e ci concentriamo sulle persone anziché su ciò che stanno facendo. Ci concentreremo sugli stessi ingegneri del software, ed è questo il punto di questa analisi dell’ingegneria del software.

Oggi, presenterò specificamente due punti di vista sull’ingegneria del software. Prima presenterò il punto di vista dominante, che credo sia predominante nel campo. Purtroppo, questo punto di vista dominante ha generato critiche, come accennato in precedenza, con persone che presentano approcci di auto-aiuto che alcuni, me compreso, hanno motivo di opporsi perché non presentano un’ambizione realistica per la disciplina dell’ingegneria del software. Tuttavia, esaminerò questo punto di vista dominante, anche solo perché alcuni concetti fuorvianti sono ancora incredibilmente popolari. Conoscere questi concetti fuorvianti è di primaria importanza, anche solo per individuare persone incompetenti che potrebbero mettere a rischio la vostra supply chain a causa della loro incompetenza.

Successivamente, mi sposterò verso un punto di vista dalla trincea, che è una raccolta di elementi radicati nella mia esperienza personale come CEO di un’azienda di software che opera proprio nel campo del software per la supply chain aziendale. Come vedremo, le intuizioni riguardano molto le persone e non tanto la tecnologia stessa.

Il punto di vista dominante dell’ingegneria del software afferma che un’iniziativa software inizia con la raccolta dei requisiti per il software di interesse. La maggior parte delle iniziative software nelle grandi aziende adotta questa prospettiva attraverso un processo che di solito inizia con una Richiesta di Proposta (RFP), una Richiesta di Preventivo (RFQ) o una Richiesta di Informazioni (RFI). Questo approccio deriva dalle pratiche del XX secolo che sono state molto efficaci nell’ingegneria meccanica e nelle opere di costruzione. Tuttavia, ritengo che per quanto riguarda il software, questi approcci per la raccolta dei requisiti siano profondamente fuorvianti.

Nel software, non sai cosa vuoi; semplicemente non lo sai. Sapere cosa vuoi è sempre la parte più difficile del software. Ad esempio, se consideriamo un problema semplice come il riapprovvigionamento delle scorte, l’enunciato del problema è incredibilmente semplice: in qualsiasi momento, voglio sapere la quantità che dovrei riapprovvigionare o riordinare per ogni singolo SKU. Il problema stesso è semplice, ma definire cosa sia una buona quantità diventa diabolico complesso e difficile. Come regola generale, chiarire i requisiti è molto più difficile che scrivere il pezzo di software stesso.

È solo confrontando la tua intuizione con il feedback dato dal mondo reale che puoi far emergere gradualmente i requisiti. I requisiti non cadono dal cielo; possono essere ottenuti solo attraverso un processo abbastanza sperimentale, e devi avere questa interazione con il mondo reale. Tuttavia, l’unico modo per avere questa interazione è avere il prodotto software, poiché la raccolta dei requisiti è fondamentalmente un processo molto empirico ed emergente. Il problema è che quando hai finito con i requisiti, avere i requisiti diventa irrilevante perché, se hai i requisiti, significa che hai già il prodotto corrispondente che implementa quei requisiti. Quindi, quando hai accesso ai requisiti corretti, hai già il prodotto in produzione, funzionante, e il fatto di avere quei requisiti è in qualche modo irrilevante.

Pertanto, il punto è che iniziare il processo attraverso la lente dei requisiti è, a mio parere, una follia. I requisiti dovrebbero probabilmente venire per ultimi come documentazione in una fase tardiva, in cui si documentano tutte le ragioni principali che ti hanno portato a implementare il prodotto nel modo in cui l’hai fatto, non il contrario.

Una volta definiti i requisiti, l’approccio classico prevede di procedere con la fase di progettazione. Concordo sul fatto che, ad un certo punto, potrebbe essere necessaria una progettazione. Tuttavia, il tipo di pensiero che si applica in questa fase di progettazione è spesso fuorviante. Il problema si riduce a tenere sotto controllo il costo del cambiamento. La prospettiva classica non software sul costo del cambiamento è che il costo aumenta in modo esponenziale nel tempo. Ad esempio, se si cambia la progettazione di una macchina molto presto, quando si sta solo lavorando su una bozza, il costo del cambiamento è minimo. Al contrario, se si attende che milioni di quelle macchine siano in circolazione, il costo del cambiamento è incredibilmente alto perché implica un richiamo, che può essere estremamente costoso.

Tuttavia, a differenza del mondo fisico, nel campo del software il costo del cambiamento non aumenta naturalmente in modo esponenziale. L’aumento del costo non può essere completamente mitigato; tuttavia, in larga misura, l’aumento del costo può essere gestito. Infatti, il costo del cambiamento aumenta nel tempo, principalmente perché le codebase tendono a crescere nel tempo. Non ho mai visto una codebase di un software aziendale ridursi significativamente da un anno all’altro; tendono a crescere. Tuttavia, è possibile gestire il costo del cambiamento fino a un certo punto.

Oggi questo aspetto sta diventando sempre più riconosciuto, anche nei circoli del software. A proposito, questa è l’essenza della metodologia Agile. Avrai visto questi termini fluttuare quando le persone dicono: “Oh, abbiamo questa metodologia Agile per il software.” Uno degli obiettivi principali della metodologia Agile è mettere sotto controllo il costo del cambiamento. Oggi non entrerò nei dettagli della metodologia Agile, ma posso dire che ritengo che questo approccio sia leggermente fuorviante quando si tratta di come esattamente si porta sotto controllo questo costo del cambiamento.

Ho osservato che il costo del cambiamento deriva principalmente dalle decisioni che vengono prese sul software e, più specificamente, dal fatto che è molto difficile resistere all’impulso di prendere decisioni. Immagina di guardare un potenziale futuro prodotto software e ci sono molte decisioni da prendere. Il tentativo iniziale sarebbe quello di prendere quelle decisioni solo per chiarire ciò che hai di fronte. Al contrario, una fase di progettazione molto buona, piuttosto che una buona progettazione, è la capacità di rimandare tutte le decisioni che non sono assolutamente necessarie, quando il prodotto non richiede che tali decisioni vengano prese ora. Infatti, se non prendi la decisione, finché la decisione non viene presa e non hai stabilito che è necessario adottare questo specifico approccio di progettazione o approccio tecnologico, è ancora in sospeso, pronto per essere cambiato perché ancora nulla è stato deciso.

Uno degli aspetti per tenere sotto controllo il costo del cambiamento è imparare a rimandare tutte le decisioni nella misura massima possibile. Dal punto di vista della supply chain, questo sembra molto strano perché significa che per tutte le persone nel team di sviluppo software e per tutte le persone che osservano il prodotto e il team di sviluppo software, sembra che siano tenuti all’oscuro. È ancora peggio perché sono tenuti all’oscuro apposta, il che è molto sorprendente. Eppure, è esattamente ciò che deve accadere ed è necessario farlo apposta. Ecco perché è sconcertante, per dir poco.

Ora, se le decisioni di progettazione prematura sono radicate nella necessità a volte fuorviante di controllo, i problemi associati a questa necessità di controllo non si fermano qui. Una volta che la fase di progettazione è terminata, il punto di vista dominante sull’ingegneria del software afferma che dovremmo procedere con la costruzione del software, chiamata anche fase di implementazione. Il modo in cui viene tipicamente fatto è presentare una sorta di proiezione a cascata, chiamata anche diagrammi di Gantt. Questo è ciò che puoi vedere sullo schermo. Credo che questo approccio, i diagrammi di Gantt e le cascate, sia incredibilmente tossico e la tossicità di questo approccio non dovrebbe essere sottovalutata per quanto riguarda il software. Affrontare il problema in questo modo significa letteralmente predisporre la tua supply chain al fallimento, almeno per quanto riguarda le iniziative software.

Un modo molto migliore per comprendere il problema e affrontare la costruzione del software è pensare ad esso come a un processo di apprendimento. La costruzione del software riguarda l’apprendimento di tutto ciò che serve per ottenere un buon prodotto. Questo è un processo di apprendimento e tutte quelle parti apprese sono un sottoprodotto del fatto che il mondo interagisca con il software che sta emergendo dal processo di costruzione. Il problema chiave con una previsione a cascata è che stai proiettando ciò che stai per scoprire. Questo semplicemente non è possibile per definizione. Ciò che stai per scoprire era sconosciuto fino a quando non hai scoperto quegli elementi. Non puoi proiettare le tue scoperte. Puoi aspettartele, ma non puoi pianificare i dettagli di ciò che stai per scoprire. Puoi avere intuizioni, ma questo è il massimo che puoi ottenere. L’idea che puoi trasformare quelle vaghe intuizioni in una previsione a cascata precisa è, ancora una volta, una completa follia.

A proposito, questa piccola apparente contraddizione sulla costruzione del software come processo di apprendimento spiega anche perché a volte replicare un pezzo di software può essere estremamente facile o estremamente difficile. Se un team cerca di replicare un prodotto software che è già sul mercato e questo team ha accesso alla comprensione o alle lezioni che hanno portato alla produzione del software che stanno cercando di copiare, allora tipicamente replicare il prodotto software - reimplementarlo o ricodificarlo - può essere fatto con solo una piccola frazione del tempo e del budget che è stato necessario per creare il software in primo luogo. Al contrario, se il team non ha accesso a queste intuizioni di alto livello e, ad esempio, l’unica cosa a cui ha accesso è il codice sorgente, il team finirà molto frequentemente con un prodotto di qualità molto bassa perché essenzialmente tutte le parti apprese o i frammenti di conoscenza sono stati persi. Hai appena replicato l’aspetto superficiale del prodotto.

Dal punto di vista della supply chain, la sfida più grande qui è rinunciare volontariamente e domare il tuo bisogno di controllo. Il processo a cascata è l’espressione di un’azienda che vuole controllare il processo. Ad esempio, se dico: “mettiamo sotto controllo questo progetto”, ciò sarebbe percepito come qualcosa di molto ragionevole. Perché dovresti fare il contrario? Perché dovresti affermare, ad esempio, “lasciamo che questo progetto sia completamente fuori controllo?” Ma la realtà è che questo grado di controllo è un’illusione completa per quanto riguarda il software e danneggia completamente la tua capacità di consegnare un prodotto di alta qualità alla fine. Domare il tuo desiderio di controllo è, dal punto di vista della supply chain, probabilmente la sfida più grande quando si tratta della costruzione del software.

Sin dall’emergere dei programmi informatici, sono stati afflitti da bug e difetti. Per affrontare questi problemi evidenti, il punto di vista dominante è che sia necessario effettuare dei test. I test assumono molte forme. Per quanto riguarda la necessità di test, sono d’accordo, anche se questo è molto vago in questo momento. Alcuni strumenti sottolineano che i test devono essere effettuati dopo la costruzione, alcuni sottolineano che i test devono essere effettuati durante la costruzione e altri specificano che i test devono essere effettuati prima della costruzione. Alcuni approcci affermano che i test devono essere effettuati prima, durante e dopo la costruzione del software.

La mia visione generale sul problema è che si dovrebbe fare tutto il possibile per mantenere il ciclo di feedback il più breve possibile. Abbiamo discusso questo punto nella precedente lezione: mantenere il ciclo di feedback il più breve possibile è di importanza critica per ottenere effettivamente qualcosa che funzioni nel mondo reale. Pertanto, di solito consiglierei di prestare attenzione a ciò che stai facendo in termini di testing per capire se stai effettivamente stringendo questo ciclo di feedback o meno. Ad esempio, per la maggior parte delle situazioni, non raccomanderei naturalmente lo sviluppo guidato dai test (una metodologia che dice che i test vengono prima), semplicemente perché per la maggior parte delle situazioni, iniziare con i test ritarderà solo il tempo necessario per ottenere un feedback sul tuo pezzo di software dal mondo esterno.

Tuttavia, la mia più grande preoccupazione riguardo ai test è una limitazione non detta, qualcosa che sembra essere generalmente trascurato. I test possono valutare solo il rispetto delle regole che hai stabilito tu stesso. Il problema è che nel software non ci sono vincoli rigidi. Non esiste un modo chimico per avvicinarsi all’adeguatezza del tuo prodotto rispetto al problema che stai cercando di risolvere. Questo è molto diverso dal mondo fisico. Ad esempio, nell’ingegneria meccanica, c’è un criterio canonico: la tolleranza dimensionale di una parte. Qualunque cosa tu stia progettando in termini di ingegneria meccanica, la tolleranza dimensionale sarà di primaria importanza. È un candidato ovvio e naturale. Tuttavia, nel software non esistono candidati ovvi e naturali.

Il problema qui diventa quello dell’adeguatezza. Se vogliamo prendere un esempio di supply chain, come le scorte di sicurezza, è completamente semplice progettare un insieme di test automatizzati per convalidare i calcoli delle scorte di sicurezza. È molto semplice implementare questo tipo di logica di testing. Tuttavia, questo non può dirti che le scorte di sicurezza sono una cattiva idea fin dall’inizio. Stai testando solo ciò che conosci.

Quando si tratta di una macchina fisica, ci aspettiamo usura e strappo e quindi ci aspettiamo una sorta di manutenzione per mantenere la macchina in condizioni di funzionamento. Tuttavia, perché il software avrebbe bisogno di qualsiasi tipo di manutenzione per continuare a funzionare? Certamente, dobbiamo sostituire i computer quando si guastano nel tempo. Tuttavia, questo aspetto è molto marginale e nel software aziendale, i guasti fisici delle macchine non rappresentano nemmeno il 10% dei costi effettivi di manutenzione. Questo esiste, ma l’impatto di questo tipo di manutenzione è estremamente limitato.

Tuttavia, la manutenzione nel software aziendale è di primaria importanza. I costi di manutenzione sono enormi. Per molti fornitori di software aziendale, la manutenzione rappresenta letteralmente l'80% o più dei costi di ingegneria. Si scopre che i fattori che generano questa necessità di manutenzione hanno ben poco a che fare con la fisica. Il primo fattore è la volontà di pagare dei clienti stessi. Se un fornitore può far pagare una quota di manutenzione annuale del 20% rispetto a quanto è stato pagato per l’installazione del software durante il primo anno, allora il fornitore di software addebiterà quella cifra. Fondamentalmente, dal punto di vista dei costi, il costo della manutenzione è determinato dalla volontà di pagare dei clienti aziendali.

Il secondo fattore è il tipo di manutenzione che deve essere effettuata solo per mantenere il software in funzione. Infatti, ogni singolo giorno che passa, l’ambiente circostante il prodotto di interesse si discosta dal prodotto stesso. Il sistema operativo continua a evolversi, il sistema di database continua a evolversi e lo stesso si può dire per tutte le librerie di terze parti utilizzate dal software. Nessun prodotto software è un’isola. Ogni singolo prodotto software dipende da una miriade di altri prodotti software e quegli altri prodotti si evolvono da soli. Le persone che sviluppano quei prodotti software continuano a lavorarci e mentre lavorano su quei prodotti, li modificano. Quindi, arriva un momento in cui il prodotto che hai smette semplicemente di funzionare perché c’è un’incompatibilità. Non hai fatto nulla tranne che non tenerti al passo con il resto del mercato. Il secondo fattore è tutta la manutenzione che deve essere effettuata solo per mantenere il software in funzione e per renderlo compatibile con il resto del mercato.

Il terzo fattore è la quantità di lavoro necessaria per mantenere il prodotto utile. Infatti, il software è stato progettato ed elaborato in un certo momento e ogni singolo giorno che passa, il mondo si discosta da ciò che è stato visto al momento in cui il prodotto è stato progettato in primo luogo. Quindi, anche se nulla si rompe realmente in termini di compatibilità hardware, si scopre che man mano che il mondo cambia, inevitabilmente l’utilità del prodotto diminuisce perché il mondo si discosta semplicemente dalle aspettative che sono state incorporate nel prodotto. Se vuoi mantenere il software utile, devi costantemente mantenerlo.

Dal punto di vista della supply chain, la manutenzione è una grande sfida e abbiamo affrontato questo aspetto nella precedente lezione, che riguardava la consegna orientata al prodotto per la supply chain. Il costo della manutenzione influisce significativamente sui benefici capitalistici che puoi ottenere dal tuo progetto software. Idealmente, vuoi che il tuo progetto software abbia un ritorno sull’investimento molto elevato, ma per farlo devi assicurarti di non avere costi di manutenzione massicci. Questi costi annulleranno completamente il profitto e il rendimento capitalistico che puoi ottenere dal tuo investimento software.

La sfida più grande qui, ancora una volta dal punto di vista della supply chain, è che il modo più semplice per ridurre i costi di manutenzione è concentrarsi su ciò che non cambia. Come ho già detto, la maggior parte dei costi è legata alle cose che accadono e che stanno cambiando, sia nell’ecosistema del software che nel mondo in generale. Tuttavia, se ti concentri sulle cose che non cambiano, otterrai essenzialmente la maggior parte del tuo software che si deteriorerà solo lentamente perché, appunto, la maggior parte di ciò che il tuo software affronta sono le cose che non cambiano.

Il problema è che concentrarsi su ciò che non cambia è più facile a dirsi che a farsi, perché hai una forza molto umana che si oppone a questo intento: la paura di perdere qualcosa. Quando guardi la stampa, i media, i tuoi colleghi, ecc., ci sarà un flusso costante di novità, parole alla moda e ogni singola parola alla moda ha questa urgenza, a causa della paura di perdere qualcosa, di fare semplicemente la cosa e non essere lasciato indietro. Ad esempio, tutte quelle parole alla moda sarebbero IA, blockchain, IoT e tutte quelle cose che sono molto presenti. Credo che nella supply chain, queste parole alla moda siano davvero una distrazione e contribuiscano significativamente ai problemi di manutenzione perché sono una distrazione da ciò che non cambia. Al contrario, quando inizi a guardare quelle parole alla moda, stai cavalcando un’onda e stai cavalcando esattamente il tipo di cose che molto probabilmente cambieranno nel tempo, aumentando così nel tempo i tuoi costi di manutenzione.

Ora che abbiamo finito con la visione tradizionale dell’ingegneria del software, approfondiamo una serie di consigli personali che dovrebbero essere utili per condurre iniziative software tenendo a mente la supply chain. Uno dei problemi più frequenti quando si tratta di persone che lavorano nel settore del software è una misconcezione sulla propria identità e sto rubando questa idea da un imprenditore di nome Paul Graham. Un ingegnere, ad esempio, dirà: “Sono un ingegnere Python”. Anche se potrebbe non essere così estremo, è molto frequente che gli ingegneri del software percepiscano la propria identità attraverso una breve serie di tecnologie che hanno padroneggiato, che compongono il loro set di competenze. Questa confusione tra la propria identità e il proprio attuale set di competenze tende ad essere rafforzata dalle pratiche di assunzione che sono diffuse nel settore IT e del software in generale. Dal punto di vista dell’assunzione, ci sono molte aziende che dichiarano nei loro annunci di lavoro: “Ho bisogno di un programmatore Python”. Quindi, c’è qualcuno da una parte che pensa: “Sono un programmatore Python” e poi c’è un’azienda che pubblicherà una posizione di lavoro in cui è praticamente scritto: “Ho bisogno di un programmatore Python”. Quindi, improvvisamente avere la giusta identità non è solo una questione di percezione; ci sono ricompense finanziarie legate all’avere la giusta identità, l’etichetta giusta, il tag giusto che puoi attaccare a te stesso, rendendoti più attraente sul mercato.

Tuttavia, questa percezione basata sull’identità, in cui le tecnologie diventano legate a sé stesse come ingegnere del software, porta a numerosi problemi che influenzano praticamente ogni singolo progetto software e in particolare i progetti software della catena di approvvigionamento. Quando si interagisce con una persona, tipicamente un ingegnere del software, che ha fortemente legato la propria identità alla tecnologia presente nella tua azienda, il problema diventa che ogni critica alla tecnologia tende ad essere presa da un punto di vista personale. Se dici che sono un programmatore Python e critichi il mio software, lo prendo personalmente. Il problema è che non appena le persone prendono le critiche alla tecnologia come critiche personali, diventa molto difficile ragionare su quei problemi. Questi ingegneri del software tenderanno, sfortunatamente, a respingere tutti i feedback, solo perché li vedono in parte come critiche personali.

Al contrario, se l’azienda utilizza una tecnologia che non è la tecnologia percepita come identità principale dall’ingegnere del software, ad esempio, la tua azienda ha alcuni sistemi implementati in Java e hai un ingegnere del software che dice: “Sono un programmatore Python”, allora tutti i problemi saranno percepiti attraverso la lente che questa tecnologia è di bassa qualità. Di nuovo, questo è un altro problema in cui le critiche e i feedback saranno respinti come un atteggiamento del tipo “non è un mio problema; è solo a causa di questa tecnologia molto scadente che è stata utilizzata qui e ora in questa azienda”. In entrambe le situazioni, che l’ingegnere del software abbia un’identità legata alla tecnologia che stai utilizzando o abbia un’identità legata a una tecnologia che non stai utilizzando, si creano una serie di problemi e i feedback vengono respinti invece di essere sfruttati per migliorare la tecnologia.

Ora, da una prospettiva della catena di approvvigionamento, dobbiamo tenere presente che l’ambiente della catena di approvvigionamento è incredibilmente caotico e quindi i problemi si verificheranno tutto il tempo. Proprio a causa di questo caos ambientale, è molto importante avere team di ingegneri del software che possano guardare dritto negli occhi questi problemi e fare qualcosa al riguardo, anziché respingere i feedback quando si verificano. È fondamentale assemblare team che non alimentino il dramma in cima al caos della catena di approvvigionamento a causa della loro percezione della propria identità.

Questa idea si estende agli ingegneri del software, che spesso scelgono tecnologie che si adattano alla loro identità o all’identità che vogliono acquisire. Scelgono la tecnologia per acquisire le competenze, in modo da poter aggiungere un’altra parola chiave al loro curriculum. Tuttavia, questo approccio porta a scegliere tecnologie per motivi non correlati alla risoluzione dei problemi che l’azienda deve affrontare. Questa è la prospettiva sbagliata per decidere se una tecnologia è rilevante o adeguata per affrontare le specifiche problematiche dell’organizzazione.

Costruire un curriculum può essere un potente motivatore per gli ingegneri del software, poiché ci sono vantaggi finanziari reali associati all’avere un elenco di parole chiave. Le migliori aziende software spesso guardano con disprezzo i curriculum con un lungo elenco di parole chiave. Come CEO di Lokad, se vedo un curriculum con mezza pagina di parole chiave, viene scartato direttamente. Tuttavia, molte aziende, specialmente quelle mediocri, cercano attivamente persone con molte parole chiave, pensando che queste persone saranno incredibilmente versatili e agili all’interno dell’organizzazione. Dalla mia esperienza, spesso è il contrario.

Continuando con il tema dell’identità e della costruzione del curriculum, è fondamentale prestare attenzione al fatto che gli architetti del software non dovrebbero essere troppo legati a una particolare tecnologia. Già è difficile assumere ingegneri del software, quindi a volte bisogna fare compromessi. Tuttavia, quando si tratta di architetti del software, fare compromessi selezionando individui con un attaccamento emotivo a una determinata tecnologia può essere disastroso. Queste persone avranno un impatto su larga scala sulla tua azienda.

Questo problema di pregiudizio nella costruzione del curriculum non è limitato agli ingegneri del software o ai professionisti del software. Si verifica anche tra il personale IT. Ad esempio, ho incontrato diversi direttori IT in grandi aziende che volevano passare a SAP mentre il loro esistente ERP era perfettamente funzionante. I costi enormi associati al passaggio a SAP non sarebbero mai stati compensati dai benefici attesi di un ERP più moderno. In questi casi, era in atto un comportamento irrazionale, in cui l’interesse personale del direttore IT nel implementare SAP nel suo curriculum prevaleva sull’interesse dell’azienda stessa.

Da una prospettiva della catena di approvvigionamento, è essenziale prestare attenzione a questi conflitti di interesse. Non è necessario avere molte competenze o competenze nel campo del software per individuare i conflitti di interesse. In altri settori, come la scienza medica, anche i medici possono prescrivere farmaci sbagliati a causa di conflitti di interesse, anche quando sono in gioco delle vite. Questo dimostra che i conflitti di interesse sono incredibilmente tossici. Immagina solo come si manifestano questi problemi nella gestione della catena di approvvigionamento, dove non ci sono vite in gioco e la principale preoccupazione è il denaro. In questo contesto, c’è ancora meno riluttanza a lasciare che i conflitti di interesse si sviluppino.

A differenza del mondo fisico, il mondo del software offre pochissimi vincoli su come procedere con le iniziative software e l’approccio al lavoro. La natura umana non ama il vuoto e le persone possono sentirsi inquiete per la mancanza di struttura. Di conseguenza, nel corso degli anni sono emerse numerose pratiche che continuano a evolversi. Con ogni pratica viene introdotta una nozione di ortodossia. Alcuni esempi di queste pratiche includono la programmazione estrema, il design orientato al dominio, il design guidato dai test, i microservizi, Scrum e la programmazione agile. Ci sono molte pratiche e ne emergono di nuove ogni anno.

Con ogni pratica viene introdotta una nozione di ortodossia. Non appena le persone iniziano a seguire una pratica, possono interrogarsi se stanno aderendo ai principi fondamentali. Gli ingegneri del software sono solo persone e le persone amano i rituali e le tribù. Una pratica fornisce un senso di appartenenza a una tribù con credenze condivise. Ecco perché troverai anche incontri associati a queste pratiche, che soddisfano un bisogno molto umano.

Può essere difficile e persino deprimente fissare un problema, incerti su tutto e avere quasi nessuno con cui confrontarsi per affrontare la questione. La cosa interessante è che, anche se una pratica può essere discutibile o leggermente irrazionale, i benefici possono essere reali. Pubblicizzare una pratica all’interno e all’esterno della tua azienda può aumentare il morale e aiutare a reclutare candidati potenziali.

In un colloquio di lavoro, quando le persone chiedono come lavori, non è esattamente convincente dire che improvvisi e non hai regole. È più efficiente ispirare fiducia presentando una pratica come se risolvesse i problemi all’interno dell’azienda. Il punto chiave è che, nel breve termine, queste pratiche non sono tutte negative, anche se sono per lo più irrazionali. Generare un senso di appartenenza può essere vantaggioso. Tuttavia, diventa velenoso se le pratiche vengono prese troppo sul serio o per troppo tempo. Una pratica può essere interessante solo perché ti costringe a guardare il problema da un angolo diverso. Ma una volta che hai guardato il problema da un angolo diverso, dovresti cercare un altro angolo. Non dovresti attenerti a un solo angolo per troppo tempo. Da una prospettiva della catena di approvvigionamento, questo illustra l’eccezionalità radicale del mondo del software.

Nella fabbrica, l’eccellenza significa fare sempre esattamente la stessa cosa. Nel mondo del software, è esattamente il contrario. Se fai sempre la stessa cosa, è una ricetta per la stagnazione e il fallimento nel tempo.

Il software è complesso e il software aziendale lo è ancora di più. Spesso, diversi ingegneri finiscono per lavorare su una determinata iniziativa, il che porta a una tendenza naturale alla specializzazione. Quando un ingegnere lavora su una determinata parte del codice, c’è una propensione naturale ad assegnare la stessa persona quando nuovi compiti richiedono di toccare quella stessa parte del codice. I benefici sono reali, poiché questa persona è già familiare con il codice e può essere più produttiva.

Il problema principale della specializzazione è che può portare a un senso di proprietà su determinate parti del codice, creando vari problemi. Ci sono due classi di problemi associati a questa proprietà: il “fattore camion” e i giochi di potere. Il fattore camion si riferisce al rischio di perdere un dipendente che possiede conoscenze o competenze uniche. Ciò potrebbe essere dovuto all’uscita del dipendente per un’altra azienda o all’incapacità di lavorare per qualsiasi altro motivo. I giochi di potere possono verificarsi se un dipendente si rende conto che il suo contributo è vitale per l’azienda e utilizza questa leva per richiedere uno stipendio più alto o altri benefici.

Nella mia esperienza, gli ingegneri del software di solito non hanno una forte propensione a fare giochi di potere, ma questi problemi possono diventare sempre più frequenti nelle grandi aziende. Ci sono molte pratiche di ingegneria del software che cercano di affrontare questo problema direttamente, come la programmazione in coppia. Tuttavia, l’idea chiave è che troppo di una cosa buona può essere velenoso per l’azienda. La cosa migliore è essere consapevoli di questa classe di problemi, piuttosto che attenersi semplicemente a una pratica particolare che dovrebbe affrontare il problema. Questo perché tali pratiche possono creare altri problemi, distrarti o limitare la tua capacità di prestare attenzione ad altre cose che non hai ancora visto. Da un punto di vista del software, la lezione chiave qui è che la cultura è l’antidoto a questa classe di problemi, non il processo.

Ci troviamo di fronte a una situazione in cui abbiamo un trade-off molto sottile tra i guadagni di produttività ottenuti grazie alla specializzazione delle persone in determinate parti del codice e i rischi associati al fatto che queste persone possiedano quelle parti del codice. Quello che si desidera è coltivare una situazione in cui ci sia sempre un certo grado di ridondanza in termini di conoscenza sulla base di codice da parte di tutto il team, in modo che ogni singolo ingegnere abbia una certa sovrapposizione di competenze. Questo è un trade-off molto sottile che devi raggiungere se vuoi mantenere un certo grado di produttività. L’unico modo per farlo effettivamente nel mondo reale è attraverso una cultura ben compresa dell’ingegneria del software. Non esiste un processo che possa garantire che le persone siano curiose del lavoro dei loro colleghi. Non puoi avere un processo sulla curiosità; deve far parte della cultura.

Valutare le competenze e la competenza degli ingegneri del software è difficile, e questa domanda è fondamentale perché sebbene il software sia chiaramente un lavoro di squadra e la squadra sia più della somma dei suoi membri, il livello di base dei membri del team ha un grande impatto sulle prestazioni dell’intero team.

Un aspetto che ho osservato essere ampiamente sottovalutato dalle persone al di fuori dell’industria del software, e talvolta anche dalle persone all’interno dell’industria, è l’importanza delle competenze di scrittura. Se stai creando software, stai soddisfacendo due pubblici distinti. Da un lato, hai il pubblico della macchina, il tuo compilatore. Scrivi il codice e il tuo compilatore lo accetterà o lo rifiuterà. Questa è la parte facile. Il tuo compilatore è il tuo compagno indefesso che ti dirà se il tuo codice è corretto o sbagliato. Il compilatore è completamente prevedibile e ha una pazienza infinita.

Dall’altro lato, hai il pubblico dei tuoi colleghi, che probabilmente includerà te stesso tra sei mesi. Scrivi il codice e alla fine lo dimenticherai. Sei mesi dopo, guarderai il codice che hai scritto, pensando che sia stato scritto da qualcun altro perché sembra così poco familiare. Quando scrivi codice per i tuoi colleghi, il vantaggio è che a differenza dei compilatori, i tuoi colleghi cercheranno di capire cosa stai cercando di ottenere. Il compilatore non cerca di capire le tue intenzioni; applica meccanicamente un insieme di regole.

I tuoi colleghi cercheranno di capire, ma sfortunatamente non sono come i compilatori. Non hanno una pazienza infinita e possono essere facilmente confusi e indotti in errore dal tuo codice. Ecco perché, ad esempio, scegliere nomi memorabili, illuminanti e appropriati è di primaria importanza. Un buon programma non riguarda solo avere qualcosa di corretto; anche la scelta dei nomi delle variabili, delle funzioni e dei moduli è di importanza critica se vuoi avere un codice che si integri bene con i tuoi colleghi e, ancora una volta, i tuoi colleghi includono te stesso tra sei mesi. Da una prospettiva di supply chain, il messaggio chiave è che le competenze di scrittura sono di primaria importanza e oserei dire che spesso sono più importanti delle competenze tecniche. Le buone competenze di scrittura sono la competenza numero uno di cui avrai bisogno per domare la complessità presente nella tua supply chain. Domare la complessità del tuo panorama applicativo non è una grande sfida tecnica; è una sfida di organizzazione di idee ed elementi e di avere una storia coerente in tutto il quadro. Queste sono competenze molto simili alla scrittura e abbiamo affrontato questo aspetto in una precedente lezione dal titolo “Scrittura per la supply chain”.

Se la competenza di scrittura è di primaria importanza per essere un buon ingegnere del software, c’è un’altra competenza che è di primaria importanza per essere un ingegnere del software in generale: la tolleranza al dolore. Credo che questa sia la competenza numero uno nel senso di ciò che serve per essere effettivamente un ingegnere del software, non un grande ingegnere, solo un ingegnere. Più specificamente, quando dico dolore, intendo la resistenza alla noia e alla frustrazione che accompagnano il processo di sviluppo del software quando si affrontano sistemi estremamente fragili, mal progettati e pieni di insidie in tutti i modi possibili, a volte da parte di persone che non ci sono nemmeno più. Quando si lavora con il software, si hanno quattro decenni di problemi accumulati sotto i piedi e si lotta con essi tutto il tempo. Questo può essere un esercizio incredibilmente frustrante a volte.

Solo per darti un’illustrazione, come ingegnere del software, avrai bisogno della pazienza di trascorrere quattro ore a cercare tra conversazioni casuali e semi-spazzatura su un forum web che menzionano un codice di errore simile a quello che stai affrontando. Dovrai passare attraverso questo tipo di assurdità per ore per arrivare alla radice del problema e a volte ci vogliono settimane per risolvere un bug apparentemente banale. Di conseguenza, la conseguenza di ciò è che abbiamo un processo di selezione avversa molto intenso in atto in tutta l’industria del software, che seleziona persone che hanno una grande tolleranza al dolore. Questo processo di selezione ha due conseguenze principali.

In primo luogo, le persone che rimangono ingegneri del software tendono ad essere incredibilmente tolleranti al dolore. Quando dico tolleranti al dolore, intendo la resistenza alla frustrazione derivante dai costanti problemi software affrontati. Se stai selezionando persone con una tolleranza incredibile al dolore, potrebbero non riconoscere nemmeno quando le loro azioni stanno peggiorando la situazione. Potrebbero aggiungere stranezze aggiuntive ai prodotti software, aumentando il livello di frustrazione nell’interagire con il software per tutti, inclusi loro stessi. Tuttavia, se hanno una tolleranza incredibile al dolore, non ci prestano attenzione. Questo processo di selezione avversa esclude le persone comuni che presterebbero attenzione ma non sono diventate ingegneri del software perché non sopportavano il dolore. Questo problema è particolarmente intenso per il software di supply chain perché ci sono molte parti che non sono super eccitanti. Alcuni aspetti possono essere necessari ma banali, il che significa che le persone con una grande tolleranza al dolore che operano in questo campo possono peggiorare la situazione a causa dell’abbondanza di compiti potenzialmente noiosi.

Il secondo aspetto di questo processo di selezione avversa è che quando le persone possono permettersi il lusso di accettare un salario più basso per evitare problemi che generano un dolore intenso, lo fanno. Se qualcuno è già ben pagato, potrebbe decidere di accettare un lavoro meno remunerato ma con il vantaggio di un dolore meno intenso. La maggior parte delle persone probabilmente farebbe questo, e nella pratica molte persone lo fanno. Ciò significa che le persone che rimangono in questo settore, dove c’è una intensità molto alta di dolore ambientale, sono spesso coloro che non possono permettersi di rinunciare all’opportunità di un salario più alto. Questo spiega, in larga misura, perché ci sono un numero significativo di ingegneri del software provenienti dall’India e dal Nord Africa. Questi paesi hanno sistemi educativi abbastanza buoni che producono individui ben istruiti, ma i paesi sono ancora relativamente poveri. Le persone in queste posizioni non hanno il lusso di rinunciare a lavori di ingegneria del software più remunerati a causa dell’alta domanda e dei salari più alti rispetto ai loro salari di base. Non hanno il lusso di fare altro, e quindi finiscono per essere molto presenti nel settore.

Non c’è nulla di sbagliato in questi paesi; è solo un’applicazione meccanica delle forze di mercato. Questo non è un giudizio, solo un’osservazione. Il fatto è che la tolleranza al dolore non è tutto ciò che serve per essere un ottimo ingegnere del software. È solo una condizione, ma se non hai quella, allora non sei affatto un ingegnere del software. Tuttavia, se la tolleranza al dolore è l’unica cosa che hai, ti renderà un ingegnere del software piuttosto mediocre. Da una prospettiva di supply chain, la lezione qui è prestare molta attenzione al tipo di team che la tua azienda sta radunando, sia internamente che attraverso fornitori di software. Assicurati che gli ingegneri che vengono raccolti non abbiano la tolleranza al dolore come unica competenza, perché ciò significa che avrai un risultato molto scarso in termini di qualità del software e valore aggiunto del software. Di nuovo, la tolleranza al dolore è necessaria, ma non è sufficiente.

Nel 1975, Frederick Brooks stava già sottolineando che i mesi-uomo non rappresentavano il valore creato dal software e il valore generato dagli ingegneri del software in generale. Quasi cinque decenni dopo, le aziende IT sono tra i più grandi datori di lavoro al mondo. Nel 2020, negli Stati Uniti, c’erano 3 milioni di dipendenti nel settore IT, ma meno di 1 milione di persone per l’intero settore automobilistico. L’industria IT ha ora almeno tre volte più persone rispetto all’industria automobilistica. La maggior parte di queste aziende IT, alcune delle quali sono assolutamente gigantesche con diverse centinaia o migliaia di dipendenti, non addebitano più per mesi-uomo. Questo era negli anni ‘70. Ora addebitiamo per kilo-giorni, che corrisponde fondamentalmente a mille giorni di manodopera. La situazione è argomentabilmente peggiorata rispetto al problema che Frederick Brooks stava delineando quasi cinque decenni fa, principalmente a causa dell’incredibile aumento in termini di scala e magnitudine del problema. Tuttavia, la maggior parte delle prime lezioni è ancora valida. “The Mythical Man-Month” rimane un libro molto interessante sull’ingegneria del software.

Nel software, la produttività varia enormemente. Da un lato dello spettro, non ci sono persone con una bassa produttività; ci sono persone con una produttività negativa. Ciò significa che quando iniziano a lavorare su un prodotto software, lo peggiorano solo. Non puoi nemmeno fare più un rapporto tra la produttività delle persone. È molto peggio di così; ci sono persone che danneggiano attivamente il tuo prodotto. Questo è un problema enorme. Dall’altro lato dello spettro, ci sono gli ingegneri cosiddetti 10x, persone che hanno una produttività dieci volte superiore rispetto a un ingegnere medio, che sperabilmente ha una produttività positiva. Questi ingegneri 10x esistono, ma questa produttività massiccia dipende incredibilmente dal contesto. Non puoi semplicemente trasferire un ingegnere software 10x da un’azienda all’altra o anche da una posizione all’altra e aspettarti che quella persona mantenga la sua incredibile produttività. Di solito, è una combinazione di competenze uniche e una situazione specifica che genera quella produttività. Tuttavia, è importante tenere presente che poche persone possono guidare la maggior parte del valore generato da un prodotto software. A volte, si riduce a una sola persona che crea la maggior parte di tutti gli elementi intelligenti del software e il vero valore aggiunto, mentre il resto si occupa di cose che hanno un valore aggiunto discutibile al massimo. La lezione chiave qui, identificata cinque decenni fa, è che quando si è in ritardo nella supply chain, l’unica opzione ragionevole a disposizione è ridurre l’ambito dell’iniziativa software. Tutte le altre opzioni sono peggiori.

Aggiungere manodopera peggiora le cose, come si dice spesso che aggiungere manodopera a un progetto software in ritardo lo rende ancora più in ritardo. Questa affermazione di Brooks era valida cinque decenni fa ed è ancora valida oggi. Le altre opzioni non funzionano neanche. Se inizi a far fare straordinari alle persone, si ritorcerà contro perché le persone saranno stanche e faranno più errori, ritardando ulteriormente il prodotto. Se cerchi di abbassare la qualità, finirai con qualcosa che non funziona più. Queste cose sfuggiranno al tuo controllo ed esploderanno tra le tue mani, quindi non puoi compromettere la qualità.

Da una prospettiva di supply chain, la lezione chiave qui è che se affronti un’iniziativa che sembra richiedere più di dieci ingegneri software a tempo pieno, procedi con la massima cautela. Di solito, è un segno che si tratta di un problema molto mal formulato. È necessario un incredibile lavoro di squadra per far lavorare dieci persone sullo stesso prodotto contemporaneamente mantenendo la produttività. Nella supply chain, osservo che le persone spesso sono troppo ambiziose in termini di scala e numero di persone coinvolte. Ho visto progetti di migrazione ERP con 50, 100 o 200 persone che lavoravano contemporaneamente. Questo è assolutamente insensato. Raggiungere qualsiasi grado di cooperazione richiede giocatori di squadra incredibilmente capaci per evitare di perdere tutto a causa degli attriti. Se stai avendo difficoltà, mantieni la tua iniziativa software focalizzata, breve e limitata.

La mia osservazione finale riguarda un fraintendimento frequente riguardo alle grandi aziende. La maggior parte delle persone direbbe che le grandi aziende sono avverse al rischio, ma questa non è la mia esperienza. La mia esperienza è che le grandi aziende sono avverse all’incertezza, non al rischio, anche se da lontano le due cose possono essere confuse. Da lontano, la spiegazione razionale data è che le grandi aziende sono avverse al rischio, ma in realtà ho osservato più volte che le grandi aziende, quando si trovano di fronte all’opportunità di scegliere tra un fallimento certo e un successo incerto, favoriranno invariabilmente la certezza del fallimento rispetto al successo incerto.

Le grandi aziende favoriranno invariabilmente la certezza del fallimento rispetto al successo incerto, ancora e ancora. Questo può sembrare sconcertante e irrazionale in superficie, ma non lo è. Le grandi aziende non sono un’unica entità; sono bestie politiche composte da molte persone. La politica e le apparenze sono fondamentali, soprattutto nelle strutture molto grandi.

Considera la prospettiva di chi è responsabile di un’iniziativa software. Da un lato, hai un’iniziativa in cui l’esito è certo: fallirà. Tuttavia, stai giocando secondo le regole e tutti sanno che fallirà. Nessuno ti biasimerà per giocare sul sicuro e fallire, perché è ciò che si aspettano. Al contrario, il successo incerto sembra strano. Seguire questa strada significa fare cose insolite e potenzialmente dannose per la carriera, molto più di quanto non lo sia giocare secondo le regole.

Dal punto di vista della supply chain, la lezione qui è che nel mondo del software è estremamente importante non predisporre il proprio fallimento solo per giocare secondo le regole, soprattutto quando le regole sono completamente sbagliate. Ad esempio, ho visto aziende fallire per decenni utilizzando metodi come l’analisi ABC e le scorte di sicurezza, metodi che possono essere provabilmente errati e garantire il fallimento delle relative iniziative. Questi metodi sono sbagliati per motivi matematici e statistici di base, quindi non dovrebbe sorprendere che non riescano a fornire valore aggiunto nella supply chain. Tuttavia, sono stati ritenuti preferibili perché non sembravano pazzi, essendo materiale di testo.

Attenzione al comfort che si può ottenere predisponendo il proprio fallimento solo per eliminare l’incertezza. Eliminare l’incertezza non è l’obiettivo; l’obiettivo è massimizzare la possibilità di successo, non ridurre l’incertezza.

In conclusione, l’ingegneria del software è troppo importante per essere lasciata solo nelle mani degli ingegneri del software. Il software è ovunque nella supply chain e sta guidando la meccanizzazione del lavoro intellettuale. Siamo ancora in una fase iniziale del processo, ma si può già dire, senza dubbio, che le aziende che non rimangono estremamente competitive su questo fronte saranno eliminate dal mercato del tutto dalle normali forze di mercato. Per la supply chain, la sfida più grande è di natura culturale. Questo non è un problema tecnico, ma un problema culturale. L’ingegneria del software mette in discussione il modo stesso in cui guardiamo e affrontiamo i problemi. La maggior parte delle soluzioni intuitive tende ad essere sbagliata, spettacolarmente.

In un certo senso, l’ingegneria del software nella supply chain riguarda la domare il caos, domare tutta la complessità e l’incertezza che si trova ovunque nella supply chain. Per domare questo caos, che sarà il compito degli ingegneri del software, se il processo stesso è troppo levigato o ordinato, se il processo stesso non ha un elemento di caos al suo nucleo, allora non c’è spazio per il cambiamento, la casualità o la creatività. Quello che viene percepito come eccellenza si trasforma rapidamente in stagnazione e poi in fallimento. Per le aziende più tradizionali, la sfida più grande di questo approccio culturale, oltre allo shock culturale, è lasciar andare l’illusione del controllo. Il tuo piano di migrazione ERP quinquennale è un’illusione; non hai alcun controllo su un progetto così massiccio. Allo stesso modo, il tuo business case che illustra i profitti attesi della tua attuale iniziativa è anche un’illusione.

Affrontare la meccanizzazione del lavoro intellettuale comporta il maggior pericolo di non fare cose che non puoi pienamente razionalizzare. Il maggior pericolo è fare cose completamente irrazionali sotto mentite spoglie di razionalità.

Diamo un’occhiata alla domanda. La prossima lezione si terrà mercoledì 15 dicembre, alla stessa ora, alle 15:00, ora di Parigi, e tratterà la sicurezza informatica. Ora, darò un’occhiata alla domanda.

Domanda: Come misuri il ritorno capitalistico dei tuoi investimenti software?

Per lo più, non lo fai. La misurazione è il risultato dell’impresa stessa. È qualcosa di confuso se vuoi misurare il ritorno sull’investimento. Presuppone che tu possa trovare una misurazione in anticipo, cosa che di solito è implicita in questo tipo di domanda. Presuppone che tu possa trovare questa misurazione prima di costruire il tuo caso aziendale con scenari e poi puoi prendere una decisione e procedere o meno con il tuo investimento software. Quello che sto dicendo è che non funziona così con il software. Letteralmente, prima fai la cosa, poi impari cosa devi imparare e lungo il percorso, imparerai anche che tipo di benefici ci sono. Per guidare la tua azione, hai bisogno di una comprensione a livello elevato. La lezione non è fare le cose a caso, ma non fare le cose che sono profondamente irrazionali sotto mentite spoglie di razionalità. L’intuizione a livello elevato, se sei assolutamente convinto di qualcosa e il tuo istinto ti dice che è il percorso corretto, può essere un argomento molto più razionale rispetto a calcoli fantasiosi che hanno solo la pretesa di razionalità ma si basano su numeri falsi. La realtà è che man mano che procedi con il tuo progetto software, le misurazioni diventeranno più chiare perché inizierai a imparare ciò che stai cercando di raggiungere e poi imparerai come misurare l’adeguatezza di ciò che stai facendo rispetto a ciò che dovresti fare. La misurazione è qualcosa che arriverà come risultato se lo fai bene. Tuttavia, come conseguenza di ciò, significa che per quanto riguarda il software, è molto meglio provare cose e fallire rapidamente. Non vuoi impegnarti in un impegno massiccio; è meglio farlo in modo estremamente incrementale, con meno persone e alta produttività. Impari lungo il percorso come procedere.

Ma poi arriva un altro problema: non appena inizi a fare ciò, la gestione delle aziende deve essere in grado di gestire molte iniziative contemporaneamente. Questo è molto sconcertante, soprattutto per le aziende più tradizionali, perché la gestione non si aspetta di avere così tante iniziative che vanno in direzioni diverse. Eppure, questo è esattamente ciò che sta già accadendo nelle grandi aziende software da decenni e questa è una delle essenze delle lezioni apprese dall’ingegneria del software da una prospettiva umana.

Domanda: Non è una contraddizione dire che coloro che hanno molte parole chiave non si associano a una particolare tecnologia?

Beh, non dico che avere molte parole chiave ti protegga dall’associarti a una particolare tecnologia. Ci sono due problemi diversi. Uno è il problema di avere una persona che ha una forte associazione tra la propria identità personale, la propria identità percepita e le proprie competenze. Questo è il primo problema. Il secondo problema è che costruire il proprio curriculum vitae comporta un conflitto di interessi molto forte. Il mio messaggio è, da un lato, attenzione a quelle politiche identitarie; sono incredibilmente tossiche. Il mio secondo messaggio è attenzione ai conflitti di interesse in tutte le loro forme; sono incredibilmente tossici anche loro.

Ora, se enfatizzi molto una particolare tecnologia, potresti rimuovere alcune parole chiave per la tecnologia che disapprovi nel tuo curriculum vitae. Tuttavia, di solito, i due problemi sono separati e puoi anche avere qualcuno che dice: “La mia identità è che sono un programmatore Python”, come ho mostrato in una diapositiva, e poi nel tuo curriculum vitae metti più di 20 parole chiave. Le due cose non sono esclusive; possono anche accadere contemporaneamente. Inoltre, non sottovalutare il fatto che a volte l’identità può essere associata a qualcosa di aspirazionale, qualcosa che vuoi acquisire. Potresti dire: “Finora ho programmato in Python, ma voglio diventare un programmatore Rust, quindi mi considero un programmatore Rust, anche se finora ho fatto principalmente Python.” Sono possibili tutti i tipi di comportamenti.

Domanda: L’ingegneria del software è considerata una scienza ausiliaria per la supply chain. Quali sarebbero le scienze ausiliarie per l’ingegneria del software?

Probabilmente la psicologia, la sociologia e l’etnologia sono tutti campi rilevanti quando si tratta di ingegneria del software. Se si inizia ad affrontarla come l’interazione delle persone, allora queste scienze ausiliarie sono cruciali. Per fare un lavoro serio nell’ingegneria del software, non si tratta solo della tecnologia del software, anche se è necessario comprendere il contesto del software in modo che le interazioni tra le persone abbiano senso. Non è necessario capire cosa va nel codice, ma è necessario comprendere concetti come una base di codice o gli strumenti esistenti e i problemi che cercano di risolvere. Tuttavia, per il scopo di questa serie di lezioni sulla supply chain, devo tracciare una linea nel terreno, decidendo cosa includere e cosa non includere, poiché ovviamente non posso coprire ogni singolo campo di ricerca.

Domanda: Chiedi a dieci persone intelligenti una soluzione e ne troveranno più di dieci. Concordare su una delle prime cinque e usarla in modo coerente è meglio. Come bilanci queste due approcci e i relativi vantaggi contrastanti?

È una domanda molto ampia, ma se cerco di inquadrarla nel caso specifico dell’ingegneria del software, puoi avere molte proposte, ma non tutte dovrebbero essere considerate con lo stesso peso. Esiste una competenza nel guardare a lungo termine il software. Quando dico che dovresti concentrarti su ciò che non cambia, si scopre che alcune persone sono molto brave in questo lavoro e altre no. L’esperienza entra in gioco quando si vuole valutare chi ha le competenze per questa visione a lungo termine e cosa non cambia. Nella mia modesta esperienza, di solito ci vuole almeno 35 anni a qualcuno per iniziare a diventare molto bravo in questo, e le persone migliori hanno più di 60 anni. Ci vogliono anni di esperienza per vedere il movimento e i modelli.

Quando dici che hai così tante persone, un’illusione è che tutte quelle soluzioni sembrano buone, ma è solo un’apparenza. Non sai quanto sforzo ci vorrà per testare le acque. Puoi solo fare un prototipo o testarlo? Tra quelle dieci persone, ci sono alcune con competenze uniche nell’individuare soluzioni che saranno dannose a lungo termine? Ricorda che i costi di manutenzione sono essenzialmente determinati dalle decisioni che hai preso. C’è una decisione importante che può farti del male a lungo termine?

Questo è un aspetto complicato e, tra l’altro, qualcuno che ha una visione a lungo termine può spiegare perché una certa opzione, nel lungo periodo, genererà tutti i tipi di problemi. Non è solo un’intuizione. Ti diranno: “Questo tipo di cosa, ci sono passato, l’ho visto in altri prodotti.” C’è un detto: l’uomo intelligente impara dai propri errori, ma l’uomo saggio impara dagli errori degli altri. Questo è molto applicabile a questo caso.

Domanda: Come misurano le aziende l’aumento dell’efficienza operativa per ogni dollaro investito nell’implementazione di software per le supply chain?

Questa è una domanda estremamente difficile. Il problema è letteralmente l’incommensurabilità dei paradigmi. Deriva dall’epistemologia; l’idea è che quando passi da un modo di operare a un altro e quei paradigmi sono radicalmente diversi, la maggior parte delle misure è semplicemente inutile. Prendiamo ad esempio le vendite telefoniche rispetto all’e-commerce. Le aziende di vendita per corrispondenza esistevano già dalla metà del XIX secolo. Se inizi a considerare l’e-commerce come un miglioramento rispetto alle aziende di vendita per corrispondenza, potresti cercare di misurare il miglioramento, ma la realtà è che praticamente tutte le aziende di vendita per corrispondenza sono fallite. Le aziende di e-commerce che dominano oggi sono di diverse ordini di grandezza più grandi della più grande azienda di vendita per corrispondenza che sia mai esistita. Amazon è probabilmente 100 volte più grande della più grande azienda di vendita per corrispondenza storica e il confronto è molto sfocato.

La meccanizzazione del lavoro intellettuale è così incredibilmente preoccupante e puzzolente perché non è come il regno fisico. Con la produzione fisica, puoi misurare l’efficienza con modi canonici. Tuttavia, quando inizi a meccanizzare il tuo lavoro intellettuale, cosa significa efficienza? Per un’azienda come Amazon, l’intera supply chain è completamente guidata dal software. Se le persone rimanessero solo a casa e non facessero nulla, sospetto che l’intera supply chain funzionerebbe comunque bene, anche se tutti quegli ingegneri non facessero nulla per uno o due giorni. Allora perché Amazon tiene ancora quegli ingegneri? Beh, perché investono nei loro miglioramenti.

A proposito, una cosa interessante su Jeff Bezos è il suo processo di gestione chiamato “disagree but commit”. Dice che ci sono progetti in cui il suo istinto da CEO gli dice che è sbagliato e non è d’accordo con il progetto. Tuttavia, si impegna a sostenere il progetto dal punto di vista del budget perché ha assunto e si fida delle persone che ci lavorano. È un approccio un po’ schizofrenico: come CEO, dovrebbe essere l’autorità suprema dell’azienda, ma rinuncia a questa autorità e dice: “Non sono d’accordo, ma puoi avere il budget e procedere”.

Il motivo di questo approccio è che gli investimenti nel software di solito sono abbastanza economici. Se qualcuno propone un’idea apparentemente folle che non è molto costosa e non metterebbe in bancarotta l’azienda, perché non provarci? Se funziona, potrebbe essere un’idea brillante. Questo rappresenta uno shock culturale nel passaggio dalle tradizionali aziende di supply chain, dove la gestione dovrebbe avere la visione e guidare i team. Nel campo del software, il leadership consiste principalmente nel risolvere i problemi che emergono tra gli ingegneri del software.

Da Lokad, quando si investe nel software, la preoccupazione principale non sono i rendimenti in dollari. Invece, l’attenzione è rivolta a capire se l’investimento affronta un aspetto fondamentale della gestione della supply chain. Se è fondamentale per una vasta gamma di situazioni di supply chain, allora vale la pena perseguirlo.

Ad esempio, nel settore dell’aftermarket automobilistico, affrontare il problema della compatibilità meccanica è di primaria importanza. Non stai vendendo pezzi di auto per servire le persone; stai vendendo pezzi per servire le auto. Un singolo pezzo può essere compatibile con più veicoli e alcuni pezzi potrebbero avere sovrapposizioni meccaniche. Questo problema deve essere affrontato; è fondamentale per il business. Se non lo affronti, qualcun altro lo farà e alla fine sarai spinto fuori dal mercato.

Per quanto riguarda gli investimenti nel software, è importante correre rischi e abbracciare l’innovazione, purché non minaccino la stabilità finanziaria dell’azienda.

Domanda: È fuorviante dire che i grandi team di progetto sono assurdi. Nei sistemi ERP, un team di 10 persone potrebbe essere sufficiente per lo sviluppo, ma progetti più grandi richiedono più persone. Per costruire una torre sono necessarie più persone rispetto a una casa. Potresti chiarire i tuoi commenti?

Prenderò una posizione che potrebbe antagonizzare molte persone. Il sostentamento di milioni di persone dipende da aziende IT incredibilmente grandi. Negli Stati Uniti nel 2020, le aziende IT rappresentavano tre milioni di dipendenti americani. Quindi quando dico che non c’è assolutamente motivo di avere un ERP che richiede così tante persone, ovviamente tutte le persone che guadagnano da vivere vendendo grandi team o facendo parte di un tale team saranno fermamente in disaccordo con me.

Il mio punto di vista è: la tua disaccordo deriva da ragioni scientifiche fondamentali che spiegano perché il lavoro non può essere svolto con meno persone, o è nel tuo interesse finanziario mantenere lo status quo e avere un esercito di persone per fare il lavoro? Se guardiamo a tutta l’innovazione che ha avuto luogo, la distruzione creativa delineata dall’economista Schumpeter, ogni volta che c’è stata un’importante innovazione economica, di solito c’è stata un’enorme miglioramento della produttività. Ma coloro che sono rimasti indietro hanno combattuto aspramente per impedire che queste innovazioni avvenissero.

Gli ERP non sono nulla di nuovo; sono presenti da circa quattro decenni. La maggior parte degli ERP che vedo al giorno d’oggi non aggiungono molto valore rispetto a quelli che le aziende avevano uno o due decenni fa. Ho visto molti ERP più vecchi che vanno benissimo, e i nuovi ERP spesso non sono sostanzialmente migliori, soprattutto considerando i milioni investiti nei progetti di migrazione degli ERP. In questi enormi progetti, vedo una produttività abissale da parte delle aziende IT.

Il mio punto di vista è guardare aziende come JD.com, Amazon o Rakuten. Quante persone hanno bisogno queste aziende per svolgere compiti simili? Di solito, si finisce con rapporti folli. Ad esempio, Zalando, una grande azienda di e-commerce europea con sede a Berlino, Germania, ha costruito il proprio ERP con un team più piccolo rispetto alla maggior parte dei team che ho visto per aziende di dimensioni simili che devono migrare il loro ERP. Quindi vedi, da un lato, hai un’azienda come Zalando, in grado di sviluppare il proprio ERP, completamente personalizzato alle loro esigenze. Fa un ottimo lavoro come ERP adatto a loro, e il costo e il numero di persone coinvolte sono solo una frazione di ciò che altre aziende di dimensioni simili hanno bisogno di fare semplicemente un aggiornamento di versione. Il costo è di nuovo solo una frazione. Metto in discussione se sia necessario coinvolgere così tante persone, ed è questo il problema del lavoro di colletto bianco nel XXI secolo. Per essere un dipendente molto bravo, significa che devi avere il coraggio di automatizzarti, di renderti obsoleto.

Questa è una cosa molto particolare. Quando i lavoratori di colletto blu venivano resi obsoleti, era fatto da altri. Ma al giorno d’oggi, quasi non ci sono più lavoratori di colletto blu. Richiede una mentalità diversa, ed è per questo che c’è una lotta per adattarsi a questo nuovo paradigma, principalmente proveniente dall’industria del software. Va bene renderti obsoleto perché in realtà non ti stai rendendo obsoleto; non c’è limite all’ingegno umano. Stai solo automatizzando alcune attività, liberandoti per affrontare la sfida successiva, che è ancora più interessante della precedente. Aziende come Amazon non licenziano i loro ingegneri del software appena risolvono un problema. Li ricompensano e li promuovono per affrontare il problema successivo, più difficile.

In risposta a una domanda sulla mentalità analitica degli operatori della supply chain bloccati nel pensiero post-Seconda Guerra Mondiale, concordo sul fatto che per molte aziende, non tutte, l’ingegneria del software è progredita. Si definisce come un processo umano, o un processo interpretativo. Concordo. L’industria del software non riguarda solo tecnologie dure e centrali. Sebbene alcune posizioni richiedano incredibili competenze tecniche quantitative, la maggior parte dell’industria del software si percepisce come avendo un approccio orientato alle persone, una cultura condivisa.

In larga misura, credo che la dominanza che gli Stati Uniti e Silicon Valley hanno nel software in tutto il mondo sia dovuta alla difficoltà di replicare la loro cultura. La cultura tende ad essere molto intangibile e difficile da documentare. Quando la documenti, domi l’ingrediente caotico necessario per l’innovazione. Se documenti la cultura, la organizzi e la processi, perdi improvvisamente quel aspetto di emergenza caotica di idee e innovazioni.

Ci sono luoghi come Silicon Valley dove questa cultura è diffusa, e sono avanti rispetto al loro tempo in questo senso. Per concludere su questo argomento, vorrei citare William Gibson, che ha detto: “Il futuro è già qui; semplicemente non è distribuito in modo uniforme.” Vedo questa cultura ora essere replicata su scale molto più piccole in molti altri luoghi, e il processo continuerà e crescerà nel tempo.

Questo è tutto per oggi. Ci vediamo la prossima volta. Nella nostra prossima sessione, discuteremo di un argomento che può essere piuttosto deprimente ma è molto importante: la sicurezza informatica. Ci vediamo la prossima volta!