Stop meeting, start coding

Dalle riunioni infruttuose alla generazione di valore con il codicedi e e

Una provocazione?

“Stop Meeting, Start Coding”, la frase sulla cui base abbiamo realizzato anche un adesivo, non è tanto una provocazione, quanto una “licenza poetica” che si ispira al principio Agile “Stop Starting, Start Finishing”: smettiamo di iniziare cose nuove e finiamo quelle che abbiamo lasciato aperte.

Figura 1 – L’adesivo che ben riassume il concetto esposto in questo articolo.

Figura 1 – L’adesivo che ben riassume il concetto esposto in questo articolo.

Il rito della riunione

Oggi le persone si sono abituate a passare da una riunione all’altra in modo schizofrenico: dalle tre alle quattro, dalle quattro alle cinque, e così via. Così si rischia di non chiudere mai niente e anzi continuare ad aprire nuovi fronti.

Perché si è arrivati al punto di dire “basta riunioni”? E cosa si intende per “start coding”? Nell’agilità la conversazione è un punto centrale; dire “stop meeting” sembrerebbe quasi un controsenso o un incentivo all’isolamento dagli altri. Quello che proveremo a capire qui, infatti, non è come cancellare tutte le riunioni, ma come evitare quelle poco efficaci per liberare più tempo al nostro vero lavoro: la costruzione di valore.

Perché fare tante riunioni genera insoddisfazione?

Siamo sicuri che qualche risposta all’interrogativo presente nel titolo di questo paragrafo emergerà leggendo i punti seguenti:

  • passare da una riunione all’altra su temi sempre diversi non dà tempo di razionalizzare quello che si porta a casa, metterlo a terra e fare un passaggio verso lo step successivo;
  • non ci si riesce a concentrare sul codice, e quindi sul contenuto e sul servizio che si dovrebbe implementare;
  • a fine giornata ci si sente inconcludenti perché non si è chiuso quello che si voleva chiudere, mentre quando si chiude tutto, anche con fatica, si è molto soddisfatti;
  • si accumula ritardo;
  • si iniziano a tagliare funzionalità e a creare debito tecnico, che alla fine del progetto contribuisce a creare entropia;
  • si iniziano ad avere interruzioni non prevedibili, riunioni non pianificate, e si iniziano a scoprire i problemi che ci sono in produzione: è un fuoco che si autoalimenta.

 

Quale valore creiamo con il nostro lavoro?

In linea di massima ognuno di noi, nel proprio lavoro, crea servizi volti a soddisfare le necessità degli utenti. È necessario che questi servizi abbiano un costo accettabile, che siano realizzati nel tempo che serve e che siano facili da manutenere.

Negli ultimi anni, con il fiorire di nuovi mercati e nuove tecnologie, abbiamo assistito alla chiusura di quei business che, nonostante generassero valore, avevano un costo di manutenzione troppo alto: se il costo di manutenzione supera il valore generato, allora il business non riesce a resistere.

Se prendiamo il caso di un’azienda IT, nello specifico, qual è l’attività che genera più valore? È la scrittura del codice. Con questo non intendiamo solo la scrittura del codice sorgente, ma di tutto quello che contribuisce affinché il servizio resti in piedi, sia funzionante e affidabile e crei valore per l’utente finale. Si intende quindi l’interfaccia, gli script, le configurazioni, le pipeline di automazione, eccetera.

Tutto il resto è un potenziale spreco. È essenziale quindi massimizzare il tempo dedicato alla scrittura del codice, riducendo al minimo le altre attività.

 

Il progetto perfetto?

“Io sono il team, io sono cliente, io pago”: ecco il progetto perfetto dal punto di vista della riduzione degli sprechi e dell’ottimizzazione del tempo. Questo però ovviamente non è possibile. Non solo: la condivisione del lavoro è un aspetto positivo e spesso crea grandi benefici proprio al lavoro stesso.

Il progetto perfetto ha una comunicazione semplice, risolve necessità chiare e, quando si arriva al risultato, questo è evidente a tutti: gli utenti stanno usando il prodotto con piacere e questo genera profitto.

Il contesto in cui lavoriamo normalmente, però, è più complesso del quadro appena esposto e si presenta ricco di interazioni. Vediamone le principali di seguito.

