Fai Funzionare i Contratti Agile per i Tuoi Team e Clienti

Tuttavia, emergono nuove situazioni. Le priorità cambiano. Arrivano imprevisti. Ora hai il piacere unico di dover affrontare ogni tipo di sfida, gestire change order, e cercare in tutti i modi di garantire la soddisfazione del cliente e la redditività dell’agenzia. Siccome tutti i project manager sono supereroi in incognito, probabilmente riuscirai a risolvere tutto, ma l’ambito rigidamente definito contro cui hai dovuto lottare di certo non aiuta.

E se ti dicessi che esistono modi per impostare i tuoi contratti che possono ridurre un po’ di quello stress da mangiarsi le unghie, permettendo al team di dare il meglio?

In questo articolo ti descriverò un tipo di contratto agile che la nostra agenzia di sviluppo prodotto ha adottato negli ultimi anni, che abbiamo chiamato Contratto di Durata e Prezzo. Dopo essere passati a questa tipologia agile di contratto, abbiamo potuto sostenere operativamente le nostre metodologie agili e concentrarci sul valore e sui risultati di un progetto, piuttosto che sui dettagli minuziosi spesso indicati in altri tipi di SOW.

L’obiettivo di questo articolo è aiutarti a comprendere un modo alternativo per strutturare i contratti e i processi agili di agenzia per ottenere risultati e ricavi tangibili.

Contratti di Durata e Prezzo: cosa sono?

I Contratti di Durata e Prezzo sono un termine che abbiamo sviluppato per descrivere il nostro metodo preferito di fare business con i nostri clienti. Con i Contratti di Durata e Prezzo, il costo del progetto viene determinato in base alla durata della partecipazione dei nostri membri del team sul progetto. Vedremo più avanti i dettagli.

Ti ricordi quando hai letto il Manifesto Agile e hai visto quella parte che dice: “collaborazione con il cliente più che negoziazione contrattuale”? È proprio da lì che tutto è iniziato per noi.

Crema è un’agenzia di sviluppo prodotto con un team distribuito in tutto il Paese e sede centrale a Kansas City, Missouri. Dopo oltre 6 anni di contratti a perimetro fisso e approccio a cascata, il nostro team iniziava a sfruttare sempre di più le metodologie agili per lo sviluppo dei prodotti. Volevamo creare un contratto agile che funzionasse per noi e per i nostri clienti. Allo stesso modo, un contratto agile avrebbe sostenuto meglio la nostra cultura collaborativa e la focalizzazione sul valore che stavamo offrendo alle squadre dei clienti con cui lavoriamo. Abbiamo pensato che dovesse esistere una soluzione migliore che elencare dettagliatamente consegne o funzioni ben definite prima ancora che il prodotto fosse davvero avviato.

Dopo alcune ricerche, che vedremo più avanti in questo articolo, il nostro team ha capito che era necessario sviluppare una struttura di pricing che ci permettesse di restare flessibili e contemporaneamente definire ciò che il cliente acquista. Se i nostri clienti, in fondo, acquistano l’accesso ai membri del nostro team, perché dovevamo essere valutati in base ad un elenco di specifiche che sapevamo sarebbero cambiate? Abbiamo iniziato a focalizzarci sull’idea di team di prodotto dedicati, ovvero una serie di ruoli individuali impegnati su un progetto particolare per un determinato periodo di tempo.

Abbiamo iniziato a sperimentare un linguaggio che sostenesse questa idea e fornisse chiarezza ai nostri clienti. Volevamo che capissero che il team di prodotto con cui lavoreranno per raggiungere i loro obiettivi può farlo senza essere vincolato a un perimetro specifico. Questo è possibile perché negoziamo l’ambito strada facendo insieme ai nostri clienti. Stanno pagando per lavorare con un team per una determinata durata. Il prezzo deriva dal numero di membri del team, con diversi livelli di impegno, per un periodo di tempo stabilito.

È così che è nato il nome Contratti di Durata e Prezzo. Ai nostri clienti li chiamiamo Engagement Summary, ma li abituiamo alla terminologia “durata e prezzo” lungo tutto il percorso di vendita fino alla chiusura dell’accordo.

