Um âmbito de serviço claro e sem ambiguidades: 10 elementos para o cliente saber o que está a comprar

A regulamentação federal atual dos Estados Unidos para serviços baseados em resultados recomenda descrever o trabalho principalmente pelos resultados exigidos, em vez de impor a forma de execução ou indicar apenas um número de horas. Também se refere a padrões de desempenho mensuráveis e, nas declarações de objetivos, inclui elementos como finalidade, escopo, período e local de execução, contexto, resultados exigidos e restrições operacionais. [1]

O Digital, Data and Technology Playbook do Governo do Reino Unido também promove especificações claras orientadas para resultados. Recomenda explicitamente o foco no utilizador e no problema a resolver, em vez de impor antecipadamente uma solução técnica. [2]

A orientação britânica atual sobre distribuição de risco e abordagens de preço acrescenta que os indicadores de desempenho devem ser mensuráveis e objetivos, e que o fornecedor deve ser responsabilizado por resultados que possa efetivamente influenciar. [3]

Estas fontes pertencem ao domínio da contratação pública e não constituem um modelo universal para todos os serviços. Ainda assim, ilustram um princípio muito útil: um bom escopo deve indicar o resultado esperado, a forma de o avaliar e os limites da responsabilidade.

Uma boa descrição deve ajudar simultaneamente:

O cliente - a compreender o que vai receber, o que não vai receber e o que será exigido da sua parte.

O especialista - a definir limites de responsabilidade, premissas e o momento em que um novo pedido se torna uma alteração de escopo.

Ambas as partes - a acordar como determinar de forma razoável que o trabalho combinado foi concluído.

Se a descrição cumprir bem apenas uma destas funções, pode continuar a deixar demasiado espaço para conflito ou interpretações diferentes.

Comece por explicar por que motivo o serviço é necessário.

Não comece com uma lista de ferramentas ou tarefas se o cliente ainda não compreende o objetivo.

Em vez de:

"Configuração de análise, relatórios e eventos."

prefira:

"O objetivo é obter dados fiáveis sobre as etapas do formulário em que os utilizadores abandonam com maior frequência, para que a equipa possa identificar os pontos que precisam de melhoria."

Esta abordagem segue o princípio de descrever necessidades e resultados, em vez de impor uma solução, promovido pelo Digital, Data and Technology Playbook britânico. [2]

O objetivo responde a "porquê?", enquanto o resultado responde a "o que deve existir ou ser verdade no fim do trabalho?"

Um resultado pode ser, por exemplo:

• um documento concluído,
• uma funcionalidade em funcionamento,
• uma configuração implementada,
• uma pesquisa concluída com conclusões,
• um conjunto de materiais preparado,
• uma sessão realizada com um resumo definido.

Para serviços baseados em resultados, a FAR descreve os requisitos principalmente através dos resultados exigidos e não apenas pela forma de execução. [1]

Isto não significa que cada serviço deva garantir um resultado de negócio que o especialista não controla. Pode comprometer-se a lançar uma campanha dentro do escopo acordado, mas garantir um aumento de vendas de 30% pode depender de muitos fatores fora do seu controlo.

O escopo deve indicar as partes concretas do trabalho abrangidas pelo acordo.

Num projeto de site, por exemplo, pode incluir:

• análise do site atual,
• preparação da arquitetura da informação,
• design de um número definido de vistas,
• versões para dispositivos móveis,
• implementação do design aprovado,
• documentação básica de entrega.

O objetivo não é criar a lista mais longa possível. O objetivo é nomear os principais elementos que influenciam o esforço e as expectativas antes do início do trabalho.

O escopo descreve o trabalho, enquanto os elementos entregues descrevem o que o cliente irá realmente receber.

Por exemplo:

• um ficheiro fonte,
• um relatório num formato definido,
• um módulo funcional,
• um repositório de código,
• um conjunto de elementos gráficos,
• uma gravação,
• documentação,
• uma lista de recomendações,
• acesso a um ambiente configurado.

Se a forma do resultado for importante, indique-a. "Relatório" pode significar duas páginas de texto ou um documento detalhado com análise, prioridades e exemplos. O nome, por si só, nem sempre basta.

Os critérios de aceitação respondem à pergunta: como se pode determinar que o resultado acordado foi entregue de acordo com o requisito?

Podem dizer respeito, por exemplo, a:

