Il sito web a cui fa riferimento questo articolo è disponibile esclusivamente in lingua inglese, ma è possibile ottenerne la traduzione automatica tramite le apposite funzionalità del proprio browser web o utlizzando servizi di terze parti come Google Translate

Cosa sono le best practices?

Prima di scendere nel dettaglio delle open practices dobbiamo per prima cosa rispondere alla domanda "Cosa sono le best practices?" relative ad un particolare campo.

Le best practices (tradotte in italiano con buone pratiche o buone prassi) sono le procedure riconosciute come più adatte per una determinata attività o contesto, indipendentemente dal fatto che tale attività o contesto sia riferita all'ambito lavorativo o meno.

All'interno delle aziende possono essere già presenti delle practices, ovvero delle linee guida per lo svolgimento delle attività lavorative quotidiane ma questo non determina automaticamente che siano le best practices; le attuali procedure infatti potrebbero essere state redatte e messe in opera molti anni prima e mai aggiornate per vari motivi, non sempre validi (la resistenza al cambiamento al primo posto).

In altri casi, le procedure potrebbero essere sub-ottimali semplicemente per un motivo: chi le ha redatte pensava – in buonafede – che fossero il miglior modo di portare a compimento una attività, senza informarsi e fare ricerche su ciò che viene messo in atto al di fuori della propria azienda per compiere le stesse attività o attività comunque assimilabili.

Le Open Best Practices

Le Open Best Practices sono una raccolta di procedure sviluppate inizialmente da Red Hat Open Innovation Labs per documentare in maniera libera le interazioni con i propri clienti per poi espandersi e diventare successivamente un sito raccoglitore di procedure per il DevOps (ovvero lo sviluppo e la messa in produzione di software).