Scomponendo i vari elementi, la struttura è questa:

• La durata è il periodo dell’ingaggio dalla data di inizio autorizzata a quella di conclusione.
• Il prezzo sono i compensi associati all’ingaggio sul progetto, determinati dalle tariffe settimanali dei membri del team di produzione.

Lead Smarter in the Age of AI

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Comments

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Ulteriori Contesti

Nulla di tutto questo è avvenuto in un vuoto. Abbiamo guardato molto attentamente alle altre agenzie di prodotto che ammiravamo in cerca di ispirazione. Il team di Hanno è sempre stata una fonte di ispirazione per noi. Il loro modello era disponibile online all’epoca e dichiaravano apertamente di adottare l’approccio “vendere persone a settimana”. Questa strategia, semplice e diretta, ci ha colpito perché si allineava con il nostro concetto di team di prodotto dedicato. Abbiamo raccolto ciò che potevamo da Hanno e da altri nel settore, iniziando poi a costruire una nostra versione del modello.

Non è successo tutto dall’oggi al domani. Ci sono stati molti tentativi ed errori nel trovare il linguaggio giusto, capire come e dove inserirlo lungo il processo di vendita e—ovviamente—capire come metterlo in pratica una volta ottenuto il contratto. Volevamo sfidarci a cambiare e raggiungere un punto migliore perché gli scope fissi ci costringevano a coprire sforamenti per mesi e, a volte, limitavano il nostro team nell’offrire il miglior lavoro possibile.

Mentre sperimentavamo l’uso di linguaggio più agile nei contratti a scope fisso, abbiamo iniziato a incontrare un potenziale cliente chiamato tilr. All’epoca erano una startup emergente, intenzionata a rivoluzionare il settore delle assunzioni. Abbiamo condotto con loro una sessione strategica di 3 giorni che ha prodotto dei wireframe di massima e oltre 100 user story. Volevano procedere con lo sviluppo completo per piattaforme web e mobile, ma non ci sentivamo a nostro agio a racchiudere tutto in un contratto a scopo fisso. Sarebbe stato completamente aleatorio, e non ci sembrava il modo migliore di avviare una nuova collaborazione con un gruppo con cui ci trovavamo molto bene.

Internamente, abbiamo cercato di trovare un modo per proporre un contratto agile, più grande di qualsiasi cosa avessimo mai fatto prima, senza però passare da un processo di discovery completo. Se ci fosse mai stato un momento perfetto per sfruttare un Contratto a Durata e Prezzo, era quello. Dopo aver individuato quanto tempo avremmo voluto dedicare a progettare/costruire/testare questo nuovo prodotto e i membri del team necessari, abbiamo preso come punto di partenza le user story. Abbiamo chiarito che il team tilr avrebbe pagato per il livello di impegno concordato del team—non per lo scope.

Non fraintendetemi—ci sono stati dei dibattiti interni su questo approccio. Alcuni consigliavano di effettuare una discovery completa per delimitare meglio e specificare lo scope, ma altri temevano che questo potesse farli desistere. Volevamo una relazione a lungo termine con questo cliente.

Alla fine, ci siamo trovati tutti d’accordo e abbiamo inviato il nostro primo vero Contratto a Durata e Prezzo poco prima del Giorno del Ringraziamento 2015, sperando il meglio. È stato un salto nel vuoto e, onestamente, andava contro alcune delle nostre convenzioni di allora.

Una volta nelle mani del cliente, ci sono state alcune discussioni successive con il loro team e una revisione legale abbastanza intensa che ha richiesto qualche settimana. Questo processo ha permesso al nostro team di rivedere diverse volte il contratto agile, affinando il linguaggio e rendendo più solido tutto l’approccio. Col senno di poi, è stata una cosa positiva. Ci è sembrato di aver fatto convergere tre elementi importanti:

1. Ciò che volevano i nostri clienti
2. Come volevamo gestirci
3. Come funzionava la nostra cultura aziendale

E indovinate un po’? Ha funzionato. Sono stati nostri clienti per quasi 3 anni.

Considerazioni sull’Implementazione

