Trionfa sulla follia dei contratti: Alexa Huston spiega come un contratto agile possa portare benefici al tuo progetto—e come ottenere il consenso dei clienti. Questo episodio offre preziosi consigli a chiunque stia lottando con lo spazio ambiguo tra progetti a ambito fisso e progetti agili, discutendo sfide, vantaggi e svantaggi dell’utilizzo dei diversi tipi di contratti agili.
Questo podcast fa parte di un articolo pubblicato su The Digital Project Manager.
Puoi leggere l’articolo qui.
Elenco correlato di strumenti: Concorrenti e alternative a Wrike
Guarda qui: La mia organizzazione è diventata agile: come affrontare la transizione
Leggi la Trascrizione:
Stiamo sperimentando la trascrizione dei nostri podcast usando un programma software. Perdonate eventuali errori di battitura poiché il bot non è corretto al 100% delle volte.
Ben Aston:
Benvenuti nel podcast Digital PM, dove andiamo oltre la teoria per offrire consigli esperti su come condurre meglio i progetti digitali.
Grazie per l'ascolto, sono Ben Aston, fondatore di Digital Project Manager. Mi chiedo se conoscete questo classico dilemma del project management, quando ereditate un progetto dal team di sviluppo business e per qualche motivo, qualche strano motivo, il budget assegnato al progetto non sembra avere alcuna relazione con il lavoro svolto.
Succede sempre, vero? Ed è incredibilmente stressante per il project manager, per il team che realizza il lavoro, e alla fine anche per il cliente, che spesso resta deluso dal risultato finale.
Questo episodio è sponsorizzato da Resource Guru, lo strumento di pianificazione delle risorse utilizzato da team di aziende come Apple, Ogilvy, Deloitte e Publicis. Gli ascoltatori DPM possono ottenere il 20% di sconto a vita sul proprio account usando il codice coupon DPM2018.
Scopri di più su resourceguru.io/dpm
Oggi parliamo quindi di un modo migliore per gestire la follia dei contratti con cui molti di noi si confrontano. E penso davvero che questa conversazione vada ben oltre il project management, è qualcosa di più grande. Un discorso che ... attraversa project management e new business, tra contrattazione e operations, e davvero, dobbiamo trovare una strada migliore. Quindi, se hai familiarità con le problematiche di contrattualistica e statements of work che ho appena menzionato, adorerai l’episodio di oggi, che parla proprio di un diverso modello di collaborazione. Continua l’ascolto per scoprire come puoi evitare di rimanere invischiato nel dolore di dover ridimensionare un progetto ancora prima che sia iniziato.
La mia ospite speciale oggi è Alexa Huston di Crema. Alexa è una ex DPM diventata esperta di new business. Quindi comprende bene questa sfida sia dal lato nuovo business che cerca di vendere, sia dal punto di vista del project manager che deve consegnare. Sono sicuro che avremo una conversazione interessante.
Inoltre Alexa è anche una delle nostre esperte DPM residenti alla Digital Project Management School, quindi se vuoi imparare da lei, dai un’occhiata alla nostra Mastering Digital Project Management School, dove sarà presente. Vai su Resourceguru.io/dpm.
Ciao e benvenuta, Alexa!
Alexa Huston:
Grazie per avermi invitata!
Ben Aston:
Allora, Alexa, raccontaci, cosa c'è di nuovo nel mondo di Alexa? Credo che tu stia per affrontare una grande novità.
Alexa Huston:
Conosci la frase, “Quando piove, diluvia?”
Di solito significa qualcosa di negativo, ma in realtà stanno succedendo molte cose positive: mi sono fidanzata un mese e mezzo fa e una settimana dopo la ditta del mio compagno gli ha offerto un nuovo ruolo a Phoenix, quindi ci trasferiamo nel deserto.
Di conseguenza, ho messo insieme una proposta per mantenere il mio lavoro a Crema, perché lo adoro. E sono abbastanza fortunata da poter dire che l’hanno accettata, quindi lavorerò in smart working per la prima volta nella mia vita. Inoltre stiamo organizzando il matrimonio, ci sono tante cose in ballo.
Ben Aston:
Parliamo allora dell’organizzazione del matrimonio. Ovviamente organizzare un matrimonio è project management. Hai assunto una wedding planner? O stai gestendo tutto tu come un project manager?
Alexa Huston:
Sto sorridendo tantissimo. Abbiamo assunto una coordinatrice ed organizzatrice perché ci sposeremo in Messico e abbiamo scelto una location in una città dove non siamo mai stati. Quindi fare tutto al buio fa un po’ paura e mancano solo otto mesi, quindi ho pensato, “Mi serve aiuto.”
Ben Aston:
Quindi la tua strategia di mitigazione del rischio è stata assumere una wedding planner e sperare che tutto vada bene.
Alexa Huston:
Esatto, e abbiamo appena fatto la prima chiamata con lei ieri sera, è fantastica. Ma essendo una project manager sulla via della guarigione, continuo a chiederle cose da “stakeholder management”, tipo, “Cosa ne pensi di questo processo? Lavori sempre così o ci sono altri modi migliori?” È stato interessante trovare il giusto equilibrio.
Ben Aston:
Credo che per un project manager affidarsi a qualcuno che gestisca il progetto sia sempre un po’ stressante, almeno all’inizio, ti chiedi sempre “Sapranno davvero cosa stanno facendo?”
Alexa Huston:
Sì, proprio ieri le ho chiesto: “Puoi mandarmi una copia del contratto firmato da tutti? Ho solo la versione con le mie firme.” E probabilmente lei ha detto: “Certo.”
Ben Aston:
Bello! In bocca al lupo con i preparativi.
Alexa Huston:
Grazie!
Ben Aston:
E in Messico, in un posto dove non sei mai stata, quindi ...
Alexa Huston:
Andrà tutto bene, è un mango grove/ristorante, hanno anche case sugli alberi dove alloggiare. È bellissimo.
Ben Aston:
Non vedo l’ora.
Alexa Huston:
Sì.
Ben Aston:
Bene, raccontaci meglio come cambierà il tuo ruolo, allora? È interessante capire come cambia la tua posizione passando da dipendente in sede a lavoratore remoto. Se qualcuno sta considerando questa cosa, qual è stata la tua strategia? Ovviamente tu ti stai trasferendo, quindi in un certo senso non avevano scelta, ma come hai impostato tutto, e quale sarà la tua modalità da remoto?
Alexa Huston:
Esatto, hai centrato il punto. La mia strategia era: “Mi trasferisco comunque, ma elencherò i vantaggi per l’azienda del fatto che io lavori da remoto.” E sono parecchio fortunata ... Nell’ultimo anno e mezzo, sempre più dipendenti di Crema lavorano da remoto, soprattutto negli ultimi tre mesi è diventata proprio una tendenza.
Quindi è già una direzione su cui l’azienda si sta muovendo: come pensare a un team distribuito, come gestire un team remoto. Mi sento privilegiata per questo. Ma lavorando nel new business ho presentato tutte le opportunità che si aprono su un nuovo mercato, il vantaggio che può portare. Ho anche sottolineato i risultati che sono riuscita a ottenere nella nostra cultura orientata ai risultati. Anche se di solito sono in ufficio, posso già lavorare a distanza, quindi ho evidenziato tutti i vantaggi per l’azienda, poi ho strutturato una strategia di comunicazione e una timeline così che tutti si sentissero tranquilli.
Inoltre, colpo di scena, sono rimasti solo io e un altro ragazzo nelle vendite. Ma man mano che cresciamo, abbiamo capito che serve un po’ di specializzazione, quindi mi hanno consigliato un libro, Predictable Revenue, che è stato utilissimo, e l’abbiamo usato come guida per ridisegnare il nostro processo.
Io mi muoverò verso il top del funnel, più outbound sales, che per me è una novità: campagne email verso aziende che non ci conoscono affatto, sperando che generino nuovi lead, che passeranno poi a Nate, il mio collega, che farà una seconda qualifica e li porterà avanti nella pipeline di vendita.
Finora abbiamo lavorato molto su referenze e strategie poco prevedibili, quindi è un cambiamento su cui sto cercando di investire.
Ben Aston: Tutto cambia… Anch’io ho iniziato a lavorare in agenzia, come contractor, ed è tutto remoto al 100%. È proprio un’altra situazione rispetto a quando lavori in ufficio, dove puoi andare direttamente dai colleghi. Cercare di parlare con le persone può essere una sfida.
Alexa Huston:
È una sfida, è una cosa nuova, anche questa settimana ho inviato messaggi e mi sembrava nessuno ascoltasse, ma era più che altro che dovevo impostare in modo diverso le conversazioni e renderle più orientate all’azione se volevo una risposta, oppure non avere paura a chiamare direttamente se sono disponibili.
Bisogna trovare un modo di chiudere la comunicazione con ...
Ben Aston:
Sì, assolutamente. Io trovo molto utile usare sempre Zoom. La tentazione è quella di stare solo su Slack, ma invece è meglio fare lo sforzo di parlarci. Devi assicurarti di non avere una macchia sulla camicia, ma provare a fare la fatica di conversare veramente con qualcuno invece che inviargli messaggi, secondo me aiuta molto.
Alexa Huston:
Concordo.
Ben Aston:
Allora, hai trovato di recente qualche scoperta che migliora la tua vita?
Alexa Huston:
Un esempio molto semplice ma utilissimo. Ho acquistato un bel quaderno su Amazon, con un segnalibro a nastro e un portapenne laterale. Sto cercando di trovare un equilibrio tra il prendere appunti digitalmente e scriverli a mano. Prima usavo un quaderno senza segnalibro e avevo tutto sparso, mi dava fastidio. È un piccolo cambiamento, ma ora sento molto più organizzata.
Ben Aston:
L’effetto nastro.
Alexa Huston:
Proprio l’effetto nastro, sì.
Ben Aston:
Anche io ho ricominciato a prendere appunti su un quaderno. Ho Trello, Evernote, ma quando scrivo davvero qualcosa a mano riesco a concentrarmi meglio, non vengo distratto dalle notifiche come su pc o smartphone.
Se devo proprio riflettere su qualcosa e prendere appunti, sono molto più efficace scrivendo. Molto meglio che digitare, anche perché su pc o telefono arriva sempre qualcosa che disturba.
Alexa Huston:
Assolutamente, è essere consapevoli di sé, sperimentare diversi metodi, perché anche io uso tanti strumenti e a volte la tecnologia stanca. Quindi provo a semplificare. Scrivo e basta.
Ben Aston:
Sì. E usa il nastro! Prendi un quaderno con il nastro.
Alexa Huston:
Prendi il nastro!
Ben Aston:
Metteremo il link nella trascrizione.
Bene, parliamo ora del tuo articolo e torniamo allo scenario che dicevo all’inizio. Il business team vuole vendere, questa è la tua mansione. Anch’io ultimamente ho lavorato nello sviluppo business. Si vuole vendere, quindi si fa un’offerta grossa e apparentemente generosa al cliente, per vincere il lavoro. Spesso si tende a sottostimarsi un po’, apparire più convenienti rispetto ai competitor. Talvolta si tende a pensare che il primo progetto sia una “loss leader”. Cosa che, per inciso, sconsiglio sempre.
Ma a volte semplicemente si fa una stima troppo approssimativa. Si pensa “Mah, magari va bene così”, si dice al cliente “Ok, lo facciamo per 100.000”, quando in realtà servirebbero 200.000.
Di solito in agenzia si cerca di vendere un servizio ricorrente, un contratto a tariffa fissa, oppure tempo e materiali. Ultimamente si parla tanto di contratti a valore. Ma con tutti questi modelli, una volta firmato il contratto, iniziano i problemi: il PM si trova dover consegnare il progetto senza abbastanza budget.
Ma qual è la strada migliore? Alexa ha scritto un articolo su un nuovo tipo di contratto, quindi leggete l’articolo per approfondire. Ma oggi ne parleremo: è un contratto basato sulla durata e sul prezzo.
Potrebbe essere questa la soluzione ai nostri problemi? Alexa, spiegaci il contratto basato su durata e prezzo. Come funziona? Che cos’è?
Alexa Huston:
Premessa: ci siamo inventati noi il termine, è semplicemente ciò a cui siamo arrivati qualche anno fa. Ma significa letteralmente ciò che dice: abbiamo creato accordi che supportano operativamente le nostre metodologie agili e sono focalizzati sul valore e sui risultati di un progetto invece che su uno scope fisso o dettagli troppo specifici.
In breve, la durata è il tempo in cui il team lavorerà per il cliente, il prezzo è frutto della tariffa oraria per il numero di ore dedicate. Si differenzia dal retainer, dal compenso fisso o dal value-based (che tra l’altro è molto difficile da applicare in agenzia): è solo un metodo più semplice—even se non privo di complicazioni e richiede molta formazione al cliente.
Ma ci sembra il modo migliore per far capire al cliente cosa sta davvero acquistando e permette al nostro team di non essere vincolato a uno scope definito da altri senza tutte le informazioni.
Anche il miglior contratto a scope fisso può essere valido in alcuni casi, ma nello sviluppo prodotto spesso ci sono tante variabili e milestone che cambiano lungo il percorso.
Vogliamo insomma evitare i classici extra costi che capitano nei contratti a compenso fisso.
Podcast correlato: Trovare la giusta sinergia tra Ops e PMO (con Alyson Caffrey di Operations Agency)
Ben Aston:
Quindi, come funziona? Come business development, vendi un team di 5 persone. Il team costa 5k a settimana. Dici al cliente: “Ok, sono 25.000 a settimana.” Poi stabilisci un preventivo? Dici, ad esempio, “Pensiamo che sarà un progetto di quattro settimane, circa un mese, quindi stimiamo 100.000” e cerchi di far approvare questo budget, o dici solo: “Non sappiamo quanto durerà. Sono 25k a settimana, iniziamo subito a fatturare”? Come funziona?
Alexa Huston:
Ottima domanda. Senza entrare troppo nei dettagli, cerchiamo di partire con uno scope più ridotto—magari quattro o sei settimane di design e test di un prototipo, per esempio. Ma cerchiamo di trasmettere comunque l’idea che vogliamo offrire un team prodotto dedicato. Quindi sì, quei cinque ruoli, ad esempio QA, strategist, design e sviluppo. E diciamo: “Per la fase di prototipo, ad esempio, per arrivare a una prima versione della vostra app, serviranno circa 3-6 mesi.” Si negozia la durata e si lavora fino a quella scadenza; anche se si raggiungono i risultati prima, il cliente può usare la squadra per approfondire altre parti del prodotto finché non scade la durata del contratto, sperando magari di proseguire insieme dopo quella fase.
Perché si lavora su backlog e roadmap, spesso a fine contratto a durata/prezzo c’è ancora lavoro da fare ed è facilissimo rinnovare.
“Abbiamo lavorato bene insieme, ci sono altre attività in vista, prolunghiamo la collaborazione e continuiamo.”
Ben Aston:
Ok, quindi cercate di dare al cliente almeno una stima della durata. Tipo, “3-6 mesi”. Come gestite le aspettative su quanto sarà di qualità il risultato prodotto? E come aiutate il cliente a “vendere” l’idea alla propria dirigenza, quando devono giustificare una richiesta da 300.000 euro per una prima fase di prototipo senza certezza di risultato?
Alexa Huston:
È difficile, non lo nascondo. Ci sono diversi aspetti: uno è far capire che non stanno scrivendo un assegno in bianco, ma focalizzare sulla risoluzione dei loro problemi concreti, spiegare il ritorno sull’investimento laddove possibile.
Spesso dobbiamo relazionarci con uno/due referenti che poi devono giustificare tutto ai capi, quindi insistere sul nostro approccio agile e mostrare casi studio simili aiuta.
Lettura correlata: Cos’è lo Scaled Agile Framework®? Spiegazione per Project Manager
Aiuta anche mostrare concretamente il livello di qualità a cui arriveranno. Abbiamo molto investito sul nostro processo di sviluppo prodotto, vogliamo che percepiscano un team esperto, e per noi questa è la migliore alternativa ai loro problemi.
Per semplificare il prezzo, a volte prendo una lavagna, scrivo le risorse, il costo orario, monto una tabellina, così visualizzano la composizione del prezzo. Poi spiego: “Avrete valore perché gestirete le priorità sprint per sprint. Vi consigliamo e supportiamo in ogni passo.” Mettiamo il cliente alla guida del prodotto, sulla priorità del backlog, durante la grooming con il nostro team.
Ben Aston:
Vi capita che il cliente dica: “Mi avevi venduto questa squadra, ma vanno troppo lenti”? Tipo, “Non producono abbastanza, il backlog è lungo e non avanza”?
È una mia paura.
Alexa Huston:
Succede, ed è qui che bisogna applicare metodologie scrum/agile, perché idealmente qualcosa si rilascia già nelle prime settimane. Spesso, l’ansia iniziale del cliente cala appena vede evolvere il progetto. Invitiamo i clienti persino nel nostro software di PM e in Slack, così possono osservare tutto in real time. Ci vuole fiducia, ma quando vedono avanzamenti, anche non utilizzabili all’inizio, riescono a farsi un’idea di dove si arriverà.
Ben Aston:
Quindi coltivate fiducia dando trasparenza. Mostrate tutto anche nei canali interni?
Alexa Huston:
Sì, creiamo due canali Slack per progetto: uno interno per discussioni riservate (su problemi da gestire, ecc.), uno “progetto_collab” con tutti i referenti, dove aggiorniamo costantemente lo stato.
C’è molta trasparenza, e questo aiuta.
Ben Aston: Bene. Nell’articolo citi anche la negoziazione dello scope con il cliente come parte della fiducia. Interessante: come li supportate davvero? Di solito il cliente non è molto “potente” e riporta tutto ai suoi capi. Cercate di salire di livello o gestite solo i referenti?
Alexa Huston:
Per funzionare serve un referente abbastanza autonomo e decisionale nel team cliente. A volte c’è burocrazia: bisogna capire chi decide veramente, lo sveliamo già in fase vendita. L’ideale è che ci sia un product owner con background tecnico/design. Collaboriamo con lui/lei controllando che abbia accesso e potere decisionale, che riveda spesso la roadmap e riorganizzi il backlog fuori dagli sprint.
Magari la settimana prima dello sprint kick-off il backlog viene riordinato, noi affianchiamo e consigliamo. Perché a volte le ipotesi iniziali cambiano. Ad esempio alcune integrazioni possono saltare, o capita che una tecnologia venga chiusa improvvisamente. Ci si adatta in corsa, senza bisogno di change order come avviene coi contratti a scope fisso. Si decide insieme al cliente e si modifica la rotta. Il loro coinvolgimento diretto è la chiave del successo.
Ben Aston:
Parliamo del contratto: che aspetto ha lo statement of work?
Alexa Huston:
È semplice. Preciso che abbiamo rivisto anche la nostra MSA affinché sia allineato con questo modello. Quindi abbiamo adattato anche quello. Usiamo PandaDoc per condividere i contratti; è una piattaforma molto comoda. Manteniamo tutto ad alto livello, indicando “quali sono gli obiettivi di business, il percorso per raggiungerli”, quindi è essenziale avere almeno un quadro di massima su cosa si vuole costruire. Linkiamo eventuali user story, prototipi o materiali di design presenti.
Così si dà chiarezza a tutti, sia quelli direttamente coinvolti sia gli stakeholder esterni. Mettiamo una tabella con le risorse, la tariffa oraria/settimanale, e la durata dell’impegno.
In base alle necessità del cliente aggiungiamo clausole se servono supporto extra orario o altro. Ma il contratto resta semplice, non più le 8-9 pagine di una volta che nessuno leggeva. Ora i clienti sanno cosa stanno acquistando, prima di firmare.
Se tutto va bene, la burocrazia si mette in disparte: serve ovviamente firmare e allineare le idee, ma poi si lavora sprint per sprint senza ansie contrattuali.
Ben Aston:
Hai detto che si preparano almeno delle user story o delle idee. Quindi investite più tempo nella vendita per definire meglio le cose che in passato?
Alexa Huston:
Cerchiamo di evitare di lavorare gratis, quindi è un equilibrio tra analisi dei bisogni in fase vendita e non impegnare troppo la squadra anzitempo. Partiamo magari con una discovery tecnica di una-due settimane, strategia e allineamento, poi aumentiamo il coinvolgimento del team.
Quindi per le prime due settimane il team lavora a basso regime, poi si entra nel vivo. La tabella con prezzi e ruoli si adatta di conseguenza. Così si va a pieno regime su ciò che si è scoperto all’inizio dell’ingaggio.
Alcuni arrivano con tutto pronto, e allora chiediamo: “Sei d’accordo che qualcosa cambierà?” Perché cambierà. Serve molta educazione sia upfront sia strada facendo.
Ben Aston:
Dove può fallire questo approccio? Qualche storia di fallimenti, clienti delusi o PM scontenti?
Sembra tutto perfetto.
Alexa Huston:
Non è una soluzione magica. Serve maturità nel team: se sono alle prime armi con l'agile, o non lavorano insieme da molto, magari non è l’approccio giusto. Se lo scope è già molto definito e il progetto è “a cascata”, va bene così, non c’è bisogno di adattarlo per forza.
I problemi li abbiamo avuti quando ci siamo allontanati troppo dal nostro modo migliore di lavorare, adattandoci alla logica cliente danneggiandoci. Non vuol dire essere rigidi, ma trovare il giusto compromesso.
Questo modello dà potere al PM di suggerire soluzioni migliori per il prodotto, senza la paura di sconvolgere tutto come capita nei contratti a scope fisso. Qui si evita questo problema.
Ben Aston:
A volte, come PM, vorremmo essere strategici e consigliare il meglio, ma per rispettare tempi/budget/scope finiamo per non fare il massimo per il cliente. Che è triste.
Alexa Huston:
Sì, e la cosa utile nel fare questo cambiamento è che ci si interroga molto sul linguaggio da usare nei contratti. È utile sperimentare prima in un contesto interno, senza fatturare ovviamente, ma così si ragiona su come potrebbe funzionare e poi magari fare retrospettive per migliorare ancora.
Coinvolgete anche sviluppatori e designer, capire se hanno già usato questo tipo di approccio, di solito lo gradiscono molto, perché con uno scope rigido spesso non sanno davvero per cosa stanno lavorando finché non sono dentro al progetto—ed è frustrante.
Chiedete ai team coinvolti come la vedono davvero.
Ben Aston:
Ultima curiosità: per chi ascolta e vuole provare, magari con nuovi clienti, meglio testare su un progetto interno? Con quali tipi di progetti funziona meglio e dove invece fatica?
Alexa Huston:
Domanda utile: funziona molto bene sui progetti multipiattaforma. Ad esempio con una startup che voleva un’app iOS, Android e web, con oltre 100 user story—era impossibile stimare tutto in partenza.
Funziona se la runway prodotto è lunga, servono molte persone. Non è ideale per siti marketing, contenuti lineari ecc.—non bisogna applicarlo a tutto a forza.
Se puoi stimare il carico settimanale o mensile, prova e vedi se si adatta.
Serve comunque un team abituato a lavorare insieme, focalizzato sugli obiettivi di business e con un cliente decisionale.
Ben Aston:
Mi piace molto questo punto: formare i team è il primo passo. Se la squadra ha esperienza insieme, il modello funziona meglio. Quindi meglio provare subito su progetti interni, vedere quanta roba si riesce a portare avanti in uno, due, tre mesi. Cosa succede se qualcosa va storto, se bisogna rifare qualcosa. Così si creano dei pod funzionali e si può poi vendere l’esperienza anche ai clienti. Ottimo consiglio.
Alexa Huston:
Verissimo, ci siamo ispirati ad Hanna, un’agenzia spettacolare. Pubblicavano i progetti e vendevano team “a settimana”. È da lì che abbiamo pensato a usare product team dedicati, invece che vendere solo una singola risorsa (“body shopping”).
Che infatti porta solo problemi e silos. Questo modello è per team grandi, non per una singola persona.
Ben Aston:
Sì, non è “body shopping”.
Alexa Huston:
Esattamente.
Ben Aston:
Bene. Allora, il consiglio chiave, quale sarebbe? Per chi fatica a portare avanti questa idea, qualche suggerimento pratico?
Alexa Huston:
So che sembra banale, ma la chiave è comunicare. Anche internamente: tutte le figure coinvolte vanno informate fin da subito. E ovviamente occorre comunicare col cliente i vantaggi, il motivo per cui il modello porta valore vero. Assicurarsi che sia allineato a come lavora davvero il vostro team. Nel nostro caso una cultura agile è stata preziosa. Quindi, spiegare chiaramente i vantaggi e i risultati del modello rispetto all’attività pura è fondamentale.
Comunicare, comunicare, comunicare.
Ben Aston:
Consiglio ragionevole. Spesso i manager decidono di cambiare tutto da un giorno all’altro, senza coinvolgere chi lavora davvero. Comunicare e ottenere l’accettazione delle persone è cruciale.
Alexa, grazie davvero per essere stata con noi oggi, è stato un piacere.
Alexa Huston:
Grazie a voi.
Ben Aston:
Come dicevo all’inizio, Alexa sarà ospite anche nel nostro prossimo corso a settembre: Mastering Digital Project Management. Se non sapete di cosa si tratta ma sentite il bisogno di formazione, dategli un’occhiata: è un corso crash di sette settimane pieno di momenti interattivi, videolezioni, assignment, gruppi di studio, opzionali incontri di coaching. Collegatevi su dpmschool.com e iscrivetevi finché ci sono posti!
E se volete unirvi alla discussione su come contrattualizzare in modo agile, commentate il post o visitate la sezione risorse su thedigitalprojectmanager.com oppure entrate nel nostro team Slack dove troverete tanti spunti interessanti.
Alla prossima, grazie per l’ascolto.
