generale

robot pointing on a wall

L’impatto dell’AI sui Team di lavoro

/in , , , /by

Se proviamo a cercare un po’ di articoli sull’Intelligenza Artificiale e il lavoro, la quasi totalità si concentra su elementi di produzione/efficienza: come creare più post, come fare più contenuti, come sviluppare nuovi agent… e anche su LinkedIn si parla della velocità di realizzazione di ricerche, contenuti e di come grazie all’AI possiamo fare più cose a parità di tempo.

Proviamo ad andare oltre questo elemento superficiale e considerare gli effetti sui Team di lavoro facendo delle ipotesi su quello che potrebbe accadere ai gruppi di lavoro in vari ambiti (soprattutto marketing, comunicazione, prodotto) partendo da alcune premesse di carattere generale.

Read more: L’impatto dell’AI sui Team di lavoro

Quattro premesse

Prima di parlare dell’impatto dell’AI sui team di lavoro sono opportune quattro premesse:

  • premessa sui contenuti: alla velocità di produzione non corrisponde un aumento di spazi;
  • premessa sulle attività: l’efficienza sulla produzione sposta l’attenzione su decisioni e priorità;
  • premessa sulle competenze: l’AI è una protesi magnificativa che richiede una doppia componente;
  • premessa sull’organizzazione: con poca chiarezza i benefici sono quasi nulli.

Premessa sui contenuti

Grazie all’evoluzione dell’Intelligenza Artificiale oggi è possibile fare più contenuti? Assolutamente sì, ma è un elemento che non dovrebbe monopolizzare le conversazioni: aumentare la produzione di contenuti non è un obiettivo, ma potrebbe essere uno strumento funzionale al raggiungimento di alcuni obiettivi, anche se improbabile.

Perché improbabile? Banalmente per tre ragioni:

  1. Non è aumentata la quantità di tempo disponibile: abbiamo sempre 24 ore in una giornata, non abbiamo più tempo rispetto al passato e mediamente gli Italiani passano quasi due ore al giorno sui Social Media (con una leggera flessione anno su anno);
  2. Non sono aumentati gli spazi disponibili: se il tempo speso sulle piattaforme non aumenta, lo spazio disponibile per attirare l’attenzione delle persone rimane lo stesso.
  3. Non c’è causalità tra quantità e risultati: aumentare la quantità di post (o di budget) non si traduce necessariamente in un aumento dei risultati funzionali al raggiungimento degli obiettivi.

Se guardiamo qualche infografica ci sono già più contenuti che tempo, spazio e persone per guardarli.

Per cui riflettere su come automatizzare o aumentare la produzione di contenuti non è particolarmente interessante, bisognerebbe chiedersi sempre di più quali contenuti ha senso produrre.

Approfondimenti sul contesto:

Premessa sulle attività

Se il focus dell’AI è “produrre di più” ci stiamo concentrando sulla realizzazione di attività (o task) e anche questo non dovrebbe essere un obiettivo: se infatti ci concentriamo sul “fare cose” nel giro di alcuni mesi saremo nuovamente saturi e al punto di partenza, nuovamente stressati e con backlog lunghissimi.

There’s always more to build than we have time or resources to build – always

Le attività dovrebbero essere focalizzare sul ridurre la quantità di lavoro massimizzando l’impatto delle poche attività rimaste

Minimize output, and maximize outcome and impact

Le due frasi di Jeff Patton riportando l’attenzione a un tema che potremmo definire strategico: se oggi il costo e il tempo di realizzazione (operatività) si compattano, il focus e l’attenzione si spostano su altri elementi più decisionali sia in positivo (cosa fare) che negativo (cosa scegliere di non fare).

Approfondimenti sul contesto:

Premessa sulle competenze

L’Intelligenza Artificiale consente alle persone di migliorare le proprie competenze e velocizzare alcune attività sempre da un punto di vista operativo. Migliorare non significa creare o sostituire: da questo punto di vista l’AI è una protesi estensiva e in alcuni casi magnificativa 1.

Rimanendo vicini a questo concetto e riprendendo il concetto di persona T-Shaped o π-Shaped (alcune competenze orizzontali e alcune verticali) ecco che l’AI consente di aumentare le capacità senza però diventare sostitutiva (anche se questo è uno dei desideri non detti da parte di certe organizzazioni o manager).

Realtà vs Desiderio

Con l’AI lavoratori e lavoratrici assumono una forma che ricorda più una V, ma non consente di estendere le proprie competenze (che chiameremo, come nell’immagine “non skill”).

Una maggior autonomia delle persone, grazie all’aumento delle capacità, richiede anche una riflessione sul ruolo della persona e sul lavoro stesso. Se infatti in passato la Job Description o il Ruolo erano molto legati alla componente operativa, con la perdita di rilevanza di questa ecco che i confini tra alcune professioni tendono a perdere di senso.

Possiamo dare concretezza a questo concetto con un esempio: il lavoro dello Scrittore. Se tradizionalmente siamo abituati a sottolineare la componente pratica (una persona che di lavoro scrive), nel momento in cui l’Intelligenza Artificiale riduce/semplifica la parte operativa, la dimensione del lavoro si sposta verso la parte creativa (intesa come capacità di sviluppare soluzioni emergenti).

Ad aumentare di rilevanza sono ambito e capacità di affrontare una serie di nuove sfide in contesti ignoti.

Approfondimenti sul contesto:

Premessa sull’organizzazione

In un contesto dove il contesto VUCA si rinforza (dato che abbiamo un aumento di accelerazione e volatilità, incertezza, complessità e ambiguità) possiamo proporre una nuova metafora vicina al mondo ittico:

Pesce organizzato mangia pesce disorganizzato

Se infatti conosciamo già due frasi piuttosto famose – Pesce grande mangia pesce piccolo e pesce veloce mangia il pesce lento – oggi la componente organizzativa (non intesa come rigidità, ma come conoscenza del lavoro e capacità evolutiva) consente di massimizzare il valore delle nuove tecnologie.

Uno dei limiti che sta emergendo nell’implementazione di soluzioni legata all’AI è infatti il debito semantico, ovvero l’ambiguità su processi, ruoli, pratiche, struttura.

Nel momento in cui si vogliono ottimizzare i processi, è necessario che questi siano noti, nel momento in cui si vuole sostituire una persona, è necessario avere chiaro il ruolo etc. etc

La presenza di poca chiarezza sta generando la diffusione dei due/tre use case nell’adozione dell’AI su larga scala, con un focus sempre sulle attività e poco sugli impatti.

Approfondimenti sul contesto:

Team e AI

Sulla base di queste premesse che compongono il contesto è possibile andare a immaginare quali potrebbero essere gli impatti sui team di lavoro.

Come Team di Lavoro, appoggiandoci a Scrum, intendiamo un gruppo di persone (superiore a due e inferiore a 10) in possesso delle competenze e capacità necessarie per trasformare delle idee in incrementi.

Nel team consideriamo una eventuale presenza di Agenti AI (entità autonome o semi-autonome basata su intelligenza artificiale, sviluppata per perseguire uno o più obiettivi specifici all’interno di un ambiente definito).

Riduzione del numero di membri

Uno dei primi effetti potenziali sui team è la riduzione del numero di persone necessarie per produrre lo stesso output.

L’AI consente a singoli individui di svolgere in autonomia attività che in precedenza richiedevano il contributo di più specialisti e quindi un numero minore di persone è ora in grado di coprire un ventaglio di attività più ampio.

Aspetti positivi

  • Possibilità di lavorare su un numero limitato di attività
  • Efficienza operativa
  • Riduzione dei costi fissi
  • Comunicazione più semplice

Aspetti negativi

  • Aumento delle dipendenze esterne per mancanza di skill “profonde”
  • Incremento della superficialità data la riduzione dei punti di vista
  • Crescita della fragilità dato che ci sono meno ridondanze

Domanda chiave: come garantire resilienza in team più piccoli?

Team super-frazionati

Onde evitare dipendenze esterne, manteniamo un numero di persone simile al passato, ma questo team viene diviso su più progetti essendo aumentata la capacità produttiva. Ogni membro del team lavora su più stream e i team diventano sovra-estesi e multi-funzionali.

Questo è il modello adottato (spesso) nei contesti che vogliono massimizzare l’output senza ridisegnare l’organizzazione.

Aspetti positivi

  • Riduzione dei costi
  • Sviluppo di skill trasversali
  • Flessibilità cross-progetto

Aspetti negativi

  • Riduzione del deep work e aumento del content switching
  • Aumento dei costi organizzativi
  • Diminuzione della qualità per priorità concorrenti

Domanda chiave: come evitare la dispersione nei team frammentati?

Singolo Team multiprogetto

