Share The Pain, ovvero come far funzionare un team digitale

In questo articolo tratto un argomento che mi sta molto a cuore che è anche uno di quelli più contro intuitivi, soprattutto nell’ambito del digitale e nella gestione appunto di piattaforme e prodotti digitali.

Un concetto che infatti ripeto spesso è che la tecnologia è tutto sommato facile, se la raffrontiamo al vero problema che è invece quello delle persone.

Inteso come: gestire gli aspetti tecnologici di una piattaforma digitale è il problema minore rispetto a quello di gestire le persone che lo fanno funzionare.

A dispetto di quello che pensano molti non addetti ai lavori, un prodotto digitale non sta in piedi da solo ed è necessario farlo evolvere e correggerlo continuamente.

Ancora non siamo al punto che c’è un’intelligenza artificiale che programma da sola e gestisce le infrastrutture che ospitano il codice, e in realtà non penso che nel giro di pochi anni vedremo mai delle macchine che fanno tutte queste cose da sole perché la tecnologia digitale è fortemente basata su un processo intellettuale e creativo che è ancora lontano da essere modellato in forma di intelligenza artificiale.

Dobbiamo dunque prendere atto una volta per tutte che parlando di digitale, parliamo anche di persone, con tutti i problemi del caso: problemi di comunicazione, problemi personali, interazione tra colleghi, lavoro di gruppo e così via.

Allora, cosa succede? Che nella tua azienda ti ritrovi con tutta una serie di problemi ricorrenti, magari ti fai il mazzo ma hai una serie di problemi che sono sempre presenti e innumerevoli aspetti tecnici da gestire nell’operatività quotidiana che ti portano via tempo ed energie intralciando lo sviluppo dell’azienda.

Ne cito alcuni:

• Nonostante la grande quantità di tempo e denaro che hai speso, il codice dei tuoi prodotti digitali è pieno di errori e i sistemi sono inaffidabili.
• La nuova versione messa online rompe le parti che funzionavano nella versione precedente o ricompaiono gli stessi errori di mesi prima.
• Capitano spesso incidenti in produzione che fanno perdere traffico, ricavi e reputazione. E grazie alla legge di Murphy, spesso gli incidenti capitano quando non c’è più nessuno in ufficio per poterli risolvere o la persona che se ne occupa non c’è.
• Oppure è sufficiente che un tuo programmatore o un sistemista chiave si ammali, che è un’eventualità del tutto prevedibile, a causare gravi danni: se nessuno è in grado di decifrare il suo sistema unico di lavoro, puoi trovarti ad affrontare impreparato l’incubo della tecnologia. Quando succede poi si pensa “ma dove diavolo l’ha messo quello script?”. E intanto non si riesce a risolvere il problema.
• Oppure chi si occupa dello sviluppo e della manutenzione degli aspetti tecnologici e le persone che si occupano del business non si capiscono a vicenda, il risultato è che si spreca molto tempo, si litiga e magari il prodotto finale non è quello desiderato ed è spesso pieno di caratteristiche inutili.
• E così via.

E per quanto il metodo usato per gestire tutti questi aspetti possa essere avanzato, ci sarà sempre la frustrazione del committente nel vedere una certa quota di problemi che permangono.

La soluzione finale è dare tutta la tecnologia in outsourcing, ma questo non toglie il fatto che parliamo di qualcosa che non è perfetto e non potrà mai esserlo, qualche problema ci sarà sempre, sarà importante piuttosto il modo in cui questi problemi vengono affrontati.

Dobbiamo quindi fare i conti con il fatto che ad esempio i bug, cioè le anomalie del software, sono qualcosa che fa parte della natura stessa dello sviluppo del software. Ci saranno sempre.

Adesso che è chiaro almeno un po’ di più il ruolo delle persone nella tecnologia, vediamo alcuni concetti e metodi utili per ridurre una grossa quota di questi problemi ponendo l’attenzione sugli essere umani piuttosto che sui computer, e quindi sul team nel quale queste persone lavorano.

Ci sono in particolare alcuni principi e pratiche di lavoro, alcune delle quali sono stati formalizzati ormai parecchi anni fa in alcune metodologie, cioè metodi da declinare nella propria realtà lavorativa.

Anche qui bisogna rendersi conto, lato business, che per far funzionare un prodotto digitale non è sufficiente mettere assieme qualche programmatore, del quale magari un manager non riesce neanche a capire le competenze.

Non ci sono cioè dei singoli geni dell’informatica che sono in grado di far funzionare tutto in un sistema complesso come una piattaforma digitale, è sempre necessario un team, spesso anche molto ampio.

E’ dunque anche necessario organizzare adeguatamente il lavoro applicando delle specifiche pratiche, che non significa però mettere in fila delle attività in un grafico GANTT, pensando di aver magicamente risolto tutti i problemi di gestione.

La tecnologia nell’informatica non funziona affatto così, non è come costruire un ponte con calcoli precisi, è molto più complesso ed è appunto molto dipendente anche dalle persone.

E non funziona neanche introdurre un intervento spot con un coach o un motivatore, la motivazione non si introduce dall’esterno in quel modo: dura magari un paio di giorni, poi diventa più bassa di prima, così come le tipiche iniziative di miglioramento portate avanti in questi casi durano alcune settimane e sistematicamente vengono smantellate.

Ne ho viste troppo di queste implementazioni fatte con le migliori intenzioni, con grandi costi, fallite miseramente dopo poco tempo.

Di questo ne parlerò meglio in un’altra occasione, per ora è importante sapere che una di queste metodologie con le quali organizzare e svolgere il lavoro in modo decisamente più produttivo si chiama XP, cioè extreme programming, che tra le varie pratiche propone quella chiamata “collective ownership”.

