Il Thread, questo sconosciuto

Lezioni di Posta Elettronica – (ultima revisione: 13/08/2015)

Il Thread, questo sconosciuto

Se l’email permette, con il semplice reply, di mantenere organizzata una corrispondenza elettronica sulla base di un unico subject originario perché in tanti, troppi, si ostinano a crearne sempre di nuovi?

Premessa: volenti o nolenti, fiduciosi o scettici, early adopter oppure cronici ritardatari, un po’ in tutte le aziende, anche nell’italica penisola, sta affermandosi l’uso della posta elettronica per il trasferimento di informazioni e/o di documenti non ancora stampati (…) – chiamarla “virtualizzazione“, o meglio ancora “dematerializzazione del workflow” (impiegatizio) sarebbe troppo ottimistico, nonché prematuro e naïf; posta la semplicità d’uso dello strumento – metti un indirizzo, metti un oggetto ed un subject, un corpo e magari un allegato, premi “invia” ed è fatta… –, poi, anche ai lavoratori con una preparazione meno che minima all’impiego del binomio PC + Internet può esser richiesto di presidiare la propria e/od un’altrui mailbox.

Seconda premessa: data la fluttuante percezione, tendente alla formalità oppure alla non formalità, della comunicazione via mail — “verba volant, scripta manent“… — quest’ultima vede crescere sempre più il proprio appeal presso quella, tutt’altro che infrequente, tipologia di lavoratore che, nel premere “invia“, scorge l’opportunità di scaricare il barile, pure in perfetta bona fide, ad un qualsiasi interlocutore. In una ordinaria situazione organizzativa nella quale la gestione della corrispondenza costituisce – e soprattutto rappresenta (soggettivamente) – solo una fra le molte impellenze del lavoro da fare, infatti, è facile che ne scemino il valore e la strumentalità percepiti, a favore di una, altrettanto percepita, occasione per fugare o quantomeno contenere lo spesso crescente Distress.

Eustress (Stress “buono”) & Distress (Stress “cattivo”)

In tal senso – non va, tuttavia, sottovalutato lo zampino dell’onnipresente (!) Attenzione Parziale Continua! – la facoltà di spegnere, il più rapidamente possibile e con pochissime mosse – ed una qualunque ricognizione sulla corrispondenza pregressa può comportare concentrazione e, soprattutto, tempo… –, quantomeno una parte della propria sollecitazione rappresenta una tentazione cui resistere è tanto più arduo quanta è la percezione, realistica o meno, di tale sollecitazione – il che, d’altronde, candida qualsiasi eccessiva/sospetta frettolosità non altrimenti motivabile (…) nella gestione delle email ad eventuale fattore/sintomo (in un “quadro sindromico“…) di incipente o conclamata condizione da Stress Lavoro-Correlato

Terza premessa: la larghissima penetrazione, a partire dalla sfera individuale/personale alla conquista di quella professionale, che la Messaggistica Istantanea avanzata – e d’altro canto pure semplificata… – (WhatsApp, Telegram, etc.) sta avendo sulla popolazione tutta sta, altresì, almeno agli occhi degli early adopter, avendo un effetto di imbarbarimento dei costumi e delle prassi della corrispondenza elettronica: disinvolta trascuratezza persino sui principii più semplici – ed utili..! – della Netiquette (assenza del subject, valanga di allegati pesanti, …), frettolosità (eccessiva) nei reply – neanche si trattasse di mettere un “like” o uno “share” al post di un amico..! – e nei forward e chi più ne ha più ne metta

Un tanto premesso fra le pratiche più perniciose nell’ab…uso della Posta Elettronica sta affermandosi, un po’ per la ormai abitudinaria istantaneità della comunicazione ed un po’ per l'”effetto scarica-barile“, è la tendenza alla (ripetuta) “Novazione dell’Oggetto del Messaggio“, in barba al fatto che quasi tutti i gestori email (client o Webmail) trattino correntemente ed efficacemente (…) il threading entro cui incorniciare una specifica Corrispondenza Elettronica… Ancora una volta è la carenza di alfabetizzazione – o, per meglio dire, di vera e propria educazione di base all’uso di questi strumenti… – il contesto in cui siffatte “devianzemetodologiche si ingenerano o semplicemente vengono tollerate fintantoché non diventano dispersive – a detrimento dell’efficienza..! – prassi aziendali.

Corrispondenza & Comunicazione

