hotrod die cast model on board

Il debito tecnico nel Marketing

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

È possibile usare Scrum in Agenzia e nel Marketing?

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.
man wearing black and white stripe shirt looking at white printer papers on the wall

Perché è pericoloso lavorare su più progetti

Ogni tanto ripropongo una tabella che mette in relazione il numero di progetti seguiti contemporaneamente e l’inefficienza: l’elemento più evidente è che al crescere dei progetti cresce l’inefficienza, ma questa è solo il punto di partenza.

Partiamo dalla tabella

Tabella con il rapporto tra progetti gestiti simultaneamente e l'inefficienza dovuta alla perdita di passaggio da un contesto all'altro

Questa tabella è abbastanza famosa perché è citato in uno dei testi classici “Fare il doppio in metà tempo” di Jeff Sutherland (link affiliato Amazon 1). La prime reazioni a questa tabella sono mediamente lo sconforto e soprattutto la negazione “ah, ma io sono bravissimə a gestire più cose contemporaneamente”. Bene, facciamo un piccolo esperimento: bastano carta, penna e un telefono (mi spiace, niente colla vinilica a questo giro).

Su due righe dovrete scrivere in stampatello il vostro nome e cognome

NOME

COGNOME

Scrivete prima tutto il nome e poi tutto il cognome e cronometrate quanto ci mettete: io ho impiegato 12 secondi.

Bene, adesso scriviamo sempre nome e cognome su due righe MA alterniamo una lettera del nostro nome a una del nostro cognome

Il risultato è “praticamente” quello di prima

NOME

COGNOME

Anche qui provate a cronometrare quanto ci mettete: io ho impiegato 16 secondi.

Per fare la stessa identica cosa (scrivere 17 lettere su un foglio di carta) nel secondo caso ho usato 4 secondi in più. Non ho “aggiunto più valore”, non ho “fatto più cose”: il semplice fatto di dover passare da una cosa all’altra (il famigerato multitasking) mi ha rubato 4 secondi che non potrò dedicare ad altro.

Ci sono migliaia di varianti su questo esperimento 2, ma ampliamolo ai nostri progetti dove invece di fare azioni relativamente semplici come scrivere il nostro nome e cognome dobbiamo scrivere libri, analizzare campagne, implementare modifiche cosa succede? Un grande classico “non capisco: ho lavorato un sacco, sono stanco e oggi non ho concluso nulla”.

Perché è rischioso gestire tanti progetti contemporaneamente?

Immaginiamo per un secondo la rappresentazione teorica dei nostri progetti: in generale abbiamo un momento d’inizio (Start – A) e un momento di chiusura (Finish – B)

Rappresentazione teorica di un progetto che deve andare dallo stato A allo stato B

Cosa succede normalmente? Che abbiamo tante cose da fare e ci sono quindi tutti i nostri progetti (rappresentati da dei magnifici pacchetti azzurri) che aspettano di essere presi in carico

Il primo approccio è quello di iniziare a lavorare su tutti perché “il cliente lo vuole subito”, “mi ha chiamato l’account e dobbiamo andare avanti” e tutte quelle belle frasi che si sentono spesso sui progetti. Per cui iniziamo a lavorare contemporaneamente su tutti i progetti

lavoro contemporaneo su vari progetti in parallelo

Bene, cosa succederà a questo punto? Molto banalmente che inizieremo a suddividere le nostre giornate passando da una urgenza all’altra cercando di fare tutto e, banalmente, accumulando solo ritardi e sprechi.

Perché parlare di rischio? Se sei un freelance credo sia evidente: avere tanti progetti aperti e nessuno finito significa rischio finanziario perché non puoi emettere fattura se le attività non sono concluse. Un’attività aperta e non conclusa è uno spreco.

Dovremmo iniziare a smettere di dire “è pronto all’80%”. O è finito o non lo è.

Il costo mentale di passare da una cosa all’altra è estremamente elevato: ormai c’è una significativa bibliografia in merito e non ci sono più dubbi. Pensate ad esempio al fastidio quando state lavorando, siete concentrati e un collega (o un figlio se siete in “smart working”) vi interrompe: per riprendere il filo dei pensieri ci metterete cinque, dieci minuti (a volte anche di più).

Sempre in “Fare il doppio in metà tempo” c’è un interessante aneddoto sulla correzione di bug: se corretto in giornata richiedeva un’ora, se corretto dopo tre settimane, lo stesso bug, richiedeva 24 ore. Molto banalmente perché bisogna ricordarsi e ricostruire tutto e, più passa il tempo, più è difficile.