Torniamo allo scenario da cui è partito quest’articolo. Il consiglio numero uno che posso dare per prevenire i problemi legati a questo tipo di situazioni è coinvolgere il project management nel processo di vendita (o almeno dare un’occhiata al software di gestione delle risorse clienti). Insieme ai membri del team di produzione, infatti, saranno loro a occuparsi degli aspetti più complessi per garantire che ciò che è stato previsto e promesso possa effettivamente essere realizzato. Se i project manager vengono esclusi dalla fase di vendita, spesso si generano contratti poco ottimali in cui si perdono dettagli e le aspettative su aspetti come la disponibilità verso il cliente non sono allineate.

La cosa più importante nell’implementare qualsiasi tipo di contratto agile è strutturare processi e momenti di confronto in modo che il cliente non creda di avere un assegno in bianco. Prestiamo molta attenzione a evitare che il contratto agile lasci intendere che non sappiamo cosa stiamo facendo. Al contrario, dedichiamo ancora molto tempo all’inizio per identificare cosa e come porteremo a termine il lavoro. Inoltre, abbiamo costruito un processo di sviluppo del prodotto in cui crediamo e che ci dà fiducia.

Prima di andare sul concreto, va detto che bisogna garantire che la vostra MSA o altri accordi esistenti siano revisionati per supportare questa tipologia di rapporto. Questo è fondamentale per assicurare che sia possibile rendere operativo un contratto agile.

Dopo aver verificato che un’opportunità sia qualificata, creiamo una prima bozza di proposta che ripete la descrizione dell’ingaggio, gli obiettivi del cliente e come struttureremmo il team intorno a tali obiettivi. Si tratta di un documento di lavoro che modifichiamo insieme al gruppo cliente alcune volte. Vogliamo assicurarci che il budget sia in linea, così come le tempistiche e altri dettagli specifici. Tipicamente, partiamo con una collaborazione di 4-6 settimane durante la quale realizziamo prototipi ad alta fedeltà dei prodotti per testarli e validare le ipotesi. Nel frattempo, il nostro team tecnico pianifica la tech stack e analizza le eventuali integrazioni e strumenti di terze parti di cui dovremo avvalerci.

Una volta trovata l’intesa, utilizziamo PandaDoc per inviare tutti i nostri contratti. Abbiamo creato un template per il team, così da poter generare facilmente un contratto a Durata e Prezzo appena riceviamo il via libera sulla proposta. È volutamente semplice.

Idealmente, tutte queste sezioni evidenziate – o “token” come le chiama PandaDoc – dovrebbero essere state identificate prima di iniziare lo sviluppo del contratto. Compileremo ciascuna sezione con l’obiettivo generale che intendiamo raggiungere con i nostri clienti e spiegheremo l’approccio che adotteremo per arrivarci (es. 2 cicli di test utente, 3 mesi di sprint di sviluppo prodotto, ecc.).

Successivamente, definiamo i membri del team e i livelli di dedizione che ciascuno avrà per tutta la durata dell’incarico. In questo esempio, ho utilizzato un incarico di 12 settimane con un team prodotto completo, con livelli di dedizione variabili e una tariffa media di $100/ora. È facile fare delle simulazioni e vedere come dedizione, durata e tariffa influiscono sul prezzo.

Nello spirito della trasparenza, dovrei anche menzionare alcune cose:

• Anche se i membri del team hanno tariffe orarie diverse, è possibile modificarlo nella seconda colonna per ottenere i rispettivi subtotali.
• Noi consideriamo “full time” 35 ore settimanali su lavoro cliente. Lasciamo 7 ore aggiuntive ogni settimana perché i membri del team possano dedicarsi a progetti interni e attività generali di gestione.
  • Spieghiamo questa cosa ai nostri clienti. Serve a tenere sotto controllo l’idea che i clienti possano avere accesso illimitato ai membri del team per tutta la durata dell’incarico.
  • Se si ha bisogno di elencare orari di lavoro/supporto più specifici per un particolare progetto, si può farlo nel Riepilogo dell’Incarico (Engagement Summary). Si tratta di uno strumento pensato per essere ampliato a supporto degli obiettivi del cliente.

