Il tuo sistema funziona benissimo. Finché lavora la persona che sa il perché.
Immagina un’azienda che ha un sistema in funzione da sette anni. È stato costruito per fasi. Prima lo ha realizzato una software house. Poi una parte è stata presa in carico da un freelancer. In seguito un altro team ha aggiunto un modulo B2B. Un’altra agenzia ha collegato il CRM. Qualcun altro ha integrato i pagamenti.
Il sistema funziona.
L’azienda ci guadagna soldi.
I dipendenti lo usano ogni giorno.
I clienti nemmeno immaginano quanti processi avvengano in background.
C’è solo un problema.
Nessuno sa più esattamente come funzioni tutto questo.
La documentazione è in parte su Confluence. Qualcosa è rimasto su Google Drive. Alcune informazioni si trovano nei ticket. Un’integrazione è stata descritta in una mail di quattro anni fa.
E la cosa più importante "forse la ricordava Łukasz".
Solo che Łukasz se n’è andato tre anni fa.
E per tre anni non è successo nulla.
Fino a un certo martedì mattina.
Il sistema funziona. Quindi va tutto bene?
È uno degli stati più ingannevoli in cui possa trovarsi un sistema aziendale.
Funziona.
Non ci sono guasti.
Gli utenti sono soddisfatti.
L’area commerciale usa l’applicazione.
Gli ordini passano.
I dati arrivano nel CRM.
I report vengono generati.
Quindi la reazione naturale è: Non tocchiamo nulla. Perché mettere mano a qualcosa che funziona?
E in effetti non c’è motivo di cambiare un sistema che funziona solo perché si può.
Il problema è che un sistema può essere stabile dal punto di vista tecnico e allo stesso tempo molto instabile dal punto di vista organizzativo.
Può funzionare oggi, ma nessuno sa cosa succederà quando sarà necessario cambiare server, fornitore API, dominio, libreria, metodo di autenticazione o una parte del processo aziendale.
Può essere efficiente, ma dipendente da una sola persona.
Può essere sicuro, ma nessuno sa dove si trovino tutte le chiavi di accesso.
Può essere sviluppato, ma solo da chi conosce la storia di tutte le decisioni.
Ed è proprio qui che entra in gioco il concetto di bus factor.
Quante persone possono sparire prima che il progetto inizi ad avere problemi?
Il bus factor è un concetto molto semplice, anche se brutale.
Ci chiediamo: quante persone devono diventare indisponibili prima che il progetto non possa più essere mantenuto in modo efficiente?
Se la risposta è: "Una", abbiamo un problema.
Se la risposta è: "Due, ma entrambe lavorano in un’altra azienda", abbiamo un problema ancora più grande.
Ovviamente non si tratta di una "scomparsa" letterale delle persone.
Un programmatore può lasciare l’azienda.
Un freelancer può terminare la collaborazione.
Una software house può smettere di assistere il cliente.
Un amministratore può cambiare lavoro.
La persona responsabile di una specifica integrazione può passare a un altro reparto.
Il detentore della conoscenza può semplicemente ammalarsi o essere indisponibile per alcune settimane.
Se con lui scompare la possibilità di comprendere il sistema, l’azienda non ha un problema di personale.
Ha un problema di business.
Il codice non sempre dice perché qualcosa funziona
Si potrebbe dire: "Ma abbiamo il codice sorgente. In caso di bisogno, un nuovo programmatore lo leggerà."
In teoria sì.
In pratica il codice risponde soprattutto alla domanda: come il sistema fa qualcosa.
Non sempre risponde alla domanda: perché lo fa proprio in questo modo.
E questa è una differenza enorme.
Nel codice può esserci una condizione: "Se il cliente ha un certo tipo di account, esegui l’operazione X."
Un nuovo developer può trovarla.
Ma da dove dovrebbe sapere il perché?
Potrebbe essere un requisito di business.
Potrebbe essere un residuo di una vecchia integrazione.
Potrebbe essere una protezione contro un errore di un’API esterna.
Potrebbe essere una soluzione a un problema che si presentava cinque anni fa.
Potrebbe essere la risposta a un caso particolare di uno dei clienti più grandi.
Potrebbe esserci per un ottimo motivo.
Oppure per nessuno.
Senza contesto è difficile valutarlo.
Per questo la documentazione di sistema non dovrebbe limitarsi alle istruzioni:
"clicca qui, poi qui".
La documentazione più preziosa spesso descrive decisioni e dipendenze, non solo il funzionamento delle funzionalità.
La conoscenza più pericolosa è quella che esiste solo nella testa di qualcuno
Le aziende hanno molto spesso della documentazione. Solo che la documentazione non è sempre la stessa cosa della conoscenza.
Possiamo avere una descrizione dell’API - ma non sapere perché usiamo proprio quell’API.
Possiamo avere una procedura di deploy - ma non un elenco di tutti i punti in cui bisogna modificare la configurazione.
Possiamo avere una descrizione dell’integrazione - ma non sapere cosa succederà se il fornitore esterno cambia il metodo di autorizzazione.
Possiamo avere un elenco di server - ma non sapere quale sia critico per uno specifico processo.
Possiamo avere accesso al repository - ma non all’account su cui si trova l’infrastruttura di produzione.
Sono proprio questi gli elementi che possono trasformare una modifica apparentemente semplice in un’indagine di più giorni.
Un’integrazione che funziona da cinque anni resta comunque una dipendenza
Uno degli ambiti più spesso ignorati sono i servizi esterni;
- Pagamenti.
- SMS.
- E-mail.
- CRM.
- ERP.
- Mappe.
- Sistemi di corriere.
- Piattaforme di marketing.
- Sistemi contabili.
- Servizi cloud.
- API esterne.
- Librerie open source.
Ogni cosa del genere è parte di un ecosistema più ampio.
Se il sistema utilizza dieci servizi esterni, non abbiamo un solo sistema. Abbiamo un sistema più dieci dipendenze. E ciascuna di esse può cambiare.
Il fornitore può cambiare API.
Può interrompere il servizio.
Può cambiare il modello di prezzo.
Può dismettere la vecchia versione.
Può introdurre nuovi requisiti di sicurezza.
Può essere acquisito da un’altra azienda.
Per questo sta assumendo un ruolo sempre più importante anche la conoscenza della provenienza dei componenti e delle dipendenze software. Il NIST indica tra le altre cose l’importanza dell’SBOM, cioè il Software Bill of Materials - un elenco formale dei componenti usati per costruire il software. Un inventario di questo tipo aiuta a capire da cosa è composto il sistema e a valutare più rapidamente l’impatto delle vulnerabilità o dei cambiamenti nella catena di fornitura.
Per il business, tutto questo si può riassumere in una domanda molto semplice:
Sai da cosa dipende il tuo sistema?
E ora immagina un cambio di software house
È uno dei momenti in cui tutte le lacune emergono alla luce del sole.
L’azienda ha collaborato per anni con un unico fornitore. All’improvviso la collaborazione finisce. Le ragioni possono essere molte; cambio di strategia. cambio di budget. acquisizione dell’agenzia. problemi organizzativi. mancanza di competenze per un ulteriore sviluppo. Oppure semplicemente l’azienda vuole lavorare con un altro partner.
La nuova software house chiede:
"Dov’è il repository?" - C’è.
"Dov’è l’infrastruttura?" - C’è.
"Come distribuiamo in produzione?" - "Non lo sappiamo, lo faceva il team precedente."
"Come funziona l’integrazione con l’ERP?" - "Forse tramite quel server."
"Quali chiavi API abbiamo?" - "Dovrebbero essere in una mail."
"Quali API sono di produzione?" - "Non lo sappiamo."
"Quali processi sono critici?" - "Bisogna chiedere a Łukasz."
Łukasz non lavora più lì...
Ed è proprio per questo che il trasferimento di un progetto non è solo il trasferimento del codice. Bisogna trasferire anche la conoscenza.
La documentazione non è un costo. È una polizza
In molte aziende la documentazione viene trattata come qualcosa che si fa "quando c’è tempo".
Cioè di solito mai.
Oppure alla fine del progetto.
Oppure quando qualcuno lo chiede.
È un errore.
La documentazione è uno dei meccanismi che limitano il rischio operativo. Non genera direttamente vendite. Non migliora la conversione. Non fa bella figura in una presentazione.
Ma in una situazione di crisi può fare la differenza tra: "lo sistemiamo oggi"
e: "prima dobbiamo trovare la persona che ricorda come funzionava".
Nelle nuove linee guida NIST relative ai piani di sicurezza, privacy e gestione del rischio della supply chain del software, documentare lo scopo del sistema, il suo stato, i controlli e la responsabilità e il comportamento delle persone che lo gestiscono è trattato come elemento di una gestione ordinata del sistema.
Questo mostra molto bene il cambiamento di mentalità.
La documentazione non è solo uno strumento per lo sviluppatore.
È un elemento della continuità operativa dell’organizzazione.
Che cosa dovrebbe essere documentato?
Non si tratta di creare una documentazione di 800 pagine che nessuno aprirà mai.
Una buona documentazione dovrebbe rispondere soprattutto alle domande che sorgono quando qualcosa cambia o smette di funzionare.
- Chi è il proprietario del sistema?
- Dove si trova il codice?
- Dove si trova la produzione?
- Come funziona il processo di rilascio?
- Quali sono gli ambienti?
- Quali sono le integrazioni critiche?
- Quali servizi esterni utilizziamo?
- Chi è il loro fornitore?
- Quali contratti e account abbiamo?
- Dove si trovano le chiavi e i dati di accesso?
- Chi ha i permessi?
- Come funziona il backup?
- Come funziona il ripristino del sistema?
- Quali componenti open source vengono utilizzati?
- Quali librerie sono obsolete?
- Quali sono le decisioni architetturali più importanti?
- Quali elementi sono critici per il business?
- Cosa succede se un determinato servizio esterno smette di funzionare?
Non è una documentazione "per i programmatori".
È una mappa delle dipendenze del business dalla tecnologia.
"Funziona, quindi non tocchiamo nulla" può essere una strategia. Ma bisogna conoscerne il costo
Non tutte le aziende hanno bisogno di ricostruire un vecchio sistema.
Non tutti i sistemi legacy sono cattivi.
Non tutto il vecchio codice va riscritto.
Anzi - a volte un sistema stabile e datato è una soluzione molto migliore di una migrazione costosa eseguita senza una ragione concreta.
Il problema non è l’età del sistema.
Il problema è la mancanza di conoscenza del suo stato.
Se sappiamo come funziona il sistema, quali dipendenze ha, dove si trovano i rischi e chi è in grado di mantenerlo, possiamo decidere consapevolmente:
- lo lasciamo,
- lo modernizziamo,
- riscriviamo una parte,
- lo migramo,
- oppure non tocchiamo nulla.
Se non lo sappiamo, la decisione "non tocchiamo nulla" non è una strategia.
È una scommessa.
Come si presenta un audit di un sistema ereditato?
Quando un sistema esistente arriva in una software house, il primo passo non dovrebbe essere: "Riscriviamolo." - Prima bisogna capirlo.
Un buon audit dovrebbe coprire tra l’altro l’architettura dell’applicazione, il codice sorgente, il database, l’infrastruttura, il processo di rilascio, le dipendenze, le integrazioni, la sicurezza, l’accesso ai servizi e la documentazione.
Ma è altrettanto importante comprendere il business;
- Quali processi sono critici?
- Quali funzioni vengono usate ogni giorno?
- Quali moduli generano ricavi?
- Quali elementi possono essere disattivati senza conseguenze?
- Cosa succede quando una determinata integrazione smette di funzionare?
- Quali elementi sono i più rischiosi?
Solo dopo aver unito la prospettiva tecnica e quella di business si può dire, che cosa richiede davvero un cambiamento.
L’audit non deve per forza finire in una rivoluzione
A volte il risultato dell’audit è sorprendentemente semplice.
Il sistema è a posto, bisogna solo:
- Completare la documentazione.
- Mettere ordine negli accessi.
- Aggiornare alcune librerie.
- Trasferire la proprietà degli account.
- Descrivere il processo di rilascio.
- Aggiungere il monitoraggio.
- Definire il backup.
- Introdurre una seconda persona nelle aree che conosceva solo uno sviluppatore.
E all’improvviso il bus factor passa da 1 a 3.
Non è necessario riscrivere l’intera applicazione.
Non bisogna buttare via sette anni di lavoro.
Non bisogna costruire tutto da zero.
A volte il problema più grande non è la tecnologia.
È la mancanza di una mappa.
Il sistema dovrebbe sopravvivere alle persone che lo hanno creato
Questa è probabilmente la regola più importante: un buon sistema dovrebbe essere in grado di sopravvivere alla partenza dello sviluppatore.
Dovrebbe sopravvivere al cambio dell’amministratore.
Dovrebbe sopravvivere al cambio di software house.
Dovrebbe sopravvivere alla riorganizzazione dell’azienda.
Dovrebbe sopravvivere a diversi anni di sviluppo.
Questo non significa che ogni programmatore debba capire ogni riga di codice. Significa che la conoscenza critica per il funzionamento del business non può esistere solo nella testa di una persona.
Perché un dipendente può andarsene.
Un freelancer può terminare la collaborazione.
Un’agenzia può sparire.
Un fornitore può cambiare servizio.
E l’azienda deve comunque continuare a funzionare.
La tecnologia dovrebbe essere di proprietà dell’organizzazione, non della memoria di una singola persona
Questo è particolarmente importante nel caso di sistemi costruiti nel corso di molti anni.
Se l’azienda paga per il software, dovrebbe sapere non solo dove si trova il codice.
Dovrebbe sapere:
- cosa possiede,
- da cosa dipende,
- chi ha accesso,
- chi può modificarlo,
- come può essere messo in produzione,
- come può essere ripristinato,
- come può essere trasferito a un altro team.
NIST nei materiali attuali sul due diligence dei fornitori richiama l'attenzione, tra l'altro, sull'origine, la resilienza, le pratiche di cybersecurity e le dipendenze nella catena di fornitura. Questo mostra una direzione più ampia: le organizzazioni dovrebbero sempre più sapere non solo chi ha fornito il sistema, ma anche di cosa è composto il sistema e quali rischi sono associati alla sua manutenzione.
Non è più solo un tema per il reparto IT.
È un tema di gestione del rischio aziendale.
Il momento peggiore per conoscere il proprio sistema è il guasto
Si possono dedicare alcuni giorni a un audit.
Si può mettere ordine nella documentazione.
Si possono verificare le dipendenze.
Si può descrivere l'architettura.
Si possono verificare gli accessi.
Si può stabilire chi è davvero responsabile delle singole aree.
Si può ridurre il bus factor.
Oppure si può aspettare.
Fino al momento in cui il sistema smetterà di funzionare.
Allora le domande saranno esattamente le stesse.
Solo che la pressione sarà maggiore, gli utenti aspetteranno, le vendite potrebbero fermarsi e ogni ora costerà denaro.
Per questo vale la pena porsi una domanda, prima che si presenti un problema: Se domani sparisse la persona che conosce meglio il tuo sistema, sapremmo ancora come mantenerlo?
Se la risposta è "no", non significa ancora che il sistema sia sbagliato.
Significa che l'azienda ha un rischio nascosto che finora non ha mai dovuto attivare.
In Web24 prendiamo in carico non solo il codice
La presa in carico di un progetto esistente è un lavoro completamente diverso dall'avviare un nuovo sistema da zero.
Per prima cosa bisogna capire cosa esiste già.
Cosa funziona.
Cosa è critico.
Cosa è una dipendenza.
Cosa è un problema.
Cosa è solo il residuo di decisioni precedenti.
E soprattutto - dove si trova la conoscenza senza la quale il sistema non può essere sviluppato in modo sicuro.
Solo allora si possono pianificare le azioni successive.
A volte sarà una modernizzazione.
A volte crescita.
A volte riordino dell'infrastruttura.
A volte presa in carico della manutenzione.
E a volte semplicemente la creazione di una buona mappa del sistema, che per anni nessuno ha avuto il tempo di preparare.
Perché un software house responsabile non dovrebbe costruire una tecnologia che funziona solo quando al computer c'è la persona giusta.
Il sistema dovrebbe essere più grande della memoria di una sola persona.
E il business dovrebbe avere la certezza che, quando qualcuno se ne va, la tecnologia non se ne vada insieme a lui.