Per fare un po’ di storia si potrebbe cominciare evocando la Letteratura. Almeno in quella occidentale un genere noto a tutti è quello della cd. “corrispondenza epistolare” fra un autore ed un altro, o fra un autore e qualcun altro – ad esempio il caro amico o la donna amata: Tizio scrive a Caio, il quale risponde al primo riferendosi precisamente ad una o più epistole (lettere manoscritte) della loro, appunto, “corrispondenza” pregressa; benché i due si conoscano e verosimilmente sappiano (implicitamente) ciò che si sono scritti in precedenza, più o meno esplicitamente ciascuno, per agevolare la controparte – nel cd. “information retrieval/recall“, visto che non è detto vi sia la possibilità materiale di consultare il pregresso e la memoria può fare cilecca… –, può far riferimento a precisi “segmenti” (pezzi) dei contenuti precedentemente esposti dall’uno e/o dall’altro. Questi riferimenti, che spesso si declinano in pedisseque citazioni (e.g. «In merito a quanto da te espresso affermando che… bla bla bla…») del pregresso, solo apparentemente corrispondono ad una (mera) manifestazione di cortesia o semplice buona educazione: come spesso accade, infatti, nati con un intento prettamente funzionale (agevolare la contestualizzazione del discorso), sono stati, con il tempo, codificati socialmente all’interno di ciò che chiamiamo “buone maniere” – di cui molti interlocutori insistono (…) ancora a tener conto (nel valutare le proprie controparti)..!

Nella comunicazione istituzionale ed organizzativa, e non solamente per la potenziale valenza giuridica di ciò che viene discusso – e di come viene discusso… –, la questione si complica ulteriormente, innanzitutto perché a diventare potenzialmente più articolate sono l’entità (più persone) ed il ruolo sia del/i mittente/i che del/i destinatario/i e poi perché, ancor più banalmente, può crescere imprevedibilmente la quantità di corrispondenze concorrenti e, con essa, il rischio, organizzativamente parlando, di disordine/rumore

Tipici elementi di una cd. “Lettera Commerciale” (nel mondo anglosassone)

Sicché, dai tempi del (solo) cartaceo in poi, le organizzazioni si sono dotate di protocolli (insiemi di regole e formalismi convenzionali), nonché di un copioso armamentario di strumenti di cancelleria, nonché, infine, di mansioni professionali dedicate, al precipuo scopo di imbrigliare la molteplice corrispondenza evitando quanto possibile il disordine, e questo sia nella comunicazione formale con l’esterno che in quella interna: all’arrivo di una missiva la stessa dovrebbe presentarsi in un format (grafico e contenutistico, ad es. la cd. “Lettera Commerciale“) tale che sia possibile, da un lato, rinvenirne a colpo d’occhio gli elementi distintivi (mittente, oggetto, …) e, dall’altro, trovare materialmente lo spazio per apporvi, magari con un timbro, la codifica organizzativa interna (cd. “protocollazione” – in italiano).

Mi risulta quasi divertente quando i miei allievi si sorprendono del fatto che le stesse posizioni degli elementi di una lettera commerciale – ad esempio quelli tipicamente allineati a destra nel format italiano – siano tutt’altro che casuali ed invero funzionali all’archiviazione in raccoglitori, con tanto di eventuali forature e/o spillature, ed all’apposizione di timbri e quant’altro…

Non casualmente, pertanto, sin dagli albori della posta elettronica si è tentato di trasferire questi, ormai, requisiti di organizzabilità dei flussi di corrispondenza nelle funzionalità di server e client email, persino in una dimensione d’uso prevedibilimente nonché auspicabilmente più individuale (titolare dell’account) o circoscritta (co-titolari dello stesso account, titolare + vicario/i, titolare + segretario/a): ciascun messaggio in arrivo, ad esempio, può essere raccolto in una specifica cartella/directory (o sotto-cartella/sub-directory) in una struttura a radice e/o tassonomizzato apponendovi uno o piùtag” e/o categorie di classificazione, magari pure in maniera automatizzata (imponendo specifiche “regole” di “filtraggio” della posta); d’altro canto la automazione – sempre basata su regole già definite o definibili dall’utente… – disponibile in un qualunque client può estendersi alla risposta automatica ed all’inoltro automatico di un messaggio. Fra le utilità di un gestore di posta c’è anche la (automatica) organizzazione dei messaggi in arrivo in specifici thread (“filoni“), che corrisponde, ottimizzandola, alla best practice, nella corrispondenza formale tradizionale (cartacea), al riferimento, nella replica ad un messaggio, anche al “protocollo in uscita” di questo, oltreché all’oggetto (ad es. “Concessione autorizzazione avvio lavori – vs prot. 12345/2002“), tipica dell’ambito istituzionale.

Threading dei messaggi

