Un ambito del servizio chiaro e senza ambiguità: 10 elementi per far capire al cliente cosa sta acquistando

La normativa federale statunitense attuale per i servizi basati sui risultati raccomanda di descrivere il lavoro soprattutto attraverso i risultati richiesti, anziché imporre come debba essere svolto o limitarsi a indicare un numero di ore. Fa inoltre riferimento a standard di prestazione misurabili e, nelle dichiarazioni degli obiettivi, include elementi quali finalità, ambito, periodo e luogo di esecuzione, contesto, risultati richiesti e vincoli operativi. [1]

Il Digital, Data and Technology Playbook del Governo britannico promuove allo stesso modo specifiche chiare orientate ai risultati. Raccomanda esplicitamente di concentrarsi sull'utente e sul problema da risolvere invece di imporre in anticipo una soluzione tecnica. [2]

L'attuale guida britannica sulla distribuzione dei rischi e sugli approcci di prezzo aggiunge che gli indicatori di prestazione dovrebbero essere misurabili e oggettivi e che il fornitore dovrebbe rispondere dei risultati sui quali può realmente influire. [3]

Queste fonti appartengono al settore degli appalti pubblici e non sono un modello universale per ogni servizio. Tuttavia mostrano un principio molto utile: un buon ambito dovrebbe indicare il risultato atteso, come può essere valutato e i limiti della responsabilità.

Una buona descrizione dovrebbe aiutare contemporaneamente:

Il cliente - a capire che cosa riceverà, che cosa non riceverà e che cosa gli verrà richiesto.

Lo specialista - a definire i limiti di responsabilità, le ipotesi e il momento in cui una nuova richiesta diventa una modifica dell'ambito.

Entrambe le parti - a concordare come stabilire ragionevolmente che il lavoro concordato è stato completato.

Se la descrizione svolge bene solo una di queste funzioni, può comunque lasciare troppo spazio a contestazioni o interpretazioni diverse.

Inizia spiegando perché il servizio è necessario.

Non partire da un elenco di strumenti o attività se il cliente non ha ancora chiaro l'obiettivo.

Invece di:

"Configurazione di analisi, report ed eventi."

meglio:

"L'obiettivo è ottenere dati affidabili sulle fasi del modulo in cui gli utenti abbandonano più spesso, così che il team possa individuare i punti che richiedono miglioramenti."

Questo approccio segue il principio di descrivere bisogni e risultati invece di imporre una soluzione, promosso dal Digital, Data and Technology Playbook britannico. [2]

L'obiettivo risponde a "perché?", mentre il risultato risponde a "che cosa deve esistere o essere vero al termine del lavoro?"

Un risultato può essere, ad esempio:

• un documento completato,
• una funzionalità funzionante,
• una configurazione implementata,
• una ricerca conclusa con risultati,
• un insieme di materiali preparato,
• una sessione svolta con un riepilogo definito.

Per i servizi basati sui risultati, la FAR descrive i requisiti soprattutto attraverso i risultati richiesti e non solo attraverso il metodo di esecuzione. [1]

Questo non significa che ogni servizio debba garantire un risultato commerciale che lo specialista non controlla. Può impegnarsi a lanciare una campagna entro l'ambito concordato, ma garantire un aumento delle vendite del 30% può dipendere da molti fattori fuori dal controllo del fornitore.

L'ambito dovrebbe indicare le parti concrete del lavoro comprese nell'accordo.

Per un progetto di sito web, ad esempio, può includere:

• analisi del sito attuale,
• preparazione dell'architettura dell'informazione,
• progettazione di un numero definito di schermate,
• versioni per dispositivi mobili,
• implementazione del progetto approvato,
• documentazione di consegna di base.

Lo scopo non è creare l'elenco più lungo possibile. Lo scopo è nominare gli elementi principali che incidono sull'impegno richiesto e sulle aspettative prima dell'inizio del lavoro.

L'ambito descrive il lavoro, mentre gli elementi consegnati descrivono che cosa il cliente riceverà realmente.

Per esempio:

• un file sorgente,
• un rapporto in un formato definito,
• un modulo funzionante,
• un archivio di codice,
• un insieme di elementi grafici,
• una registrazione,
• documentazione,
• un elenco di raccomandazioni,
• accesso a un ambiente configurato.

Se la forma del risultato conta, deve essere indicata. "Rapporto" può significare due pagine di testo oppure un documento dettagliato con analisi, priorità ed esempi. Il solo nome non sempre basta.

I criteri di accettazione rispondono alla domanda: come si può stabilire che il risultato concordato è stato consegnato secondo i requisiti?

Possono riguardare, ad esempio:

• completezza,
• conformità alla specifica concordata,
• un formato definito,
• funzionamento sui dispositivi o negli ambienti indicati,
• un numero massimo di errori di una categoria definita,
• tempi di consegna,
• parametri qualitativi definiti.

