Passare dai Contratti Waterfall ai Contratti Durata & Prezzo (con Tucker Sauer-Pivonka di Crema)

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Scusate eventuali errori, il bot non è sempre preciso al 100%.

Ben Aston:

Benvenuti al Podcast DPM, dove andiamo oltre la teoria per dare consigli pratici su come guidare al meglio progetti digitali. Grazie per esservi sintonizzati, sono Ben Aston, fondatore di The Digital Project Manager. I progetti raramente seguono il piano prestabilito e quando i piani cambiano, spesso si genera parecchio stress. Bisogna fare telefonate, organizzare riunioni, aggiornare i piani, ricalcolare le stime e, di solito, emettere richieste di variazione. Ma se ci fosse un altro modo per gestire i cambiamenti nei tuoi progetti? In questo podcast, solleveremo il coperchio su un modo diverso di gestire il cambiamento con i contratti agili. Continua ad ascoltare per capire come far funzionare i contratti agili per te e conoscere vantaggi e sfide di questo approccio.

Oggi sono con Tucker Sauer-Pivonka, Direttore della Gestione di Prodotto, aiutando davvero product manager a crescere e svilupparsi. Inoltre, è responsabile anche dello sviluppo delle best practice. Ciao Tucker.

Tucker Sauer-Pivonka:

Ciao Ben, piacere sentirti oggi.

Ben Aston:

Anche per me. Una delle cose che volevo chiederti, proprio all’inizio: so che parte del tuo ruolo riguarda lo sviluppo del team. Mi chiedo se puoi condividere qualche spunto su ciò che hai scoperto funzionare davvero per aiutare il tuo team a crescere ed evolversi. Forse in riferimento ai tipi di contratto che utilizzate o sperimentate. Come nutri il team e lo aiuti a crescere? Cosa hai scoperto che funziona per te?

Tucker Sauer-Pivonka:

Sì. Penso che la prima cosa da riconoscere subito è che ognuno apprende in modo un po’ diverso, e ognuno ha bisogno di modalità diverse di coaching. Quindi, una delle prime cose che faccio con i membri del mio team è sedermi con loro ed iniziare a valutare proprio questo. Come apprendono? In che modo preferiscono ricevere i feedback? Come apprezzano i riconoscimenti? Tengo traccia di tutto, così posso adattare il mio approccio in modo che ognuno risponda meglio. Passo molto tempo a fare one to one con loro, su diversi argomenti di crescita. Insomma, li alleno su qualunque cosa con cui stiano avendo difficoltà in quel momento. Sono temi che emergono di volta in volta e li affrontiamo insieme. Inoltre, presso Crema abbiamo uno studio di gruppo su un libro chiamato Multipliers.

Questo è un grande aspetto della crescita del team. E, ovviamente, ci sono anche le conferenze. Abbiamo una conferenza tra poco, a fine settembre, a cui parteciperemo, dedicata anche alla gestione di prodotto. Andranno tutti insieme, non solo per fare team building, ma anche per imparare argomenti nuovi.

Ben Aston:

Bene, come si chiama questa conferenza, lo sai?

Tucker Sauer-Pivonka:

Si chiama Industry: The Product Conference, si tiene a Cincinnati, se ricordo bene.

Ben Aston:

Festa a Cincinnati, se volete unirvi a Tucker e al suo team. Vorrei approfondire… hai detto che col team trattate diversi argomenti. Sei disposto a condividere quali temi o aree aiuti il team ad affrontare in particolare? E quali sono le difficoltà che stanno incontrando e che tu li aiuti a superare?

Tucker Sauer-Pivonka:

Sì, credo che sia molto diverso da persona a persona, perché ciascuno ha livelli di competenza diversi. Quindi ognuno affronta problemi diversi. Ma molte delle questioni che trattiamo in gruppo riguardano proprio la gestione del cliente. Del tipo: “il mio cliente ha detto questo, oppure il cliente chiede di fare qualcosa di cui non abbiamo parlato, come dovrei gestirlo?”. Non ho ora l’esempio perfetto, ma capita spesso una situazione simile.