Nel trattare qualunque messaggio email sia i client che i server ne contemplano le intestazioni, di norma invisibili all’utente finale nonché generate in automatico dai sistemi, sulla base di standard globalmente condivisi (e.g. RFC 2822), e nella fattispecie gli headers (intestazioni) seguenti…

  • Message-ID” → IDentificativo univoco (unico) dello specifico messaggio, eventualmente figlio (“child“) di un altro messaggio;
  • References” → lista di Message-ID antecedenti/genitori (“parent“) allo specifico messaggio;
  • (e/o) “In-Reply-To” → singolo Message-IDparent” dello specifico messaggio

…possono definire esattamente la posizione di un messaggio all’interno di un suo (eventuale) “albero genealogico“, ovverosia la “conversazione“/thread (specifica corrispondenza) cui potrebbe appartenere, che a sua volta è rappresentabile, tipicamente da un client, attraverso un algoritmo.

Tipica rappresentazione di un thread (Parent) – e di sub-thread (Child/Parent) – in un client email:
ogni thread può essere esploso (expand [-]) o ridotto (collapse [+]) per personalizzare la visualizzazione.

In estrema sintesi: ogni volta che decidiamo di pigiare il Reply ad un messaggio in arrivo provochiamo la creazione di un nuovo Message-ID, cui associamo anche l’ID del messaggio ricevuto – e tutti quelli che l’hanno preceduto –, predispondendo per l’incorniciamento del tutto nel medesimo thread. L’opportunità che il threading offre, a questo punto, dovrebbe essere emersa, ed è pure ben più utile dal mero copincolla automatico del Body e del Subject – cui aggiungere un “RE:” (reply) od un “FW:” (forward): consentire, nel contesto dei vari flussi di comunicazione necessariamente complessi tipici della comunicazione in ambito organizzativo (Ordini di Servizio, Stati di Avanzamento Lavori, etc.), una ulteriore opzione di strutturazione dei messaggi – e dunque pure recupero! –, totalmente automatica, rispetto alla tassonomizzazione in base a cartelle/categorie/tag, che, diversamente, può essere solo semi-automatica (e.g. applicazione dei “filtri“); pertanto il threading va considerato il primo se non anche primario metodo di archiviazione automatica dei messaggi in arrivo (*) a disposizione dell’utente – laddove per “archiviazione” si voglia intendere un procedimento “intelligente ed intellegibile” e non il mero stocaggio dei messaggi…

(*) …Tenendo presente che svariati client di posta elettronica contemplano gli interi thread, comprendenti sia i messaggi ricevuti che quelli inviati:

  • risposte di altri ad un proprio messaggio iniziale;
  • proprie risposte a messaggi altrui;
  • risposte altrui a messaggi altrui.

Corrispondenza e Threading

Vale forse la pena, a questo punto, avanzare una distinzione terminologica, anticipando sin da ora che lo scopo di un’adeguata educazione all’uso utile della posta elettronica è giustappunto la riduzione di tale distinzione, ossia la capacità, da parte di mittenti e destinatari, di avvicinare il più possibile i due termini, proattivamente coscienti che il rispetto/adesione (compliance) al secondo funge da facilitazione (operativa) per il primo:

Corrispondenza/Conversazione Elettronica
L’insieme complessivo di messaggi percepibili da mittenti e destinatari come appartenenti ad un dato tema, generale – in ambito organizzativo potrebbe essere un intero progettooppure specifico – ad esempio una specifica attività (task) o sub-attività (sub-task) progettuale. È il “lato umano” della faccenda
Threading
Il procedimento (automatico) grazie al quale un messaggio viene fatto appartenere ad una filiera (insieme) di altri messaggi qualora in risposta (reply) ad uno qualsiasi di questi. Costituisce l'”opportunità digitale” della faccenda

Dalla “naïvité” al “professionalism” nell’impiego del threading nella corrispondenza elettronica – si noti il ruolo
del Clima (ambiente organizzativo) quale co-fattore per la maggiore oppure minore compliance fra i due.

Far aderire maggiormente le proprie corrispondenze ai threads, d’altro canto, è tutt’altro che complicato… Tuttalpiù trattasi di mantenere, con costanza, una serie di buoni propositi prima ancora d'”istanziare” una nuova corrispondenza:

  1. Essere dotati di una policy, aziendale o personale, per la cancellazione dei vecchi messaggi (e.g. solo dopo tot mesi), evitando il controproducente costume di cancellarli via via che vengono letti (…) – neanche si trattasse di notifiche di un social network;
  2. (Proporzionalmente alla complessità/eterogeneità delle potenziali corrispondenze…) aver già predisposto per un’archiviazione, manuale e/o automatica, dei messaggi in cartelle (e sotto-cartelle), procedendo alla collocazione nelle stesse dei messaggi già trattati (letti, eseguiti, cui è stata data risposta, etc.);
  3. Essere per lo meno abbastanza aggiornati con la lettura dei pregressi messaggi in “Posta in Arrivo“, in maniera da essere, il più frequentemente possibile (…), capaci di…
  4. …fare mente locale per capire se un dato tema possa essere stato già trattato, sapendone recuperare il/i messaggio/i originario/i e scegliere quello più opportuno cui fare Reply;