La FAR richiede che gli standard di prestazione nei contratti di servizi basati sui risultati siano misurabili e strutturati in modo da consentire la valutazione dell'esecuzione. [1]

La guida britannica sul rischio aggiunge che gli indicatori dovrebbero essere oggettivi e riferirsi a risultati sui quali il fornitore può influire. [3]

Per questo "il cliente sarà soddisfatto" è molto meno utile di un criterio collegato a un risultato specifico e osservabile.

Un servizio dipende spesso da azioni dell'altra parte.

È utile indicare se il cliente deve fornire:

• accessi ai sistemi,
• contenuti o materiali,
• dati,
• informazioni sul marchio,
• decisioni e approvazioni,
• una persona di contatto,
• un ambiente di test,
• risposte entro un tempo definito.

Se la mancanza di materiali del cliente può bloccare il lavoro, questo deve essere chiaro.

La responsabilità sui tempi non dovrebbe essere descritta come se lo specialista controllasse azioni che in realtà non controlla.

Prezzo e tempi sono spesso validi solo in presenza di determinate ipotesi.

Esempi:

• il database esistente è disponibile e funziona correttamente,
• il cliente possiede i diritti sui materiali forniti,
• un sistema esterno dispone di un'interfaccia funzionante,
• il progetto non richiede la migrazione di dati storici,
• il numero di versioni linguistiche è definito in anticipo,
• le decisioni saranno prese da una persona indicata.

La guida GAO sulle stime affidabili dei costi considera importanti una definizione chiara dell'ambito, le basi tecniche, le regole e ipotesi, oltre all'analisi del rischio e dell'incertezza. [7]

Un servizio piccolo non deve copiare un processo pensato per grandi programmi. Il principio resta comunque valido: se la stima dipende da qualcosa che potrebbe risultare falso, dichiaralo.

Le esclusioni non sono il segno di un'offerta debole. Spesso indicano che l'impegno è ben definito.

Se qualcosa può essere facilmente scambiato per una parte inclusa nel servizio, è utile dichiarare espressamente che non lo è.

Per esempio:

• acquisto di licenze,
• creazione di contenuti,
• immagini a pagamento,
• traduzioni,
• manutenzione dopo il lancio,
• lavori su un altro sistema,
• revisioni illimitate,
• costi di servizi di terzi.

Non serve elencare tutto ciò che lo specialista non farà. Le esclusioni più utili sono quelle che il cliente potrebbe realisticamente considerare parte del servizio.

Un termine dovrebbe dire più di "circa due settimane" quando l'avanzamento dipende da approvazioni o materiali del cliente.

È utile chiarire:

• da che cosa parte il conteggio del tempo,
• se esistono fasi intermedie,
• quali decisioni chiudono ogni fase,
• quanto tempo ha il cliente per rispondere quando questo incide sul calendario,
• come vengono comunicati i ritardi,
• come funziona l'accettazione finale.

In un servizio semplice possono bastare poche frasi. In una collaborazione più ampia, le fasi aiutano entrambe le parti a capire che cosa è già stato completato e che cosa deve succedere dopo.

Una buona descrizione del servizio dovrebbe spiegare che cosa accade quando emerge un nuovo requisito dopo l'inizio del lavoro.

Un meccanismo pratico può essere molto semplice:

"Il lavoro al di fuori dell'ambito descritto richiede la conferma del nuovo ambito, del suo impatto sui tempi e di qualsiasi prezzo aggiuntivo prima dell'inizio di quel lavoro."

È inoltre utile indicare chiaramente:

• il modello di tariffazione,
• il prezzo o il modo in cui viene calcolato,
• le regole di pagamento,
• eventuali costi aggiuntivi,
• le regole per ulteriori cicli di revisione.

Questo non elimina i cambiamenti. Fa sì che una modifica sia una decisione consapevole e non un'estensione nascosta dell'impegno iniziale.

Un ambito chiaro non richiede di controllare ogni passaggio del lavoro dello specialista.

Il Digital, Data and Technology Playbook britannico mette in guardia contro una specifica eccessiva della soluzione e osserva che le specifiche orientate ai risultati possono lasciare al fornitore spazio per proporre un modo più efficace di risolvere il problema. [2]

La FAR preferisce allo stesso modo descrivere i risultati richiesti anziché imporre esattamente come il lavoro debba essere svolto. [1]

Perciò:

"il sito deve supportare correttamente gli scenari concordati sui dispositivi indicati"

può essere un requisito migliore rispetto all'imposizione di ogni dettaglio di implementazione quando la tecnologia stessa non costituisce un vincolo essenziale.

Naturalmente, in alcuni servizi il metodo conta per sicurezza, conformità, integrazione o standard tecnici. In questi casi deve essere descritto.