Una ulteriore possibilità è rappresentata da team stabili, strutturati, che operano contemporaneamente su più iniziative, mantenendo un’identità e una coesione interna.

A differenza dei team super-frazionati, in cui le singole persone sono coinvolte in progetti diversi spesso in contesti separati, qui il team agisce come unità unica e coerente, anche se lavora su stream paralleli. È una forma organizzativa che tenta di massimizzare l’efficienza senza perdere la cultura di team.

Aspetti positivi

  • Efficienza operativa
  • Resilienza e cultura di team
  • Diminuzione degli overhead rispetto a team separati

Aspetti negativi

  • Ambiguità decisionale
  • Potenziali carichi disomogenei
  • Dipendenza da figure di coordinamento

Domanda chiave: come generare impatto e non solo output?

TAAS – Plug and Play

Un ulteriore scenario è rappresentato da team modulari temporanei, attivati su richiesta in base a una specifica esigenza progettuale. Parliamo di team costruiti con logica Plug & Play o Team As A Service (TAAS): composti da persone interne, collaboratori esterni e, in alcuni casi, agenti AI, con l’obiettivo di rispondere rapidamente a bisogni puntuali (campagne, prodotti sperimentali, redesign, validazioni rapide).

A differenza dei team stabili o funzionali, questi team hanno una durata limitata e una missione chiara: vengono creati e sciolti in modo flessibile, spesso operando su processi già standardizzati o documentati.

Questo modello consente alle organizzazioni di reagire in modo rapido a opportunità o cambiamenti, senza dover riconfigurare l’intera struttura e richiede una forte maturità progettuale, chiarezza di obiettivi e un sistema di gestione del lavoro che consenta l’integrazione veloce dei team temporanei nel flusso complessivo.

Aspetti positivi

  • Massima flessibilità nella risposta ai bisogni progettuali
  • Attivazione rapida di competenze e capacità
  • Scalabilità abilitata da AI e standard operativi
  • Maggiore controllo sui costi variabili rispetto a team interni fissi

Aspetti negativi

  • Rischio di perdita di continuità e conoscenza progettuale
  • Maggiori costi cognitivi per integrazione e onboarding
  • Possibile disconnessione rispetto alla cultura e ai processi interni
  • Dipendenza da documentazione ben fatta e processi formalizzati

Domanda chiave: Come mantenere coerenza e qualità in team temporanei attivati su richiesta?

Note:

  1. In Kant e l’Ornitorinco U. Eco definisce le protesi in tre macro-categorie: sostitutive (fanno quello che il corpo faceva, ma non fa più) estensive ( prolungano l’azione naturale del corpo) e magnificative (qualcosa che qualcosa che va oltre l’estensione) ↩
green hedge maze

It’s Not Me, It’s You (Gantt)

/in , /by

Quasi sempre, quando sono in agenzia o in azienda per consulenze o formazioni su processi e gestione dei progetti, nelle prime sessioni ci sono delle domande sui Gantt di progetto, famigerati strumenti di previsione progettuale. Dopo un minimo di discussione, prendiamo il Gantt e lo buttiamo con la consapevolezza che è uno strumento estremamente interessante, ma che probabilmente non fa al caso nostro. Per capire il motivo andiamo con ordine.

Read more: It’s Not Me, It’s You (Gantt)

Un minimo di Storia del Gantt

Il Gantt è uno strumento che ci consente di rappresentare la pianificazione di un progetto usando barre colorate: avremo quindi delle attività (sulla sinistra) con descrizione, durata, etc. e la visualizzazione su un arco temporale delle attività (sulla destra) con la possibilità di vedere dove siamo oggi (la linea tratteggiata in viola) nell’evoluzione del progetto dall’inizio alla fine.

Questo celebre strumento prende il nome dal suo creatore, Henry Laurence Gantt, che lo introdusse nel 1916 1. Questo strumento, così come altre pratiche di Project Management dei primi del ‘900, si basa sull’idea di poter spezzettare il lavoro in più parti e, misurando il tempo necessario per ogni attività, poter fare delle valutazioni e delle previsioni. Primo piccolo problema di questo strumento: il principio di visualizzare e gestire le risorse nasce con la schiavitù e l’esigenza di monitorare il lavoro 2 e nasce quindi con uno specifico contesto in mente: è uno strumento di controllo.

Al netto delle problematiche culturali (superabili), rimane una criticità: il contesto per cui è pensato questo strumento (e i necessari passaggi per costruirlo).

Il contesto del Gantt

Una delle caratteristiche della visione progettuale (e manageriale) della prima metà del novecento è la staticità del contesto aziendale.

  • se le attività e i mercati non cambiano nel tempo (o cambiano molto molto lentamente) ha perfettamente senso creare ex-ante una lista di tutto quello che c’è da fare;
  • se le attività non cambiano nel tempo e sono note è assolutamente possibile, alla luce dell’esperienza passato, poter prevedere il futuro del progetto.

Considerando questi due elementi appaiono sia i punti di forza che gli eventuali limiti di questo strumento che nasce per gestire una certa classe di progetti caratterizzati da predicibilità e scarso tasso di cambiamento (sia a livello di cambiamento dei requisiti che di contesto).

  • Siamo in un contesto statico? Può essere un buono strumento.
  • Siamo in un contesto dinamico? Può non essere un buono strumento.

Trovandomi a gestire normalmente progetti legati al marketing o ai prodotti digitali il mio contesto è tutto tranne che statico: potremmo scoprire che una certa funzionalità non è più necessaria, che un competitor ha lanciato qualcosa al quale dobbiamo rispondere, che un nuovo aggiornamento richiede lo sviluppo di nuovi content… oltretutto lavoro value driven e non guidato dal piano.

Tra piani e valore

Come detto poco sopra, il Gantt ha una caratteristica molto interessante: il fatto di distribuire su un arco temporale l’elenco dettagliato delle attività, la famigerata WBS (Word Breakdown Structure). Se abbiamo una bella Project Charter e una WBS strutturata ecco che traslare le attività su un calendario calcolando l’effort (la quantità di lavoro necessaria per realizzare l’attività) diventa semplice e se abbiamo uno strumento per allocare le persone e tenendo conto dei calendari possiamo calcolare l’elapsed 3.

Abbiamo messo in fila diversi “se” di cui due molto grandi: elenco delle attività completo e risorse disponibili. Quante volte abbiamo queste informazioni all’inizio del progetto?

Senza queste informazioni diventa molto difficile organizzare il tutto e poter avere uno strumento che ci aiuti nella gestione del progetto e nella visualizzazione del suo avanzamento. È come voler capire dove siamo durante un viaggio con una mappa disegnata secoli prima: ti mancano i riferimenti, fai fatica a capire dove ti trovi e di conseguenza quanto manca.

Inoltre, come è anche giusto che sia, se mi dai un piano il mio obiettivo è seguire quel piano e fare in modo che ci siano meno deviazioni possibili (ogni deviazione sono costi che si alzano e ritardi che si accumulano) 4. Personalmente io vivo questo approccio abbastanza male, perché ho l’idea che nel fare i progetti si debba cercare la massimizzazione del valore (e non litigare sulle CR).

Sì, ma…

Piero, come sei fiscale! Abbiamo capito che nel Gantt ci dovrebbe essere come minimo nome del task, inizio, fine, durata, predecessore e successore… ma noi non lo facciamo, facciamo una cosa più semplice e per noi funziona!

Certo che funziona, solamente non state usando un Gantt e non c’è nulla di male in questo, ma le parole sono importanti e vorrei citare un bel passaggio della Scrum Guide

 While implementing only parts of Scrum is possible, the result is not Scrum.

La frase citata è delicata, ma molto importante per comprendere e valutare le attività per quello che sono: “giochiamo a calcio, ma quando vuoi puoi anche prenderla con le mani” è un bellissimo sport/gioco, ma non è Calcio.

“Facciamo Scrum, ma senza lo Scrum Master, il PO è il PM, non facciamo la Sprint Review” stai facendo una cosa probabilmente interessante, ma non è Scrum. Allo stesso modo se non stai inserendo gli elementi base di un Gantt in un Gantt non stai facendo un Gantt (lapalissiano).

Al posto del Gantt

Se il Gantt funziona molto bene in certi contesti (per cui continuerò a sostenere la validità di questo strumento) bisogna tenere conto che in altre situazione potrebbe non offrire vantaggi significativi o avere dei costi di aggiornamento/mantenimento così alti da renderlo sub-ottimale: per fortuna non è l’unico strumento esistente.

In molti casi per le agenzie o i dipartimenti marketing una meravigliosa Timeline può essere più che sufficiente: invece di scendere nel dettaglio rappresentiamo la sequenza di milestone e task in ordine cronologico 5.

