O que é um statement of work (SOW)? Guia antes de assinar

Se você está se perguntando o que é um statement of work (SOW), pense nele como o documento de projeto que fica por baixo dos termos jurídicos de um contrato de serviços. Ele diz exatamente o que será entregue, até quando, por quem e por quanto. Na prática, é aqui que a maioria das disputas do tipo "não era isso que tínhamos combinado" é ganha ou perdida.

O que um statement of work realmente contém?

Um SOW descreve um trabalho específico. Ele não tenta cobrir toda a relação entre duas empresas. Os bons documentos costumam trazer os mesmos blocos centrais.

• Escopo: o que o fornecedor vai fazer, com verbos claros, e o que ele não vai fazer.

• Entregáveis: os resultados concretos, como uma base de dados migrada, um guia de marca ou 40 horas de suporte.

• Cronograma e marcos: datas ou durações amarradas aos entregáveis, e não a um vago "até o fim do trimestre".

• Valores e pagamento: preço fixo, tempo e materiais ou uma combinação, com os gatilhos de cada fatura.

• Critérios de aceite: como o cliente decide que um entregável está pronto.

• Papéis e dependências: quem fornece acesso, dados, aprovações ou ambientes de teste, e até quando.

• Processo de mudança: como escopo, preço ou datas podem ser alterados depois que o trabalho começou.

Na prática, a estrutura faz o seguinte: transforma uma ideia combinada de boca em algo que uma terceira pessoa consegue ler e verificar. Essa terceira pessoa costuma ser um juiz, um auditor ou um colega novo que herda o projeto.

Em que o SOW se diferencia de um MSA, de uma proposta ou de um pedido de compra?

A confusão costuma vir de documentos parecidos que aparecem juntos no mesmo negócio.

Um master services agreement (MSA) reúne os termos jurídicos permanentes: responsabilidade, propriedade intelectual, confidencialidade, proteção de dados, rescisão e lei aplicável. Ele é assinado uma vez. Cada SOW se apoia nele e cobre um projeto. Um único MSA pode sustentar uma dúzia de SOWs ao longo de vários anos.

Uma proposta é um documento comercial. Ela descreve o que o fornecedor pretende fazer e por que você deveria escolhê-lo. Normalmente não é vinculante, e muitas vezes acaba reaproveitada como primeiro rascunho do SOW. É aí que começam os problemas, porque linguagem de marketing termina dentro de um contrato.

Um pedido de compra é uma autorização de pagamento. Ele registra um preço e uma quantidade, raramente um escopo. Depender só de um pedido de compra em um projeto de serviços deixa o trabalho indefinido.

Para um trabalho pontual, um contrato único com o SOW como anexo pode funcionar perfeitamente. A separação entre MSA e SOW passa a valer a pena quando você vai contratar o mesmo fornecedor várias vezes.

Qual cláusula prevalece quando o MSA e o SOW divergem?

É a pergunta que a maioria das pessoas pula, e é a que mais custa dinheiro.

Acordos bem redigidos seguem um padrão simples. O MSA controla os termos jurídicos. O SOW controla escopo, cronograma e valores. Uma cláusula de ordem de precedência diz isso em uma ou duas frases e nomeia qual documento prevalece em caso de conflito.

Sem essa cláusula, você depende de como um tribunal lê os documentos em conjunto. Pelo direito inglês, por exemplo, os documentos de um contrato são em geral lidos como um único acordo. Assim, uma inconsistência não se anula sozinha: ela cria uma discussão, e discussões têm custo.

Veja o tipo de redação a procurar, apresentada como exemplo de redação e não como orientação para a sua jurisdição:

§ Em caso de conflito, os termos do MSA prevalecem sobre o SOW, exceto quanto a escopo, entregáveis, cronograma e valores do projeto descrito, hipóteses em que prevalece o SOW.

Atenção a uma armadilha. Um SOW que sobrescreve discretamente o teto de responsabilidade ou a titularidade da propriedade intelectual "apenas para este projeto" é legítimo quando as duas partes querem isso. Vira problema quando ninguém percebeu. Quem assina um SOW deve lê-lo como contrato, e não como plano de projeto.

O que faz o escopo aguentar pressão?

O escopo é onde os SOWs costumam falhar. Um escopo vago não é neutro: ele favorece quem está mais disposto a argumentar depois, e na prática essa costuma ser a parte com mais poder de negociação.

Três hábitos fazem o escopo se sustentar.

Primeiro, escreva as exclusões. Uma lista do que está fora do escopo costuma ser mais útil do que a lista do que está dentro. "Não inclui integração com o sistema de faturamento legado do cliente" encerra uma conversa que, de outra forma, tomaria três reuniões.

Segundo, amarre os entregáveis a substantivos, e não a adjetivos. "Um site responsivo" é discutível. "Oito templates, testados nas duas versões mais recentes de quatro navegadores indicados" é verificável.

Terceiro, declare as premissas. Se o cronograma depende de o cliente devolver o feedback em cinco dias úteis, diga isso, e diga o que acontece com o prazo se ele não devolver. Pedidos de atraso são bem mais fáceis de sustentar quando a dependência ficou por escrito.