Ottenere Supporto per un Contratto Agile

Se c’è un tema principale che attraversa tutto questo articolo, è la comunicazione. Per ottenere il coinvolgimento per un contratto agile, dovresti aspettarti di investire una considerevole quantità di tempo in ricerca, formazione e iterazione interna del tuo approccio. Metti idee sul tavolo con il gruppo. Sperimenta un contratto agile su un progetto interno. Conduci retrospettive di progetto per monitorare cosa funziona e cosa va migliorato. Chiedi al tuo team di produzione se hanno già lavorato in passato con diversi tipi di contratti agili.

Una volta che vi siete allineati internamente, dovrai formare potenziali clienti ed effettivi clienti – non solo all’inizio, ma durante tutto il processo. Parla loro delle sessioni periodiche di raffinamento del backlog. Ricordagli che saranno loro alla guida quando si tratta di fissare priorità e decidere cosa affrontare in ogni sprint. Rimarca il focus sul valore e sui risultati, non sulle singole funzionalità. Ci sarà tempo per entrare nei dettagli delle funzionalità a mano a mano che uno sprint viene pianificato e avviato.

Non esiste una soluzione miracolosa per allineare tutti. Serve avere fiducia nell’idea, essere disposti a sperimentare e avviare un processo di formazione continua. Se pensi che questa tipologia di contratto agile possa funzionare per la tua azienda, trova internamente dei sostenitori che condividano questo approccio e partite insieme!

Vantaggi e Svantaggi

Come per la maggior parte delle cose nella vita, anche per i Contratti a Durata e Prezzo esistono pro e contro. Lo facciamo da circa 3 anni e abbiamo riscontrato che quanto segue corrisponde alla realtà. Cominciamo dagli aspetti positivi.

Vantaggi:

• I Contratti a Durata e Prezzo accelerano il completamento delle pratiche formali per l’avvio di un progetto.
• Limitano il peso degli obblighi contrattuali una volta avviato il progetto. Il team può cambiare direzione se/dove necessario.
• Per questo motivo il team può concentrarsi nel fare il proprio lavoro nel migliore dei modi.
• Il team può anche proporre idee a beneficio del prodotto senza paura di sconvolgere tutto il perimetro del lavoro. Si può così creare più valore in meno tempo, visto che non si è vincolati da un documento di definizione del perimetro.
• Mette il cliente a capo del tavolo. Può prendere decisioni lungo il percorso. Anche se qualsiasi cliente pensa di sapere cosa vuole prima dell’inizio di un progetto, le cose cambieranno. I Contratti a Durata e Prezzo supportano questa realtà.
• Poiché il contratto può in genere passare in secondo piano, favorisce il rapporto nel suo complesso. Il team può concentrarsi sul prodotto e il valore che porta all’attività.
• Semplificano la pianificazione delle risorse. Teniamo le nostre dediche semplici: un quarto di tempo, metà tempo o tempo pieno.
• La dedizione full-time dei membri del team è ideale dal punto di vista dell’utilizzo. Cerchiamo di offrirla quanto più spesso possibile, soprattutto per i ruoli di sviluppo.
• Alla fine, veniamo comunque pagati, ma c’è meno burocrazia (overhead) per gli ordini di cambiamento e altri problemi che sorgono con scopi fissi. Dì addio a certi problemi amministrativi!

Svantaggi:

• È una vendita più difficile. Devi impegnarti nel lavoro di formazione sin dal primo giorno con i potenziali clienti e ribadire il processo e il valore affinché si sentano a loro agio con un contratto agile. Chi ha molta esperienza di solito ci è già passato e capisce. I clienti meno esperti potrebbero avere bisogno di alcune analogie per comprendere meglio cosa sia un contratto agile. Dedica tempo all'educazione!
• Potresti dover allungare i tempi di chiusura dell'accordo per assicurarti che tutti siano a proprio agio con gli obiettivi della collaborazione.
• Dal punto di vista del business, questo limita la possibilità di ottenere un grande margine di profitto. Se il team termina qualcosa in anticipo, non puoi godere del vantaggio di quel profitto extra. La buona notizia è che il margine è affidabile, ma non puoi trattenere alcun eccesso dovuto all'efficienza.
• Se questi contratti agili vengono adottati su larga scala, potrebbero diventare troppo utilizzati per qualsiasi situazione. In realtà, alcuni progetti non sono adatti a essere gestiti in base a durata e prezzo. Se il tuo team è inesperto o nuovo ai processi agili, non è un approccio raccomandato.
• Allo stesso modo, durante la crescita di un'organizzazione, è giusto utilizzare contratti a scopo fisso per progetti di piccola entità, ben definiti.

