Checklist e approccio lean in barca

Gentilmente sollecitato insieme ad Alessandro da Matteo eccomi qui a raccontare qualcosa sull’impiego di checklist nel nostro team… di regata. Partiamo dal problema: come assicurarsi che in ogni fase della regata, a cominciare dall’allestimento della barca, le azioni necessarie vengano eseguite? Come garantire che vengano eseguite nell’ordine corretto? Come prevenire vuoti di memoria, potenzialmente pericolosi?

La situazione in cui si trova un equipaggio di una barca è di costante pressione: da una parte, banalmente, lo scenario agonistico di competizione verso gli altri equipaggi, dall’altra la stessa procedura di regata richiede la conformità a tempi e standard ben definiti. Ho scritto standard a ragion veduta, perché è su questo campo che si gioca tutta la partita delle checklist. Considerato che un equipaggio è costituito da persone che collaborano per un obiettivo comune e che ogni ruolo comporta delle responsabilità e delle azioni che inevitabilmente possono essere interpretate in modo diverso da persone diverse, si pone il problema per il gruppo di sincronizzarsi con una certa uniformità sui sub-obiettivi, sulla sequenza delle azioni da svolgere e sulla qualità minima garantita.

Per raggiungere questo allineamento, che ci si augura il più raffinato possibile, si può quindi descrivere l’obiettivo globale per mezzo di un insieme di vincoli (uno standard, appunto) e lasciare che ogni membro dell’equipaggio svolga le azioni locali che ritiene più opportune prendendosene carico, accettandone la responsabilità. In altre parole si rinuncia al micro-management che detterebbe legge sui singoli gesti di ognuno a bordo per esaltare l’arbitrio individuale su come eseguire in pratica la manovra necessaria.

Una checklist quindi cos’é? È un elenco di condizioni che devono essere soddisfatte per garantire il successo di un processo e spesso le usiamo senza dare loro questa importanza. Esistono checklist per far decollare aerei; per fare i bagagli; per fare la spesa al supermercato; per progettare social network; per definire i passaggi da rispettare per un deployment di un’applicazione e per allestire una barca da regata rimanendo sicuri di aver pensato a tutto, liberando la testa per dedicarla a problemi più critici, come la tattica.

La tattica è infatti quel calcolo che una mente pensante fa tutte le volte che una data strategia – devo comprare certi prodotti per mangiare – si incontra e si scontra con un ambiente mutevole – c’è fila al banco carni, intanto penso alla frutta. Nessuno sarebbe così pazzo da cercare di pianificare gli acquisti al supermercato al livello del singolo passo fra i corridoi, ma ogni nonna che manda un nipotino a fare acquisti lo dota di una rudimentale quanto efficace checklist che garantisce il set di prodotti da acquistare in qualsiasi modo e sequenza il bravo nipotino riterrà validi. Purché siano leciti! :-)

Su Wikipedia si legge:

A tactic is a calculated action determined by the absence of a proper locus. The space of a tactic is the space of the other

oppure

Tactics, then, are isolated actions or events that take advantage of opportunities offered by the gaps within a given strategic system, although the tactician never holds onto these advantages.

Due estratti molti affascinanti.

La cosa importante è che in uno scenario tattico – come la regata, come il deployment di un’applicazione – le persone coinvolte possano flessibilmente risolvere gli imprevisti mantenendo il focus su cosa sia necessario completare per ritenere l’operazione un successo. Tra le mille opzioni possibili

  1. lasciamo all’individuo la libertà di scegliere quali compiere nel dettaglio – tattica
  2. comunichiamo dei vincoli corrispondenti alla strategia – checklist
  3. lasciamo che la soluzione emerga

Il commitment di ogni elemento del team garantisce che il miglior sforzo possibile sia impiegato sul problema tattico posto dall’incontro tra checklist e variabili ambientali.

Ovviamente lo standard, la checklist, non è niente di più che una delle possibili e inevitabilmente parziali rappresentazioni della conoscenza del team. Di fatto costituisce un tentativo di esplicitarne la massima quota possibile. Non sia mai che non possa essere messo in discussione a valle di nuove informazioni o valide considerazioni ridefinenti la strategia del team! Probabilmente un team di principianti tenderà ad affidarsi alle checklist con più pedissequità di un team esperto, ma l’importante è che sia vivo uno spirito critico di gruppo che favorisca il miglioramento continuo dello standard, un processo che nel mondo lean si chiama kaizen.

Un paio di spunti di riflessione per te e per me: le user story si possono considerare come una checklist per il completamento di un wireframe? Ed il Test Driven Development? Non è forse sviluppo lungo le linee guida di una checklist sui generis che evolve fianco a fianco con il codice stesso? Tu che ne pensi? Io qualche idea me la sono fatta…