Molti stakeholder

Ci sono tanti canali di comunicazione e tante idee: persone che hanno interesse che il servizio venga realizzato, aziende che realizzano con noi il servizio digitale, e così via.

Molti utenti finali

Non c’è un’unica necessità assolutamente chiara ed evidente da soddisfare, ma ci sono diverse sfumature. Non esiste la persona ideale da indicare come “il mio utente”: abbiamo varie personas con differenti abitudini e sfaccettature.

Obiettivi contrastanti

Anche internamente all’azienda possono esserci obiettivi diversi. Se, ad esempio, esiste un bonus su tempistiche e velocità di sviluppo, verrà meno il focus sugli interessi degli utenti e su come loro stiano utilizzando il nostro prodotto. Inoltre, quando parte un progetto, non è detto che l’operatività abbia sempre ben chiaro quale sia l’obiettivo finale.

 

Da questi contesti derivano incomprensioni, bisogno di confronto e vengono quindi giustamente pianificate riunioni. Quando però sentiamo uno sviluppatore dire che passa più tempo in riunione che a scrivere codice… be’, questo è un grande campanello d’allarme!

 

Evitare che le riunioni generino insoddisfazione

E allora cosa si può fare affinché le riunioni non generino quel senso di incompiutezza e insoddisfazione? La risposta è la più semplice: “scrivere buon codice”, e cioè fare bene quello per cui siamo stati assunti. Il cambiamento parte da noi: fare bene questo lavoro porterà effetti positivi su tutto il resto, a partire dalle riunioni.

Un buon codice è:

  • semplice da gestire;
  • semplice da comprendere;
  • semplice da far evolvere.

Perché non lo facciamo sempre così? Non lo facciamo perché siamo costantemente sotto pressione, abbiamo tempi più stretti di quanto preventivato e avere metodo e disciplina è oggettivamente faticoso e non sempre abbiamo voglia di applicare tanto impegno.

Inoltre non si ha sempre la fortuna di far partire un progetto da zero: quasi sempre il nostro lavoro si innesta su qualcosa che è già iniziato. Diventa così necessario creare nuove pratiche anche se questo può sembrare ancora più faticoso.

Il codice è di tutti

Se non lavoriamo da soli, dobbiamo pensare all’impatto che il nostro lavoro ha su quello degli altri. La prassi migliore è senza dubbio quella di adottare delle regole comuni che siano automatiche. Avere delle linee guida per scrivere codice non serve, a meno che non ci sia sempre qualcuno a verificarle. Per questo usare un lint, automatizzare il sistema, può essere molto più efficace.

Le regole comuni si possono sempre cambiare all’occorrenza ma, per farlo, sarebbe bene operare una merge request e non fare exception al lint, così da evitare che ciascuno crei da sé le proprie regole…

 

Il principio di Pareto e l’approccio 80/20

Il principio di Pareto è un risultato di natura statistico-empirica che si riscontra in molti sistemi complessi ed è senza dubbio applicabile anche al nostro lavoro di sviluppatori.

Il principio afferma che “la maggior parte degli effetti è dovuta ad un numero ristretto di cause”: tradotto in numeri, Pareto stima che il 20% dello sforzo produca l’80% del risultato, mentre il restante 20% del risultato è prodotto con l’80% dello sforzo.

Cosa ci insegna questo principio? Quando si fanno le stime bisogna considerare tutti gli aspetti, anche quelli che non sono nel backlog: è nei dettagli che si nascondono i veri costi. Ci saranno dettagli che non abbiamo previsto e problemi che non avremmo mai immaginato. Dobbiamo metterli in conto perché non esiste un sistema senza bug: se nessuno si lamenta, vuol dire che nessuno sta usando il nostro software…

 

Non innamoriamoci della tecnologia

I tecnici hanno una vera passione per la tecnologia: quando programmano sono felici. A volte, però, ci si innamora delle soluzioni tecniche, tralasciando i reali bisogni degli utenti. Bisogna invece sempre chiedersi se il codice che si sta scrivendo risolverà il problema che hanno gli utenti.