Gli aspetti di gestione del cliente sono tra i più difficili da insegnare: si finisce spesso nel discutere su “mi sentivo strano a riguardo… era giusto o no? Dovrei gestirlo diversamente la prossima volta?”. Queste sono tipicamente le direzioni verso cui vanno le nostre conversazioni.

Ben Aston:

È vero. Ci sono capacità trasversali (soft skill) da sviluppare nella gestione clienti e nella gestione del team. Non esiste una risposta giusta unica. Dipende sempre. Ma si può migliorare sempre. Ecco, hai menzionato la conferenza: mi interessa sapere dove trai ispirazione e come resti aggiornato. Come rimani attuale e dove trovi la tua ispirazione?

Tucker Sauer-Pivonka:

Uso diversi canali. Libri, sì, ma anche molti articoli: Medium è una delle mie risorse preferite su temi di gestione prodotto e gestione team. Ricordo sempre che su Medium chiunque può pubblicare, quindi vanno presi con le pinze: non sono sempre esperti, ma offrono comunque spunti utili su come affrontare varie situazioni.

Oltre a quello, seguo molte tendenze dell’industria: Wired, per esempio. Mi aiuta ad essere aggiornato sulle novità tecnologiche, anche al di fuori del mondo del project management.

Ben Aston:

Fantastico. E nel campo tecnologico, sei una persona all’avanguardia? Qual è l’ultimo gadget che hai comprato?

Tucker Sauer-Pivonka:

Bella domanda. Vorrei avere qualcosa di entusiasmante da raccontare, ma non sono proprio sul filo del rasoio. Sono un early adopter, ma non primissimo. Se posso, provo nuovi prodotti appena escono. Adesso, punto il nuovo iPad. Ho già un iPad Pro che va bene, ma vorrei il nuovo modello anche se, tutto sommato, quello attuale funziona perfettamente. Quindi non posso giustificarlo.

Negli ultimi tempi mi sono interessato alle ultime versioni di iOS e iPadOS, tutto quello che è stato presentato a WWDC. Ho pensato molto su come impatteranno sull’industria – e magari anche sui prodotti che sto creando. E poi sì, sono un po’ nerd di Zelda, ed è appena stato annunciato il sequel di Breath of the Wild, quindi sto impazzendo anche per quello.

Ben Aston:

Bene! Io invece ho messo in lista di prossimi acquisti il DGI Rover – non so se si chiami davvero Rover, ma hanno presentato quella specie di piccola telecamerina su un carro armato che ti costruisci. Sembra fantastico.

Tucker Sauer-Pivonka:

Sembra divertente!

Ben Aston:

Già. È una di quelle cose che ci si chiede: “Ne ho davvero bisogno?”. Ovviamente penso ai figli, si divertiranno! A proposito del tuo iPad Pro: hai trovato altre soluzioni hardware o software che ti stanno semplificando la vita e che tutti dovrebbero conoscere?

Tucker Sauer-Pivonka:

Negli anni ho sempre cercato il giusto bilanciamento tra appunti manoscritti, note digitali, gestione delle attività… Mi incuriosisce il fatto che scrivere a mano si assimila diversamente rispetto al digitare, e quindi ho sempre cercato la soluzione ottimale. Per un periodo prendevo appunti su iPad con Apple Pencil, e mi sono trovato bene. Oggi sono a metà strada: uso sia iPad o computer come archivio definitivo per il lavoro, sia un piccolo taccuino cartaceo per le note e le attività quotidiane.

Alla fine della giornata, trasferisco note e attività nell’app Todoist, per avere tutto sotto controllo. Sto cercando di strutturare così il mio workflow: mi aiuta a comprendere meglio ciò che faccio e a gestire le priorità in modo più efficace, anche in termini di gestione del tempo.

Ben Aston:

Interessante, quindi usi un taccuino fisico per le note? Sei tornato all’analogico per appunti e promemoria?

Tucker Sauer-Pivonka:

