Strumenti per la gestione

Hai mai fatto una caccia al tesoro al documento perduto? Il file che descrive quel processo aziendale lo trovi nella lista SharePoint di quel server, mentre la bozza della nuova brochure per la fiera della settimana prossima è in quella folder condivisa. Lo stato di avanzamento lavori per quell’insieme di modifiche è nel foglio Excel che ti ho condiviso settimana scorsa via email. Infine la presentazione da usare per il workshop con il cliente la settimana prossima è in Google Slides.

Un po’ romanzato, ma non molto distante dalla realtà: infatti quello che ho  descritto è stato uno dei passaggi del mio processo di onboarding nella mia vecchia azienda. In Particular Software, il processo di onboarding, che segue immediatamente la fase di selezione del personale [1], fornisce una e una sola risposta: “lo trovi su GitHub”.

Disordine, disordine ovunque

Al crescere delle dimensioni di un’organizzazione è facile che le cose scappino di mano.

Di fronte alla necessità di tenere traccia di alcune informazioni, un team fa la sua scelta e introduce un nuovo sistema. A questo punto la frittata è fatta e la dispersione di informazioni in più sistemi ha inizio. Come effetto secondario, le informazioni vengono duplicate, perché è molto probabile che un altro team, ignaro delle scelte del primo, introduca un altro sistema per tracciare informazioni simili.

Queste dinamiche spiegano perché, nelle grandi organizzazioni, uno dei focus della strategia aziendale sia il consolidamento dei sistemi di gestione (management systems) [2].

Il lusso della novità

Noi siamo stati fortunati. Quando la nostra organizzazione è nata da quello che un tempo era un progetto open source gestito da una persona sola [3], non avevamo nulla. Appena si è manifestata la necessità di avere dei sistemi gestionali, l’allora ristretto gruppo di ingegneri del software, terrorizzati dal problema della duplicazione, ha fatto la scelta per loro più naturale: perché non scegliere quello che già usiamo tutti i giorni per la gestione del ciclo di vita dei prodotti anche per gestire tutto il resto?

E GitHub fu.

Tra gli strumenti di gestione del ciclo di vita delle applicazioni (Application Lifecycle Management, ALM [4]), GitHub è indubbiamente il peggiore. Scarno e senza nessun supporto per ALM, insomma, uno strumento pessimo. L’assenza di supporto per ALM si è però rivelata paradossalmente la sua forza maggiore.

Con il tempo, e grazie alle nuove funzionalità rilasciate negli anni, abbiamo plasmato lo strumento a nostra forma e piacimento. Come tutte le cose che avvengono da noi [3], tutto è in continua evoluzione e quello che scrivo oggi sarà probabilmente vecchio tra sei mesi o poco più.

Il primo problema: la collaborazione

Slack [5] è lo strumento che più usiamo per la collaborazione quotidiana. Senza entrare nei dettagli, è una chat, e come tutte le chat gestisce conversazioni. Le conversazioni sono però volatili, hanno senso nel momento e spesso sono prive di contesto. La volatilità è però un nemico sul lungo periodo. Qualsiasi cosa facciamo è spesso discussa in Slack, ma in seguito viene resa persistente in un issue [6], o in un file markdown [7] su GitHub. Come abbiamo già avuto modo di dire, un issue rappresenta un problema da risolvere, mentre un documento rappresenta uno stato di fatto. Ad esempio, i processi sono documentati con artefatti markdown, allo stesso modo sono documentate policy o decisioni di lungo respiro.

Il secondo problema: ogni macroattività ha bisogno di processi diversi

La documentazione dei vari processi si è rivelata essere il secondo problema. In molte realtà esiste il manuale delle procedure [8]. Tutti i nostri processi sono documentati sotto forma di artefatti markdown. Uno dei vantaggi di rendere persistente tutta la documentazione in Git [9] è che la storia delle modifiche viene automaticamente conservata ed è molto facile tornare indietro nel tempo per visualizzare come fosse un documento in un dato momento storico. Inoltre GitHub offre una serie di strumenti di collaborazione che, sfruttando questo concetto di storicizzazione, permettono un’esperienza di modifica dei documenti molto ricca.