Se e solo se nessun messaggio email precedente può essere sfruttato per agganciarvi una replica, allora, mantenendo altri buoni propositi, è plausibile la creazione di un Subject ex novo e pertanto di un nuovo thread/corrispondenza – tenendo conto che diversi client email consentono l’ereditarietà di “References” e “In-Reply-Topersino alterando un Subject originario, laddove in Reply ad un messaggio precedente:

  • Ideare un Subjectparlante: corto e tuttavia il più possibile rappresentativo
    • …dell’insieme di contenuti trattati nel corpo del messaggio (potenzialmente difficile, soprattutto se tali contenuti sono tanti ed eterogenei → indicato a chi è assai talentuoso nei riassunti…), ad esempio…Debrief cliente "XYZQ" — primo incontro…, in cui la sola informazione evidente è il verosimilmente nuovo cliente, e pertanto tutto il peso informativo è calcato sui contenuti…
    • …e/o dell’argomento – una data commessa, una fase della stessa, un cliente, etc., – cui i contenuti del messaggio si riferiscono (più affrontabile perché l’unica variabile da considerare è il livello di prospettiva, dal macro al micro, sull’argomento), ad esempio…Dettagli affitto stand…, in cui chiaramente ci si aspetta che il/i destinatario/i sappia/no del perché, del percome e forse anche del quando sussista tale volontà di disporre di uno stand in una qualche manifestazione…
  • Evitare il Subject "Post-It", non "parlante poiché scevro da una qualsiasi contestualizzazione (vedasi il punto precedente), ad esempio…
    Ti ha cercato il Dott.Rossi……con nel Body esclusivamente un numero di telefono…
    Ti prego di stamparmi…senza Body e contenente esclusivamente un allegato, magari pesantissimo – e quindi da scaricare già solo per capire di che si tratta…
    Sala Riunioni

    …, che possono essere anche comprensibili in una chat o su WhatsApp et similia ma che perdono tutto il loro "effetto immediatezza" nella mailbox, più idonea al (noto) uso asincrono

  • Impiegare codifiche del Subject, purché convenzionali (condivise fra tutti i mittenti ed i destinatari, per esempio su policy aziendale!), proporzionalmente alla complessità/eterogeneità delle potenziali corrispondenze (e.g. più progetti concorrenti), ad esempio…"Cliente XYZQ" > "Commessa 123" > Rilascio > Slittamento data , e, d’altro canto evitare codici, abbreviazioni e terminologia specifica qualora non globalmente condivisi (in precedenza), ad esempio…Riass.Fin Pol. 1234567890/2003…intentendo "Polizza di riassicurazione finanziaria n°1234567890/2003".

Nota bene: trattasi solamente di consigli di buon senso, ovviamente… Saper sommarizzare (“summary“) alla perfezione, nel Subject, i contenuti del Body è un’arte e nemmeno ai “maestri” tutte tutte le opere riescono sempre… L’importante è non propendere costantemente per lo (sciatto) atteggiamento inverso!

Novazione e Gemmazione del Subject

Una “novazione” del Subject si ha ogniqualvolta, anziché preoccuparsi di recuperare l’ultima email di una corrispondenza esistente e farci un semplicissimo reply, rispettando così il threading, la persona pigiaNuovo Messaggio“, cominciando così un nuovo thread. All’apice di una ipotetica “classifica dei casi più dementi in cui si nova un Subject” camperebbe, senza alcun dubbio, il seguente esempio:

Thread esistente:
  • Richiesta monitor più grande (>= 19'')
    • Re: Richiesta monitor più grande (>= 19'')
      • Re: Re: Richiesta monitor più grande (>= 19'')
Subject novato:
Richiesta monitor più grande (>= 19'')(esattamente uguale all’originario)

…anche nelle tanto subliminali quanto laconiche varianti

Subject novati:
Richiesta monitor più grande (>= 19'') URGENTE
URGENTE Richiesta monitor più grande (>= 19'')