Esatto. Poi però passo tutto in digitale. Personalmente, niente può sostituire il gesto di aprire il taccuino, cliccare la penna e iniziare a scrivere. Prendere note su iPad con la Pencil è ottimo, ma (sembra banale) devi aprire l’app corretta, trovare il taccuino virtuale giusto, assicurarti che la Pencil sia carica… piccole barriere che però, alla lunga, frenano davvero il processo.

Così mi ero ridotto a portarmi dietro iPad e un’infinità di post-it. Scrivo su un post-it appena ho un’idea – e a quel punto ho pensato che non fosse sostenibile. Da qui la decisione di passare a un vero taccuino.

Ben Aston:

È una battaglia che vivo anche io. La mia soluzione è Evernote: un taccuino per le cose da fare, un altro come “scratchpad”, area appunti grezzi che poi trasferisco nella to-do list. E uso un mini blocchetto così piccolo da non poterci scrivere più di un promemoria: così sono costretto a non creare liste duplicate ovunque.

Ma parliamo dell’articolo e del case study che hai scritto per noi. Parla proprio del passaggio da contratti stile waterfall a contratti durata e prezzo. Abbiamo già parlato di contratti agili e anche nella DPM School ci hanno chiesto esempi di contratti agili (Alexa ne ha scritto un ottimo articolo). Ma per chi non li conosce: puoi spiegare brevemente cos’è un contratto durata & prezzo e come funziona?

Tucker Sauer-Pivonka:

Sì. Lo spiego dal punto di vista di come lo facciamo noi, a Crema. Non è per forza una formula universale ma è quella che conosco meglio. Un contratto Durata & Prezzo ruota tutto attorno a un team dedicato: per esempio, due sviluppatori full time, un tester part time, un designer per metà tempo, e un product manager, magari insieme a uno stratega. Entrambi a un quarto di tempo.

L’attenzione si sposta quindi sulla composizione del team e sugli obiettivi, invece che sull’elenco dettagliato di deliverable e funzionalità, con stime orarie accanto. Perché? Perché il software è troppo complesso per essere stimato tutto in anticipo – le cose non vanno mai secondo i piani.

Questi contratti ci consentono di spostarci dove c’è più valore per il cliente. Ogni fine ciclo si valuta e si riorienta, così si consegna il maggior valore possibile. In un contratto “chiuso prezzo” invece le priorità del business possono cambiare in sei mesi, e rischi di consegnare cose inutili al cliente: questo metodo agile ti consente di adattarti davvero ai bisogni del cliente, mentre lavori.

Ben Aston:

Hai parlato dei progetti per cui i contratti agili hanno senso: sviluppo software, sviluppo prodotto. Ma hai incontrato casi in cui questo contratto durata/prezzo non ha funzionato?

Tucker Sauer-Pivonka:

Credo che dipenda dal tipo di lavoro. Da noi funziona perché sviluppiamo prodotti complessi e non puoi dettagliare tutto in anticipo, ci sono troppi rischi. Se stai creando siti web molto simili tra loro, con processi ripetibili, allora forse un contratto “chiuso prezzo” (fix-go) ha più senso: la prevedibilità è più alta. Dipende sempre dalla natura del lavoro: più prevedibilità, più senso ha un contratto classico.

Ben Aston:

Un altro tema emergente è il value-based pricing, ovvero il prezzo basato sul valore. È una cosa diversa dal modello durata/prezzo, in cui il cliente acquista “ore” di team. Come si confronta questo modello con il value-based pricing dal punto di vista della marginalità e semplicità di gestione? Hai situazioni in cui, ad esempio, con il value-based pricing avresti potuto guadagnare di più, rischiando meno?

Tucker Sauer-Pivonka:

Sono due logiche diverse. Nel nostro caso, sviluppando prodotti ampi, all’inizio non è chiaro quale sarà il risultato finale, quindi è impossibile mettere un prezzo fisso collegato al valore. Il value-based pricing funziona meglio su progetti ben delimitati, ad esempio uno sprint di design, ma su grandi sviluppi diventa complicato.

In termini di profittabilità, il bello dei contratti durata/prezzo è che la marginalità si regola da sola: quello che “vendi” è il team stesso, non le ore o le funzionalità. E non c’è rischio di essere scoperti sulle stime o andare fuori budget, perché si consegna valore continuo, non ore tracciate. Il rischio di essere sotto o sopra le ore non esiste perché non si ragiona in termini di ore vendute.

