Uma Declaração de Trabalho (SOW) às vezes é confundida com um Contrato Principal de Serviços (MSA) e, de fato, alguns usam os termos de forma intercambiável.
Por outro lado, uma SOW é a maneira ideal de definir o escopo de um projeto, especialmente um projeto complexo, ao contrário de um MSA, que detalha um acordo de serviços de longa data. (Você pode ler um blog recente meu sobre como elaborar contratos, SLAs e MSAs).
Muitas vezes, um cliente exigirá especificamente uma SOW, portanto, você deve estar preparado para elaborar uma que atenda a ambas as partes.
Se você já tem um contrato ou MSA com um cliente, sua SOW pode abranger algumas das mesmas questões e reforçar esses vínculos.
Visão geral da SOW
Uma SOW, na maioria das vezes baseada em projetos, concentra-se em definir quais são os resultados e quando eles devem chegar.
Igualmente importante, o SOW define todos os marcos que estão por trás dos resultados esperados e quem faz o quê. Isso requer cronogramas, uma forma de avaliar o progresso e um mecanismo para vincular o pagamento ao andamento do projeto. Além disso, todos os recursos essenciais para o projeto são definidos no SOW, bem como quais partes arcam com quais custos.
Também é necessário haver um acordo sobre como o projeto é gerenciado e governado, por quais métodos e o que define sucesso ou fracasso. Às vezes, essas métricas incluirão KPIs; outras vezes, há outras maneiras de definir se o projeto está progredindo adequadamente, e essas métricas dependem do escopo ou do estilo do projeto. Algumas, por exemplo, podem estar mais relacionadas à infraestrutura ou à rede, enquanto outras tratam inteiramente de novos serviços. Obviamente, essas seriam medidas de maneira muito diferente. Por exemplo, medir um projeto de infraestrutura pode exigir a verificação de que o hardware esteja instalado, configurado e tenha bom desempenho de rede e segurança. Um serviço seria avaliado com base no fato de estar devidamente personalizado para o cliente, de os usuários finais poderem utilizar o serviço — como no caso do backup em nuvem — e de haver confiança de que o serviço pode cumprir os SLAs.
Pode ser uma boa ideia estabelecer um procedimento de gerenciamento de mudanças para lidar com alterações no escopo do projeto, dificuldades imprevistas fora do controle de qualquer uma das partes ou outras circunstâncias. Dessa forma, você terá um mecanismo para lidar com as mudanças solicitadas, acomodando ambas as partes.
Entretanto, uma SOW nem sempre pode abranger todos os aspectos do projeto. Para empreendimentos complexos, pode haver vários documentos relacionados e adendos para tratar de detalhes, como especificações no caso de um projeto de software ou adendos de contrato relacionados a garantias de serviço.
Como uma SOW leva a outros trabalhos
Assim como um simples contrato, MSA ou SLA, uma SOW é usada para medir o desempenho de um prestador de serviços. Se você tiver um bom desempenho, essa SOW será uma ferramenta de vendas fundamental para adquirir novos negócios. Você não só provou que pode realizar o projeto, como também entende o cliente e está totalmente preparado para fazer mais. E você pode demonstrar isso de forma detalhada, mostrando como lidou com todos os aspectos do projeto e comprovando seu desempenho de alto nível.
Aspectos legais
Assim como em um contrato ou MSA, qualquer SOW deve ser cuidadosamente revisada por um consultor jurídico. Ao mesmo tempo, a linguagem inclui aspectos técnicos e jurídicos. Como a SOW é um documento usado por muitas pessoas, inclusive gerentes e outros profissionais de negócios, ela deve ser redigida usando uma linguagem clara e sem jargões, tanto quanto possível. É importante que o documento seja compreensível para todos os leitores, não apenas para advogados e especialistas técnicos. Para conseguir isso, peça a um membro alfabetizado da sua equipe ou a um terceiro que leia o documento para verificar a clareza e faça as edições apropriadas.
Aqui estão alguns dos aspectos legais que a SOW deve abranger.
Propriedade intelectual
Em muitos casos, um MSP cria propriedade intelectual exclusiva para os clientes, ou seja, invenções com valor de mercado. Isso pode incluir técnicas, scripts, códigos e ferramentas de software completas. Nesta seção, o cliente deve concordar que, embora haja direitos de uso, você, como criador, é o proprietário dessas invenções.
Informações confidenciais
Suas práticas comerciais, preços e descontos podem ser tão valiosos quanto sua propriedade intelectual.
Seus clientes não devem compartilhar essas informações com seus clientes potenciais e, principalmente, com os concorrentes.
O mesmo se aplica ao MSP. Como prestador de serviços de confiança, você tem acesso a dados e estratégias confidenciais dos clientes. Proteger essas informações não é apenas do seu interesse profissional, mas também do seu interesse legal.
Rescisão do contrato
A rescisão pode prejudicar ambos os lados. Se você rescindir o contrato, o cliente não terá o projeto ou serviço de que precisa desesperadamente. Para você, pode não obter a receita com a qual contava e pode ter problemas para recuperar os custos irrecuperáveis.
A SOW deve determinar, para ambos os lados, o que é justa causa para rescisão e se e como uma das partes pode ser compensada pelo trabalho prometido ou entregue no momento da rescisão. Ela deve estabelecer quem é o proprietário de qual propriedade, como hardware físico, e se (e quando) isso precisa ser devolvido ao verdadeiro proprietário.
Alguns detalhes sobre MSP
O governo do Estado do Texas trabalha com Provedores de Serviços Gerenciados (MSPs) e Provedores de Serviços em Nuvem, que prestam assistência em aplicações e operações de TI. Por meio do documento “Como redigir uma Declaração de Trabalho eficaz”, o governo oferece orientações aos MSPs. Um exemplo é particularmente relevante, pois trata de um contrato de Declaração de Trabalho (SOW) referente às funções essenciais dos MSPs.
Aqui está o exemplo: "O cliente deseja que o fornecedor forneça monitoramento e manutenção do local, o que inclui monitoramento e alertas remotos de equipamentos de rede, reparos e manutenção remotos e no local e serviços de resposta a interrupções no local em Houston, Dallas e El Paso", diz o documento.
Veja como as responsabilidades são divididas.
- "Funções e responsabilidades do cliente
- Acesso ao site em todos os três locais
- Compra e entrega de equipamentos de rede
- Projeto de configuração para todos os equipamentos de rede
- Funções e responsabilidades do fornecedor
- Responder a interrupções na rede de acordo com os SLAs
- Responder às solicitações dos clientes de acordo com os SLAs
- Forneça todas as atualizações de desenho de rede à medida que as mudanças ocorrerem"
O fornecedor, ou MSP, deve:
- "Realize o inventário do local e forneça uma lista de inventário e esquemas atualizados.
- Relatórios semanais de status".
O Texas também exige SLAs como parte da SOW. "Os níveis de serviço permitem que o cliente especifique as expectativas de nível de serviço para os serviços que estão sendo executados. Os níveis de serviço podem estar vinculados aos tempos de resposta do serviço, ao tempo de atividade de uma rede, ao tempo médio de reparo (MTTR) ou a medidas semelhantes.
- O fornecedor responderá às interrupções em até duas horas após a notificação.
- O fornecedor fornecerá um status em até 4 horas após a notificação da interrupção."
O Texas também tem especificações e o que é necessário para aceitar o trabalho e, se isso não for cumprido, o estado reterá o pagamento.
- "Realize o inventário do local e forneça uma lista de inventário e esquemas atualizados.
- Relatórios semanais de status".
A vinculação do pagamento ao trabalho realizado também é fundamental para o Texas, e o documento detalha: "O preço e os cronogramas/marcos de pagamento podem estar vinculados aos entregáveis, conforme mencionado acima, mas também podem estar vinculados à conclusão das fases de um projeto, desde que o fornecedor demonstre a conclusão da tarefa e o acompanhamento em direção à meta do projeto.
Exemplo: Fases do projeto que podem gerar pagamentos:
- Relatório de práticas comerciais atuais
- Pode incluir entrevistas com o pessoal, redações, análise de plataformas de TI, etc.
- Relatório de análise de lacunas
- Isso incluiria as tarefas do fornecedor de identificar a meta final do cliente, analisar os sistemas e processos atuais e elaborar o relatório de lacunas.
- Relatório de avaliação final"
CompTIA para o resgate
Para muitas questões relacionadas a MSP, a CompTIA oferece uma grande variedade de recursos. No guia “Incorporating a Statement of Work” (Incorporando uma Declaração de Trabalho), a organização fornece orientações sobre os fundamentos da elaboração de uma SOW e explica por que você pode precisar dela.
Solução de disputas
Como em qualquer contrato, uma SOW ajuda a proteger ambas as partes no caso de uma disputa, especialmente uma que parece estar se encaminhando para o tribunal.
"Se houver uma disputa sobre um contrato, uma das primeiras coisas que um tribunal faz é tentar entender o que as partes pretendiam. A Declaração de Trabalho é o lugar para dizer a elas. Todo contrato deve ter algum tipo de descrição do que está sendo vendido, do tipo de trabalho que será feito ou dos objetivos a serem alcançados; não precisa ser mais elaborado do que as circunstâncias justificam", argumenta a CompTIA.
Premissas básicas
A CompTIA acredita que grande parte da SOW pode se basear nas informações de sua cotação original, mas depois você acrescenta detalhes sobre como as contingências são tratadas. "Você, sem dúvida, cotou seu preço com base no que faria para o cliente, no que o cliente ou um terceiro poderia fazer e quando ou com que frequência. Muitas vezes, essas suposições são baseadas no que você tem controle e no que não tem", explicou a CompTIA.
O grupo cita o exemplo de um reparo no local que deve levar um dia. No entanto, esse cronograma pressupõe que você recomendou que o cliente mantivesse peças de reposição em estoque. Se isso não acontecer, esse reparo de um dia pode se transformar em vários.
Quanto maior o escopo, mais abundantes são os problemas
Para projetos ou tarefas menores, um contrato simples pode ser suficiente. Mas projetos mais amplos e complexos trazem mais variáveis. “A instalação levanta uma série de questões quando incluída no contrato. Chave na mão? Tempo e materiais? Pagamentos por etapas? Coordenação de prestadores de serviços? A prestação de serviços de suporte técnico traz um conjunto distinto de problemas”, são algumas das questões levantadas pela CompTIA. “Quais pacotes você terá que dar suporte? Qual é o nível de treinamento dos usuários? Qual é a idade do sistema? A natureza do negócio do cliente e as leis que o regulam também complicam a equação. Os setores de saúde e financeiro costumam ter quantidades significativas de informações de clientes que são altamente confidenciais e potencialmente prejudiciais se comprometidas.”
Conclusão
Os MSPs se dedicam de coração aos serviços que prestam. Ao mesmo tempo, os clientes nem sempre são perfeitos. Pode ser difícil lidar com eles, e podem ocorrer falhas de comunicação porque eles não entendem de tecnologia tão bem quanto você.
É por isso que contratos como SOWs e MSAs são tão importantes. Eles oferecem proteção legal para você no caso de um mal-entendido e dão ao cliente um roteiro para o que você oferece. Eles também podem ser documentos vivos que mudam à medida que você acrescenta serviços novos ou de nível superior.