Resista à tentação de copiar um modelo e preencher os espaços em branco. Um modelo mostra os títulos das seções. Ele não consegue dizer quais premissas são específicas do seu projeto.

Como escrever aceite e pedidos de mudança?

Os critérios de aceite respondem a uma pergunta: quando um entregável está pronto o bastante para ser pago? "Alta qualidade" e "a contento do cliente" não respondem. Um critério testável responde. Em uma migração de dados, por exemplo, pode ser "todos os registros transferidos e um relatório de conciliação sem diferenças não explicadas".

Inclua um mecanismo de aceite tácito. Um padrão comum é considerar o entregável aceito se o cliente não apontar deficiências por escrito dentro de um prazo definido, muitas vezes em torno de dez dias úteis. Sem isso, o cliente pode travar a aprovação indefinidamente, e com ela a última fatura. Se você é o cliente, peça um prazo claro para o fornecedor corrigir o que foi apontado, para que a contagem seja justa dos dois lados.

Os pedidos de mudança merecem o mesmo cuidado. O aumento de escopo raramente chega como um grande pedido. Chega como dez pedidos pequenos que, cada um, parecem razoáveis. Um processo de mudança de um parágrafo resolve isso: qualquer alteração de escopo, preço ou datas exige uma ordem de mudança por escrito, assinada pelas duas partes antes de o trabalho começar. Muitos fornecedores perdem margem em projetos simplesmente porque o SOW permitia acordos verbais.

Preço fixo ou tempo e materiais: qual combina com um SOW?

A seção de preço muda a forma como o risco é dividido, por isso vale escolher com cuidado.

O preço fixo coloca o risco de entrega no fornecedor. Funciona quando o escopo é bem compreendido e dificilmente vai mudar. Funciona mal quando o escopo é nebuloso, porque o fornecedor vai embutir uma margem de segurança ou brigar a cada mudança.

Tempo e materiais coloca o risco de esforço no cliente. Serve para trabalhos exploratórios, mas precisa de um teto ou de um limite máximo, senão o orçamento é apenas uma opinião.

Um modelo híbrido, com preço fixo por marco, costuma ser o compromisso mais honesto. Cada marco tem seu próprio entregável, teste de aceite e fatura, o que torna o SOW fácil de auditar e fácil de interromper se o projeto sair do trilho.

Quais ferramentas ajudam a redigir, assinar e revisar um SOW?

Ferramenta nenhuma vai escrever um bom escopo por você, mas pode eliminar o trabalho repetitivo ao redor dele.

Para redigir a partir de blocos reutilizáveis, com aprovações e assinatura eletrônica no mesmo fluxo, uma plataforma de documentos é prática.

Para apenas assinar, com trilha de auditoria e aceitação ampla entre as partes, um serviço de assinatura eletrônica dedicado basta.

Para equipes que fecham muitos SOWs por ano e precisam vinculá-los a um MSA, uma plataforma de gestão do ciclo de vida de contratos mantém a ligação entre os termos-mestre e cada documento de projeto.

Para uma primeira passada de risco nas cláusulas dentro do Word, um complemento de revisão com IA pode sinalizar exclusões ausentes ou uma cláusula de responsabilidade conflitante antes de um humano ler.

Nenhuma dessas ferramentas substitui um advogado quando os riscos são altos. Use o software para pegar os problemas rotineiros e leve ao seu advogado qualquer coisa incomum, grande ou transfronteiriça.

Onde as pessoas erram ao assinar um SOW e o que fazer antes de assinar o próximo

Depois de ler muitos desses documentos, as mesmas falhas aparecem sempre.

• Assinar o SOW antes de existir um MSA, e o projeto roda sem termos de responsabilidade ou de propriedade intelectual.

• Deixar datas como "aproximadamente", sem consequência para o atraso.

• Descrever entregáveis por atividade ("prestar suporte") e não por resultado ("responder a chamados prioritários em até quatro horas úteis").

• Esquecer a proteção de dados quando o fornecedor vai tratar dados pessoais. Na UE e no Reino Unido, isso costuma exigir um acordo de tratamento de dados junto com o SOW, e os detalhes certos dependem das jurisdições envolvidas.

• Nunca atualizar o SOW depois de uma mudança verbal e depender da memória um ano depois.

Nenhum desses riscos exige genialidade jurídica para ser evitado. Exige alguém que leia o documento devagar antes de assinar. Três ações cobrem a maior parte deles.

1. Confirme que existe um MSA e que o SOW diz qual documento prevalece nos termos jurídicos e em relação a escopo e valores.

2. Reescreva cada entregável para que um estranho consiga dizer, sim ou não, se ele foi entregue, e acrescente exclusões e premissas.

3. Confirme a janela de aceite, o prazo de correção e a regra de ordem de mudança por escrito, e mantenha cada aditivo anexado ao próprio SOW.

Se o projeto for grande, envolver dados pessoais ou cruzar fronteiras, peça para seu advogado revisá-lo. A resposta depende da lei aplicável, e uma revisão curta custa muito menos do que uma disputa.