• completude,
• conformidade com a especificação acordada,
• um formato definido,
• funcionamento nos dispositivos ou ambientes indicados,
• um número máximo de erros de uma categoria definida,
• prazo de entrega,
• parâmetros de qualidade definidos.

A FAR exige que os padrões de desempenho em contratos de serviços baseados em resultados sejam mensuráveis e permitam avaliar a execução. [1]

A orientação britânica sobre risco acrescenta que as medidas devem ser objetivas e relacionadas com resultados que o fornecedor possa influenciar. [3]

Por isso, "o cliente ficará satisfeito" é muito menos útil do que um critério ligado a um resultado concreto e observável.

Um serviço depende frequentemente de ações da outra parte.

É útil indicar se o cliente deve fornecer:

• acessos aos sistemas,
• conteúdos ou materiais,
• dados,
• informação de marca,
• decisões e aprovações,
• uma pessoa de contacto,
• um ambiente de testes,
• respostas dentro de um prazo definido.

Se a falta de materiais do cliente puder bloquear o trabalho, isso deve ficar claro.

A responsabilidade pelos prazos não deve ser descrita como se o especialista controlasse ações que, na realidade, não controla.

Preço e prazo são frequentemente válidos apenas sob determinadas premissas.

Exemplos:

• a base de dados existente está disponível e funciona corretamente,
• o cliente possui os direitos sobre os materiais fornecidos,
• um sistema externo possui uma interface funcional,
• o projeto não exige migração de dados históricos,
• o número de versões linguísticas é definido antecipadamente,
• as decisões serão tomadas por uma pessoa indicada.

O guia do GAO sobre estimativas fiáveis de custos considera importantes a definição clara do escopo, bases técnicas, regras e premissas, bem como a análise de risco e incerteza. [7]

Um serviço pequeno não precisa de copiar um processo criado para grandes programas. O princípio continua, contudo, a ser valioso: se a estimativa depende de algo que pode revelar-se falso, diga-o.

As exclusões não são sinal de uma oferta fraca. Muitas vezes demonstram que o compromisso está bem definido.

Se algo puder ser facilmente confundido com uma parte incluída no serviço, é útil indicar expressamente que não está incluído.

Por exemplo:

• compra de licenças,
• criação de conteúdos,
• imagens pagas,
• traduções,
• manutenção após o lançamento,
• trabalhos noutro sistema,
• revisões ilimitadas,
• custos de serviços de terceiros.

Não é necessário listar tudo o que o especialista não fará. As exclusões mais úteis são aquelas que o cliente poderia realisticamente assumir como parte do serviço.

Um prazo deve dizer mais do que "cerca de duas semanas" quando o progresso depende de aprovações ou materiais do cliente.

Convém esclarecer:

• o que inicia a contagem do prazo,
• se existem etapas intermédias,
• quais decisões encerram cada etapa,
• quanto tempo o cliente tem para responder quando isso afeta o calendário,
• como são comunicados os atrasos,
• como funciona a aceitação final.

Num serviço simples, algumas frases podem bastar. Numa colaboração maior, as etapas ajudam ambas as partes a compreender o que já foi concluído e o que deve acontecer a seguir.

Uma boa descrição de serviço deve explicar o que acontece quando surge uma nova exigência depois do início do trabalho.

Um mecanismo prático pode ser muito simples:

"O trabalho fora do escopo descrito exige confirmação do novo escopo, do impacto no prazo e de qualquer preço adicional antes do início desse trabalho."

Também é útil indicar claramente:

• o modelo de cobrança,
• o preço ou a forma de o calcular,
• as regras de pagamento,
• custos adicionais que possam surgir,
• regras para rondas adicionais de revisão.

Isto não elimina alterações. Faz com que a alteração seja uma decisão consciente, em vez de uma expansão oculta do compromisso inicial.

Um escopo claro não exige controlar cada passo do trabalho do especialista.

O Digital, Data and Technology Playbook britânico alerta contra a especificação excessiva da solução e indica que especificações orientadas para resultados podem deixar ao fornecedor espaço para propor uma forma mais eficaz de resolver o problema. [2]

A FAR também prefere a descrição dos resultados exigidos em vez da imposição exata da forma de execução. [1]

Por isso:

"o site deve suportar corretamente os cenários acordados nos dispositivos indicados"