Talvolta impieghiamo del tempo all’inizio del progetto nello scegliere la tecnologia perfetta per la nostra soluzione. Solitamente è tutto tempo perso: la soluzione verrà fuori in modo incrementale nel corso del progetto. È meglio partire per gradi per arrivare pian piano a un risultato: il TDD, ad esempio, aiuta a risolvere problemi in modo incrementale.

Riconosceremo il framework migliore solo quando questo diventerà un pattern, una scelta consapevole all’interno del progetto.

L’informagica non esiste

Purtroppo la dura realtà è questa: l’informatica è fatta da persone che compongono righe di codice, non c’è nessuna magia dietro. Se vi capita un problema che si risolve magicamente da solo, sappiate che esso si ripresenterà fatalmente una domenica notte quando il software sarà in produzione.

Ogni potenziale difetto non risolto è un debito che crescerà nel tempo e dovrà prima o poi essere pagato con gli interessi.

 

In conclusione: puntare alla semplicità

La semplicità, ossia “l’arte di massimizzare il lavoro non svolto”, è essenziale ma è la cosa più difficile da raggiungere: scrivere un codice pulito, lineare, comprensibile, con un metodo tecnico ben preciso. Per arrivare alla semplicità dobbiamo ambire ad essere dei programmatori “pigri”:

  • scrivere poco codice, solo quello necessario;
  • automatizzare tutto il possibile: imparare quindi modi furbi per farlo;
  • conoscere bene prima di progettare: non posso fare mille ipotesi sulle cose che non so;
  • dormire la notte: devo fare in modo che i sistemi funzionino e che nessuno mi chiami per improvvisi crash notturni;
  • dimenticare le cose, non tenere nulla a mente: prendere appunti, scrivere un backlog chiaro, leggere le mail e segnare nel calendario;
  • riutilizzare il know-how già acquisito;
  • evitare il copia-incolla perché difficile da manutenere.

Se scrivo bene il mio codice, il software avrà bisogno di meno manutenzione, avrò meno riunioni di emergenza e meno interruzioni impreviste. Ogni riunione deve avere uno scopo, solo così porta valore e non genera insoddisfazione.

Quattro consigli pratici

Lasciamoci allora con quattro consigli pratici per cominciare a liberarci dall’insoddisfazione delle nostre riunioni:

  1. ricordiamoci che il cambiamento parte da noi e dal nostro modo di scrivere codice;
  2. fidiamoci dei colleghi: non dobbiamo esserci sempre tutti in tutte le riunioni;
  3. facciamo riunioni brevi: meno di 1 ora, altrimenti non abbiamo mai una pausa tra un’ora e l’altra.
  4. Se organizziamo una riunione, mettiamo sempre un’agenda o un ordine del giorno e otteniamo sempre un output.

In questo modo avremo più tempo per le cose importanti. Stop meeting, start coding!

 

Riferimenti

[1] Un video della presentazione “Stop meetings, start coding” di Giulio Roggero

https://vimeo.com/308447832

 

[2] Lean-Kanban University, Stop starting, start finishing”. Lightning Source Inc, 2012

 

[3] Robert C. Martin, Clean Code. A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008

 

[4] Agile manifesto principle not understood. Stack Overflow

https://is.gd/8hMIeQ

 

Condividi

Pubblicato nel numero
251 giugno 2019
Lavora come Communication Master in Mia-Platform. Nel team comunicazione si occupa di copywriting e pianificazione della comunicazione. Appassionata di tecnologie, mette in pratica in questo mondo le sue conoscenze di scrittura e comunicazione. Ha sperimentato il modo di applicare i metodi Agile anche a un team non tecnico, per la…
Communication Master in Mia-Platform, cerca di colmare il gap tra analogico e digitale per capire la realtà e poterla raccontare. Appassionato esploratore del mondo, scrive di innovazione, in tutte le sue forme: tecnologie, processi, tecniche, metodi, strumenti, organizzazioni.
Come CTO e co-founder di Mia-Platform, aiuta i team a semplificare la digital transformation delle aziende concretizzando le loro strategie in software funzionante. Ingegnere Informatico, ha anche fondato Agile Reloaded srl e ricopre il ruolo di Strategic Partner di Intré srl.
Ti potrebbe interessare anche