Ben Aston:

Quindi il cliente compra un team per un periodo di tempo? Ti è mai successo che dopo alcune iterazioni il cliente si dica insoddisfatto del valore ricevuto? Come gestisci questo scenario in cui il cliente sente di non aver ottenuto il valore sperato dal tempo acquistato?

Tucker Sauer-Pivonka:

Non capita spesso, in verità. Il motivo è che lavoriamo molto sulla trasparenza e l’allineamento con il cliente, durante tutto il processo: non solo all’inizio del ciclo, ma anche man mano che emergono cambiamenti. La comunicazione è fondamentale e parte della gestione progetto consiste proprio in questo confronto continuo.

Parliamo apertamente di deviazioni, delle motivazioni, di cosa abbiamo scoperto strada facendo e perché cambia la stima. Mettiamo tutto sul tavolo e lasciamo che il cliente decida se, ad esempio, preferisce cambiare direzione. Così il dialogo è costante e il cliente si sente davvero coinvolto.

Ben Aston:

Bene. Parliamo del case study e di come hai stimato la timeline. In quel caso hai stimato almeno 7 mesi di lavoro. Come ci siete arrivati, nonostante non fosse tutto definito? L’avete stimato dopo la fase di prototipazione?

Tucker Sauer-Pivonka:

Sì, in quel caso e in molti altri avevamo già fatto una fase preliminare di prototipazione e audit tecnico. Quindi, grazie a queste attività, abbiamo stimato la durata necessaria a raggiungere gli obiettivi. Con l’esperienza, sviluppi il “naso” per valutare le tempistiche in base alla complessità delle parti coinvolte.

La durata però, nel nostro modello, non si basa su deliverable ma sugli obiettivi di business. Era chiaro che c’era lavoro sufficiente per almeno 7 mesi, focalizzati sugli obiettivi prioritari, compatibilmente con il budget e la disponibilità del cliente (che, sappiamo bene, nel software non è mai “finito”).

Ben Aston:

Quindi una parte della valutazione era: capire col cliente fino a che punto si può spingere il budget e la durata, vero?

Tucker Sauer-Pivonka:

Esatto. Se il cliente vuole solo 3 mesi, va bene, si lavora sulle cose prioritarie in quel periodo. È come “noleggiare” un team: ottieni quello che il team può produrre in quei mesi, scommettendo sempre sul valore più alto.

Ben Aston:

La fase di prototipazione invece era a prezzo fisso, su sei settimane? Quanto erano definiti i deliverable in uscita?

Tucker Sauer-Pivonka:

Tecnicamente anche la prototipazione rientra nel modello durata/prezzo, ma assomiglia di più a un prezzo fisso. Qui vengono definiti alcuni deliverable specifici (prototipo ad alta fedeltà, file di design, risultati delle interviste utente…). Se però emergono nuove esigenze a metà, siamo pronti a cambiare, sempre restando entro la durata e il prezzo concordati.

Ben Aston:

È fondamentale, perché spesso si rischia di deragliare già in fase di prototipazione. Con il modello durata/prezzo si riesce quindi a gestire facilmente i cambi di rotta.

Quindi dopo le sei settimane di test e prototipo, avete prodotto questa stima di 7 mesi di lavoro. È stato un calcolo bottom-up o top-down? Siete partiti dal budget disponibile o dal lavoro necessario?

Tucker Sauer-Pivonka:

In quel caso, abbiamo combinato le due cose: valutazione della complessità (tramite “taglia maglietta”) e un’idea tecnica di roadmap. La proposta è stata presentata come bozza, pronta a essere adattata sulle esigenze e priorità emerse col cliente. Abbiamo costruito la roadmap insieme a loro, stimando i tempi area per area, fino a comporre i 7 mesi.

Ben Aston:

Chiaro.

Tucker Sauer-Pivonka:

