#BIMpill – DevOps e Qualità

Un alto dei principi che amo particolarmente, tra quelli che il framework DevOps mette in campo per ridurre gli sprechi e aumentare la qualità, fa parte della cosiddetta “seconda via”, ovvero il principio del feedback (ne ho parlato presentando il framework nella prima pillola dedicata).

Il principio enuncia il bisogno di spingere la qualità (e il suo controllo) il più possibile vicino alla fonte, ovvero responsabilizzare e rendere responsabili le persone un produzione. Si sposa bene con il principio della non-esistenza del BIM specialist puro, che ho enunciato più volte: in BIM esistono progettisti, ingegneri, specialisti disciplinari, ma la figura del disegnatore non trova corrispettivo. E, forse, non è mai davvero esistita.

All’interno di questo principio, esistono almeno quattro tipi di controlli di qualità inefficaci:

1. Richiedere ad un team diverso da quello di sviluppo di portare a termine attività manuali tediose ed esposte ad alti margini di errore che potrebbero essere facilmente automatizzate e portate a termine dal team che ne ha bisogno: team dedicati alla produzione di componenti, al rilevamento delle interferenze, all’annotazione sono strategie fallimentari tipiche di un’azienda tossica;
2. Richiedere l’approvazione di persone distanti dal lavoro quotidiano, costringendoli a prendere decisioni senza una conoscenza adeguata del lavoro e delle potenziali implicazioni delle loro decisioni, oppure costringendole ad un’approvazione solo meccanica, formale e senza significato;
3. Creare grandi volumi di documentazione dal dettaglio discutibile, che diventano obsoleti pochissimo tempo dopo la loro redazione (un punto talmente rilevante per quanto riguarda il BIM execution plan che mi sembra quasi offensivo esplicitarlo;
4. Consegnare grandi quantità di semilavorati a chi deve approvarli e poi attendere il loro feeback (magari sperando che gli errori si perdano nella grande quantità di informazioni).