Nel definire l'ambito è importante distinguere tra:

il risultato diretto del lavoro dello specialista e un risultato di business che dipende anche da altri fattori.

Uno specialista può impegnarsi a:

• preparare e lanciare una campagna entro l'ambito concordato,
• svolgere un'analisi,
• consegnare un numero definito di materiali,
• implementare una funzione che soddisfa criteri stabiliti.

Serve molta più cautela con garanzie su vendite, numero di clienti, posizione nei motori di ricerca o altri risultati che dipendono dal mercato, dal budget, dal prodotto, dalle azioni del cliente o da sistemi esterni.

La guida britannica attuale sulla distribuzione del rischio afferma esplicitamente che i fornitori dovrebbero essere responsabili dei risultati sui quali possono influire. [3]

Una buona descrizione non indebolisce la responsabilità. La assegna dove esiste realmente il controllo.

Non tutti i servizi richiedono un documento di più pagine.

Per un'attività semplice, tutte le informazioni essenziali possono stare in pochi paragrafi. Per un progetto più grande, lo stesso modo di ragionare può diventare una specifica dettagliata, un calendario, criteri di accettazione e un processo formale di modifica.

Un esempio di Terms of Reference pubblicato dalla Banca Mondiale osserva che il documento dovrebbe esprimere chiaramente i requisiti dei servizi di consulenza e le aspettative dell'ente committente, e dovrebbe essere adattato al progetto specifico e al contesto locale. [4]

La lunghezza non è la cosa più importante. La domanda principale è se un'informazione mancante potrebbe realisticamente cambiare il prezzo, i tempi, la responsabilità o il risultato atteso.

La descrizione di un servizio su un sito o in un profilo può essere solo una parte del processo contrattuale. Gli obblighi legali specifici dipendono dal paese, dal tipo di transazione, dallo status delle parti e dalla modalità di vendita.

Nelle relazioni tra impresa e consumatore nell'UE, il portale ufficiale Your Europe indica tra le informazioni precontrattuali le caratteristiche principali del servizio, il prezzo totale incluse le spese, le modalità di pagamento ed esecuzione e, quando applicabile, la durata del contratto. [5]

La guida dell'UE per le imprese indica inoltre che le condizioni standard dei contratti con i consumatori devono essere eque e formulate in linguaggio chiaro e comprensibile, in modo che il consumatore possa comprenderne anche le conseguenze economiche. [6]

Questi requisiti riguardano determinate relazioni di consumo nell'UE. Non devono essere estesi automaticamente a tutte le transazioni tra imprese o ad altre giurisdizioni.

Questo articolo è una guida editoriale alla descrizione dei servizi, non un modello di contratto né consulenza legale.

1. Il cliente comprende il problema o l'obiettivo che il servizio affronta?
2. Il risultato finale è indicato?
3. È chiaro che cosa è incluso nell'ambito?
4. Il cliente sa quali elementi concreti riceverà?
5. Esiste un modo ragionevole di valutare il completamento?
6. È chiaro che cosa il cliente deve fornire o gestire?
7. Le ipotesi più importanti sono visibili?
8. Sono indicate le esclusioni evidenti che potrebbero generare confusione?
9. Tempi e fasi riflettono le dipendenze di entrambe le parti?
10. È chiaro che cosa succede quando cambia l'ambito?
11. Prezzo, modello di tariffazione e costi aggiuntivi sono presentati nel momento appropriato?
12. La descrizione evita di promettere risultati che lo specialista non controlla?

Il test migliore per una buona descrizione è semplice.

Dopo averla letta, cliente e specialista dovrebbero rispondere in modo simile a queste domande:

Che cosa deve essere raggiunto? Che cosa verrà fatto? Che cosa riceverà il cliente? Che cosa non è incluso? Che cosa deve fare il cliente? Come sapremo che il lavoro è concluso? Che cosa succede se cambia l'ambito?

Se le risposte coincidono, prezzo e tempi hanno un contesto molto migliore.

Se le risposte divergono, spesso il problema non inizia durante l'esecuzione. Inizia già nella descrizione del servizio.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Apri fonte

[2] UK Government - The Digital, Data and Technology Playbook
Apri fonte

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Apri fonte

[4] World Bank - Sample Consultants Terms of Reference
Apri fonte

[5] Your Europe - Contract information: what you should know before buying
Apri fonte

[6] Your Europe - Contracts with consumers
Apri fonte

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Apri fonte

Nota metodologica: le fonti hanno ambiti diversi e non formano un unico standard comune per la descrizione dei servizi. L'articolo utilizza solo i principi che sostengono realmente: orientamento ai risultati, misurabilità, ambito chiaro, ipotesi, responsabilità per i fattori sotto il controllo del fornitore e trasparenza delle informazioni per il cliente.