pode ser um requisito melhor do que impor a implementação exata quando a tecnologia em si não constitui uma limitação essencial.

Naturalmente, em alguns serviços o método é importante por razões de segurança, conformidade, integração ou normas técnicas. Nesses casos deve ser descrito.

Ao definir o escopo, é importante distinguir entre:

o resultado direto do trabalho do especialista e um resultado de negócio que depende também de outros fatores.

Um especialista pode comprometer-se a:

• preparar e lançar uma campanha dentro do escopo acordado,
• realizar uma análise,
• entregar um número definido de materiais,
• implementar uma funcionalidade que cumpra critérios definidos.

É necessária muito mais cautela com garantias sobre vendas, número de clientes, posição em motores de pesquisa ou outros resultados que dependam do mercado, orçamento, produto, ações do cliente ou sistemas externos.

A orientação britânica atual sobre distribuição de risco afirma expressamente que os fornecedores devem ser responsabilizados por resultados que possam influenciar. [3]

Uma boa descrição não enfraquece a responsabilidade. Coloca-a onde existe controlo real.

Nem todos os serviços precisam de um documento com várias páginas.

Numa tarefa simples, toda a informação essencial pode caber em alguns parágrafos. Num projeto maior, o mesmo raciocínio pode transformar-se numa especificação detalhada, calendário, critérios de aceitação e processo formal de alterações.

Um exemplo de Terms of Reference publicado pelo Banco Mundial indica que esse documento deve apresentar claramente os requisitos dos serviços de consultoria e as expectativas da entidade contratante, e ser adaptado ao projeto concreto e às circunstâncias locais. [4]

O mais importante não é o tamanho. A questão principal é saber se uma informação em falta poderia realisticamente alterar o preço, o prazo, a responsabilidade ou o resultado esperado.

A descrição de um serviço num site ou perfil pode ser apenas uma parte do processo contratual. As obrigações legais concretas dependem do país, do tipo de transação, do estatuto das partes e da forma de venda.

Nas relações entre empresas e consumidores na UE, o portal oficial Your Europe identifica como informação pré-contratual as características principais do serviço, o preço total incluindo encargos, as condições de pagamento e execução e, quando aplicável, a duração do contrato. [5]

A orientação da UE para empresas também indica que as condições padrão dos contratos com consumidores devem ser justas e redigidas em linguagem clara e compreensível, para que o consumidor possa entender as suas consequências económicas. [6]

Estes requisitos dizem respeito a determinadas relações de consumo na UE. Não devem ser aplicados automaticamente a todas as transações entre empresas nem a outras jurisdições.

Este artigo é um guia editorial sobre como descrever serviços, não um modelo de contrato nem aconselhamento jurídico.

1. O cliente compreende o problema ou objetivo que o serviço procura resolver?
2. O resultado final está identificado?
3. Está claro o que está incluído no escopo?
4. O cliente sabe que elementos concretos irá receber?
5. Existe uma forma razoável de avaliar a conclusão do trabalho?
6. Está claro o que o cliente deve fornecer ou assegurar?
7. As premissas mais importantes são visíveis?
8. As exclusões óbvias que podem causar confusão estão descritas?
9. O prazo e as etapas refletem dependências de ambas as partes?
10. Está claro o que acontece quando o escopo muda?
11. O preço, o modelo de cobrança e os custos adicionais são apresentados no momento adequado?
12. A descrição evita prometer resultados que o especialista não controla?

O melhor teste de uma boa descrição é simples.

Depois de a ler, cliente e especialista devem responder de forma semelhante a estas perguntas:

O que deve ser alcançado? O que será feito? O que o cliente receberá? O que não está incluído? O que o cliente deve fazer? Como saberemos que o trabalho está concluído? O que acontece se o escopo mudar?

Se as respostas coincidirem, preço e prazo passam a ter muito melhor contexto.

Se as respostas forem diferentes, muitas vezes o problema não começa durante a execução. Começa já na descrição do serviço.

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

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

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

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

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

[6] Your Europe - Contracts with consumers
Abrir fonte

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

Nota metodológica: as fontes têm âmbitos diferentes e não formam uma norma única para descrição de serviços. O artigo utiliza apenas princípios que elas realmente sustentam: foco em resultados, mensurabilidade, escopo claro, premissas, responsabilidade por fatores sob controlo do fornecedor e transparência da informação para o cliente.