Analisi e riflessioni sul marketing

black and white color pencils on black and white background

Aristotele, logica e Intelligenza Artificiale

/in , , /by

Capita in ogni progetto (soprattutto digitale): arrivano le richieste con una soluzione dentro: le richieste non sono “abbiamo questo problema”, ma “vogliamo fare questa cosa”. Quando chiedi da dove viene quella certezza, la risposta è qualcosa come: “Ho visto come l’ha fatto un competitor” oppure “L’ho provato e funziona”.Quella certezza, quasi sempre, nasce da un’esposizione superficiale a qualcosa di complesso. E oggi quella esposizione è diventata più rapida, più convincente e più accessibile che mai.

Read more: Aristotele, logica e Intelligenza Artificiale

Nuovi problemi vecchi

Claude Design, l’ultimo strumento che ha alimentato il dibattito su AI e professioni creative, non ha inventato nulla di strutturalmente nuovo, ma ha reso più visibile una dinamica che esiste da quando esistono gli strumenti digitali:

abbassare la soglia di accesso a un dominio non equivale ad abbassare la soglia di competenza in quel dominio.

La differenza è che oggi quella soglia si abbassa in dieci minuti invece che in dieci mesi e questo cambia molto, ma non nel modo in cui il dibattito tende a descriverlo.

In mano a un designer, Claude Design fa quello che ogni buono strumento fa quando viene usato da chi ha conoscenza dichiarativa: accelera l’output e ne migliora la qualità.

Il designer sa cosa sta chiedendo, sa valutare quello che ottiene, sa quando il risultato è sbagliato anche se sembra convincente. Lo strumento moltiplica la competenza esistente.

In mano a un non-designer, fa qualcosa di diverso e altrettanto utile:

consente di effettuare iterazioni, di arrivare alla conversazione con l’altra persona con qualcosa in mano, non per sostituire quella conversazione, ma per renderla molto più produttiva.

Il collo di bottiglia

Per anni, la sperimentazione iniziale in qualsiasi progetto digitale aveva un costo (a volte nascosto) importante: richiedeva l’interazione tra persone diverse prima ancora che il lavoro reale iniziasse.

  • Volevi esplorare tre varianti di un’interfaccia? Serviva un designer.
  • Volevi capire se una soluzione era tecnicamente praticabile? Serviva uno sviluppatore.

Nel frattempo, chi aveva l’idea aspettava, il designer riceveva un brief vago, lo sviluppatore riceveva un wireframe sbagliato, e il ciclo ricominciava in una lunghissima partita a pong.

Quel ciclo ha un nome: fase di esplorazione 1 e aveva un costo che pochi mettevano a budget 2 perché non era visibile, distribuito nel tempo di tutte le persone coinvolte.

Watt Humphrey aveva descritto questo problema con una precisione che non ha perso nulla in trent’anni:

“For a new software system, the requirements will not be completely known until after the users have used it.”

3

L’incertezza sui requisiti non è cattiveria, non è incompetenza, ma è la natura del problema. Le persone arrivano con idee confuse non perché non si siano impegnate, ma perché un requisito diventa noto solo quando viene testato. Prima di quel momento, quello che abbiamo non è un requisito: è un’ipotesi.

Agile e Lean Startup hanno portato questa idea al centro della pratica professionale e dovrebbe essere patrimonio comune ormai. L’MVP (il Minimum Viable Product – Minimo Prodotto Fattibile) non è una versione economica del prodotto finale: è uno strumento epistemico. Serve infatti a validare le assunzioni critiche prima di investire sulla realizzazione 4.

La sperimentazione non è “proviamo e vediamo cosa succede”; è un’attività disciplinata.

  • Cosa voglio capire?
  • Quale ipotesi sto testando?
  • Cosa mi dirà che avevo ragione o torto?

Senza quelle domande, il prototipo non è un esperimento: è un’impressione con un’interfaccia sopra.

Un elemento costante

La versione zero, l’esplorazione, il prototipo, il wireframe grezzo, ha un costo che si è ridotto drasticamente: meno persone coinvolte, meno cicli di andata e ritorno, meno tempo perso a spiegare cosa si intende. Evviva.

Attenzione: la versione finale richiede ancora le stesse figure di prima [Ref]Da questo punto di vista ho dei dubbi sul fatto che sia effettivamente più economico: l’altro giorno è apparsa una notizia nella quale il CTO di Uber ha detto che hanno già finito il budget AI 2026 in questi primi mesi. Meno persone ok, ma il costo dei tool è interessante[/ref].