Se vogliamo rimanere ad alto livello, ma fornendo maggiori informazioni ecco che la Roadmap può essere un altro strumento particolarmente interessante da esplorare. È un documento più legato alla strategia (per cui ci vogliono traguardi e obiettivi) che però contiene informazioni utili legate anche agli Stakeholder e ad altre informazioni.

Niente più dettagli!

Evviva: Piero ha detto che non dobbiamo più dettagliare le attività.

Momento, momento, momento: non dobbiamo dettagliarle nella Timeline o nella Roadmap, ma questo non significa che le attività non vadano specificate insieme (valutando insieme al team quale sia il giusto livello di granularità).

Magari lo facciamo durante lo Sprint Planning (se usiamo Scrum) o in una riunione simile se usiamo un sistema Ibrido, ma per evitare ambiguità e incertezza, abbiamo bisogno di trasparenza e confronto.

Per cui Gantt mi spiace, non sei tu, sono io: i miei progetti cambiano troppo velocemente e io ho bisogno di qualcosa che mi porti valore. Speri rimarremo amici e ogni tanto potremo ancora parlare.

Note:

  1. Datare esattamente l’introduzione di uno strumento non è mail facile, tendenzialmente possiamo essere confidenti dicendo inizio del 20° secolo, o 1910-1916 volendo restringere il periodo. Il 1916 è la data di pubblicazione del libro “Work, Wages, and Profits” in cui ne parla esplicitamente: fonte – PMI ↩
  2. Da questo punto di vista lo stesso Gantt aveva identificato alcune pratiche premianti legate al superamento delle attività base, una sorta di MBO ante litteram, riprese dalle pratiche di gestione delle piantagioni di cotone: qui un piccolo approfondimento ↩
  3. Ovviamente anche in questo caso è necessario un tool e anche se si possono disegnare cose interessanti con Excel non è per me lo strumento giusto per una gestione completa tramite Gantt ↩
  4. Se vogliamo questa è una delle grandi diatribe tra Project Manager, persone che si occupano di gestire progetti che vengono assegnati, e Product Manager, persone che si impegnano per il successo di un prodotto. Sono due mondi vicini, ma non perfettamente sovrapposti e tendenzialmente il mondo Agile è più spostato sulle idee di Product Management ↩
  5. Lo so che molti hanno sempre chiamato Gantt la timeline… ↩
person wearing red hoodie

Qualche triste verità sui tool di Project Management (AI Inclusa)

/in , /by

Quando insegno Project Management o lavoro in agenzia sull’ottimizzazione della gestione dei progetti arriva sempre una domanda “ma secondo te cambiando/introducendo un tool risolviamo i problemi?” con una mia risposta di base che è “gli strumenti sono importanti, ma non sperate siano la Soluzione”.

Read more
an artist s illustration of artificial intelligence ai this image depicts ai safety research to prevent its misuse and encourage beneficial uses it was created by khyati trehan as part

L’AI tra Hype e Processi

/in , , /by

Ogni giorno una persona che lavora nel digital si alza e sa che sarà uscito un nuovo tool di AI, che i tool già esistenti avranno presentato una nuova funzionalità e che ci saranno innumerevoli post su LinkedIn che raccontano di quanto sia interessante l’ultimo Ai Agent (con tanto di “commenta e chiedi il contatto per ricevere” che ha sostituito le landing page con i whitepaper).

Se da un lato abbiamo tanto hype con alte aspettative, dall’altro c’è una domanda frequente a cui è difficile dare una risposta immediata: “come possiamo ottenere dei benefici nella nostra azienda con queste incredibili AI?”. La risposta dovrebbe essere semplice, ma non lo è per una ragione estremamente banale: spesso mancano le basi, ma andiamo con ordine.

Read more
person holding clear light bulb

Qualche spunto per parlare di Smart Working

/in , /by

Come per ogni tema anche lo Smart Working è diventato oggetto di tifoseria: c’è la fazione che dice “impossibile non farlo: solo da remoto” e l’altra all’opposto “giammai: si lavora solo in presenza”. Credo che entrambe le fazioni estremiste siano nel torto e che si debba considerare lo Smart Working (inteso in senso esteso) come uno strumento da usare all’interno di una strategia precisa.

Read more: Qualche spunto per parlare di Smart Working

Strumenti e strategia

In queste primissime righe abbiamo già dato alcuni spunti importanti che consentono di valutare meglio il discorso.

Innanzitutto lo Smart Working è uno strumento e, come tale, ha aspetti positivi, negativi, punti di forza, debolezza, aree di applicazione etc. La stessa cosa si può dire del lavoro in Presenza o degli approcci Ibridi.

Se questa modalità di lavoro è uno strumento deve essere scelta sulla base di una strategia aziendale (che non può essere “non mi piace non vedere le persone”), di un contesto specifico e di una valutazione appropriata. Su questo punto a me piace una frase

The essence of strategy is choosing what not to do

Michael Porter

Non è scritto da nessuna parte che di debba lavorare in presenza o che si debba lavorare da remoto: è fondamentale essere consapevoli delle possibilità e decidere cosa perseguire e cosa invece non fare. Andiamo ora a parlare nello specifico di questi due strumenti: il lavoro in presenza e il lavoro da remoto.

Tra lavoro in presenza e remoto

Ci sono ormai numerose esperienze di successo di lavoro da remoto: come non citare Automattic (dato che siamo su WordPress), Zapier, Gitlab come casi noti (ma la lista è estremamente lunga). Abbiamo un sacco di bibliografia e indicazioni su come funziona, come realizzarla e i problemi. D’altra parte conosciamo anche molto bene il lavoro in presenza, i suoi punti di forza e le sue criticità.

Prima di passare a un’analisi di dettaglio possiamo dire che il lavoro da remoto richiede una maggior organizzazione da parte dei team (e in generale dell’impresa) mentre il lavoro in presenza consente oggi una maggior velocità per i team. Altro aspetto generale è che per le imprese che nascono “full remote” l’organizzazione è più semplice rispetto alle aziende che devono poi transitare dalla presenza al remoto.

Considerazioni sul lavoro da remoto

Come già detto è possibile avere imprese che funzionano bene e che hanno una buona cultura con persone che lavorano da remoto.

Tra i vantaggi di questa modalità sicuramente abbiamo :

  • un abbattimento delle barriere geografiche con la possibilità di attingere a persone e talenti di tutto il mondo;
  • una gestione del lavoro per obiettivi più che per tempo con un conseguente elasticità per la gestione del tempo lavorativo/personale;
  • un risparmio sui tempi di trasporto e un minor uso dei mezzi di trasporto.

Tra gli svantaggi possiamo invece elencare come elementi principali:

  • necessità di una forte organizzazione (struttura, processi e strumenti) per tutte le attività;
  • comunicazione e feedback meno veloci rispetto alla presenza;
  • la cultura è costruita e non avviene casualmente;
  • selezionare persone con una predisposizione adatta a questa modalità;
  • potenziali differenze tra dipendenti in aziende che hanno produzione e amministrazione;
  • gestione di contratti e stipendi in varie parti del mondo.

Questi sono alcuni elementi generali non collegati a disfunzioni (o antipattern) particolari come “da casa mi interrompono meno e lavoro di più”. In questo caso non è un problema del lavoro in presenza, ma delle modalità con le quali è stato implementato il lavoro in ufficio (tant’è che alcune persone negli ultimi anni hanno iniziato a vivere all’interno di Zoom o Webex o altri sistemi perché si è tentato di replicare quella modalità).

L’elemento più interessante (e complicato) del lavoro da remoto è sicuramente la sua organizzazione: un lavoro asincrono (che non richiede la presenza degli interlocutori in contemporanea) richiede la definizione delle modalità di lavoro e una organizzazione dei processi molto maggiore rispetto a quanto sia necessario per un lavoro in presenza (che è mediamente sincrono). Da questo punto c’è un grosso lavoro sulle modalità di lavoro e la definizione di cosa può essere sincrono e cosa asincrono.

Sul punto della comunicazione e feedback riprendiamo per un secondo i principi dell’Agile Manifesto

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Principles behind the Agile Manifesto

Non si dice che è l’unico modo, ma che è il più efficiente: in presenza posso verificare e parlare con il collega immediatamente, da remoto è più strutturato. Se guardiamo le esperienze positive sul remote working tutti, tutti tutti dicono che è necessario aumentare la comunicazione e strutturarla: da questo punto di vista è richiesta una maggior disciplina alle persone che fanno parte di queste imprese (anche per evitare di lavorare sempre).

Mediamente le imprese che fanno remote hanno anche degli incontri periodici (di team, nazionali o globali) per andare a sviluppare alcuni elementi (es. conoscenza dei colleghi, sviluppo di progetti specifici etc.).

