Contratti = Aspettative

Tutte le relazioni cliente/fornitore si basano su un insieme di aspettative, che siano scritte oppure no. Quando assumete un imbianchino, l’atto di applicare la pittura è solo parte dell’ingaggio. Tutti gli step che portano al lavoro finito si trovano nei dettagli.

Mi aspetto che l’imbianchino:

• arrivi a casa mia in orario
• sposti tutti i mobili necessari per poter lavorare
• copra le cose con dei vecchi stracci
• non fumi in casa mia
• non pulisca i pennelli nel lavandino della mia cucina
• sia rispettoso e professionale
• finisca il lavoro in tempo
• lasci la casa come era prima che cominciasse il lavoro

Non mi aspetto che l’imbianchino:

• dia da mangiare al mio cane mentre sono al lavoro
• imposti il mio sistema di allarme
• pitture zone che non ho richiesto
• applichi tre mani di vernice

In ogni progetto, piccolo o grande che sia, molte cose non vengono dette o specificate. Non essere precisi può portare a disaccordi, battibecchi e pressione alta.

Per quel che riguarda il mio lavoro quotidiano, mi trovo dall’altra parte della barricata: in Happy Cog, lavoriamo ogni anno con dozzine di clienti. Negli anni, si imparano una o due cose, solitamente come risultato di errori fatti durante il percorso. Una relazione d’affari è governata da quello su cui ci si accorda da entrambe le parti. Uno “Statement of Work (SOW)” o “Statement of Services (SOS)” [dichiarazione dei servizi, ndr] è uno strumento utilizzato per allineare le aspettative. Di solito usavamo il SOW e lo SOS come sinonimi della parola “contratto” o “proposta”, ma in realtà sono un po’ diversi. In qualunque modo li chiamiate, vi salveranno la pelle.

SOW e MSA#section1

Uno Statement of Work (SOW) è solitamente un documento che accompagna ancora un altro documento, a cui spesso si fa riferimento come Master Services Agreement (MSA). Sono i Lenny and Squiggy degli accordi legali. Il MSA è solitamente un documento fondamentale per l’intera relazione, mentre il SOW gestisce di solito le specifiche di un singolo progetto o ambito di lavoro. I nostri clienti più grandi solitamente preferiscono avere a che fare con un MSA, anche se noi preferiremmo usare il nostro accordo, che chiamiamo Project Service Agreement (PSA). L’acronimo da solo mi fa già innamorare!

Tipicamente, un MSA gestirà gli argomenti di relazione-gestione quali:

• Servizi generali—In termini generici, è quello che fornirete al cliente (servizi di web design, content strategy, etc.).
• Project Management—Quali saranno i ruoli dei project managers da entrambe le parti
• Deliverable—Come verranno forniti i deliverables e come saranno accettati dal cliente
• Supporto/Deployment—Che tipo di assistenza fornirete al cliente per l’implementazione e che supporto aggiuntivo fornirete man mano che procedete.
• Pagamenti/Spese—Il modo in cui verrete pagati, quali spese saranno coperte e quali no.
• Audits—I modi in cui il cliente può chiedervi di provare che state facendo il vostro lavoro.
• Riservatezza—Quello che non potete dire del lavoro e quello che il cliente può fare se rivelerete un segreto.
• Cessione di licenze—Quali informazioni possedute dal cliente potete usare e per quanto tempo.
• Diritti proprietari—Chi possiede il lavoro (anche parti individuali di questo) quando il lavoro sarà terminato.
• Durata e risoluzione—Quando dura l’accordo, chi può porre fine all’accordo e per quale motivo.
• Dichiarazioni e garanzie—Assicuratevi di poter fare il lavoro, di non essere in conflitto con altri accordi e che sistemerete ciò che non funziona se è colpa vostra.
• Indennizzi—Per assicurarsi contro qualsiasi danno che potrebbe soffrire un altro.
• Assicurazione—I tipi e la quantità di copertura assicurativa che vi viene richiesto di portare per fare il lavoro.

D’altro canto, un SOW di solito gestisce cose come:

• Servizi richiesti—Descrizione del progetto.
• Descrizione delle fasi di progetto—Dettagliare il numero di fasi e quello che va in ciascuna di queste.
• Durata del progetto e milestones—Stima di quanto tempo sarà necessario per il progetto e quali saranno le milestones durante il percorso.
• Ore risorsa—Quante ore vengono allocate per ciascuna fase.
• Pagamenti—Quello che fate pagare per ciascun professionista nella vostra azienda.
• Compiti proposti & deliverables—Quello che farete e consegnerete e quando.
• Date di inizio e completamento—Quando comincerete e, se tutto va bene, quando finirete.
• Compensi per il servizio—Quanto farete pagare per l’intero impegno.
• Schedule e temini di pagamento—Quanto sarete pagati e quando.
• Elenco dei rappresentanti—Le persone coinvolte da entrambe le parti o almeno quali saranno i loro ruoli.

Come potete vedere, è tutto piuttosto rinvigorente!