Figure che con gli strumenti AI, lavorano in modo strutturalmente diverso. Non meno: diversamente. A tal proposito è molto bello il racconto di Matteo Bossolini, co-founder di Cato, nell’ultimo episodio di Cosa Sposta: il programmatore non scrive meno codice perché è diventato pigro, ma perché è diventato architetto 5.

Il designer con Claude Design arriva alla soluzione più velocemente perché ha già eliminato le opzioni ovviamente sbagliate.

Lo sviluppatore con Claude Code produce l’architettura del sistema più in fretta perché ha già testato tre approcci senza scrivere una riga.

La competenza non vale meno; vale nel momento giusto, sul problema giusto.

Rispettare il tempo dei colleghi significa arrivare alla conversazione con un semilavorato che ha già attraversato un ciclo di verifica personale. Non “ho un’idea”, ma “ho testato questa ipotesi, ho visto che non funziona così, e voglio capire se la direzione è giusta”. Quella è la versione zero fatta bene.

Il rischio di distorsione

C’è però un effetto collaterale che va nominato senza eufemismi, e che Luca Sartoni ha descritto in un bel post: chi produce la versione zero tende a dimenticare che è una versione zero.

Non è pigrizia, non è malafede: quando in dieci minuti ottieni qualcosa che sembra un risultato professionale, il cervello registra competenza acquisita. E quella sensazione, quando incontra il potere decisionale, produce esattamente il danno che Luca descrive:

il lavoro degli esperti viene scavalcato, le risorse vengono allocate su basi emotive, chi ha competenza di dominio si trova a difendere scelte che non avrebbe mai fatto.

Il problema non è lo strumento, ma la mancanza di una distinzione operativa che le organizzazioni non stanno ancora facendo in modo esplicito: chi può produrre la versione zero (sempre di più) e chi può validare la versione finale (gli stessi di prima) sono due ruoli diversi e confonderli costa<.

Ma Aristotele?

C’è un concetto che Google ha sviluppato anni fa e che non ha mai ricevuto l’attenzione che merita fuori da alcune cerchie di sviluppo prodotto: il pretotyping.

In estrema sintesi il pretotyping aiuta a capire se ha senso fare qualcosa, il prototipo è già ragiona sul come fare a realizzare La distinzione con il prototipo è semplice ma fondamentale. Il pretotyping risponde alla domanda “ha senso farlo?”; il prototipo risponde alla domanda “Riusciamo a farlo?”. Sono due domande diverse, con due strumenti diversi e due momenti diversi 6.

La sperimentazione con gli strumenti AI vive esattamente nel primo spazio: serve a capire cosa ha senso fare prima di chiedere a qualcuno di farlo e portarlo alla finalizzazione.

Ed è qui che entra in gioco qualcosa che Aristotele aveva formalizzato ventiquattro secoli fa: il principio di non contraddizione.

A non può essere contemporaneamente A e non-A.

Il lavoro di sperimentazione non può essere contemporaneamente sperimentazione e prodotto finale. Non è una questione di contesto o di ottimismo: è una contraddizione in termini.

A è il pretotipo. Non-A è il prodotto. A non diventa non-A per accumulo di iterazioni: diventa non-A quando qualcuno con le competenze giuste decide che l’ipotesi è stata validata e che vale la pena realizzarla.

Confondere i due momenti non è efficienza; è saltare la domanda più importante.

Peccato che saltare la domanda più importante nell’era in cui gli strumenti AI rendono tutto più veloce costi più di prima perché la velocità amplifica gli errori di metodo, non li corregge.

BONUS: grafica by Gemini

Una comoda rappresentazione dei due pattern fatta con Nano Banana