Quando abbiamo condiviso la proposta, abbiamo anche chiarito che poteva essere aggiustata: se serviva partire con 3 mesi, si poteva iniziare da lì. Era chiaro che avrebbero avuto la roadmap personalizzata per il loro MVP, su base empirica, da ridefinire insieme se necessario.

Ben Aston:

Bene. Parliamo un secondo del metodo. Nel case study hai detto di aver usato un approccio agile-scrum: quanto seguite il manuale Scrum e dove invece lo adattate alle vostre necessità? Mi incuriosisce soprattutto il ruolo del product owner e se lo ricopre il cliente o uno di voi.

Tucker Sauer-Pivonka:

Da noi si dice spesso: “le persone prima dei processi”. Penso di aver rubato questa frase a qualcuno… Applichiamo “scrum con la s minuscola”: lasciamo flessibilità al team di adattare il processo quando serve. In agenzia è più difficile mantenere i ruoli rigidi del manuale Scrum, come può fare Apple in azienda. Quindi da noi il product owner tipicamente è il referente principale lato cliente, a cui però affianchiamo uno strategist interno come co-owner e coach, dato che alcuni clienti non hanno esperienza come proprietari di prodotto digitale.

A volte certe responsabilità possono ricadere sul product manager interno, specie se il cliente non riesce a garantire la presenza quotidiana. Quanto a Scrum master e product manager, spesso li uniamo in un solo ruolo, il che va contro il manuale Scrum, ma per noi funziona: ci occupiamo delle cerimonie, degli stand-up (spesso automatizzati), della rimozione dei blocchi e delle decisioni di prodotto.

Queste sono le due maggiori deviazioni rispetto a Scrum “con la S maiuscola”. Il resto lo seguiamo piuttosto alla lettera: planning, stime, retrospettive, demo prodotto… Li concentriamo di solito in un unico meeting alla settimana, chiamato Kick-Off del mercoledì.

Ben Aston:

Quindi il product owner può essere il cliente o uno del vostro team. Vorrei affrontare il tema del cambiamento: nel case study hai parlato di conflitti di priorità tra vecchio e nuovo prodotto. Come gestite questi conflitti col cliente? Come lo aiutate a gestire il backlog, sia a livello teorico che pratico?

Tucker Sauer-Pivonka:

La prima cosa da fare è essere molto empatici e capire la causa reale del cambio di priorità. La maggior parte delle volte il cliente non vuole cambiare priorità, ma si trova costretto per esigenze di business. Quindi la comunicazione deve essere chiara, trasparente e bisogna spiegare che ogni cambio di priorità cambia il piano complessivo.

Se emergono nuove urgenze, lo comunico subito al mio team spiegando il contesto reale, in modo da allineare tutti e togliere eventuali malumori. Durante tutto il progetto controllo spesso che il cliente abbia chiaro che ogni cambiamento ha delle conseguenze sulle scadenze e sui risultati attesi. Si tratta di coinvolgerli e responsabilizzarli su ogni scelta, così da minimizzare le incomprensioni.

In termini di strumenti, più la situazione è visuale, meno rischi di fraintendimenti. Che sia Jira o altro, è importante che il cliente abbia accesso e veda lo stato reale delle cose. Spesso un’immagine spiega più di tante parole.

Ben Aston:

Quindi il cliente ha accesso a Jira?

Tucker Sauer-Pivonka:

Sì, assolutamente. Massima trasparenza: sono nostri ospiti anche su Slack. In Jira possono vedere tutto, verificano priorità e requisiti. Questo evita fraintendimenti in sprint review o a fine ciclo.

Ben Aston:

Nel case study hai anche parlato di costruire un rapporto di fiducia tramite trasparenza e artefatti aggiornati (roadmap, burn-down chart ecc). Con clienti meno tecnici, come eviti che si sentano sopraffatti da tutti questi strumenti?

Tucker Sauer-Pivonka:

È importante essere umili nell’ammettere errori e mostrarne la soluzione: aiuta a instaurare fiducia perché il cliente capisce che non gli stai nascondendo nulla. Se un cliente si sente sopraffatto dai tool, non li obblighiamo a usarli, ma lasciamo che siano a disposizione. Per agevolarli creiamo video guida personalizzati sulle funzionalità essenziali di ciascuno strumento, e teniamo la porta aperta a qualunque segnalazione di disagio.