Passare da un task/attività/progetto all’altro ha un costo molto elevato. Interrompersi e riprendere le attività (dopo aver lavorato su altro) significa iniziare con le domande tipo: cosa stavo facendo? cosa volevo dire qui? la premessa qual era? perché stavo pensando di aumentare il budget sulla campagna 5?

Da qui l’idea tanto banale quanto geniale degli Approcci Agili e soprattutto Lean

bilanciato

Non lavorare su tutto, ma capire cosa siamo in grado di gestire in maniera ottimale e diventare molto molto veloci nel chiudere i progetti. Il nostro obiettivo non è farci vedere impegnati (il famigerato “Facite ammuina), ma cercare di lavorare in maniera equilibrata riducendo i rischi.

Da qui una frase importantissima: Stop Starting & Start Finishing (Smettila di aprire roba e inizia a chiudere le attività)

E se ho più progetti e non sono tutti azzurri? Io lavoro tanto con Agenzie e Reparti Marketing e anche in questo caso, non cambia molto, banalmente abbiamo questa situazione

esempio di backlog multiprogetto

Immaginiamolo nella gestione delle attività di uno specialista di Social ADV che gestisce sei campagne per cinque clienti diversi. Questa persona dovrà svolgere una serie di attività come analisi performance, controllo budget, reportistica.

Se applichiamo l’approccio “apri tutto” analizzerò le performance di tutte e sei le campagne, poi analizzerò le performance e infine farò la reportistica. Se invece utilizzo un approccio più orientato alla filosofia Agile e Lean: prendo la campagna rossa, analizzo le performance, controllo il budget, faccio il report. Poi passo alla verde, stesso ciclo, poi le azzurre e poi le gialle.

Fare in questo modo mi consente di chiudere più rapidamente e di non dover, ad esempio, in fase di report dover tornare a guardare le campagne perché mi sono dimenticato gli elementi che volevo sottolineare al cliente.

Pensiamolo anche con le slide (uno tra i grandi insegnamenti ricevuti nel 2009 in Hagakure da Cimny): invece di saltare da una slide all’altra, indice, poi qualche bozza etc. fermati e finisci ogni slide prima di passare alla successiva. Fai giusto tutto al primo colpo 3.

Si tratta semplicemente di ripensare al modo in cui lavoriamo e gestiamo i nostri progetti: cerchiamo di condensare i progetti diversi e chiuderli prima di passare ad altro in modo da ridurre i costi di passaggio.

Per cui è possibile lavorare su più progetti (anche da remoto), gestendoli meglio.

(se poi ti appassiona il tema facciamo dei corsi bellissimi sul Project Management in Digital Update: con questo link c’è anche un 10% di sconto per i nuovi iscritti)