Notes:

  1. A questo approccio vengono dati nomi diversi a seconda della disciplina di riferimento: Ideazione, Product Exploration, Discovery… è un momento in cui si fanno degli esperimenti per raccogliere esigenze e necessità reali prima di impegnare risorse nello sviluppo vero e proprio ↩
  2. Non tutte le aziende hanno competenze di product management #sadness ↩
  3. Per un nuovo sistema software, i requisiti non saranno completamente noti fino a quando gli utenti non lo avranno utilizzato.” Il principio vale ben oltre il software: vale per qualsiasi prodotto, servizio o interfaccia che non è mai esistito prima nella forma in cui lo si sta progettando. ↩
  4. Piccola sintesi sul metodo e lo strumento: fare bene cose che non hanno senso non ha valore per cui è fondamentale validare le ipotesi più rischiose prima di procedere in maniera più aggresiva e strutturata (e bruciare budget). L’MVP è lo strumento di comprensione per capire tramite sperimentazione verso soluzioni nelle quali il livello di incertezza si è ridotto ↩
  5. Se non ascoltate Cosa Sposta fatelo. Sintesi dell’episodio: Cato ha costruito l’intero software con un team di 4 persone nel tech, affidandosi a Claude, Cursor e Claude Code per la generazione del codice e concentrando il lavoro umano su architettura, PRD e ricerca di prodotto ↩
  6. La distinzione tra pretotyping e prototipo è spesso ignorata nella pratica: si salta direttamente al “come farlo” senza aver validato il “se farlo”. ↩
robot pointing on a wall

Quando il saggio indica la governance, lo stolto guarda l’AI

/in , , /by

Quando faccio progetti (di strategia, di riorganizzazione del marketing, di introduzione dell’AI), un’interessante situazione nella quale mi imbatto (credo comune a molti e molte) è che ci sono alcune incomprensioni iniziali che non sono tecnologiche: le persone fanno fatica a identificare cosa vogliono risolvere (dove spesso il racconto è focalizzato su sintomi e soluzioni) e le organizzazioni non hanno deciso chi può decidere cosa (per cui c’è un momento di lentezza per capire qual è il giro del fumo).

Non è una novità e il fatto che si riproponga in contesti diversi, con strumenti diversi, in aziende di dimensioni diverse è per me interessante. L’AI adesso è solo l’ultimo sintomo, più visibile degli altri perché arriva con aspettative alte e risultati spesso deludenti.

Il risultato è prevedibile: si introducono strumenti senza rivedere i processi, si ottimizza localmente quello che si rompe sistemicamente, si crea nuovo muda (spreco) credendo di eliminarlo 1.

Tre problemi concreti che trovo in sequenza, quasi sempre in quest’ordine.

Primo problema: non sai cosa stai risolvendo

L’errore più comune (nell’introduzione di qualsiasi strumento, AI inclusa) non è scegliere la soluzione sbagliata, ma è scegliere la soluzione prima di aver definito il problema.

Usiamo l’AI per fare le sintesi delle riunioni.

Bene. E quelle sintesi le usa qualcuno? Generano decisioni? Cambiano qualcosa?

No, ma almeno le abbiamo.

Questo è waste con un’interfaccia moderna. Nessuno strumento lo trasforma in valore, lo produce più velocemente (il famigerato AI Slop).

Prima di qualsiasi introduzione serve una domanda brutalmente semplice: qual è il problema che stiamo cercando di risolvere, e come fa questo strumento a risolverlo? Se la risposta è vaga, il problema non è ancora definito. E se il problema non è definito, qualsiasi soluzione è prematura. 2

Ma c’è un prerequisito ancora più a monte, che ho affrontato nel post precedente: per definire un problema con sufficiente precisione da poterlo delegare (a un collaboratore, a un team, a un sistema AI) hai bisogno di conoscenza dichiarativa, la capacità di descrivere quello che fai, i criteri con cui decidi, il risultato che vuoi ottenere. Chi non ha sviluppato questa competenza non riesce a identificare il problema in modo utilizzabile e finisce per delegare un compito che nemmeno lui sa definire con precisione 3.

C’è poi una seconda domanda da fare, che viene quasi mai fatta:

questo è un problema mio, del mio team, o dell’organizzazione?

Perché la risposta cambia completamente chi deve risolverlo, con quali strumenti e con quale livello di autonomia.

Secondo problema: non hai deciso chi può decidere cosa

Che si tratti di riorganizzare il marketing, introdurre un nuovo processo o adottare strumenti AI, il problema sottostante è quasi sempre lo stesso: manca una struttura chiara di governance. Chi può usare quali strumenti, per quali attività, con quali output attesi, con quale livello di autonomia non è sempre chiaro perché è parte (più frequentemente di quanto vorrei) di una conoscenza implicita, non dichiarata e che quindi deve essere trovata.