Su grandi prodotti può capitare che l’accumulo di materiali visivi e deliverable generino ansia da overload. Il trucco è consegnare le cose in modo iterativo, a piccoli blocchi, non tutte insieme. Non sempre ci si riesce, ma essere trasparenti e proattivi mitiga questi rischi.

Ben Aston:

Qual è il livello di reportistica che date al cliente? Tracciate e condividete le ore spese, o semplicemente consegnate il risultato dicendo “hai comprato il team per questo periodo”? Come funziona?

Tucker Sauer-Pivonka:

Puntiamo tutto sui risultati concreti consegnati ogni sprint: a fine sprint facciamo il punto su cosa è stato completato, cosa no, indaghiamo su eventuali scostamenti della velocità, e spieghiamo le cause. È il risultato che garantisce il corretto uso delle risorse.

Non condividiamo il dettaglio ore, il cliente compra il team e non le ore di sviluppo delle singole feature. Internamente, invece, monitoriamo le allocazioni: se qualcuno supera il tempo concordato, si avvisa il cliente e si ridefinisce l’impegno. Se al contrario qualcuno lavora meno del previsto, si valuta se ridurre l’allocazione (cosa molto rara). Ma nulla di tutto ciò viene fornito al cliente: il focus è sempre sulle cose fatte e su quelle da fare.

Ben Aston:

Benissimo. E chiudo chiedendo: quando e come il modello durata e prezzo può non funzionare? Ti è mai capitato di vederlo naufragare? Se qualcuno volesse adottarlo, a cosa dovrebbe stare attento?

Tucker Sauer-Pivonka:

Può capitare che il cliente si senta deluso dai progressi. In questi casi bisogna cogliere i segnali in anticipo: appena senti che c’è qualcosa che non va, è meglio affrontare la questione di petto con una conversazione franca e empatica, magari ripercorrendo insieme il percorso e le decisioni. Se si aspettano che si raggiunga di più, bisogna spiegare quali priorità sono cambiate e perché. Questi chiarimenti aiutano a ristabilire la fiducia e a rimettere in carreggiata il rapporto.

Non ho mai assistito a veri disastri. Mi è capitato di gestire rinnovi in cui il cliente era poco soddisfatto dei tempi, ma dopo un confronto trasparente hanno compreso le ragioni e ci siamo riallineati. Ogni volta che si supera uno scoglio simile il rapporto si rafforza: è importante che il cliente abbia sempre la sensazione di poter dirigere le priorità. Se però la sintonia non si trova, meglio dirselo subito e, se necessario, aiutare il cliente a trovare un partner più in linea con le sue esigenze.

Ben Aston:

Concordo: serve il cliente giusto per far funzionare questo modello. Serve maturità, trasparenza e capacità di gestire aspettative e cambi di priorità (e di costi). Bisogna anche saper educare il cliente già in fase di vendita e prototipazione, per prepararli a cosa aspettarsi dal rapporto. Il vantaggio, però, è che alla fine il cliente riceve davvero il massimo valore prioritario lungo tutto il percorso, invece di “trucchi” per rientrare in tempi e budget.

Penso che i contratti durata/prezzo siano un concetto molto interessante di cui discutere. Grazie mille Tucker per essere stato con noi oggi.

Tucker Sauer-Pivonka:

Grazie a voi, è stata una bellissima conversazione.

Ben Aston:

E voi cosa ne pensate? Avete mai provato un contratto agile? Raccontatecelo nei commenti qui sotto e visitate TheDigitalProjectManager.com per unirvi alla nostra community Slack, dove si tengono discussioni su tutti i temi del project delivery. C’è anche un canale agile, sarebbe bello parlarne lì.

Se vi è piaciuto quello che avete ascoltato oggi, iscrivetevi e lasciate una recensione sincera al podcast DPM su Apple Podcasts. Le valutazioni e recensioni ci aiutano tantissimo e sono davvero apprezzate. Alla prossima e grazie per l’ascolto.