In questo caso il mittente palesa la propria ingenuità nel pensare che l'”etichettamento” come “urgente” – che pure potrebbe essere trattato con un semplice intervento sui filtri ma che predefinitamente un client non riconosce, né il destinatario è portato a scorgere naturalmente – prioritizzi, neanche si trattasse del classico “timbro rosso” sulle missive cartacee (di un tempo), la rilevazione e la lettura del proprio messaggio rispetto ad altri.

Nota bene: una prioritizzazione di sistema dei messaggi è già supportata da molti client di posta (intestazioni: “Priority, “X-Priority“, “X-MSMail-Priority e “Importance“) od è emulabile con un’ulteriore codifica nel Subject, eventualmente usando una gemmazione del Subject entro il thread (vedi sotto).

Ogniqualvolta il partecipante a una corrispondenza – e nella comunicazione organizzativa i partecipanti, ad es. i membri di un team, potrebbero essere molti..! – nova un messaggio nonostante avrebbe potuto ricondurlo a quella esistente fuoriesce dalla stessa, slegandola dal thread e quindi annullando il supporto offerto dal mezzo tecnologico – non solo per sé ma anche e soprattutto per tutti gli altri partecipanti..! – ed, in definitiva, provocando “Rumore Comunicazionale“. È ormai assodato, assurgente pure ad immanente problema lavorativo, che ciò si traduca in un lievitamento dei tempi richiesti alla mera gestione (ordinaria) della posta in arrivo ed una crescita del rischio (di perdersi comunicazioni importanti, di non rispondere in tempo, etc.), ovverosia un surplus di sforzo che non può non distogliere risorse (mentali, strumentali, etc.) dal lavoro davvero da fare…

Una “Gemmazione” del Subject, invece, si ha quando si altera il Subject di un messaggio in Reply (od in Forward) ad un altro, ossia rispettando il thread. Una volta testato (empiricamente) che il proprio client email supporti l’ereditarietà di “References” e “In-Reply-To” è possibile cogliere tutte le opportunità di questa funzionalità. Il più classico nonché virtuoso esempio ricalca il comportamento (umano) nei thread dei forum e prima ancora nei newgroup (e.g. [SOLVED]), col (nuovo) Subject gemmato per enfatizzare la soluzione di un problema e lasciando alla lettura del Body i dettagli di tale soluzione:

Thread esistente:
  • Richiesta monitor più grande (widescreen >= 24'')
    • Re: Richiesta monitor più grande (widescreen >= 24'')
      • Re: Re: Richiesta monitor più grande (widescreen >= 24'')
        • Acquistato monitor widescreen 28''(gemmazione)

Un’altra tipica eventualità di gemmazione si può avere in caso di un’evoluzione della priorità codificata (“Pn” → “P0“) nel Subject:

Thread esistente:
  • P2 Richiesta monitor più grande (widescreen >= 24'')
    • Re: P2 Richiesta monitor più grande (widescreen >= 24'')
      • Re: Re: Re: P0 Richiesta monitor più grande (widescreen >= 24''), monitor fuori uso!
        • P0 Disponibilità altro monitor(gemmazione in priorità)
      • Re: Re: P2 Richiesta monitor più grande (widescreen >= 24'' + touchscreen)
        • Re: Re: Re: P2 Acquistato monitor widescreen+touchscreen 28''(gemmazione con mantenimento della priorità)

Un altro tradizionalissimo esempio, dalla virtuosità soltanto un po’ meno banale ma che è il più rappresentativo di una gemmazione vera e propria – laddove nel precedente esempio all’alterazione dell’oggetto del messaggio corrisponde pure la chiusura della corrispondenza/thread –, riguarda la differenziazione del Subject in base a ciascun specifico sotto-tema del Subject e/o del Body del messaggio:

Thread esistente:
  • "Cliente XYZQ" > "Commessa 123" > OdG Team Brief (31/08|11:30)
    • Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Richiesta Spostamento Orario (31/08|15:30)
      • Re: Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Richiesta Spostamento Data (01/09|09:30)
        • Re: Re: Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Nuova Convocazione (01/09|09:30)(gemmazione basata sul Subject)
    • Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Accordi con Partner
      • Re: Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Accordi con Partner > NO
    • Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Aggiornamenti Software
      • Re: Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief > Aggiornamenti Software > OK(gemmazioni basate sul Body)
    • Re: "Cliente XYZQ" > "Commessa 123" > OdG Team Brief (01/09|09:30) > Nuovo OdG(eventuale gemmazione di recap)