Senza questa struttura succedono due cose opposte e ugualmente dannose.

  • La prima: le persone non agiscono perché non sanno se possono, se devono, se è appropriato.
  • La seconda: le persone agiscono in modo non coordinato, producendo output incompatibili, processi ridondanti, e una frammentazione del lavoro che è peggio della situazione di partenza.

Quello che serve (e che poche organizzazioni hanno costruito in modo esplicito) è qualcosa che somiglia a una costituzione dell’autonomia 4: un insieme di principi chiari che definisce le aree in cui il problem solving locale è abilitato e le aree in cui serve coordinamento. Non un manuale operativo non una policy di 40 pagine. Un frame che risponde a: cosa puoi decidere da solo, cosa devi concordare, cosa non puoi fare senza autorizzazione esplicita.

Senza questo frame, ogni persona e ogni team risolve il problema come può, con gli strumenti che ha, secondo criteri che non sono condivisi. L’organizzazione diventa una collezione di ottimizzazioni locali che non si sommano mai in efficienza sistemica.

5

Terzo problema: il lavoro di orchestrazione frammenta l’attenzione

Quando nuovi strumenti entrano nel flusso di lavoro (e l’AI lo fa in modo particolarmente pervasivo) il lavoro cambia natura. Non scompare: si trasforma. Meno produzione diretta, più orchestrazione: definire il task, verificare l’output, correggere, iterare, integrare.

Questo sembra un miglioramento. In parte lo è, ma introduce un effetto collaterale che si rischia di sottovalutare: la frammentazione dell’attenzione.

Se ogni quindici minuti verifico l’output di un processo delegato (a un agente AI, a un collaboratore remoto, a un sistema automatizzato) sto lavorando su più cose contemporaneamente in modo strutturale (e ho già mostrato in un post precedente cosa produce il multitasking sul rendimento “Perché è pericoloso lavorare su più progetti”): il multitasking non è un’abilità. È un costo.

Il context switching non sparisce con l’AI, si moltiplica, perché le istanze di lavoro si moltiplicano.

Questo ha un’implicazione diretta su come organizzare il lavoro: non per attività, ma per blocchi di risultato.

La domanda non è “cosa faccio adesso?” ma “qual è il risultato che voglio avere al termine di questo blocco di tempo, e come organizzo gli strumenti per ottenerlo senza dover verificare ogni quindici minuti?” e oltretutto torniamo a un ripensamento profondo delle attività per evitare di rendere più inefficienti processi non pensati per l’AI.

Il focus si sposta ancor di più dall’attività all’impatto ovvero dal tempo lavorato al risultato prodotto. Non è una novità concettuale (è la logica del lavoro per obiettivi, degli OKR, di qualsiasi approccio che mette il risultato prima del processo).

Ma la moltiplicazione degli strumenti rende questa transizione non più opzionale.

6

Il problema dell’accountability che nessuno vuole affrontare

C’è un quarto problema, che non viene quasi mai nominato esplicitamente: è il più scomodo, ed è quello che rischia di avere le conseguenze più serie in particolare con l’AI, ma non solo.

Chi risponde quando qualcosa va storto?

Per rispondere con precisione, possiamo sfruttare uno strumento che il project management usa da decenni: una RAM, Responsibility Assignment Matrix, una matrice che mappa ruoli e responsabilità su attività o deliverable. Il PMBOK del PMI la definisce come strumento per illustrare le connessioni tra work package e membri del team di progetto 7.

La RACI (il tipo di RAM più usato) assegna a ogni attività quattro ruoli: chi esegue (Responsible), chi risponde del risultato (Accountable), chi viene consultato (Consulted), chi viene informato (Informed). Una regola fondamentale, ribadita dal PMBOK: per ogni attività deve esserci un solo Accountable. Non due. Non nessuno. Uno.

Ora prova ad applicare questa logica a un processo che include un sistema AI.

L’AI non può essere Accountable, per lo meno non nel senso tecnico del termine. Accountable significa rispondere del risultato, avere skin in the game, subire le conseguenze di una decisione sbagliata. Un sistema non risponde, non subisce conseguenze, non impara nel senso in cui impara una persona che ha sbagliato e ne porta il peso.

Questo non è un problema filosofico, è un problema operativo immediato.

In questo momento, tutta la responsabilità dell’output di un sistema AI ricade sull’operatore, la persona o l’organizzazione che ha scelto di usarlo, che lo ha configurato, che ha accettato il risultato. Anche quando il risultato è sbagliato. Anche quando l’errore era nel modello, nel training data, in una deriva che l’utente non aveva modo di prevedere.

