Arda Solutions s.r.l. | The Informal Blog

Qui in Arda Solutions ci siamo appassionati da tempo alla cultura del DevOps. Grazie alla formazione e approfondimento costante siamo riusciti (insieme a qualche nostro cliente molto intraprendente!) a (cercare) la tendenza all’integrazione fra Sviluppatori (fonte infinita dei mal di pancia degli Operatori IT) e gli operatori IT (fonte infinita dei mal di pancia degli Sviluppatori)

Molti propongono questo o quel prodotto per le migliori capacità di integrazione, piuttosto che la curva di apprendimento oppure le feature in continua evoluzione. Ci sono molti prodotti interessanti (altri molto di più, ma li lascio ad un prossimo articolo) ma tutti partono dallo stesso presupposto:

Una volta definiti i workflow che governano l'interazione fra Devs, Operatori IT e mantenendo alti i livelli di quality sui rilasci che impattano sul prodotto, questa o quella tecnologia vi aiuterà e in 5 minuti (cinque), potrete automatizzare tutto

Bellissimo, fantastico! Peccato che questa frase (volutamente esplicitata fino all’eccesso) nasconda un presupposto di base: definire ciò che governa l’interazione. Molto più semplice a dirsi che a farsi, questa frase presuppone in realtà soltanto la cultura necessaria per approcciarsi ad un nuovo modo di collaborare che, può sembrare difficile all’inizio, ma che in realtà (e lo abbiamo visto) aiuterà molto nell’immediato risolvendo tantissimi problemi apparentemente irrisolvibili.

I primi studi con i suddetti clienti si infrangevano infatti, non tanto sull’adozione della tecnologia (come può succedere con un nuovo ERP) e nemmeno sulla definizione dei workflow (che, nella maggior parte dei casi sono un merge di workflow già esistenti), il problema fondamentale era riuscire a proporre una visione che andasse aldilà della divisione dei ruoli per conservare le responsabilità in favore di un approccio più condiviso che mantenesse le figure inalterate ma che “obbligasse” a una comunicazione più serrata

La “tempesta” del titolo è riferita soprattutto all’approccio che abbiamo utilizzato inizialmente con i clienti che si erano resi disponibili ad attivare un progetto pilota: con l’anima nerd che ci contraddistingue abbiamo pensato che il software migliore avrebbe poi reso il servizio migliore. Ma nella realtà non è stato cosi perché avevamo tralasciato l’aspetto più importante: definire puntigliosamente e ripetutamente il “nuovo” approccio esplicitando con forza che non sarebbe stata una rivoluzione ma solo una cambio di prospettiva.

Modificato il tiro (e le slide) e focalizzando i punti su questo cambio di prospettiva siamo finalmente riusciti ad andare verso i punti successivi: costi di transizione (veramente minimi se si hanno già workflow ben definiti), costi del software (come sopra), costi di formazione (più di quelli che ci si aspetta, soprattutto in virtù di quanto spiegato in questo articoli) e ora l’implementazione è finalmente alle porte.

D’altronde, anche una tempesta può essere percepita come un disastro se si adotta sempre lo stesso punto di vista, spostarsi può aiutare a capirne anche i benefici … Comunque state tranquilli che no, non pubblicheremo nessun articolo spiegando i benefici di una tempesta! 🙂

Annunci
%d blogger hanno fatto clic su Mi Piace per questo: