Ho imparato di recente il concetto di "weight in motion".

 

Si tratta di una tecnica impiegata in logistica per verificare il contenuto di una scatola che dovrà essere spedita. Avendo buoni dati sugli imballi e sul peso dei singoli articoli, mentre questi si muovono su rulliere apposite, vengono pesati in movimento. Se il peso reale rispetta una tolleranza rispetto quello calcolato il pacco va avanti, altrimenti viene immesso in una corsia di verifica.

 

Cosa possiamo portare di tutto questo nel mondo IT?

 

Le scatole si muovono su rulliere invece che trasportate su mezzi guidati da persone (automazione, rimozione componente variabile umana, ...) -> Deployment automatizzati: non trasportiamo a mano i nostri artefatti negli ambienti ma investiamo in automazione (pipeline).

Riduzione degli sprechi: faccio due cose in uno. Mentre sposto, peso. Test Driven Development (o simili): mentre sviluppo scrivo i test.

 

Creazione di feedback più a sinistra possibile. Creo un feedback dove prima non esisteva: già durante la fase di trasporto del pacco invece che a destinazione in zona di spedizione. Continuous Integration: build + test. Eseguo i test prima di validare definitivamente il mio artefatto di build e pubblicarlo.

 

I pacchi scartati mi fanno chiedere il perché sia successo: dati errati? Aggiornamento dati. Processo di prelievo che fa fare errore agli operatori? Miglioro il processo (e non incolpo l'operatore di aver sbagliato!)

 

Si spaccano i test durante una build? Posso intervenire su quelle poche righe di codice responsabili e domandarmi come mai me ne sia accorto "tardi" invece che durante lo sviluppo. Posso migliorare gli strumenti del developer o i processi di sviluppo.

Il mondo manufatturiero e quello di produzione del software possono imparare l'uno dall'altro più di quanto possiamo immaginare.

 

E tu, che affinità trovi?

 

- Michele