Il parallelo più preciso è quello della guida autonoma. In caso di incidente, chi risponde? Il guidatore che non aveva le mani sul volante? Il produttore del software? La casa automobilistica? La risposta legale è ancora in costruzione, ma la risposta operativa attuale è che il guidatore è Accountable, perché era nella posizione di controllo.

Con l’AI in azienda funziona esattamente così. L’operatore risponde sempre. Anche se ha fatto “tutto bene”. La delega al sistema non riduce la responsabilità, la maschera, finché non emerge il problema.

Questo ha due implicazioni concrete che le organizzazioni quasi mai considerano esplicitamente.

  1. Il livello di controllo iniziale non può essere basso. Un sistema AI non è un collaboratore che ha già dimostrato di meritare autonomia. È un sistema che deve guadagnarsi la fiducia attraverso output verificati, iterazioni corrette, perimetri testati. Il controllo non è inefficienza, ma è il costo necessario di un sistema che non può essere Accountable per sé stesso.
  2. Il controllo non può probabilmente essere mai eliminato del tutto. Può essere ridotto, può essere spostato, può essere automatizzato in parte, ma la catena di accountability deve sempre terminare in una persona. Non in un sistema. Non in un processo. In qualcuno che può rispondere.

Questo è il motivo per cui introdurre qualsiasi strumento senza aver prima definito la governance dell’autonomia non è solo inefficiente. È un rischio che l’organizzazione sta assumendo senza averlo nominato (soprattutto in una narrazione dove adesso possiamo fare più cose: facciamo più cose, ma come le controlliamo senza diventare controllori a tempo pieno?).

Da dove si parte

Da tre domande, in quest’ordine.

La prima: qual è il problema che voglio risolvere? Torniamo sempre allo SMART: Specifico, misurabile, collegato a un risultato atteso. Se la risposta è vaga, il lavoro è ancora a monte e prima di rispondere serve la capacità di descrivere il proprio lavoro con sufficiente precisione dichiarativa.

Senza quella, il problem solving rimane procedurale: si agisce per intuizione, non per definizione 8 .

La seconda: chi è Accountable del risultato, e come lo verifico? Senza questa risposta l’organizzazione sta delegando responsabilità a qualcuno o qualcosa che non può tenerla.

La terza: come organizzo il lavoro per evitare che l’orchestrazione frammenti l’attenzione più di quanto lo strumento la liberi? Il guadagno di efficienza si perde se il context switching diventa strutturale.

L’AI è uno strumento potente, ma il problema che trovo spesso negli assessment non è mai lo strumento: è sempre la struttura che manca prima dello strumento e la struttura, come quasi sempre, non è un problema tecnologico 9.

Altri approfondimenti interessanti:

Report Deloitte – State of AI in the Enterprise – Solo il 21% delle imrpese ha pensato/impostato una governance per gli agenti AI

Riflessione di Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura

Notes:

  1. Ne ho scritto estesamente in “AI: può avere effetti collaterali, leggere il foglio illustrativo” — il punto Lean/VSM è preciso: automatizzare un’attività inefficiente non la rende efficiente, la rende inefficiente più velocemente. ↩
  2. Il frame del problem framing non è nuovo: Thomas Wedell-Wedellsborg lo ha articolato bene in “What’s Your Problem?”. TLDR: il modo in cui definisci un problema determina quali soluzioni riesci a vedere. Cambia il frame, cambia la soluzione, spesso radicalmente. ↩
  3. “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” — il punto centrale: chi non riesce a descrivere il proprio lavoro non riesce a delegarlo. Né a un junior, né a un sistema AI. La conoscenza procedurale non è trasferibile finché non diventa dichiarativa. ↩
  4. Ciao Holocracy, sì, sto guardando te e le tue bellissime impostazioni: consiglio di guardare https://www.holacracy.org/ Ci sono poi altri elementi interessanti come il Ren Den Hey, Sociocracy etc. ↩
  5. Ho già scritto del problema dell’ottimizzazione locale in “L’AI tra Hype e Processi”: l’efficienza su un pezzo del processo non è efficienza del processo. Il Value Stream Mapping lo rende evidente — il collo di bottiglia non è mai dove pensi. ↩
  6. L’impatto sui team di lavoro è già in corso — ne ho scritto in “L’impatto dell’AI sui team di lavoro”: l’efficienza sulla produzione sposta l’attenzione su decisioni e priorità. Il problema è che molte organizzazioni non hanno ancora spostato i criteri di valutazione delle persone nella stessa direzione. Si misura ancora il tempo, non il risultato. ↩
  7. PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), www.pmi.org. La RAM è descritta nella sezione dedicata alla gestione delle risorse di progetto. Il PMBOK cita la RACI come esempio di RAM — non come framework autonomo. La RACI (Responsible, Accountable, Consulted, Informed) è un tipo specifico di RAM, probabilmente il più diffuso, ma non l’unico: esistono varianti con designazioni diverse a seconda del contesto di progetto. ↩
  8. Il collegamento tra conoscenza dichiarativa e capacità di definizione del problema è il filo conduttore di “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” I due post si leggono in sequenza: prima sviluppi la competenza dichiarativa, poi riesci a usarla per identificare problemi risolvibili. ↩
  9. “Qualche triste verità sui tool di project management, AI inclusa” — il punto centrale: i tool non risolvono problemi strutturali. Un CRM senza processo sottostante è uno scaffale vuoto. L’AI senza governance è un acceleratore di caos. ↩