Il terzo problema: le persone hanno bisogno di un unico punto d’accesso

Come descritto in apertura, più i sistemi di gestione crescono, più la confusione aumenta. Le persone sono spaesate dalla difficoltà nel reperire le informazioni di cui quotidianamente hanno bisogno. Questo è particolarmente vero quando la realtà fluida [10] dell’organizzazione fa sì che le persone possano lavorare in molti ambiti diversi senza limiti di sorta.

Il ciclo di vita di un problema

Supponiamo che durante una chiacchierata con un cliente ci si renda conto che il prodotto non soddisfa appieno le necessità. Il cliente ci comunica che vorrebbe alcune nuove funzionalità, e che sono talmente importanti che risolverebbero il suo problema più rapidamente e a un costo inferiore. Ecco, tutte queste osservazioni nella nostra realtà quotidiana vengono riversate in un issue su GitHub. La cosa importante in questa fase è non descrivere una soluzione, ma limitarsi al problema che l’utente cerca di risolvere nel suo lavoro quotidiano.

Coma una rondine non fa primavera, un issue non fa una nuova feature.

L’analisi del problema

In questa fase, l’issue rappresenta principalmente l’informazione che il problema descritto è reale, almeno per un cliente. Quello che facciamo da questo momento in poi è cercare ulteriore evidenza: dobbiamo capire se il problema è importante solo per pochi o per una base di clienti più ampia. Ogni prova viene registrata nello issue stesso.

È a discrezione del gruppo (squad [10]) che presiede la macroattività stabilire quale sia il livello di evidenza necessario per prioritizzare la soluzione del problema. Al momento opportuno, la squad inizierà la fase di analisi alla ricerca di maggiori dettagli e di un possibile spettro di soluzioni.

La fase di analisi, come tutte le fasi successive, viene rappresentata da un nuovo issue collegato a quello che descrive il problema. Questo primo passaggio di analisi è preparato dalla squad stessa in una laboriosa fase di elaborazione dell’issue. Lo scopo è quello di garantire la massima libertà di esecuzione possibile a chi prenderà in carico il lavoro e, al contempo, evitare di caricare di preconcetti o suggerimenti in merito a possibili soluzioni.

La squad deve astenersi da qualsivoglia analisi; il problema è che i suoi membri possono a loro volta avere un bagaglio tecnico elevato, e astenersi dall’usarlo non è semplice. Per questo motivo la preparazione di ogni issue è fatta in gruppo ed è assoggettata a parecchie fasi di revisione.

La fase di ingaggio

Quando un issue è pronto, viene reso disponibile per la lavorazione.

Immaginate una lavagna virtuale aziendale, a cui tutti possono accedere, composta da tre colonne:

• da lavorare
• pronti per essere lavorati
• in lavorazione

Quando una squad vuole mandare in esecuzione qualcosa, non fa altro che “appenderlo” alla colonna “da lavorare”. Mano a mano che le cose vengono fatte, gli issue si spostano sulla lavagna. La colonna “pronti per essere lavorati” ha un limite (WIP limit, Work In Progress limit) di 5 elementi.

Quando si libera uno spazio, il primo degli issue in “da lavorare” si sposta in coda a “pronti per essere lavorati”; a questo punto le persone possono candidarsi.

Un issue pronto per la lavorazione ha tre caratteristiche essenziali:

• una corposa descrizione autocontenuta con l’obiettivo di fornire tutte le informazioni necessarie per la lavorazione;
• una lista di “skills and knowledge”, le caratteristiche e le capacità che, secondo la squad, le persone dovranno avere per affrontare e gestire il problema;
• una sezione che specifica il tempo che la squad ritiene necessario per portare a compimento il lavoro.

