{"id":282,"date":"2012-07-06T17:15:56","date_gmt":"2012-07-06T15:15:56","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/contratti-uguale-aspettative\/"},"modified":"2012-07-06T17:15:56","modified_gmt":"2012-07-06T15:15:56","slug":"contratti-uguale-aspettative","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/contratti-uguale-aspettative\/","title":{"rendered":"Contratti = Aspettative"},"content":{"rendered":"<div class=\"paragrafo\">\n<p><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2012\/07\/n55bweb.png\" border=\"0\" width=\"220\" style=\"float: right;\" \/>Tutte le relazioni cliente\/fornitore si basano su un insieme di aspettative, che siano scritte oppure no. Quando assumete un imbianchino, l&#8217;atto di applicare la pittura \u00e8 solo parte dell&#8217;ingaggio. Tutti gli step che portano al lavoro finito si trovano nei dettagli.<\/p>\n<p>Mi aspetto che l&#8217;imbianchino:<\/p>\n<ul>\n<li>arrivi a casa mia in orario<\/li>\n<li>sposti tutti i mobili necessari per poter lavorare<\/li>\n<li>copra le cose con dei vecchi stracci<\/li>\n<li>non fumi in casa mia<\/li>\n<li>non pulisca i pennelli nel lavandino della mia cucina<\/li>\n<li>sia rispettoso e professionale<\/li>\n<li>finisca il lavoro in tempo<\/li>\n<li>lasci la casa come era prima che cominciasse il lavoro<\/li>\n<\/ul>\n<p>Non mi aspetto che l&#8217;imbianchino:<\/p>\n<ul>\n<li>dia da mangiare al mio cane mentre sono al lavoro<\/li>\n<li>imposti il mio sistema di allarme<\/li>\n<li>pitture zone che non ho richiesto<\/li>\n<li>applichi tre mani di vernice<\/li>\n<\/ul>\n<p>In ogni progetto, piccolo o grande che sia, molte cose non vengono dette o specificate. Non essere precisi pu\u00f2 portare a disaccordi, battibecchi e pressione alta.<\/p>\n<p>Per quel che riguarda il mio lavoro quotidiano, mi trovo dall&#8217;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&#8217;affari \u00e8 governata da quello su cui ci si accorda da entrambe le parti. Uno \u201c<a href=\"http:\/\/en.wikipedia.org\/wiki\/Statement_of_work\">Statement of Work (SOW)<\/a>\u201d o \u201cStatement of Services (SOS)\u201d [dichiarazione dei servizi, <em>ndr<\/em>] \u00e8 uno strumento utilizzato per allineare le aspettative. Di solito usavamo il SOW e lo SOS come sinonimi della parola \u201ccontratto\u201d o \u201cproposta\u201d, ma in realt\u00e0 sono un po&#8217; diversi. In qualunque modo li chiamiate, vi salveranno la pelle.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>SOW e MSA<\/h2>\n<p>Uno Statement of Work (SOW) \u00e8 solitamente un documento che accompagna ancora un altro documento, a cui spesso si fa riferimento come Master Services Agreement (MSA). Sono i <a href=\"http:\/\/en.wikipedia.org\/wiki\/Laverne_%26_Shirley#Lenny_.26_Squiggy\">Lenny and Squiggy<\/a> degli accordi legali. Il MSA \u00e8 solitamente un documento fondamentale per l&#8217;intera relazione, mentre il SOW gestisce di solito le specifiche di un singolo progetto o ambito di lavoro. I nostri clienti pi\u00f9 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&#8217;acronimo da solo mi fa gi\u00e0 innamorare!<\/p>\n<p>Tipicamente, un MSA gestir\u00e0 gli argomenti di relazione-gestione quali:<\/p>\n<ul>\n<li><strong>Servizi generali<\/strong>\u2014In termini generici, \u00e8 quello che fornirete al cliente (servizi di web design, content strategy, etc.).<\/li>\n<li><strong>Project Management<\/strong>\u2014Quali saranno i ruoli dei project managers da entrambe le parti<\/li>\n<li><strong>Deliverable<\/strong>\u2014Come verranno forniti i deliverables e come saranno accettati dal cliente<\/li>\n<li><strong>Supporto\/Deployment<\/strong>\u2014Che tipo di assistenza fornirete al cliente per l&#8217;implementazione e che supporto aggiuntivo fornirete man mano che procedete.<\/li>\n<li><strong>Pagamenti\/Spese<\/strong>\u2014Il modo in cui verrete pagati, quali spese saranno coperte e quali no.<\/li>\n<li><strong>Audits<\/strong>\u2014I modi in cui il cliente pu\u00f2 chiedervi di provare che state facendo il vostro lavoro.<\/li>\n<li><strong>Riservatezza<\/strong>\u2014Quello che non potete dire del lavoro e quello che il cliente pu\u00f2 fare se rivelerete un segreto.<\/li>\n<li><strong>Cessione di licenze<\/strong>\u2014Quali informazioni possedute dal cliente potete usare e per quanto tempo.<\/li>\n<li><strong>Diritti proprietari<\/strong>\u2014Chi possiede il lavoro (anche parti individuali di questo) quando il lavoro sar\u00e0 terminato.<\/li>\n<li><strong>Durata e risoluzione<\/strong>\u2014Quando dura l&#8217;accordo, chi pu\u00f2 porre fine all&#8217;accordo e per quale motivo.<\/li>\n<li><strong>Dichiarazioni e garanzie<\/strong>\u2014Assicuratevi di poter fare il lavoro, di non essere in conflitto con altri accordi e che sistemerete ci\u00f2 che non funziona se \u00e8 colpa vostra.<\/li>\n<li><strong>Indennizzi<\/strong>\u2014Per assicurarsi contro qualsiasi danno che potrebbe soffrire un altro.<\/li>\n<li><strong>Assicurazione<\/strong>\u2014I tipi e la quantit\u00e0 di copertura assicurativa che vi viene richiesto di portare per fare il lavoro.<\/li>\n<\/ul>\n<p>D&#8217;altro canto, un SOW di solito gestisce cose come:<\/p>\n<ul>\n<li><strong>Servizi richiesti<\/strong>\u2014Descrizione del progetto.<\/li>\n<li><strong>Descrizione delle fasi di progetto<\/strong>\u2014Dettagliare il numero di fasi e quello che va in ciascuna di queste.<\/li>\n<li><strong>Durata del progetto e milestones<\/strong>\u2014Stima di quanto tempo sar\u00e0 necessario per il progetto e quali saranno le milestones durante il percorso.<\/li>\n<li><strong>Ore risorsa<\/strong>\u2014Quante ore vengono allocate per ciascuna fase.<\/li>\n<li><strong>Pagamenti<\/strong>\u2014Quello che fate pagare per ciascun professionista nella vostra azienda.<\/li>\n<li><strong>Compiti proposti &amp; deliverables<\/strong>\u2014Quello che farete e consegnerete e quando.<\/li>\n<li><strong>Date di inizio e completamento<\/strong>\u2014Quando comincerete e, se tutto va bene, quando finirete.<\/li>\n<li><strong>Compensi per il servizio<\/strong>\u2014Quanto farete pagare per l&#8217;intero impegno.<\/li>\n<li><strong>Schedule e temini di pagamento<\/strong>\u2014Quanto sarete pagati e quando.<\/li>\n<li><strong>Elenco dei rappresentanti<\/strong>\u2014Le persone coinvolte da entrambe le parti o almeno quali saranno i loro ruoli.<\/li>\n<\/ul>\n<p>Come potete vedere, \u00e8 tutto piuttosto rinvigorente!<\/p>\n<p>Se il MSA e il SOW hanno linguaggi simili o in conflitto, il MSA \u00e8 solitamente l&#8217;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\u00f9 concentrati sul progetto e pi\u00f9 granulari, pertanto potrebbero fornire un contesto pi\u00f9 dettagliato. Un SOW \u00e8 creato per ciascuno specifico progetto ed \u00e8 altamente specifico per il lavoro che avete tra le mani.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>State attenti a non rimanere intrappolati in un MSA a lungo termine<\/h2>\n<p>Solitamente, non firmiamo gli MSA che hanno una scadenza pi\u00f9 lunga di un anno. Perch\u00e9? Beh, supponiamo che firmiate un MSA con un termine di due anni, che dice che il cliente pu\u00f2 porre fine alla relazione quando vuole, ma voi non potete. Firmate comunque il MSA perch\u00e9 siete troppo pigri per consultare un avvocato che vi faccia avere un po&#8217; 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&#8217;accordo sul firmare un altro SOW per un progetto ancora pi\u00f9 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 \u00e8 impossibile lavorare. Dopo averle provate tutte per far funzionare il progetto, decidete di volerne uscire. Malissimo: il MSA dice che non potete. Divertitevi!<\/p>\n<p>La morale \u00e8 questa: si impara sempre e i vostri bisogni cambiano. Non fatevi intrappolare nelle cose. \u00c8 lo stesso motivo per cui non firmereste un contratto di tre anni con una compagnia telefonica per un servizio mobile.<\/p>\n<p>Non sono il primo a sostenere questo e il ragionamento si applica sia agli MSA sia ai SOW: tutto \u00e8 negoziabile. Semplicemente, non prendete  un MSA di un&#8217;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\u00e0 nel MSA che diceva che non potevamo considerare altre opportunit\u00e0 nel loro settore per un periodo di cinque anni. Ehm, no. Assicuratevi di aver guardato tutto nei dettagli.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>PSA<\/h2>\n<p>In Happy Cog, il nostro punto di partenza preferito quando si tratta di definire una relazione d&#8217;affari non \u00e8 il combo MSA\/SOW che piace cos\u00ec tanto ai nostri potenziali clienti. Come ho citato prima, noi portiamo avanti il nostro Project Service Agreement (PSA). \u00c8 specifico per ciascun progetto come un SOW ma contiene anche tutte le cose legali e di gestione come un MSA. \u00c8 un MSA, un SOW, un&#8217;offerta e un r\u00e9sum\u00e9 dell&#8217;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).<\/p>\n<p>Il nostro PSA comincia con l&#8217;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.<\/p>\n<\/div>\n<p>Poi, il PSA fornisce una panoramica della storia della nostra azienda, parla di quello che ci contraddistingue e include le bio delle persone che lavorano con noi. In seguito, ci sono molti paragrafi che introducono i problemi che stiamo cercando di risolvere. Ad un livello molto alto, descriviamo le soluzioni che proponiamo. Poi descriviamo in dettaglio le fasi necessarie, incluso il numero di ore che ci aspettiamo di dedicare a ciascuna fase.<\/p>\n<p>Dopo tutta questa prosa comincia il linguaggio legale. \u00c8 un po&#8217; di gergo, cos\u00ec come deve essere. Ogni volta che abbiamo cercato di tradurre il linguaggio legale in un modo che fosse facile da capire, ci siamo fatti pi\u00f9 male che bene. Dovete conoscere il vostro pubblico. Gli avvocati si aspettano di leggere cose scritte in un certo modo.<\/p>\n<div class=\"paragrafo\">\n<h2>Siate vaghi (avete sentito bene)<\/h2>\n<p>\u00c8 sottile ma importante: non cercate di risolvere quello che non avete ancora capito.<\/p>\n<p>Riflettendo sull&#8217;arco di molti anni, ancora prima del mio ruolo in Happy Cog, penso che noi si tenda a considerare i progetti un po&#8217; troppo in maniera \u201cuna soluzione per tutti\u201d. 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.<\/p>\n<p>Per prima cosa, stavo prescrivendo delle soluzioni prima ancora di aver compreso davvero i problemi e il solo modo in cui si pu\u00f2 essere sicuri al 100% su quello che si consegner\u00e0 \u00e8 di fare ricerche e di discutere approfonditamente. Ma come si articola il modo in cui si risolveranno i problemi se non li si \u00e8 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.<\/p>\n<p>Dovevamo risolvere questo problema. Vennero fuori due idee. Potevamo scegliere di:<\/p>\n<ul>\n<li>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\u00ec che i risultati di tale sforzo fornissero gli argomenti necessari a mettere insieme un contratto dettagliato per il resto del lavoro;<\/li>\n<li>essere un po&#8217; pi\u00f9 vaghi nella descrizione di quello che avremmo fatto.<\/li>\n<\/ul>\n<p>Il secondo punto sembra ridicolo quando lo si legge. Non dovreste essere pi\u00f9 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.<\/p>\n<blockquote><p>I deliverable specifici che Happy Cog fornir\u00e0 consisteranno in uno o pi\u00f9 (in qualunque combinazione) dei seguenti, che andranno selezionati in base alla loro adeguatezza per il progetto&#8230;<\/p><\/blockquote>\n<p>Poi, li elenchiamo. Ad esempio, i tipi di deliverables che possiamo fornire per il lavoro sull&#8217;architettura dell&#8217;informazione includono:<\/p>\n<ul>\n<li>Creazione della tassonomia<\/li>\n<li>Sviluppo delle persona<\/li>\n<li>Profilo del contenuto<\/li>\n<li>Classificazione per genere del contenuto<\/li>\n<li>Schema del sito<\/li>\n<li>Site map<\/li>\n<li>Wireframes<\/li>\n<li>Diagrammi di descrizione della pagina<\/li>\n<li>Diagrammi di flusso utenti\/processi<\/li>\n<li>Documento generale dell&#8217;experience<\/li>\n<\/ul>\n<p>Il ruolo del vostro cliente nel selezionare un fornitore include fare la necessaria \u201c<a href=\"http:\/\/it.wikipedia.org\/wiki\/Due_diligence\">due diligence<\/a>\u201d 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\u00e0, non avrete problemi nell&#8217;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 \u00e8 pi\u00f9 appropriato. La maggior parte dei nostri potenziali clienti, quando legge il nostro PSA, non batte ciglio sulla nostra mancanza voluta di specificit\u00e0.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Mettete quelle ore in un secchio<\/h2>\n<p>Tornando a quando dicevamo in anticipo cosa avremmo consegnato esattamente, ci imbattevamo in un altro grattacapo: clienti che esigono di pi\u00f9.<\/p>\n<p>Una volta abbiamo avuto un cliente che non era felice con i design che avevamo sviluppato. Gli avevamo promesso tre variazioni, con l&#8217;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: \u201cMalissimo. Tuttavia, non abbiamo ancora il nostro design e non \u00e8 colpa nostra.\u201d<\/p>\n<p>\u00c8 divertente trovarsi in queste situazioni.<\/p>\n<p>Potreste sicuramente creare un cambio di requisiti\/ordini, ma far\u00e0 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 \u201csecchio delle ore\u201d: 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\u00e0.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Documentare i requisiti<\/h2>\n<p>Sia che stiate assumendo un imbianchino, un costruttore o un&#8217;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\u00f9 dettagli quanto prima possibile per minimizzare il rischio e l&#8217;ambiguit\u00e0. \u00c8 difficilissimo farlo. Direi che il contratto non \u00e8 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\u00e0. Quello che alla fine verr\u00e0 effettivamente realizzato sar\u00e0 dettato dal budget e dalla timeline del vostro progetto.<\/p>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Ogni relazione cliente\/fornitore \u00e8 basata su una serie di aspettative, scritte oppure no. Molte cose rimangono non dette o non specificate per qualsiasi progetto, grande o piccolo che sia. Il fatto che non siano specificate pu\u00f2 portare a dei disaccordi, dei diverbi e alla pressione alta. Ma non deve essere per forza cos\u00ec. Greg Hoy dice che se la due diligence \u00e8 importante, essere vaghi \u00e8 un must. S\u00ec, avete letto bene.<\/p>\n","protected":false},"author":818,"featured_media":7000664,"comment_status":"open","ping_status":"open","template":"","categories":[263,70,276,278],"tags":[],"coauthors":[332],"class_list":["post-282","article","type-article","status-publish","has-post-thumbnail","hentry","category-business","category-numero-55-6-luglio-2012","category-project-management","category-workflow-tools"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/282","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=282"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000664"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=282"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=282"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=282"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=282"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}