October 16 2010 03:59 pm | Uncategorized

8 Responses to “Checklist e approccio lean in barca”

  1. Giorgio Sironi on 17 Oct 2010 at 13:24 #

    La parte fondamentale del TDD pero’ e’ che la checklist puo’ essere controllata e ricontrollata automaticamente premendo un bottone, anche se comprende migliaia di condizioni. Le checklist a livello di metodologia si affidano in gran parte alla disciplina, ma non e’ detto rimanga per sempre cosi (far girare un check della sintassi o i test in un pre-commit hook? :)

  2. Cesare D'Amico on 17 Oct 2010 at 16:40 #

    Io ho inteso il TDD come checklist in modo differente, ovvero la checklist del TDD è il mantra “red / green / refactor”… tu cosa intendevi Jacopo? Magari qualcos’altro :)

  3. Giorgio Sironi on 17 Oct 2010 at 16:44 #

    Il “che evolve fianco a fianco” mi fa pensare che guardi al test come a una checklist: ogni asserzione e’ un elemento della lista, e man mano che vengono soddisfatte puoi aggiungerne di nuove.

  4. Jacopo Romei on 18 Oct 2010 at 08:10 #

    Avevo inteso una checklist più nel senso ’sironiano’ di questa discussione, ma meno strettamente adeso al concetto di checklist. Mi spiego.

    Più che ad una serie di asserzioni che posso verificare una per una automaticamente – con grande vantaggio tattico, per rispondere a Giorgio – avevo in generale inteso le checklist come un dispositivo che disaccoppia la strategia dalla tattica, permettendo nel caso del TDD addirittura l’emersion della prima dalla seconda.

    Quello che conta insomma è che si descriva il valore da ottenere (test, checklist di imbarco, lista della spesa) e ci si basi sulla responsabilità del singolo – o della singola coppia :-) – per perseguire il risultato (design del software, barca armata correttamente, nonna contenta).

  5. Luigi Gangitano on 26 Oct 2010 at 16:45 #

    Uhm, Jack, mi sa che come spesso succede, quando si ha un martello tutto diventa un chiodo. :)

    Premesso che, come sai, lo sviluppo agile non è tra i miei pallini e che io, come te, non ho fatto il militare ma partecipato a qualche regata, provo ad aggiungere un paio di riflessioni, perlopiù legate alle barche.

    Visto che prendi come spunto elementi provenienti dal mondo militare (strategia, tattica e operazioni), è a quello che penso dovremmo fare riferimento.

    Riprendendo la tua analogia, in una regata la strategia è sostanzialmente obbligata: una volta deciso se partecipare o meno (in base allo stato dell’imbarcazione, dell’equipaggio, del mare e degli avversari) – anche questa è strategia – il resto è definito dal regolamento: la strategia è vincere arrivando al traguardo prima degli altri. E questo mi sento di dire che è l’unico vincolo proveniente dalla strategia. Per capirci, che sulla barca siano state passate le scotte del genoa non è un requisito proveniente dalla strategia.

    Passando alla tattica, questa definisce ‘come’ si vuole tentare di vincere arrivando prima degli altri al traguardo. E qui entrano in gioco i vincoli ambientali: il mare, il vento, la barca, l’equipaggio, etc. Il tattico stende quindi un piano (spesso anche più di uno, chiamiamoli piani di rispetto :) ) che considera i vincoli locali e gli obiettivi imposti dalla strategia (ho 10 carri armati e devo arrivare in cima alla collina, ci sono 10 nodi di vento, ho solo il genoa 3 e devo vincere) e decide quali azioni devono essere intraprese (invio due carri e tengo gli altri, prendo il lato sinistro dove ci sarà più vento).

    A questo punto dalla tattica derivano dei vincoli operativi: per poter portare due carri in cima alla collina ho bisogno di carri (!!!), munizioni, personale addestrato e poi fare in modo che il singolo reparto si muova in maniera coordinata per ottenere il risultato. E quindi le operazioni sono distinte in due classi: le operazioni preparatorie (manutenzione, addestramento, trasporto, sussistenza, ecc.) e quelle effettuate durante la guerra (sostanzialmente la gestione dei singoli scontri).

    Tornando alle barche il discorso è praticamente lo stesso: ci sono operazioni preparatorie (iscriversi, armare la barca, dare da mangiare all’equipaggio, trovare le regolazioni giuste, allenare l’equipaggio) e operazioni effettuate durante la regata (singole virate, issate, recuperi, manovre d’emergenza).

    A questo punto nella tua analogia le checklist vogliono dire due cose diverse: all’inizio parli di checklist corrispondenti all’armo della barca, alla lista della spesa e al decollo di un aereo. In questo caso si tratta di strumenti di controllo utilizzati per garantire che nessuna operazione ripetitiva venga dimenticata perché intellettualmente poco impegnativa e in questo senso si tratta di vincoli semplicemente operativi. Ottimi per le operazioni preparatorie. Nessuno di noi si scriverebbe le operazioni da fare per accendere l’automobile ma solo perché è una sequenza molto semplice (e sul manuale c’è comunque scritta!!!). Negli eserciti la qualità delle operazioni è garantita, oltre che dalle checklist per far decollare gli aerei, dall’addestramento e dall’allenamento, che infatti è continuo e impegna i soldati in tempo di pace,

    Più avanti le tue checklist puntano decisamente più in alto: sono lo strumento per la collaborazione non organizzata, formalizzano una tattica (secondo la descrizione qui sopra) e lasciano al singolo operatore la scelta su come comportarsi per ottenere lo scopo richiesto. In gergo militare si chiamano ordini e sono quelli dati dai tattici (colonnelli, capitani) ai responsabili delle operazioni (tenenti, marescialli).

    Tornando alle regate: le checklist operative sono un must perché, come sempre succede, un equipaggio non è un esercito e quindi a) non risponde agli ordini ma vuole partecipare alle decisioni (negli equipaggi non professionistici), b) non è allenato/addestrato mai abbastanza per il compito che sta andando ad affrontare (anche qui, negli equipaggi non professionistici). In b) rientra ovviamente anche il caso in cui i membri dell’equipaggio cambiano di volta in volta e quindi non hanno tutti lo stesso standard di addestramento. Assegnare ad una persona la responsabilità di verificarle (come il comandante sull’aereo o il nipotino al supermercato) ne garantisce l’effettiva esecuzione. In un certo senso anche questo fa parte della tattica. :)

    Per le checklist/ordini, invece, mi sembra di capire dal tuo discorso che dovrebbero permetter di realizzare una manovra senza controllare i singoli passi. Così ‘facciamo un peeling di spi’ diventa un ordine che si realizza se è stata comunicata e condivisa una checklist per il peeling di spi (nuova drizza, nuovo braccio, nuova scotta, peeler, issata e recupero) e ciascuno sa qual è il suo ruolo.

    E questo ci riporta all’addestramento, senza il quale le operazioni coordinate non sono possibili. Questo è il punto di forza degli equipaggi vincenti, insieme all’esperienza.

    Vogliamo parlare di checklist come metodi di addestramento? :)

  6. Jacopo Romei on 09 Nov 2010 at 19:13 #

    Ciao Luigi,

    mi fa piacere sapere che leggi questo blog anche se al contempo mi duole constatare la crescente difficoltà che incontro ad alimentarlo di idee nuove, che pur non mancano. Cercherò di rispondere al tuo lungo commento – che rischia di essere più lungo del post stesso, ma dovrò inevitabilmente essere sintetico, per gli stessi motivi che mi impediscono di scrivere un nuovo articolo con la frequenza che vorrei.

    Iniziamo dal tuo presupposto, con l’aiuto di alcuni campioni della vela[1].
    Per Philippe Presti la tattica è

    la posizione adottata rispetto alla flotta di barche e in rapporto ad un progetto strategico. È anche la gestione dell’emergenza.

    mentre la strategia è

    il sistema generale del vento (oscilllante, in scia, brezza termica, basculante e così via). In funzione degli elementi esterni ci si colloca all’interno di un sistema strategico.

    La definizione di Luc Gellusseau di ‘tattica’ è

    la gestione del breve termine per applicare la strategia. Significa, primo, esaminare i problemi, secondo, dare le soluzioni.

    e sempre lui crede che

    [La strategia sia] la gestione del lungo termine. Significa fare alcune ipotesi valutando la possibilità in cui gli eventi possono svolgersi.

    L’ultima citazione è di Bertrand Pacé, il quale non solo sostiene che

    [la tattica] permette di applicare una strategia [...]. Significa anche servirsi delle informazioni per analizzarle, prendere una decisione e poi realizzarla.

    ma addirittura che

    [...] La strategia precede la regata o una sua fase, mentre la tattica è la gestione di una regata o di una sua fase.

    Questa ultima citazione mi è molto utile a definire il rapporto “frattale” che sembra esistere tra una strategia ed una tattica che può a sua volta divenire il contesto strategico in cui collocare un approccio tattico di ordine inferiore e via dicendo.
    A valle di questo assunto, che tu metti a monte del tuo commento in maniera opposta e forse affrettata[2] si svolge tutto il resto del mio post.

    Riguardo la duplice natura delle checklist che tu scorgi nel mio post, siamo d’accordo ‘as is’ sulla loro funzione di garanzia per le operazioni ripetitive e poco focalizzanti. Non solo, siamo d’accordo, stando a quanto mi sembra di capire anche sulla seconda funzione: certo non basta una checklist per avere completate operazioni complesse e l’esperienza e la competenza del team sono dati decisivi per il successo dell’operazione. Quando alludi alle checklist come strumento di addestramento, sappi che è esattamente quello l’uso che ne facciamo a bordo della nostra barca e nei nostri team di sviluppo. Le checklist definiscono la sequenza di passi da svolgere individualmente o in gruppo perché l’acquisizione dell’esperienza non esca da binari qualitativi minimi che poi potrò persino trascendere una volta acquisita l’opportuna maestria.

    Quando praticavo arti marziali o nei primi anni di hockey il gesto mio e dei miei compagni era fortemente codificato. Poi dopo un po’ l’esperienza prese il sopravvento e ci si permise sempre maggiore interpretazione. Ma la codifica rigida e raffinata dei primi tempi non furono certo inutili!

    “E questo ci riporta all’addestramento, senza il quale le operazioni coordinate non sono possibili.”
    Sono d’accordissimo. Uno dei fatti più assodati delle metodologie agili è il presupposto di competenza del team.

    [1] La regata – Tattica e strategia, Ravon e Dumard, Ed. Mursia
    [2] Lance Armstrong vinse il Tour de France dal 1999 al 2003. Nel ‘99 4 tappe su 21, nel 2000 1 su 21, nel 2001 e nel 2002 4 su 21 e nel 2003 di nuovo solo una. Sembra che la sua strategia fosse al contempo ottimale e diversa dal “vincere arrivando al traguardo prima degli altri”.

  7. Luigi Gangitano on 10 Nov 2010 at 18:56 #

    Ciao Jack,

    ti ringrazio per il chiarimento. Mi è ora chiaro che il sistema di riferimento del tuo post è riferito all’interpretazione dei campioni che hai citato, che in qualche modo differisce dall’interpretazione classica che si dà della classificazione “Strategico, Tattico, Operativo”.

    Cambiati gli assiomi, non posso non rilevare che tu trasformi un elemento di logica temporale (”La strategia precede la regata o una sua fase”) in una dipendenza gerarchica (esiste una strategia pre-regata che genera una tattica globale che genera una strategia per-fase che genera una tattica per-fase) e questo passaggio mi convince solo in parte [1].

    Fatto sta che che le checklist a questo punto assumono un ruolo (due ruoli?) più marginali e se vogliamo strettamente operativi e questo ridimensionamento un po’ disillude le aspettative che il titolo aveva creato in me quando avevo visto l’articolo ripubblicato su FB.

    È molto probabile che la mia ignoranza in materia di metodologie agili mi abbia tratto in inganno e che, come molti ignoranti, sperassi in una loro efficacia anche in team meno esperti, ma sono d’altronde molto contento del nostro accordo sulla fondamentale importanza dell’allenamento e dell’esperienza.

    [1] Così come mi convince solo in parte l’obiezione sulla strategia: se, cambiando gli assiomi, l’ambito del confronto diventa una corsa a tappe è difficile che la strategia pensata per una singola tappa possa essere corretta. Con buona probabilità Lance Armstrong adottò una strategia del tipo: sfruttare al massimo le tappe a lui favorevoli accumulando il massimo vantaggio possibile, cercando di perdere il meno possibile in quelle a lui sfavorevoli. Poi, se vuoi, possiamo discutere se nascondere un eventuale doping dietro le cure per il cancro fosse una possibile strategia. :-)

  8. Jacopo Romei on 14 Nov 2010 at 04:38 #

    Le checklist no, non sono una panacea, ma l’assunto a monte del loro utilizzo nel contesto dello sviluppo di un prodotto[1] (software) non è affatto trascurabile.

    Se mi consenti una gragnuola di anglo-latinismi :-) , in sostanza si tratta di spostare il ‘mindset’ dal focus sulle operazioni al focus sui vincoli. Definire cosa dobbiamo ottenere e lasciare che il team si auto-organizzi, abbandonando lo spettro del “command & control”, del micromanagement che fa tanti danni.

    Per fare questo avrò bisogno di un team in grado di auto-organizzarsi, vero, ma anche di una condotta manageriale che permetta il nascere e lo svilupparsi di strutture auto-organizzate. Nessuno nasce ‘mparato, nemmeno i team esperti.

    Detto ciò: il prossimo aprile io vorrei fare la “Roma x 2″. Ti conto? :-)

Trackback URI | Comments RSS

Leave a Reply