Note:

  1. I link affiliati sono dei link specifici che portano verso un determinato negozio e che riconoscono alla persona che ha condiviso il link una commissione: sto facendo alcuni esperimenti con il programma Affiliate di Amazon e il loro programma Influencer
  2. Quello classico: provate a scrivere su tre righe i numeri da 1 a 10, da I a X, e le lettere da A a L: anche qui provate a scrivere prima tutte le serie (da 1 a 10, da I a X, da A a L) e cronometrate; provate poi a scrivere un elemento per volta (1, I, A – 2, II, B – 3 III, C – 4, IV, D… ) e cronometrate.

    Un’alternativa interessante è provare a usare due penne di colore diverso per scrivere il Nome e il Cognome e tre per le serie di numeri

  3. il concetto del “build quality in”: la qualità non si aggiunge alla fine, ma deve essere una caratteristica del sistema/prodotto e non abbozzare tutto. Su questo tema (che potremmo chiamare Lean Presentation Design io e Chiara avremmo molto da raccontare per quanto fatto per il freelance day.
silhouette of boy running in body of water during sunset

Ritornare alla normalità?

All’annuncio della (nuova) chiusura di Palestre, Teatri, Cinema etc. ci sono rimasto male e ho iniziato a rimuginare e borbottare. C’era qualcosa che non riuscivo a mettere a fuoco: cosa mi dava veramente fastidio? Alla fine ci sono arrivato: l’idea che si possa tornare alla vecchia normalità e che a farne le spese sia chi invece è già cambiato.

Alla fine del lockdown ho ripreso ad allenarmi (come credo tutti i malati di Crossfit), ma non era come febbraio. Numero chiuso e limitato, distanziati, mascherine all’ingresso, sanificare mani prima di entrare, registro della temperatura, nessun assembramento, sanificare gli attrezzi alla fine. Ogni singola volta. Niente strette di mano o “bha-la-la-lala“. Nessuno scambio di attrezzi. Ogni singola volta.

Ma alla fine funzionava.

Due volte in questi mesi siamo usciti a cena (anche per celebrare la riapertura delle scuole: lo smart working è bello se non hai creature urlanti per casa, ma questa è un’altra storia). Non era come febbraio. Prenotazione obbligatoria, mascherine fino al tavolo, sanificazione mani all’ingresso, lontanissimi dagli altri (cosa che avrei apprezzato anche prima), menù con qr code (finalmente sono utili e diffusi). Ogni singola volta

Ma alla fine funzionava.

Ho colleghi che lavorano nel mondo dell’arte, dei live e dello spettacolo e anche li: situazione non rosea, ma riscrivendo profondamente il funzionamento, i processi e la gestione delle attività hanno trovato delle soluzioni abbastanza sostenibili e soprattutto sicure.

Poi parlo con colleghi che mi raccontano invece di un mondo che è tornato quello di prima:

  • l’emergenza è finita, torniamo tutti in ufficio.
  • il dramma è finito, torniamo tutti sui mezzi pubblici.
  • basta con la DAD fallimentare, torniamo finalmente in aula.

Il mio fastidio è proprio per questo: l’idea che si possa tornare alla situazione precedente.

Mi spiace: no, la normalità è quella di giugno (mascherine, distanza fisica, meno contatti possibili, più lavoro da remoto e smart, nuove soluzioni per la didattica) ed è con questo che dovremo convivere per i prossimi mesi o anni.

Non ti piace? Vorresti andare in giro senza mascherina?

Ma io non voglio cambiare, voglio tornare a fare la cose come prim…

Spero che il concetto sia chiaro.

Ma i bambini hanno bisogno di andare a scuola!

No. Hanno bisogno di socializzare e imparare. Con la DAD si possono fare cose egregie: se qualcuno pensa semplicemente di trasferire l’aula online facendo lezione frontale davanti a una telecamera ha sbagliato tutto. I bambini possono socializzare in altri modi? Certo, ma bisogna pensarci e riflettere, non si può replicare quello che si faceva prima.

Ma i dipendenti hanno bisogno dell’ufficio!

Al netto di chi veramente produce in un luogo, i professionisti del terziario avanzato (ok boomer) non devono andare in ufficio mediamente è un problema di management che non ha capito cosa è successo negli ultimi 40 anni. C’è da ripensare i team, i progetti, processi etc.

Il vero problema? Come direbbe un mio amico è che “Non è un cazzo facile”

Ripensare spazi, processi, persone è difficile: tornare indietro sarebbe bellissimo, ma non funziona e soprattutto non succederà (a tal proposito c’è un piccolo libro di management, molto USA: “Chi ha spostato il mio formaggio” – link al libro affiliato Amazon 1

C’è chi ha capito che il mondo è cambiato, ha iniziato a correre e si è adattato e chi invece spera tutto torni come prima. È questo che mi ha dato fastidio: chiudere chi ha iniziato a correre.

Note:

  1. I link affiliati sono dei link specifici che portano verso un determinato negozio e che riconoscono alla persona che ha condiviso il link una commissione: sto facendo alcuni esperimenti con il programma Affiliate di Amazon e il loro programma Influencer
piero tagliapietra project management

Gestire progetti digitali

Era proprio necessario scrivere un altro libro sulla gestione dei Progetti Digitali? Non c’erano abbastanza testi sul Project Management? Secondo me no, soprattutto in ambito Digital e Comunicazione/Marketing.

Svelerai quindi i segreti per fare tutti i progetti digitali?

No: mi spiace, niente risposta sulla vita, l’universo e tutto quanto (tanto quella rimane 42).

Il tema principale del libro è proprio questo: non è possibile rispondere alla domanda “mi dai il metodo assoluto per fare il progetto x” perché non esistono due aziende, contesti, clienti e progetti uguali e quindi non è possibile dare delle indicazioni puntuali su come fare esattamente lo sviluppo di un sito o una campagna adwords.

Ovvio che si possono dare varie opzioni che possono essere adattate allo specifico contesto aziendale.

Ma quindi è meglio Waterfall, Scrum o Kanban o Lean Startup? Nessuno ed è qui che entra in gioco il libro.

Chi si occupa dei progetti oggi (e soprattutto di quelli in ambito Digital) a mio avviso deve conoscere tutte le metodologie e scegliere quella che potrebbe funzionare meglio (anche se possiamo già sbilanciarci sul fatto che probabilmente Agile e Lean sono le due famiglie più utili).

Si tratta quindi di adottare quello che si chiama un “Agile Mindset” e di non erigersi ad araldi di un metodo, ma di scegliere quello che consente di generare il maggior valore in quel contesto specifico

The goal of project management is to produce Business Value in the best possible way given the current environment. It odes not matter if that way is agile or predictive. The question to ask is “How we can be most successful?” 1

Per cui nel libro parlo tanto di filosofia (che è alla base di tutto: ricordiamoci la famosissima frase di Druker “Culture eats strategy for breakfast” ) della gestione e cerco di dare una prima panoramica sui vari approcci (Predittivi, Iterativi, Incrementali, Agili e Ibridi) in modo che si riesca:

  • a capire meglio il proprio ambiente lavorativo
  • identificare e mappare i propri progetti per scegliere approcci ed evoluzioni
  • sviluppare una cultura del progetto e del Project Management
  • scegliere quale metodo, famiglia e approcci approfondire

Perché leggerlo? Può servire anche a me?

Tutti noi gestiamo progetti e stiamo andando verso una Project Economy: per cui avere una rapida idea di cosa vuol dire gestire un progetto e del perché aggi si parla tanto di Agile, Scrum, Lean e Kanban (che non è Trello) per me è una competenza fondamentale.

Oltretutto ognuno di noi gestisce progetti e organizzare male l’attività significa avere persone poco motivate 2 e non riuscire a fare il progetto o non rispettare i vincoli o ridurre i margini sul progetto (o addirittura andare in perdita).

Per cui il libro serve anche a capire cosa è cambiato il Project Management negli ultimi 25 anni (da una visione ancora meccanicistica ad una più legata alla complessità e ad una visione che potremmo definire quasi Olivettiana) e come possiamo organizzare le nostre attività.

Non troverai però la soluzione migliore a livello di tool (È meglio Asana, Wricke, Monday, MS Projects, Bitrix, Miro, Kanbantool, Kananizer, Mural….), ma il processo per arrivare a trovare da solo la risposta .

Ok, dove lo trovo?

Il libro è edito Franco Angeli e qui puoi leggerne un estratto: puoi prenderlo su Amazon o da qualunque altro store o negozio fisico: sarà disponibile dal 5 marzo.

Note:

  1. Agile Practice Guide – Project Management Institute – pg 29. A mio avviso uno dei testi da leggere per adottare ili giusto approccio
  2. È importante ricordare che non gestiamo progetti, ma persone: sono infatti loro a dare vita al progetto e un Team privo di motivazione, scarsamente collaborativo e che non lavora insieme difficilmente riuscirà a garantire il raggiungimento degli obiettivi del progetto

Come fare le domande agli eventi (spiegato bene)

Ogni tanto partecipo ad alcuni eventi (a volte come relatore a volte come parte del pubblico) e uno dei grandi mali che affliggono le conferenze italiane sono le domande del pubblico: gli italiani mediamente non sono in grado di fare domande.

Read more

E quindi questo 2017? Continuo così, grazie

Febbraio 2018 inoltrato e finalmente riesco a sistemare quello che doveva essere il “post” bilancio 2017: direi che già questo racconta un sacco di cose sull’anno passato e anche su quello che si prospetta essere il 2018. In poche parole intenso, di corsa, pieno di cose belle e con alcuni sprazzi di equilibrio.

Read more

Gli Influencer spiegati bene

In questo periodo, oltre ai fiori sugli alberi, sono spuntati una serie di articoli e post sugli Influencer il cui contenuti (volendo mantenere un inglese distacco) sono vagamente discutibili e nei quali emerge una conoscenza non sempre profonda del tema. Per cui, nella speranza di fare un po’ di chiarezza e non vedere l’anno prossimo rispuntare altri articoli con le medesime riflessioni, riprendiamo alcuni concetti base.

Read more

Due parole su Buzzoole

In questi giorni ho letto l’ennesimo post relativo a Influencer Marketing e l’etica della persuasione commerciale: in teoria nulla di nuovo sotto il sole, ma sinceramente credo che sia il caso di fare un po’ di ordine e chiamare le cose con il loro nome. Se ti pago per partecipare a una campagna di comunicazione è ADV e come tale andrebbe dichiarato.

Read more

Melegatti: l’inutilità delle polemiche sul nulla

In questi giorni si è parlato molto di Melegatti sui Social Media e dopo aver letto buona parte delle discussioni ritengo fondamentale ribadire alcune cose: bisognerebbe smetterla di chiamare qualunque cosa fail, ignorare chi cerca di fare polemica sul nulla e rimettere al giusto posto i Social Media.

Read more