Nota bene: seppur l’ereditamento di “References” e “In-Reply-To” sia del tutto omesso da molti client WebmailGMail, ad esempio, consente di modificare un Subject in reply o forward, ma determinando una novazione… – è facile osservare come già un Subject ben codificato permetta contemporaneamente di:

  • Predisporre filtri permanenti e/o fare estemporanee ricerche basate, in maniera implicitamente gerarchica“Cliente XYZQ” > “Commessa 123» rileverà messaggi differenti da «“Cliente XYZQ” > “Commessa 234», e così procedendo…), sul Subject;
  • Poter emulare la medesima operazione, ma “a colpo d’occhio” (Visual Pattern Recognition), su un elenco di messaggi, ad esempio la “Posta in Arrivo” e la “Posta Inviata“, visibili in una singola schermata – purché non si sia affetti da deficit visivi (ad es. di campo visivo) tali da essere di norma costretti a leggere riga per riga, o quasi…

In sintesi, quantomeno l’archiviazione in cartelle e sotto-cartelle, quella automatica così come quella manuale, godrà di sotanziali benefici in termini di tempo impiegato – e non sprecato…

Ridondanza dei contenuti + novazione del Subject

Per comprendere appieno il (potenziale) significato (…) di un messaggio all’interno della comunicazione in ambito organizzativo potrebbe essere utile fare un parallelismo con i sistemi di Ticketing che poco per volta stiamo abituandoci ad utilizzare per segnalare guasti e disservizi ed ottenerne la soluzione, e che, non a caso, sfruttano lo stesso concetto di threading, sia che li si impieghi da interfaccia (e.g. Web) sia che se ne ricevano notifiche via email:

  1. Tizio effettua una segnalazione di guasto, seguendo, ma non necessariamente, una procedura guidata:
    • Guasto specifico/singolo (alcuni sistemi consentono esclusivamente questo tipo di segnalazione, imponendo all’utente la cd. “apertura” di più ticket…) classificabile nelle casistiche previste;
    • Guasto multiplo: lista di guasti specifici.
  2. Il sistema la registra ciascuna segnalazione attribuendole uno specifico IDentificativo, inoltrando una notifica di ricezione a Tizio, e la le smista agli operatori di supporto disponibili nonché in base alla classificazione del guasto;
  3. Un operatore viene assegnato alla ciascuna segnalazione ed il sistema notifica a Tizio questa “presa in carico“;
  4. La Ciascuna segnalazione viene processata dall’operatore in…caricato, eventualmente mettendosi in contatto per Tizio per ulteriori informazioni;
  5. A Tizio viene notificata la risoluzione…
    • Totale (i.e. guasto singolo);
    • Parziale (i.e. in guasti multipli), eventualmente predisponendo per l’apertura di nuovi ticket – così, “loop-ando” (…), nuovamente al punto 1 fino alla soluzione di tutti i guasti/disservizi…

    …da parte del sistema o dell’operatore, facendo passare lo status del ticket (segnalazione) da “aperto” a “chiuso“.

Così come un ticketaperto” (segnalato) va anche “chiuso” (risolto), ugualmente il task (attività, singola o multiple) tipicamente contenuto/aperto in un “Ordine di Servizio” inviato da un superiore in gerarchia, ma anche da un Cliente – il primo, secondo diversi approcci organizzativi, andrebbe considerato fra i tanticlienti interni” all’organizzazione… –, va eseguito/chiuso da qualcuno: una o più persone… Supporre che la comunicazione in ambito organizzativo, mediata da qualsiasi “artefatto digital-cognitivo“, differisca tanto da succitato parallelismo non solo è riduttivo rispetto alle intenzioni dei tecnocrati che negli ultimi 40-50 anni vi si sono dedicati – plausibilmente cum grano salis, ovverosia anche con un’approfondita analisi dei requisiti (operativi)… – ma è anche puraavulsione dal contesto“… Trastullarsi, nella fattispecie, con l’idea che uno scambio di email in ambito organizzativo costituisca, aldilà della percepita minore o maggiore formalità del medium, solamente una variante” della comunicazione a voce, con tutte le sue dispersività, è, d’altro canto, assai sciatto. I contenuti di un’email inviata o ricevuta, in virtù della loro strutturabilità – si pensi, ad es., ad un “OdG” (“Ordine del Giorno“) per una riunione, condiviso fra convocante e convocati –, costituiscono essi stessi un artefatto cognitivo, che si distingue dal parlato non solo per asincronicità ma anche per (maggiore) strumentalità, iniziando dalla tutt’altro che banale opportunità di replicare con le cd. “citazioni in linea” (“Inline Quoting“)…

Quando è legittimo novare un Subject

In conclusione…