Un altro punto interessante e da considerare è che si può fare remote working solo per coloro che si occupano di elementi immateriali (tendenzialmente knowledge e creative worker): una buona fetta di lavori non possono essere fatti da remoto banalmente perché richiedono macchinari specifici, linee di produzione etc. Questo ovviamente rischia di creare dei dipendenti di serie A e serie B con una serie di criticità da gestire.

Considerazioni sul lavoro in presenza

Più o meno conosciamo tutti questa modalità: c’è un ufficio, un orario, un team e si va avanti così.

Anche qui guardiamo quali sono i vantaggi:

  • disponibilità istantanea dei colleghi e delle informazioni (supermercato informativo);
  • postazione di lavoro che rispetta tutte le normative e i canoni;
  • gestione semplice degli orari lavorativi;
  • apprendimento per esposizione con feedback istantaneo.

Guardiamo gli aspetti negativi sono quattro:

  • possibilità di attingere solo a persone geograficamente prossime;
  • gestione del lavoro in modalità prevalentemente sincrona;
  • valutazione del lavoro su base oraria e non a performance;
  • il supermercato informativo porta a ignorare processi, strumenti, regole e struttura.

Gli aspetti negativi sembrano meno rispetto a quelli elencati per il lavoro da remoto, ma l’ultimo punto è un elefante perché è quello che mediamente porta a tutte le disfunzioni negli uffici. Il “management by crisis”, “lavoro da casa perché qui è un casino”, “hai due minuti?” e in generale molto dell’odio verso il lavoro in presenza nascono da questo ultimo punto.

Se infatti l’impresa remota ha la necessità di darsi processi, strumenti, disciplina etc. questi aspetti mediamente nel lavoro in presenza non vengono sempre strutturati poiché è molto facile sopperire alla presenza:

Non c’è documentazione? Vai a chiedere al collega. Non sai come si fa una cosa? Vai a chiedere alla collega.

Credo che la maggior parte delle persone che hanno lavorato in ufficio abbiano vissuto esperienze di questo tipo: alla mancanza di organizzazione si sopperisce interrompendo o comunicando.

Da questo punto di vista è interessante notare come spesso si creda che sia più facile creare cultura aziendale in presenza, ma in mancanza di processi, regole etc. la cultura aziendale diventa “la disorganizzazione”, cosa che come abbiamo visto non può accadere da remoto (per i vincoli di questa modalità).

Dovendo però ricordare un aspetto positivo dei team co-locati (visto in negativo nel lavoro da remoto) ovviamente abbiamo la velocità di feedback e comunicazione (ammesso che vi siano dei processi e non mero casino). Pensiamo agli ultimi due anni: ancora oggi si perdono minuti su minuti per webcam che non funzionano, “scusa sei in muto”, “spengo il video perché sono in macchina”.

E le modalità ibride? In questi anni ho lavorato con tanti team e ho visto le reazioni e i commenti di altri colleghi: mediamente con le attività ibride ti viene voglia di colpire i partecipanti con il PMBOK® (sesta edizione) banalmente perché nella maggior parte dei casi, invece di prendere il meglio dei due mondi, si prende il peggio.

La modalità ibrida richiede l’organizzazione del lavoro da remoto (e la sua disciplina) unita alla pianificazione delle attività in presenza: ci sono casi in cui funziona (ed è bellissimo lavorare con quei team), altri in cui ti viene voglia di tornare in presenza.

Un confronto

Andiamo ora a confrontare alcuni degli aspetti elencati in precedenza per vedere le differenze tra le due modalità (ovviamente su elementi generali e non su approcci specifici)

Lavoro in presenzaLavoro da remoto
Modalità di lavoroPrevalentemente in maniera sincronaPrevalentemente in maniera asincrona
PersonePosso attingere alle persone e ai talenti che geograficamente sono vicine (o aggiungere i costi di spostamento)Posso lavorare con le persone di miglior talento indipendentemente da dove vivono
FormazioneLe persone apprendono per prossimità con i colleghi e con sessioni ad hocFormazione individuale e con sessioni ad hoc
InnovazioneMaggior possibilità di contaminazione anche casualeStrutturata e con processi
SpaziLa postazione di lavoro è uguale per tutti e rispetta alcune norme di baseOgni persona organizza o sceglie i suoi spazi
ComunicazioneRisorse immediatamente disponibili con massima bandaStrutturata e con processi e con banda limitata
FeedbackPossibilità di interazione e verifica istantaneaStrutturata e con processi
Tipologia di lavoroMateriale e immaterialeImmateriale
Gestione del tempoOrganizzata secondo orari specificiLibertà di organizzazione

Cosa fare?

Ogni impresa, a seconda del suo contesto e della sua strategia, sceglierà la modalità che consente di raggiungere al meglio i suoi obiettivi anche passando per approcci ibridi (che risultano ancora più complesse per certi versi).

Prendiamo Tesla per analizzare un caso. Recentemente si è parlato della scelta di tornare in presenza da parte di Musk: a cosa si deve questa decisione? Non a un capriccio, ma ad una precisa visione: Tesla ha come elemento cardine la velocità. Da questo elemento a cascata la scelta degli strumenti e di conseguenza un ritorno alla presenza: essendoci un prodotto fisico (materiale) al quale si legano anche componenti software (immateriali) e volendo implementare dei feedback istantanei, la scelta è quasi obbligata. Su questo punto per chi vuole approfondire c’è una intervista a Joe Justice su Agile FM

Attenzione poiché questa strategia si applica solamente in quel contesto che ha una organizzazione molto particolare e una visione specifica: non è possibile prenderla come unica soluzione e pensare di poterla implementare in altre realtà analoghe. Come sempre è molto più complesso.

Per cui oggi non è tanto una discussione su “lavoriamo da remoto” o “lavoriamo in presenza”, ma come sempre tornano alcune domande chiave: cosa vogliamo fare? come vogliamo farlo? qual è la soluzione ottimale? Sulla base delle risposte scegliere.

assorted medals

Perché prendere certificazioni come PM?

/in , /by

Durante i corsi e le consulenze in agenzia, puntualmente la domanda arriva: perché prendi le certificazioni sul Project Management e soprattutto sull’Agile e Scrum? Servono davvero? Qui le mie considerazioni assolutamente personali partendo da una panoramica sulle certificazioni, a cosa servono e perché le prendo.

Read more
person using macbook air on table

Lavorare da remoto o in ufficio?

/in , /by