colorful abstract geometric design with spheres

Se non sai spiegarlo, non sai farlo. E nemmeno l’AI.

/in , , /by

In ogni team c’è quella persona che fa le cose in modo impeccabile: istinto, velocità, qualità. La chiami per i problemi difficili e li risolve.

Poi provi a farla lavorare con un junior, a farle trasmettere quello che sa e… catastrofe. Risultato pessimo: Senior frustrato, Junior frustrato. Non riesce a spiegare perché fa quello che fa, le fa e basta e il Junior dovrebbe apprendere per osmosi 1.

Non è cattiveria. È che sapere fare e sapere spiegare sono due competenze diverse e non si sviluppano automaticamente l’una con l’altra.

Read more

Notes:

  1. che è poi il motivo per cui alcune imprese vorrebbero tornare in presenza, così non hanno bisogno di struttura (fine del piccolo rant sulla presenza vs remoto) ↩
close up photo of yellow tape measure

La verità sulle stime di progetto

/in , , /by

C’è una domanda ricorrente che si presenta puntualmente in tutte le aule durante i corsi di Project Management e mentre lavoro con i team marketing: la famigerata domanda sulle stime di progetto. Questa domanda si presenta in vari modi: come possiamo fare stime migliori? Come facciamo a stimare? Perché le stime di progetto sono sbagliate? e varianti.

La questione stime di progetto è bellissima perché spesso parte da presupposti sbagliati e da una concezione errata di questo termine. Per migliorare le nostre stime dobbiamo partire dalle basi: che cosa è una stima?

Read more
an artist s illustration of artificial intelligence ai this image visualises the benefits and flaws of large language models it was created by tim west as part of the visualising ai pr

AI: può avere effetti collaterali, leggere il foglio illustrativo

/in , , /by

Come credo la maggior parte delle persone, tra le altre cose sto lavorando a diversi progetti legati all’Intelligenza Artificiale (IA o AI) legati all’ottimizzazione dei processi in ambito marketing (automazioni, agenti, low code e tutte quelle belle cose li) e, oltre a sporcarmi le mani guardo anche agli impatti più ampi e devo dire che ho notato una cosa interessante (forse banale): stiamo rendendo i processi meno efficienti.

Read more
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?

Notes:

  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) ↩
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.

L’importanza dei team eterogenei

/in , , /by

Uno degli aspetti più interessanti legati ai progetti sui Social Media è il tema delle competenze. Si tratta di una riflessione che può essere applicato anche ad altre aree, sicuramente a tutto il digitale: perché è così difficile sviluppare un’attività di successo? Molto semplicemente perché ci troviamo davanti a materie che richiedono l’interazione tra più persone, materie e (per rimanere in ambito aziendale) più dipartimenti o aree.

Read more

Measurement - Photo by Batara - http://flic.kr/p/bw1tqV

Social Media ROI, KPI e KRI

/in , , /by

La scelta degli indicatori per le attività sui Social Media è un argomento piuttosto dibattuto: cosa misurare per determinare il valore delle attività sui Social Network? Come determinare il ROI dei Social Media? Quali sono i KPI di Facebook? Misuro il numero di fan? Sinceramente c’è parecchia confusione sul tema è il caso di fare un po’ il punto

Read more