Tra i molti referenti all’interno di un’organizzazione mia storica cliente ce n’è uno che è proprio un “campione” di ridondanza e confusione: nova sistematicamente qualsiasi messaggio, col risultato che praticamente nessuno, né dei suoi colleghi né dei miei eventuali collaboratori, riesce a capire con tempestività e precisione quali siano i “predecessori” delle sue comunicazioni; nel tempo le conseguenze di un singolo individuo “fuori fase” rispetto agli altri partecipanti hanno causato ripristini successivi a variazioni in corso d’opera, dilatamenti dei tempi di consegna, lievitazioni dei costi ed immancabili tensioni, per non parlare della complessità delle ricognizioni ex post (i.e. project review). L’unica soluzione, presa dal cliente dopo ripetute segnalazioni provenienti da più parti, è stata quella di relegarlo ad un ruolo secondario da cui non è più possibile nuocere alla produttività del gruppo di lavoro.

Se da un lato è difficile accorgersi di star usando nel modo più efficiente ed efficace il threading dall’altro è piuttosto facile rilevare se e/o quando – e pertanto anche con chi! – ciò non accade. Ecco alcuni sintomi da sondare:

  • Pur soddisfacendo il requisito – uno dei fondamentali, specie in caso di alta eterogeneità delle varie corrispondenze (ad es. più clienti, più commesse)..! – di una generale buona codifica (ad es. «“Cliente XYZQ” > “Commessa 123”») avviando una ricerca (basata sulla suddetta codifica)…
     
    • …si ottiene una quantità di risultati non attendibile, tipicamente in vistoso eccesso rispetto alla salienza del tema
    • …e, magari contemporaneamente, latitano i messaggi con prefissi automatici di Reply (Re:/Ri:) e Forward (Fw:/I:)…
    • …e magari, sempre contemporaneamente, salta all’occhio una cospicua reiterazione di Subject, uguali o comunque non abbastanza differenti fra loro da renderli immediatamente distinguibili
    • …ed infine, entrando nel merito del Body di ciascun messaggio dal Subject poco distinguibile da altri, non è possibile rilevare differenze nei contenuti sufficientemente significanti da rendere preferibile, e quindi legittima, una novazione.

    Di converso, soddisfatto a livello quasi ideale il requisito della codifica – in ogni (nuovo) Subject, ad esempio, si riescono a far coesistere vari identificativi” condivisi (specifici task e sub-task di progetto e/o di sviluppo di prodotto, aree/divisioni e ruoli organizzativi coinvolti, precisi requisiti e deliverables, …) –, ci si dovrebbe poter attendere che nei risultati di un’analoga ricerca la stragrande maggioranza delle corrispondenze (umane) sia sovrapponibile ai thread (digitali) e che (i Subject di) questi, a loro volta, possano essere sovrapponibili alle definiteglobalmente e/o contestualmente… – WBS ABS (Work Breakdown Structure, Activity Breakdown Structure) ed OBS (Organization Breakdown Structure), magari con la minor quantità di reiterazioni (novazioni).
     

  • Se non sussistono, non dico una precisa policy aziendale sulla codifica dei Subject, ma nemmeno delle indicazioni “general-generiche” e la questione è lasciata alla buona volontà – o mero senso di auto-organizzazione – del singolo magari sarà rilevabile un occasionale rispetto spontaneo del threading, ma lo stesso non potrà comportare una concreta agevolazione nell’incorniciamento e perimetrazione (rapidi) delle corrispondenze se non fortuitamente – laddove dovrebbe essere programmatico! –, con queste probabili conseguenze:
     
    • Diventa inevitabile l’archiviazione manuale (in cartelle/etichette) dei messaggi sin dal loro arrivo, giacché ciascun messaggio, quandanche avesse un Subject decente in termini di riconoscibilità dell’argomento trattato, se non trattato immediatamente rischierebbe presto di confondersi fra gli altri nella “Posta in Arrivo“, rendendone così più ardua una successiva identificazione.
    • Un’eventuale ricerca fra i messaggi dovrebbe essere necessariamente fatta pensando ai Body e non ai Subject, e nondimeno l’aleatorietà dei risultati sarebbe ulteriormente aggravata dalla accidentalità nella presenza di thread fra gli stessi sotto forma di raggruppamenti di messaggi.
    • Ad un certo punto si sviluppa naturalmente una prassi per cui, al di là degli specifici contenuti dei Body, diventa eccessivamente saliente l’ordine di arrivo dei messaggi. Per mittenti e destinatari ciò può significare, quando va bene, di dover effettuare (molteplici) ricognizioni su una quantità a priori non definibile – in quanto verosimilmente di frequente avulsa dai reply e forward tipici del threading – di messaggi precedenti già solo per farsi un’idea di quante siano le corrispondenze e quale sia l’evoluzione cronologica (∴organizzativa) di ciascun argomento trattatovi…
    • …; quando va male può succedere che mittenti e destinatari – o peggio: solo una delle controparti! – assumano un approccio tale per cui, pure in caso di corrispondenze piuttosto articolate, vengono considerati solo i messaggi ricevuti od inviati più di recente, col consistente rischio di perdersene dei pezzi, a sua volta foriero di omissioni di variabile gravità (e.g. penali contrattuali). Contenere tale rischio adottando ultronee politiche interne di (ulteriore) ricapitolazione degli avanzamenti (recap) attraverso messaggi aggiuntivi, documenti o persino ri-materializzando la comunicazione con (una sovrabbondanza di) interazioni de visu (incontri, riunioni) non fa che inficiare ancora di più la produttività dei partecipanti.

     

  • La mancata consuetudine all’inline quoting nei reply e forward, tipica dei thread sin dai tempi di Usenet per spezzettare i singoli messaggi ricevuti (entro il dato thread!) nei loro differenti sotto-temi replicando nel dettaglio di ciascuno di questi, sovente si coniuga con un eccesso di cd. “Top Posting (risposta omnicomprensiva sopra il messaggio originale) o “Bottom Posting” (risposta sotto il messaggio), ed oltre a dare un (errato) priming – chiamiamolo suggerimento – ad una preferenza per le novazioni, magari dei singoli succitati sotto-temi, rispetto alle gemmazioni di questi (sempre entro il dato thread!), sussista o meno una prassi (formale, informale – vedi sopra) nella codifica dei Subject, è già di per sé abbastanza sintomatica:
     
    • La frequente omnicomprensività delle repliche in top posting è nemica giurata della specificità e della chiarezza – salvo che chi risponde non sia un drago della dialettica e soprattutto che abbia tempo (da sprecare) per darne sistematica prova… –, generando così rumore se la corrispondenza, invece, fosse invero densa di specifici punti (temi e sotto-temi). In tal caso questo tipo di replica, pur sempre preferibile ad una novazione tout court, andrebbe impiegato soltanto se la stessa è molto breve, persino telegrafica e comunque di sintesi rispetto al messaggio cui si riferisce.
    • È, per i destinatari, difficile distinguere prontamente se una replica in top posting costituisca un recap oppure una chiusura da parte del mittente – e qui, oltre al rumore, potrebbero ingenerarsi persino (dispersive!) tensioni emotive fra i partecipanti. Discorso diametralmente opposto, invece, per gli inoltri (forward) in top posting, che per questi fungono da cappello introduttivo e nei quali, al contrario, un eccessivo inlining potrebbe risultare fuorviante.
    • L’inlining comunica pariteticità fra i partecipanti alla corrispondenza agevolando un contesto di libero scambio dialogico, a sua volta fondamentale nella più proficua disamina su ciascun tema e soprattutto nella precoce emersione di fraintendimenti (ad es. obiettivi e requisiti progettuali) e lacune informative, laddove un indiscriminato top posting, suggerendo disparità (di funzioni, ruoli, etc.) fra i partecipanti, rischia di porre eccessiva attenzione alla trasmissione in sé – ad es. l’apertura e chiusura di un task di un ordine di servizio (vedi sopra) – e meno ai contenuti della stessa, favorendo: reticenza a fornire opinioni discordanti, magari utili, informazioni inedite e dubbi; ulteriore tentazione a novare (un Subject per ciascun task e sub-task, ad esempio); ulteriore stimolo a ricorrere ad interazioni “faccia a faccia, onde supplire alle probabili carenze informative (eccessi di implicitità vs carenze di esplicitità) dello scritto…

In buona sintesi raggiungere l’optimum, ad esempio, nel caso di una commessa aziendale, una quantità a priori prevedibile di thread – in quanto discendente da precise e condivise guideline operative e policy – entro i quali la stessa viene pienamente rappresentata, non è che utopia, distopicamente tanto soporifera da risultare, infine, facilmente controproducente! D’altro canto una sana protensione verso di esso, qualunque precipua declinazione locale questo abbia, semplifica e snellisce le ordinarie impellenze di condivisione e collaborazione, con indubbio vantaggio di contenimento dei tempi complessivi: quale che sia il grado di “dispersione” (remotizzazione) dei membri di un team, dal de visu fino ai chilometri di distanza gli uni dagli altri, ciascuno deve dimostrarvisi quantomeno abbastanza proficiente

Prospettive: Intelligenza Artificiale e Threading