In questo periodo si è parlato tanto di lavoro “non in un ufficio”: è stato affrontato il tema giuslavoristico, si è parlato del fatto che spesso non è “Smart” o “Agile” ma semplicemente la continuazione dell’ufficio, ma con altri mezzi (riprendendo un classico di von Clausewitz 1, ma secondo me c’è stata poca attenzione a cosa voglia dire per i team e in generale per l’organizzazione sui progetti.

Un picco di consapevolezza

L’epidemia che si è abbattuta in Italia a partire da febbraio 2020 ha costretto molte persone ad accettare che molte attività potessero essere fatte da casa (o in qualunque altro luogo) e che l’idea che l’ufficio sia il luogo della produzione sia un retaggio del passato (o quantomeno valido realmente solo per alcuni settori o per alcune professioni molto specifiche).

Prima non era possibile?

Assolutamente sì: ricordo le mie prime giornate di lavoro da remoto ancora in Hagakure nel 2010 e sicuramente anche prima qualcosa era possibile fare. Tecnologicamente parlando sono almeno 10 anni che è possibile lavorare “fuori” dall’ufficio.

Ci sono anche innumerevoli casi di successo o case studies 2: i primi tre che mi vengono in mente sono Automattic (remota fin dalle origini nel 2005), Zapier (remota anch’essa fin dalle origini nel 2011) e Buffer (sempre nel 2011 e autrice di alcuni esperimenti non indifferenti come gli Open Salaries nel 2013). E sono le prime che mi vengono in mente: probabilmente ne esistono altre centinaia (anche in Italia, non solo all’estero).

Ma quindi, se era possibile da un punto di vista tecnologico e vi erano già degli apripista, come mai si è spesso tirato il freno a mano? Il fatto che qualcosa sia possibile non lo rende automaticamente credibile e fattibile.

Tra la teoria e la pratica, in teoria non c’è differenza. In pratica c’è

Yogi Berra

Dovendo trovare una ragione profonda banalmente perché è più complesso, soprattutto su tre assi (focalizzandoci sempre sul team): organizzazione, comunicazione e più in generale cultura, tre aspetti profondamente interconnessi.

Due considerazioni sull’ufficio

Vi siete mai chiesti per quale motivo i team di eSport si allenino nella stessa stanza? Si può benissimo giocare a LoL da qualunque parte del mondo, quindi perché riunirsi nello stesso spazio?

Molto semplicemente per fare in modo che una serie di persone (gruppo) diventino una squadra (team) e per fare questo è più efficace ed efficiente farlo nello stesso spazio.

Vorrei sottolineare più efficace e più efficiente: si può fare anche da remoto, ma potrebbe volerci molto più tempo e i risultati potrebbero non essere gli stessi.

Se prendiamo ad esempio anche la filosofia Agile vi è sempre stato una grande attenzione alla co-locazione del team di lavoro che emerge ad esempio nei principi:

  • […]work together daily[…]
  • […]give them the environment[…]
  • […]face-to-face conversation[…]

Perché anche qui questa insistenza? Perché l’idea alla base di questa modalità di lavoro troviamo, tra le altre cose, la riduzione dell’incertezza portando un gruppo di persone a diventare un team di lavoro. Avere tutte le persone nella stessa stanza, per esempio, rende più semplici gli scambi comunicativi, in caso di dubbio il collega è disponibile per un confronto, tutti sono costantemente allineati 3.

Tornando però al team che condivide gli stessi spazi, il fatto di abitare un medesimo luogo facilita (qualora siano presenti le giuste condizioni) i passaggi all’interno del ciclo di Tuckman ed è quindi, teoricamente possibile, arrivare rapidamente al Performing.

Da remoto questo passaggio non è impossibile, ma è decisamente più difficile (in quanto la socialità è ridotta e le dinamiche//interazioni di gruppo ridotte, cosa che può portare a una minor visibilità sulle criticità tra i membri del team).

Se l’ufficio è da un lato quindi un supermercato informativo 24/7 (se ti serve qualcosa c’è il collega a disposizione), ecco che questo può nascondere tutta una serie di inefficienze che rendono difficile il lavoro da remoto:

  • se una persona è visibile posso “controllare” che sia al computer;
  • se un processo non è definito posso chiedere rapidamente a un collega;
  • se ho un dubbio su qualcosa posso alzare la testa e parlare con un altro membro del team.

Partiamo dall’ultimo punto: la comunicazione, croce e delizia del lavoro in ufficio. Spesso si ritiene il lavoro da casa più produttivo perché sono meno presenti le interruzioni (posto che lavorare da casa con dei bambini annulla immediatamente questa condizione), ma solo perché stiamo nascondendo il vero problema ovvero la mancanza di rispetto e una comunicazione strutturata.

La mancanza di una comunicazione completa, chiara, corretta e tempestiva rende molto, molto, molto difficile lavorare da remoto: ricevere informazioni incomplete, poco chiare, parziali e a poco tempestive (la classica opportunità delle 17.58 da consegnare la mattina dopo) è diffusa in ufficio perché, purtroppo, è più semplice da gestire.

Parlando sempre di semplicità e gestione, possiamo risalire e parlare di processi: se non c’è chiarezza su come fare le cose, l’ufficio è straordinario nel nascondere le inefficienze (tanto, come abbiamo detto poco sopra, basta interrompere un collega per trovare la risposta).

Sapere a chi rivolgersi (che è banalmente la mappatura di ruoli/competenze/capacità) e sapere cosa fare senza dover chiedere ogni volta a qualcuno sperando abbia la risposta da remoto rende molto, molto, molto difficile lavorare.

Infine, se non sono chiari i processi, se non ho organizzato il lavoro per modalità sincrone e asincrone, ecco che la valutazione della famigerata produttività difficilmente si potrà basare sui risultati, ma solo sulle ore passate davanti allo schermo.

Per cui, se l’azienda non è organizzata (o non vuole farlo) lavorare da remoto diventa quasi un incubo ed è, ancora una volta, un tema di cultura aziendale.

Ufficio vs Remoto

Se abbiamo superato la dicotomia libro vs e-book (l’abbiamo superata vero?) comprendendo che sono due strumenti differenti che rispondono a esigenze differenti, ecco che anche la contrapposizione dei luoghi perde di senso. Ovviamente bisogna valutare punti di forza e debolezza delle soluzioni, il contesto nel quale si è inseriti e trovare il bilanciamento ottimale.

Anche in Agile, lavorare da remoto è possibile, introduce delle criticità, ma è fattibile: la cosa che credo difficile è pensare che la capacità di creare legami con gli altri non sia fondamentale per lavorare su problemi complessi o su prodotti nuovi, il passaggio da Knowledge Worker a Creative Worker.

Dal mio punto di vista credo che l’ufficio da luogo di produzione sia (o stia diventando) il luogo della socialità: è il posto in cui crei legami con i colleghi, crei cultura aziendale, definisci alcune attività che da remoto sarebbero più complicate (le parole sono importanti: non sono impossibili, solo più complicate). Non è un caso se anche le aziende che da anni sono full remote abbiano una/due volte l’anno degli incontri globali dove tutti i membri dell’azienda si possono incontrare e socializzare.

Infine credo comunque che per generare valore nel modo più rapido con un team (per cui se si lavora individualmente cade tutto), il fatto di condividere uno spazio minimo due volte alla settimana sia, al momento, irrinunciabile. Se invece esistono già dei processi, una buona cultura aziendale, siamo vicini al performing come team, una inception di progetto in presenza (in quanto allargata anche ad altri Stakeholder non parte del team), e poi si può lavorare anche in full remote.

Se però pensiamo di prendere un ufficio e, senza cambiamenti, senza lavoro accessorio, portarlo magicamente da remoto il risultato è uno solo

Nel frattempo altre imprese e altri ecosistemi avranno fatto passi da gigante

Note:

  1. Autore del testo “Della Guerra“ ↩
  2. Quando si diffonderà anche qui la consapevolezza che la Case History è, nel mondo anglosassone, la storia clinica sarà sempre troppo tardi ↩
  3. Ci sarebbe molto altro da dire sulla condivisione degli spazi e la collaborazione, ma prendiamo per un secondo molti uffici italiani: in quanti ci sono dei team e in quanti invece ci sono delle persone che lavorano da sole all’interno della stessa area funzionale? ↩
four rock formation

Lean Presentation Design

/in , , /by

Personalmente adoro fare presentazioni 1 e recentemente, per il Freelance Day, io e Chiara abbiamo fatto una presentazione a quattro mani e, quando metti un PM con una PO succedono cose straordinarie che meritano di essere raccontate.

Il lavoro sulle slide (la parte facile)

Dopo aver concordato Argomento, Titolo e Descrizione del nostro intervento con Chiara ci siamo messi all’opera: dal momento che avremmo lavorato a distanza abbiamo optato per Google Slides (evitando in questo modo rimpalli di email e lavorando su un’unica versione condivisa).

Ci siamo dati appuntamento e in (video) presenza abbiamo inserito la copertina fornita dagli organizzatori e scelto un tema, tra quelli disponibili, con elementi che ricordassero lo stile. Poi, prima di lavorare sui contenuti, usando la prima slide e il sito, abbiamo personalizzato il tema (colori e font).

Definito lo stile era giunta l’ora dei contenuti: tempo a disposizione (25-27 minuti), scaletta, organizzazione dei temi, divisione delle slide.

A questo punto ci siamo dati appuntamento alla settimana successiva: avremmo lavorato in autonomia sulle slide e rifatto il punto. Concordata la data del prossimo incontro ognuno ha organizzato il proprio lavoro.

Martedì altro momento insieme e revisione leggera sui contenuti, ordine e qualche prima considerazione su cosa aggiungere, togliere. Definite le attività ognuno avrebbe lavorato in autonomia (provando le sue parti) e il lunedì successivo avremmo fatto una prova.

Altro incontro e prima prova: considerazioni, prendiamo qualche appunto, siamo leggermente sopra con i tempi, ripensiamo qualcosa. Appuntamento alla settimana successiva con i cronometri alla mano e slide già consegnate (5 giorni di anticipo sulle richieste degli organizzatori).

Ultimo test, 25 minuti, ci siamo: ci diamo appuntamento a sabato 24, all’una un test per il video, alle 16.30 speech, 27 minuti

Cosa c’è dietro (la parte difficile)

Io lavoro come consulente in Project Management, Chiara è una Professional Organizer: probabilmente usiamo strumenti diversi, ma condividiamo alcuni principi e soprattutto un metodo, anzi una filosofia di lavoro.

Organizzare il lavoro

Le nostre slide non hanno visto una “webex permanente”, un lavoro costantemente in presenza, ma una valutazione di cosa ci serviva (per lavorare meglio) in presenza (time boxed 2 e quando invece lavorare in maniera indipendente.

Una rappresentazione visiva è la seguente: un’alternanza di lavoro sincrono e asincrono

Nei momenti “live” lavoravamo contemporaneamente condividendo delle attività che richiedevano la presenza di entrambi, negli altri momenti ognuno dei due aveva una serie di attività da realizzare secondo la propria organizzazione, i propri impegni e le proprie preferenze (ad esempio io sono un Gufo e Chiara un’Allodola).

Sembra quasi Lavoro Agile (e non una brutta copia in digitale del lavoro in ufficio).

Metodo e disciplina

Questo modo di organizzare, fare le prove, non ce lo siamo imposto: per me e Chiara è stato naturale organizzare le attività perché fa parte, come dicevo prima, della nostra filosofia di lavoro, del modo in cui gestiamo le attività.

La buona notizia è che non siamo nati così (per lo meno io), ma che con allenamento, pratica e disciplina abbiamo trovato delle soluzioni che ci consentono di lavorare meglio. Al tempo stesso questa è anche la cattiva notizia perché non esiste uno strumento magico che consenta di gestire bene le cose: bisogna darsi un metodo di lavoro. Un metodo che non deve essere solo nostro, ma condiviso anche con le persone con le quali stiamo lavorando (immaginate se io avessi voluto lavorare in un modo e Chiara in un altro, disastro).

Come ogni gruppo di lavoro dovrebbe fare, abbiamo definito prima strumenti, pratiche e appuntamenti per definire il nostro framework (o WoW, Ways Of Working) e poi abbiamo semplicemente lavorato.

“Eh, ma per un intervento di 27 minuti, tra sincrono e asincrono, sommando le attività avete lavorato 8 ore”

Sì. E su questa osservazione due considerazioni:

  1. può sembrare tanto tempo 3, ma il nostro lavoro è stato lineare e non c’è stato nemmeno un rework, una correzione. Nessun momento in cui ci siamo detti “aspetta il template è sbagliato – il font non è quello giusto – no rifacciamo tutta la scaletta”. Nella maggior parte dei progetti si parte molto veloci e poi ci si perde: si pensa che a correre subito si sia più veloci, ma alla fine, quando si misurano i risultati, si vede che sul lungo periodo l’organizzazione paga;
  2. siamo consapevoli di quanto tempo ci abbiamo messo e dei passi cha abbiamo fatto. Molto spesso, tornando all’esempio di sopra, chi parte senza una strategia, non sapendo come lavorerà o come organizzerà il proprio lavoro farà più fatica a misurare e sapete qual è uno dei grandi segreti per far quadrare i budget di progetto? Non rendicontare. Ma credo che misurare aiuti non a controllare persone e colleghi, ma a lavorare meglio: come direbbe Mando: This is the way.

Anche qui, molto Agili.

La qualità non si aggiunge

E arriviamo alla parte finale, quella più importante e difficile, ovvero quella di filosofia (che da anche il titolo al post). C’è un elemento chiave nel modo di lavorare che abbiamo deciso di utilizzare io e Chiara che possiamo riportare agli approcci Lean e Agile

Build a culture of stopping to fix problems, to get quality right the first time.

The Toyota Way – Principio n° 5

Continuous attention to technical excellence and good design enhances agility.

Agile Manifesto – Principio n°9

Nel fare le slide, le prove, non siamo mai tornati indietro: quando si verificava un problema ci siamo fermati e abbiamo identificato la soluzione: quante volte negli uffici si finisce una presentazione e ci si accorge che il logo è vecchio? che i titoli non sono allineati? che il template non è giusto e cambiandolo bisogna rimpaginare?

La qualità di un prodotto, in questo caso una presentazione, è qualcosa che abbiamo inserito come caratteristica del nostro lavoro, non come qualcosa che è stato aggiunto dopo.

Pensiamo a quanto tempo sprechiamo nel correggere lavori fatti in maniera approssimativa e quanto invece sarebbe più interessante e produttivo lavorare meglio e dedicare quel tempo (che è finito) ad altre riflessioni e ad altre attività (anche a supporto dei colleghi).

Questo modo di lavorare, un po’ alla volta, diventa un’abitudine e difficilmente riuscirai a farne a meno per il semplice fatto che si lavora meglio e a nessuno piace lavorare male (soprattutto quando scopri quanto sia diverso e positivo il diverso approccio).

Cultura aziendale

Fare le cose giuste al primo tentativo è difficile, ma se iniziamo a non passare cose mal fatte, a fermarci qualche minuto in più, sul lungo periodo lavoreremo tutti meglio.

Non si tratta di un cambiamento facile perché questa è una tematica di cultura aziendale e non tanto di metodo o di strumenti. Se ci pensiamo bene molte scelte lavorative discendono direttamente dallo stile manageriale dell’impresa e dalla cultura dell’azieda 4A volte poi viene mitigato o ingigantito dall’attitudine personale/ref].

In un’azienda dove ti guadano male se ti fermi per una riflessione, chi si prederà del tempo per correggere? in un luogo dove “non c’è tempo” chi si sentirà autorizzato a prendersi qualche minuto in più? Se non viene data importanza al lavoro dei colleghi, quanti si prenderanno il tempo per ascoltare? E così via.

Ovviamente, per me, è un discorso molto profondo perché ha a che fare con i valori profondi di un’impresa e soprattutto con il rispetto degli altri: lasciare “le slide” in ordine in modo che qualcun altro possa lavorare meglio è rispetto per l’altro, non un semplice vezzo.

Come ha detto Deming: la qualità non si aggiunge, buona o cattiva è già nel prodotto. Per cui lavoriamo bene 🙂

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.

W. Edwards Deming

Note:

  1. Sulla mia vetrina Amazon – facendo gli esperimenti da Influencer – ho creato una sezione dedicata ai miei libri preferiti sul tema del Presentation Design ↩
  2. È il concetto che un’attività/evento può occupare al massimo un determinato tempo ↩
  3. Ecco, pensare che fare le presentazioni fatte bene sia un lavoro semplice è una grande illusione: richiedono tanto tempo per essere pensate e realizzate. Ovvio, lavorare male è sempre possibile, ma non è il modo in cui credo sia giusto lavorare ↩
hotrod die cast model on board

Il debito tecnico nel Marketing

/in , /by

Tra le varie metafore presenti in ambito IT e sviluppo progetti, una delle mie preferite in ambito Agile è quella del “Debito Tecnico”, ovvero l’idea che si possa prendere in prestito della “qualità”, ma con un costo.

La metafora del debito tecnico è abbastanza semplice da comprendere, un po’ più difficile da quantificare: per alcuni progetti in ambito Comunicazione e Marketing risulta più facile, per altri il valore numero è una chimera. Vediamo quindi che cos’è, caratteristiche interessanti e alcuni modi per dargli un valore.

Il concetto di debito tecnico

Il concetto di Debito Tecnico è una metafora sviluppata da Ward Cunningham che illustra in maniera semplice come alcune decisioni (consapevoli o meno) sui progetti producano impatti a breve, medio e lungo periodo.

Partiamo da un progetto che possiamo sintetizzare come un percorso da un punto di partenza a un obiettivo (ovviamente non è una retta: i progetti perfettamente programmabili e senza cambiamenti in ambito IT, Marketing, Comunicazione e Digital esistono solo nel vuoto e in assenza di attrito)

Durante il nostro progetto possiamo ipotizzare una serie di attività e di momenti decisionali: sappiamo anche che esiste un percorso ottimale o che, in base a delle best practice, delle good practice o solamente per la nostra esperienza, sarebbe meglio seguire una determinata strada o fare tutta una serie di attività prima di passare alla successiva.

Se però decidiamo (o ci dimentichiamo) di saltare un passaggio, ecco che introduciamo una deviazione più o meno marcata dal nostro percorso ottimale.

Facciamo l’esempio classico della deviazione nella fase iniziale

Non facciamo un incontro con il cliente per definire bene i need iniziamo subito a lavorare

Non c’è tempo per scrivere un brief o fare una riunione: te lo dico a voce mentre stai lavorando su altro

L’Account 1

Ovviamente possiamo avere cambiamenti e modifiche in qualunque fase

Facciamo anche qui qualche esempio

  • La sicurezza dl progetto è un problema che affronteremo poi più avanti;
  • Backup e analytics sono temi importanti che gestiremo al momento opportuno;
  • fare un’analisi di mercato non serve perché sappiamo già che funziona;
  • invitiamo un sacco di persone a mettere like ai post e alla pagina, penseremo dopo a delle custom audience;
  • L’analisi delle url per mappare correttamente i redirect li faremo con calma quando saremo in una fase più avanzata del progetto.

Tutte queste sono delle scelte che potrebbero avere un impatto nel futuro del progetto ed ecco entrare il concetto di Debito Tecnico e soprattutto, tra gli altri elementi, quello di interesse.

Più tempo passerà alla restituzione del debito, maggiore sarà la quota d’interesse che dovremo pagare

Un esempio di facile comprensione può essere legato allo sviluppo di un sito di WordPress:

  • non attivo un servizio di backup: più tempo passa più il costo per sistemare un sito che è cresciuto nel tempo potrebbe essere importante
  • valuto solamente l’acquisto del sito e non la manutenzione successiva: più passa il tempo più è probabile che si rompa qualcosa

Penso che la metafora sia abbastanza chiara a questo punto e che si possano fare esempi in tutti i campi. Prendo ad esempio anche alla cinofilia (settore al quale sono esposto indirettamente): non faccio un corso di socializzazione al cucciolo (breve) e mi ritrovo con il dover fare un corso/percorso di rieducazione (lungo) al cane adulto.

Considerazioni sul Debito Tecnico

Tipologie e origine

Il Debito Tecnico è un elemento che tende a comparire naturalmente all’interno dei progetti di Marketing e Comunicazione principalmente per quattro motivi:

  • velocità: non c’è tempo per fare le cose (o crediamo non ci sia)
  • inconsapevolezza: è un progetto che non abbiamo mai gestito
  • sfiducia: non ci fidiamo di collaboratori o colleghi che ci danno pareri sul loro settore
  • ottimismo: crediamo che non dovremo mai fare i conti con certe scelte (esempio classico: la sicurezza)

Date queste premesse vediamo che ci sono varie possibilità e che normalmente vengono distribuite su una matrice con quattro settori

Per cui il Debito Tecnico non è un elemento che introduciamo sempre volontariamente nel progetto, ma possono esserci casi (legati all’ignoranza sul progetto o che sia qualcosa di completamente nuovo) dove scopriamo solo alla fine che sarebbe stato meglio fare qualcosa in maniera completamente diversa.

Gestione

Posto che credo non sia possibile fare un progetto totalmente privo di Debito Tecnico, l’elemento più importante a mio avviso è la consapevolezza di questo elemento. Possiamo infatti introdurre del Debito Tecnico nel nostro progetto di Comunicazione: il Project Manager o Il Team possono infatti valutare che, dati alcuni vincoli o alcune esigenze, sia possibile fare delle scelte sub-ottimali e introdurre qualcosa di non-perfetto o non-ideale e che si dovranno gestire le conseguenze in un secondo momento.

L’aspetto più importante dal mio punto di vista è quindi rendere visibile questo Debito che abbiamo introdotto e ripagarlo il prima possibile.

Il fatto di essere infatti consapevoli non è sufficiente, dobbiamo ricordarci che la quota d’interesse per ripagare questo debito aumenterà nel tempo. Qualora infatti si aspetti troppo si possono verificare due situazioni molto pericolose:

  • il costo del debito è così alto che il team non può più dedicarsi alla gestione delle attività ordinarie o allo sviluppo di nuovi elementi, ma deve lavorare tutto il tempo solamente per ripagare gli interessi di alcune scelte fatte in passato;
  • il costo del debito è così alto che è più conveniente buttare tutto e ricominciare da capo piuttosto che mettersi a risolvere il problema sul prodotto, campagna o attività.

Stima e valore

Una delle maggiori complessità quando si parla di Debito Tecnico in ambito MarCom è dare un valore al Debito (consapevole) che stiamo introducendo: quanto ci costerà di interessi? Questa è spesso la domanda che viene fatta ed è soprattutto l’alibi che viene utilizzata per introdurlo (“la state facendo troppo grossa: dopotutto con una giornata di lavoro riuscirete a risolverlo. Dimostratemi il contrario“).

In questi anni ho visto che su alcuni progetti di comunicazione è difficile dare una quantificazione del valore del debito introdotto mentre su altri si può dare una stima legata a vari parametri: non esiste infatti la sola misura economica, ma ci possono essere anche altri Performance Indicator.

Ad esempio sul tema siti e traffico possiamo ipotizzare che un’errata migrazione di un sito possa portare a un calo del traffico tra il 40% e il 70%. Dati questi valori posso calcolare l’impatto di una determinata scelta e in alcuni casi cercare anche una quantificazione economica (rapporto visite/acquisti o visit/lead e quanto andrò a perdere).

Oppure posso vedere il CTR medio delle landing del settore nel quale sto operando e, usando questo valore come ottimale, ipotizziamo che con con delle scelte sub-ottimali raggiungeremo un valore inferiore e i nostri interessi saranno legati a questo delta.

Sull’aspetto di quantificazione al momento ho visto che si tratta più di esperienza o di un minimo di ricerca: riduciamo l’incertezza epistemica (quello che sappiamo degli eventi).

L’ideale è diventare più bravi e ricordarsi di misurarlo a valle della modifica (ci segniamo il momento in cui abbiamo introdotto del debito e scopriremo a distanza di giorni, settimane e mesi quanto ci è costato).

E quindi?

Il Debito Tecnico non è necessariamente “il male”, ma qualcosa che si spera sempre di introdurre in maniera consapevole e prudente. Gestire infatti progetti significa anche questo, gestire dei rischi (che possono essere poi gestiti o dal PM o dal Team): questi sono elementi naturali e ineliminabili dai progetti, bisogna capire come affrontarli. Fare del debito e restituirlo gradualmente può essere anche una scelta ottimale e totalmente gestibile all’interno di un team o di una campagna.

Da questo punto di vista anche nelle Retrospettive possiamo dedicare alcuni di questi eventi o parte di essi alla discussione sul debito tecnico: se si tratta di una stima dobbiamo infatti verificare se le nostre ipotesi erano corrette o se possiamo imparare qualcosa.

Anche con il debito l’ideale è migliorare costantemente nella sua gestione così come in tutti gli aspetti che riguardano i nostri team e i nostri progetti.

Note:

  1. Continuiamo sui cliché d’agenzia ricordandoci che il ruolo di account è molto delicato e importante ↩
Diritto d'autore: redwall / 123RF Archivio Fotografico

È possibile usare Scrum in Agenzia e nel Marketing?

/in , /by

In questi anni ho avuto la possibilità di fare tanta consulenza sulla gestione dei progetti di comunicazione e marketing ad agenzie e aziende di varie dimensioni e una delle domande ricorrenti è: possiamo usare Scrum in questi contesti?

NOTA: questo post è un po’ più tecnico del solito e presuppone la conoscenza di Scrum. In estrema sintesi Scrum è uno dei framework 1 della metodologia Agile. Esistono vari video: questa breve introduzione su YouTube può servire ad avere un’idea generale

La risposta breve? No.

Scrum è un framework fantastico che consente di fare “miracoli” quando è:

  1. nel giusto contesto
  2. è utilizzato per fare quello che è stato creato per fare.

Per cui: sei un’agenzia/unit/area alla quale è stato affidato lo sviluppo di un prodotto e sei struttuato con competenze intern[un team multidisciplinare composto da tre/sette persone con poche dipendenze esterne[/ref]e in grado di sviluppare il prodotto? Vai con Scrum.

  • Sei un’agenzia alla quale affidano soprattutto progetti?
  • Sei un “area” composta da una sola persona?

Se hai risposto di sì a una di queste due domande non è un problema: molto probabilmente sei una PMI come buona parte delle realtà italiane 2 (spesso più P che M) e difficilmente riuscirai a usare Scrum in purezza.

Nelle grandi realtà (Aziende o Agenzie) è possibile usare Scrum creando dei team multidisciplinari stabili e pescando all’occorrenza dagli SME (Subject Matter Espert) per realizzare dei prodotti (che possiamo anche intendere come “grandi progetti”).

E nel resto del mondo? Condannati ai Gantt? No 3, ma per arrivarci bisogna fare il giro lungo.

Alcuni limiti di Scrum all’interno del contesto agenzia e mondo MarCom

Dal mio punto di vista ci sono tre limiti di contesto (che rappresentano i punti di forza del framework da un altro punto di vista):

Prodotto-centrico

Se prendiamo la Scrum Guide si vede che il focus è lo sviluppo di “prodotti”:

  • Scrum is a framework for developing, delivering, and sustaining complex products.
  • A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
  • has been used to manage work on complex products
  • Product Owner
  • Product Backlog
  • Product Increment

La discussione non è tra l’approccio a Prodotto (focus valore) vs approccio Progetto (focus piano), ma sulla tipologia di attività che vengono fatte in agenzia e nei piccoli uffici comunicazione.

Molte agenzie oggi si specializzano in alcune verticalità: social ads, google ads, CRO, SEO, e-commerce management, reputation, automation, content creation, influencer marketing etc. che rappresentano porzioni di attività più strutturate.

Stiamo quindi descrivendo un contesto di attività lontano da quello di Scrum strutturato più per progetti.

Prescrittivo

Anche se è un modello leggero da localizzare su ogni team, ci sono alcuni aspetti dai quali non puoi sfuggire e qui la criticità è legata alla dimensione e ai ruoli.

In Scrum ci sono tre ruoli con Product Owner (PO), Scrum Master (SM) e Developmen Team (DT) e a livello di dimensioni si dice che il Developmen Team è composto da tre-nove membri (o cinque più o meno due a seconda delle scuole di pensiero).

Adorando la separazione dei poteri nel diritto, credo che il bilanciamento tra i ruoli di PO, SM e DT sia geniale e, anche se è vero che SM e PO sono un ruolo e non una persona e nella Scrum Guide non si esclude che SM lavori allo sviluppo, personalmente nelle fasi iniziali credo che vadano identificare in persone diverse.

Purtroppo il Team tenderà a focalizzarsi sulla delivery e il PO Team perderà di vista il valore, lo SM Team le dinamiche: sono alcuni antipattern 4 già visti (così come quelli introdotti dallo SM che fa anche il PO #ancheno).

Per cui mediamente abbiamo bisogno di almeno tre persone più due che, come frequentemente viene fatto notare dall’italico imprenditore, “non producono e costano”. Oltretutto in molte realtà di dimensione ridotta risulta difficile avere abbastanza persone per riuscire ad avere un team “intero”

Mancando le persone e con un focus sui progetti anche il tema dei rituali tende a venire meno. Immaginate però di dire “non facciamo il daily Scrum”: probabilmente brucerete all’inferno degli Scrummisti.

Se perdiamo ruoli e rituali Scrum ha poco senso (mentre avere mindset Agile/Lean rimane fondamentale).

Team Dedicato e Cross Funzionale

Dal momento che parliamo di Prodotti, in Scrum il Development Team è focalizzato sullo sviluppo di una sola cosa (il Prodotto) in modo da velocizzare la realizzazione di incrementi e generare il maggior valore possibile nel più breve lasso di tempo. Per fare questo lo sviluppo è realizzato da un Team Cross funzionale che contiene tutte le competenze per trasformare gli elementi del Product Backlog in Product Increment: riducendo e limitando le dipendenze esterne il Team procede più veloce (non deve aspettare risposte dagli altri Silos: ha tutto all’interno e può correre velocemente e in autonomia).

  • E se lavoriamo a Progetti (come visto sopra) oltretutto dividendo il nostro tempo tra vari Progetti senza un focus esclusivo sul un Prodotto?
  • E se la realizzazione di alcuni progetti richiede una costante relazione con alcuni SME, ma senza il budget per averli a tempo pieno nel DT?

I due punti qui sopra sintetizzano bene lo scenario prevalente nel mondo delle Agenzie e degli Uffici Marketing e Comunicazione delle PMI: non potendo inserire a tempo pieno dei professionisti verticali si ricorre ai freelance (un modello che a me piace molto se inserito nel giusto contesto culturale, soprattutto in Cooperativa).

Per cui abbiamo anche alcune criticità legate a dimensioni, tipologie di attività e competenze/dipendenze.

Quindi niente Scrum per le Agenzie?

Prima di tutto distinguiamo tra Agile (mindset/filosofia) e Scrum (framework/metodo):

è possibile essere Agile senza usare Scrum ed è possibile non essere Agile usando Scrum

Anche se sembra un gioco di parole ricordiamo uno degli elementi più importanti: alla base di Agile ci sono dei principi e dei valori, quello che il Lean definisce nel suo triangolo come Filosofia: la gestione dei team e dei progetti appoggia e affonda le sue radici nella cultura aziendale, gli strumenti sono una conseguenza.

Usare quindi Scrum seguendo alla lettera (o in maniera molto molto vicina all’originale) è possibile solamente per realtà di dimensione ampie e che seguono lo sviluppo di prodotti o grandi campagne (partecipando quindi a tutto lo sviluppo e non solo ricevendo il compito da fare) e che vanno a sviluppare il giusto contesto.

E tutti gli altri? A mio avviso è necessario sviluppare un po’ di tailoring , ovvero creare qualcosa su misura (che per me è la vera risposta) e prendere Scrum modificandolo 5 senza arrivare a Scrumban. Questo dovrebbe essere l’approccio da seguire quando si cerca di adattare elementi nati nel software (e che ancora faticano a uscire dall’ambito IT/ICT) altrimenti il rischio è come quelli che cercando di usare il modello Spotify non essendo Spotify.

Un punto di partenza per Scrum in Agenzia

Un’agenzia ha una serie di Progetti (le lampadine) con dei Brief dettagliati 6 per clienti diversi: ognuno di questi progetti avrà una serie di attività (alcune ad alto valore, alcune più urgenti, altre ancora fumose etc. etc.).

Chi definisce le attività ad alto livello e le prioritizza cross-progetto? Il PO (che rimane il massimizzatore di valore in senso esteso) che le condivide con i vari DT durante lo Sprint Planning (che in Agenzia a mio avviso a un tempo di una/due settimane).

La parte di prioritizzazione e pianificazione è fondamentale perché è qui che cerchiamo di minimizzare i danni del contest switching e del lavoro su progetti multipli: invece di passare da un’attività all’altra, avendo lavorato bene con il PO, possiamo chiudere delle attività prima di passare alle successive.

In questo caso abbiamo quindi più DT, un solo PO e un solo SM (che rimane il massimizzatore della collaborazione in senso esteso).

Alla fine dello Sprint troviamo la Review e la Retrospettiva (in questo caso obbligatoria per tutti: manteniamo alcuni elementi prescrittivi di Scrum).

Per cui cui non cambiano:

  • pilastri (transparency, inspection, adaptation)
  • valori (commitment, courage, focus, openness, respect)
  • eventi (sprint planning, daily scrum, sprint review, sprint retrospective)
  • artefatti (Backlog, DOD, Increment)

I ruoli invece subiscono una leggera modifica a mio avviso soprattutto lato PO che si trova a dover dialogare con una maggior complessità rendendo il suo ruolo più complicato di quanto già non sia 7. Per quanto riguarda invece lo Scrum Master si trova ad avere un maggior lavoro all’inizio che poi dovrebbe calare e consentirgli di passare il ruolo all’interno dei team o di cambiare attività e diventare un nuovo PO.

Questa ovviamente è una delle possibili modifiche ed evoluzioni (ce ne sono anche un altro paio abbastanza interessanti). In azienda, pensando alle dimensioni ridotte, è invece necessario andare a sviluppare un modello leggermente diverso.

Ma noi lo facciamo già…

Eh, ma alla fine è avere un commerciale/account e noi lo facciamo già!

Il PO non è (solo) un Account/Commerciale e, ad esempio, non cambia deadline a caso, non chiede modifiche random, non interrompe durante lo Sprint (se esiste una pagina The Account Academy ci sarà un motivo) 8.

È una persona che lavora con lo SM e con il DT all’interno di un contesto culturale specifico.

Ma allora basta chiamare l’Account PO ed il gioco è fatto.

Anche qui: se fosse sufficiente cambiare il nome alle cose perché si modificassero le attività sarebbe facile, ma si tratta di un cambiamento più profondo ed è anche per questo che all’inizio ho parlato di un contesto e soprattutto di mindset/cultura.

Per cui, ritornando alla domanda iniziale, anche le agenzie possono usare Scrum? In purezza è dura: con un buon cambiamento culturale, di processi e modificando alcuni aspetti e adattandolo alla proprie esigenze sì.

Note:

  1. ne esistono anche altri: XP, FDD, DSDM. Su wikipedia ne trovi una carrellata https://it.wikipedia.org/wiki/Metodologia_agile. ↩
  2. Ricordiamo che il 92% delle imprese italiane sono PMI e non tutte lavorano in ambito software ↩
  3. . Posto che è possibile essere Agili anche usando il Gantt, possiamo anche vedere come implementare altre soluzioni un pelo più moderrne. Dire che è un problema di strumento è come pensare che basti implementare un Kanban per essere Lean ↩
  4. Un antipattern è un comportamento/soluzione all’apparenza corretto, ma che introduce più problemi e non risolve il problema ↩
  5. Per i puristi ovviamente questo potrebbe dire non fare Scrum ↩
  6. Senza Brief non si dovrebbe lavorare, mai ↩
  7. Spesso ho visto il ruolo di PO banalizzato pensando fosse un PM… è molto più di così ↩
  8. Come il PO spesso il ruolo del commerciale e dell’account è o sottovalutato o fatto molto molto male. È un ruolo chiave che andrebbe gestito al meglio. Quando ti trovi a lavorare con un Account che ha chiaro il suo ruolo e la sua relazione con il team è meraviglioso lavorare con lui/lei. Negli altri casi… diciamo meno. ↩