Se il MSA e il SOW hanno linguaggi simili o in conflitto, il MSA è solitamente l’accordo che ha la precedenza. Alcuni avvocati vi diranno che dovrebbe essere il contrario e combatteranno per tale stipula. Dopo tutto, i dettagli catturati dal SOW sono più concentrati sul progetto e più granulari, pertanto potrebbero fornire un contesto più dettagliato. Un SOW è creato per ciascuno specifico progetto ed è altamente specifico per il lavoro che avete tra le mani.

State attenti a non rimanere intrappolati in un MSA a lungo termine#section2

Solitamente, non firmiamo gli MSA che hanno una scadenza più lunga di un anno. Perché? Beh, supponiamo che firmiate un MSA con un termine di due anni, che dice che il cliente può porre fine alla relazione quando vuole, ma voi non potete. Firmate comunque il MSA perché siete troppo pigri per consultare un avvocato che vi faccia avere un po’ di buon senso. Poi, stipulate un SOW per un grande progetto che richiede un anno per essere completato e tutto va bene. Basandovi su questa esperienza positiva, siete d’accordo sul firmare un altro SOW per un progetto ancora più grande. Ricordatevi, siete ancora regolati dal MSA che avete originariamente firmato un anno fa. Supponiamo che durante il secondo progetto, la persona da parte del cliente con cui vi piaceva lavorare lascia il suo lavoro e viene rimpiazzata da qualcuno con cui è impossibile lavorare. Dopo averle provate tutte per far funzionare il progetto, decidete di volerne uscire. Malissimo: il MSA dice che non potete. Divertitevi!

La morale è questa: si impara sempre e i vostri bisogni cambiano. Non fatevi intrappolare nelle cose. È lo stesso motivo per cui non firmereste un contratto di tre anni con una compagnia telefonica per un servizio mobile.

Non sono il primo a sostenere questo e il ragionamento si applica sia agli MSA sia ai SOW: tutto è negoziabile. Semplicemente, non prendete un MSA di un’azienda e, dal momento che avete bisogno di lavorare per campare, firmatelo senza leggerlo scrupolosamente. Prendetevi un avvocato e analizzate insieme il documento. Tracciate i cambiamenti. Il vostro cliente se lo aspetta e non sarete pazzi per averlo passato al microscopio. Una volta abbiamo avuto un possibile cliente che ha cercato di far passare una clausola di non competitività nel MSA che diceva che non potevamo considerare altre opportunità nel loro settore per un periodo di cinque anni. Ehm, no. Assicuratevi di aver guardato tutto nei dettagli.

PSA#section3

In Happy Cog, il nostro punto di partenza preferito quando si tratta di definire una relazione d’affari non è il combo MSA/SOW che piace così tanto ai nostri potenziali clienti. Come ho citato prima, noi portiamo avanti il nostro Project Service Agreement (PSA). È specifico per ciascun progetto come un SOW ma contiene anche tutte le cose legali e di gestione come un MSA. È un MSA, un SOW, un’offerta e un résumé dell’agenzia in un unico pacchetto intelligente ed elegantemente progettato (gli MSA e i SOW di solito sono degli orribili documenti legali, invece a noi piace costruire/progettare il nostro in modo che comunichi meglio il nostro brand).

Il nostro PSA comincia con l’informazione che il nostro potenziale cliente brama maggiormente: il costo. Risparmiategli la fatica di girare tra le pagine o di fare lo scroll del PDF. Eccolo, il nostro prezzo, proprio sulla seconda pagina, in numeri grandi e in grassetto. Sulla stessa pagina mettiamo il dettaglio del calendario dei pagamenti che noi proponiamo e il modo in cui preferiamo essere pagati. Sulle prime, sembra una cosa sbagliata da fare, ma dopo numerosi test, abbiamo scoperto che i nostri probabili clienti lo apprezzano.

Siate vaghi (avete sentito bene)#section4

È sottile ma importante: non cercate di risolvere quello che non avete ancora capito.

Riflettendo sull’arco di molti anni, ancora prima del mio ruolo in Happy Cog, penso che noi si tenda a considerare i progetti un po’ troppo in maniera “una soluzione per tutti”. Sulle prime, di solito pensavamo a quali operazioni avremmo dovuto fare, quali artefatti avremmo dovuto produrre, quanti compo avremmo dovuto progettare e quante revisioni avremmo offerto. Solitamente si trattava di una mappa del sito con tre giri di revisioni, 10-12 wireframe con tre giri di revisione, tre diversi comp del design creati da tre diversi designer ciascuno con tre revisioni e 10-12 pagine di template HTML/CSS. Per quasi tutti i progetti. Questo ha creato una serie di problemi.

Per prima cosa, stavo prescrivendo delle soluzioni prima ancora di aver compreso davvero i problemi e il solo modo in cui si può essere sicuri al 100% su quello che si consegnerà è di fare ricerche e di discutere approfonditamente. Ma come si articola il modo in cui si risolveranno i problemi se non li si è ancora compresi in pieno? State ancora cercando di essere invitati a ballare. Non ci sono ancora firme sui contratti e non volevamo fare ricerche non pagate per fare chiarezza solo per il contratto.