Questo progetto, particolarmente apprezzato dalla comunità open source, si è evoluto (anche grazie all'apertura del sito alla comunità stessa) espandendosi negli anni nei suoi contenuti ed arrivando a contenere – al momento della stesura di questo articolo – ad oltre 150 best practices per il ciclo di vita dei prodotti, non essenzialmente software.

All'interno di questo copioso numero di procedure da cui trarre ispirazione o da applicare così come sono, con molta probabilità un'azienda che non rivede le proprie procedure da molti anni potrà trovare ispirazioni per ottimizzare il ciclo di vita dei propri prodotti e servizi o anche semplicemente migliorare la produttività del personale, riducendone contemporanamente il carico di lavoro e quindi lo stress.

Il nastro di Möbius (Möbius loop)

Il nastro di Möbius è una particolare superficie non orientabile che può essere percorsa completamente (per due volte) ritornando al punto di partenza, senza mai incontrare spigoli o bordi; il nastro di Möbius è quindi spesso utilizzato per simboleggiare processi che – dopo un certo percorso – tornano alla condizione di partenza, pronti ad essere applicati nuovamente.

La Open Practice Library è costruita attorno al modello del nastro di Möbius, un modello iterativo di sviluppo dei progetti che ruota attorno alle fasi di Scoperta (Discovery), Opzioni (Options), Consegna (Delivery) e nuovamente Opzioni (Options); il tutto è integrato da una fase iniziale, che si pone alla base del processo iterativo, detta Fondamenta (Foundation), dedicata alla raccolta e analisi preliminare delle informazioni necessarie ad avviare il processo iterativo secondo il modello del nastro di Möbius.

Le operazioni che vengono tipicamente effettuate durante ognua delle fasi possono essere descritte schematicamente nel seguente modo:

• Fondamenta (Foundation): in questa fase viene effettuata una pianificazione logica di come il processo produttivo dovrà svolgersi, utilizzando astrazioni e scegliendo le strategie e le tecnologie da utilizzare
• Scoperta (Discovery): in questa fase del nastro vengono definite le pratiche che permettono di delineare i risultati da ottenere
• Opzioni (Options): questa fase è dedicata alle pratiche che permettono di scoprire e decidere quali sono i migliori strumenti per ottenere il risultato desiderato
• Consegna (Delivery): questa fase è dedicata alla messa in pratica delle idee selezionate nella fase delle Opzioni, comprendendo se la scelta effettuata si è rivelata efficace o meno

Arrivati alla fase di consegna, il nastro si avvolge su se stesso, tornando nella fase delle opzioni in cui verranno decise le strategie per iniziare il secondo giro del nastro, ovvero su come iniziare una nuova fase di scoperta per il successivo obiettivo del progetto.

Le practices presenti all'interno della libreria possono appartenere ad uno solo di questi passi (poiché dedicati a specifici compiti assegnabili ad una particolare fase del nastro) ed unite insieme possono coprire tutte quante le fasi, descrivendo quindi un intero processo produttivo, dall'inizio (analisi e progettazione) alla fine (consegna e preparazione alla nuova iterazione del ciclo per aggiornamenti o nuove funzionalità/prodotti).

Tutte le pratiche elencate nella Open Practice Library hanno un nome specifico, in modo da essere ben identificabili e permettono di assolvere – in maniera ordinata ed efficiente – uno specifico compito, dall'analisi del problema fino alla fase di distribuzione di prodotti e servizi; tutte queste procedure sono state integrate a partire da proposte della comunità, che utilizza tali metodologie lavorative per adempiere alle proprie attività aziendali quotidiane.

Implementare una o più di queste best practices all'interno del proprio flusso di lavoro permetterà di rendere più efficiente il proprio processo produttivo seguendo degli standard riconosciuti come ottimali dalla comunità.

Alcuni esempi

Per comprendere meglio le potenzialità di poter attingere ad una intera libreria di best practices che possono portare ad un miglioramente della produttività aziendale possiamo ricorrere ad alcuni esempi tratti da situazioni realmente incontrate durante gli anni di consulenza effettuata dai professionisti di Studio56 alle aziende.

Un primo esempio può essere relativo alla fase di fondamenta e pianificazione (Foundation): quando il processo produttivo di beni o servizi prevede l'interazione di più team (o di più addetti singoli, nei casi di aziende più piccole) non è raro che si generino problemi di comunicazione o interpretazione che portano ad utilizzare versioni non ancora pronte o definitive di un componente, con un conseguente spreco di tempo e risorse o – peggio ancora – con la consegna di un prodotto con difettoso o incompleto.

In questo caso, seguire una pratica come quella del Definition of Done (Definizione di Completato) potrà permette ai team di formalizzare le condizioni secondo le quali un componente (fisico, servizio o software) si considera pronto all'uso da parte di tutti i soggetti che devono utilizzarlo; tutto il tempo impiegato nel formalizzare lo stato di pronto all'uso sarà recuperato sotto forma di migliore efficienza e riduzione o azzeramento di consegna di componenti incompleti o difettosi.

Come esempio attinente alla fase di scoperta (Discovery) può essere portato quello relativo ad aziende di medie o grandi dimensioni, dove un addetto o un team non è immediatamente al corrente di chi siano i produttori ed i consumatori dei propri prodotti/servizi: ad esempio, per il progetto attualmente in corso d'opera, il "team A" potrebbe non sapere immediatamente che il consumatore della propria fase lavorativa del prodotto è il "team C", rischiando così di introdurre dei ritardi o di effettuare comunicazioni errate ad un team che non ha necessità di usare tale prodotto (es: il "team B"); questo problema si accentua se la produzione del "team A" serve come base per ulteriori lavorazioni di più team successivi distinti.

In questo caso adottare una pratica come quella del Service Blueprint permetterà di identificare univocamente le fasi lavorative del progetto, gli step che porteranno al rilascio del prodotto/servizio nella sua veste definitiva e gli attori in gioco, ovvero le persone che si occuperanno della creazione del prodotto nella sua interezza e di come dovranno interagire tra loro.

Per la fase di opzioni (Options), necessaria alla scelta dei metodi operativi per la realizzazione dei prodotti, può accadere che a fronte delle necessità operative del prodotto ci siano molte componenti da realizzare ma che il personale addetto all'organizzazione ed orchestrazione delle integrazioni non abbia una visione precisa della complessità, essenzialità e rapidità di realizzazione di ognuna di esse.

In questo caso adottare un approccio tramite una matrice di priorità impatto/sforzo realizzata insieme al reparto di produzione può far individuare rapidamente quali sono le migliori idee o funzionalità da sviluppare immediatamente e quali quelle da posizionare in fondo alla coda di lavorazione in quanto accessorie ed il cui sviluppo nelle fasi iniziali del progetto rallenterebbe tutto il processo realizzativo.

Infine, per quanto riguarda la fase di consegna (Delivery), uno dei principali problemi che si possono individuare in assenza di organizzazione e di utilizzo delle best practices è quello in cui il personale coinvolto nello sviluppo di un prodotto o un servizio non è al corrente dello stato attuale in cui si trovano le componenti che non sono sotto il suo diretto controllo. Questo introduce inefficienze, rallentamenti e la necessità di dover richiedere con frequenza agli altri attori (personale singolo o interi team) a quale punto dello sviluppo si trovano le rispettive componenti.

Per ovviare a questo problema, un approccio ultimamente molto utilizzato è quello dell'organizzazione attraverso il framework Kanban, che mette a disposizione di tutti gli attori coinvolti nel flusso lavorativo una lavagna (kanban board), che rappresenta le varie fasi del flusso lavorativo, nella quale vengono apposte delle schede (card) che rappresentano singoli aspetti o componenti del progetto da sviluppare; man mano che tali componenti progrediscono all'interno del flusso lavorativo, la loro scheda verrà spostata nell'appropriata colonna (rappresentante uno degli step del flusso di lavoro), con il vantaggio di avere sempre disponibile lo stato della lavorazione, prevenire le inefficienze e prevedere rapidamente i prossimi step da eseguire per ogni componente.

In questo caso non è necessario che la lavagna sia una reale lavagna, ma può essere sfruttato un apposito software che implementi il framework Kanban tra i tanti disponibili, tra cui il più noto è Trello.

Conclusioni

Come indicato all'inizio dell'articolo, la Open Practice Library contiene attualmente oltre 150 best practices largamente accettate dalla comunità ma non è detto né che ognuna di esse sia applicabile nella propria realtà aziendale.

Ognuna delle best practices presenti infatti ha casi in cui può essere applicata con successo ed altri in cui – a causa della composizione dell'azienda o dei prodotti/servizi realizzati – non può essere applicata (sia totalmente, sia perché potrebbe peggiorare invece che migliorare il flusso di lavoro): l'obiettivo principale è quindi quello di consultare la libreria per scoprire quali sono le migliori pratiche attualmente in uso per affrontare i comuni problemi presenti nel ciclo di sviluppo di prodotti e servizi e trovare la propria soluzione ottimale per migliorare l'organizzazione delle proprie attività, incrementando la produttività e riducendo lo stress generato da una organizzazione approssimativa del flusso di lavoro tramite l'applicazione delle best practices più appropriate.