Relazione con altri tipi di contratti

Esistono molti altri tipi di ambiti di lavoro che le aziende usano per gestire questo tipo di servizio. Ecco come pensiamo che i Contratti a Durata e Prezzo si differenzino dalle altre opzioni.

• Prezzo basato sul valore: È difficile da applicare in un contesto di agenzia senza avere una chiara comprensione di quale sarebbero i risparmi per il cliente nel lungo termine e basare il prezzo proprio su questo. I Contratti a Durata e Prezzo si concentrano sul valore, ma non determinano l'importo basandosi sul valore stesso.
• Ambito fisso: Abbiamo confrontato questo tipo di contratto per tutto l'articolo, ma in un contratto ad ambito fisso, i team sono vincolati a uno specifico set di deliverable. I Contratti a Durata e Prezzo non sono vincolati ai deliverable, ma piuttosto a una visione condivisa e a risultati attesi.
• Tempo e Materiali: In questo tipo di accordo, vieni pagato solo per quello che completi. Con i Contratti a Durata e Prezzo, viene fatturato un importo fisso per le risorse impegnate su un progetto per una durata prestabilita. Non fatturiamo a ore, anche se monitoriamo come i membri del team dedicano il loro tempo, soprattutto per le risorse impiegate a metà tempo o a un quarto del tempo, così possiamo aiutare a gestire eventuali difficoltà nella gestione del tempo.

Parole di saggezza dal nostro COO

Ho chiesto direttamente al nostro COO, Dan Linhart, quando ho deciso di scrivere questo articolo, per avere una visione completa dell'impatto che ha avuto e continua ad avere sulla nostra azienda. Mi ha condiviso alcune perle di saggezza che vale la pena riportare.

Per cominciare, ha detto: “È incredibilmente importante coinvolgere tutti i ruoli nelle fasi iniziali. Questo include i proprietari, il business development, i ruoli di produzione e gli strateghi. Se non si allineano tutti, semplicemente non si va avanti.”

Ha sottolineato l'importanza della promozione interna dell'idea e della formazione per tutte le parti interessate dell'agenzia. Anche se provi la sindrome dell’impostore, continua e impara sempre di più sul modello. Mi ha detto: “Se riesci a convincere il tuo team, puoi vendere anche al cliente.” I clienti potenziali devono conoscere i vantaggi dell’agile e dei contratti agili, così da alleviare le loro ansie. Devono essere in grado di comunicarlo anche ai loro interlocutori interni.

Oltre a questo, c’è un grande impatto di questo tipo di contratto agile sulla cultura aziendale. Vuoi assicurarti che sia integrato nel modo in cui lavori come team. In Crema, questo contratto agile si integra perfettamente con la nostra filosofia e il nostro modo di sviluppare prodotti. Se la tua organizzazione si basa di più su un modello a cascata, va bene continuare a seguire le specifiche.

Infine, non temere di provare. Puoi sperimentare i contratti a Durata e Prezzo anche solo per una settimana. La bellezza di questo modello è che può essere scalato da una settimana a più anni, a seconda dei processi e della maturità dell'organizzazione. Coinvolgi le persone giuste per gestire quel tempo, dai responsabilità al team e al cliente, e preparati all'assetto di lavoro ideale di un team agile.

Disclaimer: Questo articolo ha lo scopo di informare e ispirare un modo più semplice per approcciare un contratto più agile. Non è esaustivo né fornisce indicazioni legali. Spero che alcuni dei contenuti possano esserti utili nella tua agenzia o attività.

E adesso?

Approfondisci l'agile e i suoi concetti chiave seguendo una di queste certificazioni agile.