Dovevamo risolvere questo problema. Vennero fuori due idee. Potevamo scegliere di:

• cambiare il nostro approccio per presentare una fase di ricerca e definizione del progetto per una frazione del costo totale di progetto e far sì che i risultati di tale sforzo fornissero gli argomenti necessari a mettere insieme un contratto dettagliato per il resto del lavoro;
• essere un po’ più vaghi nella descrizione di quello che avremmo fatto.

Il secondo punto sembra ridicolo quando lo si legge. Non dovreste essere più specifici piuttosto che il contrario? Direi di no. Invece di impegnarvi prematuramente in un corso di azioni che potrebbero essere appropriate per il progetto oppure non esserlo, identifichiamo tutti i possibili artefatti che potremmo produrre in ogni fase. Poi ci impegniamo con zero di questi.

I deliverable specifici che Happy Cog fornirà consisteranno in uno o più (in qualunque combinazione) dei seguenti, che andranno selezionati in base alla loro adeguatezza per il progetto…

Poi, li elenchiamo. Ad esempio, i tipi di deliverables che possiamo fornire per il lavoro sull’architettura dell’informazione includono:

• Creazione della tassonomia
• Sviluppo delle persona
• Profilo del contenuto
• Classificazione per genere del contenuto
• Schema del sito
• Site map
• Wireframes
• Diagrammi di descrizione della pagina
• Diagrammi di flusso utenti/processi
• Documento generale dell’experience

Il ruolo del vostro cliente nel selezionare un fornitore include fare la necessaria “due diligence” per avere fiducia nel vostro lavoro, nelle persone del vostro team e nei vostri processi, compreso il controllare le referenze. Se il vostro cliente ha fiducia nelle vostre capacità, non avrete problemi nell’essere meno normativi nel vostro PSA o nel SOW. Infatti, vi state comportando in maniera responsabile. Non sapete quello che non sapete, giusto? Non suggerite cose sbagliate solo per fare un cappio attorno al vostro contratto. Siate onesti e dite che farete quello che è più appropriato. La maggior parte dei nostri potenziali clienti, quando legge il nostro PSA, non batte ciglio sulla nostra mancanza voluta di specificità.

Mettete quelle ore in un secchio#section5

Tornando a quando dicevamo in anticipo cosa avremmo consegnato esattamente, ci imbattevamo in un altro grattacapo: clienti che esigono di più.

Una volta abbiamo avuto un cliente che non era felice con i design che avevamo sviluppato. Gli avevamo promesso tre variazioni, con l’idea vincente rivista due volte ancora fino ad ottenere il design perfetto. Ci sentivamo sicuri del nostro lavoro, ma non ebbe un forte impatto sul cliente. Poco dopo, esaurimmo il numero specificato di comp e revisioni. Lo comunicammo al cliente, che rispose: “Malissimo. Tuttavia, non abbiamo ancora il nostro design e non è colpa nostra.”

È divertente trovarsi in queste situazioni.

Potreste sicuramente creare un cambio di requisiti/ordini, ma farà sputare fuoco al vostro cliente. Quindi, oltre ad abbandonare la prescrizione di compiti e deliverables specifici in anticipo, abbiamo sostituito il nostro modello con uno che utilizzi il “secchio delle ore”: diamo un prezzo fisso ai nostri lavori, ma sappiamo anche quante ore abbiamo allocato per ogni fase del progetto. Quando abbiamo esaurito il 75% delle ore di una fase, lo facciamo sapere al cliente. Poi, se raggiungono il 100% e usano tutte le ore, smettiamo di lavorare e loro devono comprarne delle altre. Non rubiamo ore da altre fasi per finanziare il deficit. In questo modo, se un cliente vuole cinque design iterati per cinque volte, a noi sta bene. Le ore vengono usate nel modo in cui le ore sono meglio utilizzate: libertà.

Documentare i requisiti#section6

Sia che stiate assumendo un imbianchino, un costruttore o un’agenzia creativa, dovete pensare ai requisiti, che oltretutto impostano le aspettative. Nel nostro mondo ci sono dei requisiti di business, dei requisiti di contenuto e dei requisiti tecnici, solo per citarne alcuni. Voi potreste pensare che un contratto sia il posto giusto per documentare questi requisiti. So di aver provato ad identificare quanti più dettagli quanto prima possibile per minimizzare il rischio e l’ambiguità. È difficilissimo farlo. Direi che il contratto non è il mezzo appropriato per articolare i requisiti. Tuttavia, il contratto dovrebbe specificare un processo attraverso il quale verranno raccolti, valutati e assegnate loro delle priorità. Quello che alla fine verrà effettivamente realizzato sarà dettato dal budget e dalla timeline del vostro progetto.

Illustrazioni: {carlok}