Il nome dell’XP sembra a sua volta piuttosto estremo, ma non è un qualcosa per ribelli del software, così come proprietà collettiva non significa comunismo del codice ma qualcosa di molto serio.

Il contrario di questo concetto, che è poi il modo tradizionale di gestire il codice, è quello di definire una “proprietà” forte: l’applicazione viene divisa in moduli e ogni modulo ha il proprio sviluppatore.

In questo contesto, gli sviluppatori possono modificare solo il codice dei moduli di loro “proprietà”.

Se qualcuno deve apportare una modifica ad un modulo scritto da altri, deve contattare il programmatore assegnato a quel modulo e chiedere a lui di apportarle.

Ci sono anche forme intermedie in cui i moduli possono essere modificati da altri programmatori, ma c’è sempre un responsabile per ciascun modulo.

Nel collective code ownership viene invece del tutto abbandonato il concetto di proprietà individuale. Il punto fondamentale è che il codice è di competenza dell’intero team, e chiunque all’interno del team può modificarlo.

Questo concetto non va confuso con assenza di proprietà, che significherebbe che nessuno è responsabile del codice. E’ vero il contrario: l’intero team ne è responsabile.

Questo funziona molto bene quando sono previsti anche i test (funzionali e unitari), in modo da assicurarsi che modifiche eseguite da un programmatore che conosce poco una certa area del codice non introduca nuovi errori gravi.

In conclusione, si tratta di un’importante pratica che deve essere adottata da ogni team digitale che si rispetti.

Ora, bisogna considerare che queste regole vanno applicate anche più in generale, non solo nel codice.

Ad esempio, poiché gli aspetti tecnici devono essere considerati di proprietà comune dell’intero team, deve valere non solo il concetto che chiunque deve mettere mano al codice per migliorarlo o risolvere problemi, ma anche il concetto che quando ci sono problemi in produzione pochi minuti prima della pausa pranzo, i colleghi che stanno lavorando alla risoluzione dell’incidente non vanno lasciati soli appena scattano le ore 13 nell’orologio.

Tutti devono aiutare, in particolare quelli che in qualche modo possono mettere a disposizione le loro competenze.

Qui va in particolare superata quella separazione tra sistemisti e programmatori tipica di molti team, che invece devono lavorare come un corpo unico.

Da questo punto di vista mi piace estendere l’intero concetto, partendo da una pratica ingegneristica del mondo del software come appunto il collective ownership e arrivando d un argomento più ampio che deve far parte della cultura di un’azienda, anche a livello imprenditoriale.

Lo chiamo “Share the pain”, cioè condividere lo sforzo, condividere la pena, anche tra team separati e anche nel rapporto tra cliente e fornitore, quando l’IT è in outsourcing.

E’ per questo che in termini più tecnici parliamo di collective ownership, cioè chiunque può e deve metter mano assieme ad altri colleghi.

Il punto è che un peso condiviso, è automaticamente un peso più leggero.

Sapere di non dover affrontare da soli un problema scoraggiante fa agire in modo più sicuro e creativo.

L’approccio al lavoro deve rendere facile poter chiedere aiuto, ruotare le responsabilità tra più persone e avere compagnia quando serve uno sforzo di tipo straordinario per ottenere un risultato o risolvere un problema.

Anche cose semplici contano: portare via la spazzatura, rispondere al telefono e così via, chiunque deve aiutare anche con queste attività spesso piccole quanto poco desiderabili.

Poi chiaramente c’è chi è specializzato e magari ha tra i propri compiti quello di svolgere esattamente quelle attività, ma il punto è far capire che deve esserci un atteggiamento per il quale certe cose non vanno semplicemente sbolognate, magari anche in modo gentile ma comunque fuori da questo spirito. Come minimo bisogna supportarsi a vicenda.

A maggior ragione questo vale nel far funzionare un prodotto digitale.

Per capirci meglio, quando qualcosa non va come da programmi o c’è una scadenza molto ravvicinata, e questo avviene praticamente sempre, dovremmo sforzarci tutti assieme, ognuno nel modo in cui può contribuire.

Il lavoro di ciascuno non si limita a completare le proprie attività entro le scadenze, ma include anche supportare in qualche modo i propri compagni.

Quando un progetto sta andando bene, stiamo andando tutti bene. Quando un progetto ha un problema, tutti abbiamo un problema.

Non lasciamo che qualcuno debba sopportare una grossa rogna da solo. Se qualcuno ha bisogno di lavorare fino a tardi su un progetto, aiutiamolo.

In ogni progetto e in ogni azienda il lavoro include il dover svolgere attività frustranti, noiose e altre rotture di scatole che devono semplicemente essere fatte.

Queste vanno considerate da tutti il lavoro di ciascuno.

Significa anche prendere del tempo per fare ciò che non necessariamente è il proprio compito, qualcosa che magari un’altra persona di norma dovrebbe fare ma che non può per qualche motivo.

E questo facendolo senza che per forza ci venga chiesto. Il lavoro viene svolto, anche se non dalla persona assegnata a questo compito, e i clienti non vengono lasciati in attesa.

Condividere lo sforzo consente dunque di essere più produttivi perché elimina la burocrazia e riduce lo stress.

Ed è fondamentale sentirsi supportati dai colleghi, che ti coprono quando c’è qualche difficoltà.

In questo caso lo spirito è come quello di un gruppo di soldati che avanzano coprendosi a vicenda dal fuoco nemico e agiscono assieme per conquistare un obiettivo.

Se non puoi fidarti dei tuoi colleghi e non hai la certezza che ti copriranno o ti aiuteranno quando sei in difficoltà, allora non esiste un team.