Noi usiamo queste informazioni per decidere se lo issue è adeguato alle nostre caratteristiche e conoscenze e se, da un punto di vista della pianificazione, è sostenibile.

Pianificazione dell’issue

Se il tempo previsto per il completamento fosse di quattro settimane, ma fra due devo volare a una conferenza, è difficile che possa dare una mano ed è probabilmente meglio scegliere altro. È altrettanto ovvio che ci possano essere situazioni in cui nessuno dei cinque issue disponibili si incastra con le mie caratteristiche o con le mie disponibilità di tempo. In uno scenario come questo abbiamo tutta una serie di attività collaterali, che noi chiamiamo “Small task” che possono essere usati come tappabuchi. Nel caso invece il problema fossero le caratteristiche e conoscenze richieste, potrei sempre decidere di candidarmi come apprendista interessato a imparare qualcosa di nuovo.

Nel momento in cui la squad ritiene di avere la corretta composizione, la “task force” viene formata e l’issue spostato “In lavorazione”.

L’esecuzione

Durante la fase di lavorazione, “semplicemente” il gruppo cerca di risolvere il problema. Degno di menzione a questo punto è il fatto che il nostro obiettivo è spesso quello di migliorare la situazione, non necessariamente risolvere il problema.

Difficilmente troverete unissue il cui titolo suoni come “Risolvere il problema XYZ”. È molto più facile che il titolo, e di conseguenza lo scopo, sia “Migliorare la situazione quando nel contesto ABC si verifica il problema XYZ”. Il dettaglio può suonare di poco conto, ma si basa sulla regola dell’80/20: spesso e volentieri un miglioramente dell’80% rende felici tutti, la situazione migliora in maniera sensibile per il cliente e i costi sono contenuti per noi. L’extra necessario per raggiungere il 100%, o la completa soluzione del problema, spesso non è necessario.

Conclusione

Siamo un’azienda di prodotto, e in quanto tale non abbiamo un obiettivo a termine, come invece avrebbe un progetto. Non dobbiamo consegnare, ma il nostro lavoro è migliorare costantemente: un issue alla volta, in un ciclo infinito che non ha motivo di fermarsi. Se si fermasse, l’organizzazione non avrebbe più senso di esistere.

Anche in questo caso, l’operatività quotidiana è costruita intorno alle necessità dell’organizzazione. E come probabilmente avrete capito, la questione non è GitHub, quanto piuttosto i processi che lo strumento scelto ci ha consentito di plasmare a nostra misura.

Riferimenti

[1] Mauro Servienti, Ci scegliamo a vicenda. MokaByte 278, dicembre 2021

https://www.mokabyte.it/2021/12/hrrecruiting-1/

[2] Roger Martin, The Role of Management Systems in Strategy, Medium

https://rogermartin.medium.com/the-role-of-management-systems-in-strategy-571583546fbe

[3] Mauro Servienti, Un’organizzazione dispersa. MokaByte 276, ottobre 2021

https://www.mokabyte.it/2021/10/unorganizzazione-dispersa/

[4] Application lifecycle management, Wikipedia

https://en.wikipedia.org/wiki/Application_lifecycle_management

[5] Slack, Wikipedia

https://en.wikipedia.org/wiki/Slack_(software)

[6] GitHub issues, GitHub

https://github.com/features/issues/

[7] Markdown, Wikipedia

https://en.wikipedia.org/wiki/Markdown

[8] Standard operating procedure, Wikipedia

https://en.wikipedia.org/wiki/Standard_operating_procedure

[9] Git, Wikipedia

https://en.wikipedia.org/wiki/Git

[10] Mauro Servienti, Non ci sono persone sbagliate. MokaByte 277, novembre 2021

https://www.mokabyte.it/2021/11/personeinorganizzazione/