La tentazione durante qualsiasi crisi finanziaria importante (o senza precedenti) è di tagliare massicciamente i costi o spendere soldi per farti uscire dal buco particolare in cui ti sei trovato. Studio di Harvard Business Review del 2010 ha scoperto che le aziende che tagliano rapidamente i costi in una recessione hanno molte più probabilità di rimanere indietro rispetto alla concorrenza che ne deriva.

Lo studio ha anche scoperto che le aziende che erano progressiste – alla ricerca dell’efficienza operativa rispetto a un taglio immediato dei costi – hanno avuto un successo significativamente maggiore, con una maggiore crescita dei ricavi e minori licenziamenti rispetto ad altre.

Questo vale per le crisi passate, presenti e future, specialmente se applicate allo sviluppo del software. In un sondaggio condotto dalla mia azienda nel maggio 2020 ai professionisti IT di tutta l’America, oltre il 60% ha riferito di aver visto licenziamenti e il 36% ha riferito una riduzione della spesa.

In modo incoraggiante, abbiamo scoperto che il 34% ha segnalato un passaggio a processi più agili e il 28% ha segnalato l’eliminazione dei processi che si stavano intromettendo – ed è esattamente ciò su cui voglio che ti concentri, sia con i problemi che stai affrontando oggi, e anche quando la tua organizzazione è in crescita.

… ed efficienza per tutti

Quando le cose sono difficili, è facile individuare le cose che stanno andando storte piuttosto che scoprirle perché stanno andando male.

Stai producendo un’app e il team di progettazione è lento a ottenere qualcosa dalla porta, e devono continuare a fare le revisioni, tutto perché la persona che scrive la copia non ottiene loro tutto ciò di cui hanno bisogno quando ne ha bisogno.

Il tuo team di sviluppo deve aspettare che l’IT prepari tutto per lanciare l’app e tutti sono consapevoli di entrambe le scadenze che stanno affrontando e qualsiasi crisi particolare che sta accadendo in quel momento.

È il cliché dello sviluppo in silos: ognuno è bloccato nel proprio mondo, comunica le cose in base a come funziona il proprio team, consegna le cose in un modo che abbia senso per loro.

Questo è un classico esempio di sviluppo in serie, in cui ogni squadra prepara il proprio pezzo quando l’altra squadra dice loro che il pezzo è pronto, portando a un blocco nel momento in cui qualcosa va storto.

Questi non sono necessariamente problemi specifici di DevOps, ma sono il tipo di cose che possono ostacolare la capacità di un’organizzazione di fornire un ottimo software. E se guardi attentamente, sono problemi interamente organizzativi che possono essere risolti in modo relativamente semplice e tuttavia rendono le persone infelici, infastidite e incapaci di spedire effettivamente il prodotto.

Fondamentalmente, sono qualcosa che puoi aggiustare senza spendere soldi.

Abbattere i muri

Una grande organizzazione di software dovrebbe essere in grado di lavorare in parallelo, con ogni parte di un team che spedisce un prodotto in grado di ottenere ciò di cui ha bisogno per essere fatto senza dover aspettare un’altra parte.

Per fare in modo che funzioni, è necessaria una valutazione di come comunicano i tuoi team, se alcune parti della tua organizzazione stanno aiutando o aggravando i problemi, o anche se alcuni strumenti si stanno intromettendo.

Ad esempio, il tuo team di software sta lanciando un sito Web di e-commerce per un marchio di scarpe. Il team di sviluppo web necessita di SKU, foto dei prodotti, prezzi e altre informazioni specifiche ogni volta sviluppano una piattaforma di e-commerce, e quindi queste sono cose che la tua organizzazione avrebbe dovuto richiedere e consegnare con largo anticipo rispetto all’inizio del progetto. In questo modo il team di sviluppo web non viene trattenuto dal cliente.

Allo stesso modo, il team di sviluppo web può stabilire uno standard per il tipo di copia di cui avranno bisogno in anticipo, quindi il copywriter non aspetterà dove posizionare le cose. Il tuo team IT sa che un sito di e-commerce sta per essere costruito e che il lancio avviene in un giorno particolare e ha tutto pronto.

Questi sembrano ovvi, ma avere un flusso di lavoro standardizzato, ben comunicato e stabilito (diciamo, in un wiki interno) per un particolare tipo di progetto significa che ci sono meno errori e pietre miliari chiaramente comunicate da raggiungere.

L’idea di lavorare in parallelo è quella che consente al tuo team di fare tutto il possibile separatamente, mentre tutti lavorano per lo stesso obiettivo e, in definitiva, forniscono prodotti migliori più velocemente.

Questa organizzazione armonica e parallela potrebbe anche richiedere di considerare ciò che funziona effettivamente per un particolare progetto rispetto a ciò che sembra importante. Questo può essere complesso quanto il modo in cui il tuo team IT sta mettendo in produzione il tuo sito, o semplice quanto gli strumenti di comunicazione che stai utilizzando per mantenere un progetto in pista.

Ad essere sinceri, se qualcosa da fare sembra una seccatura, ora è un ottimo momento per chiederti perché lo stai effettivamente facendo, quale vantaggio ti dà e chi lo sta effettivamente usando.

Avere una comunicazione chiara su quali ostacoli esistono in un progetto non è solo un buon affare, è un ottimo modo per costruire il cameratismo tra le diverse parti di un’organizzazione: tutti soffrono insieme e diventano più forti insieme.

Qualcuno potrebbe non capire lo scopo di un particolare strumento (e risentirsi di doverlo usare), oppure tutti potrebbero avere la stessa lamentela senza effettivamente esprimerla.

In definitiva, l’efficienza dello sviluppo deriva dalla comprensione dei punti di forza e dei punti deboli di tutti (e di tutto, nel caso del software) e della costruzione intorno a essi.

Probabilmente hai già i pezzi di cui hai bisogno, ma devi semplicemente dare a tutti i flussi di lavoro e incoraggiare i tipi di comunicazione che portano a termine le cose in modo rapido ed efficiente.