Caderno de encargos de software para orçamentos comparáveis

Um caderno de encargos serve para tornar as respostas comparáveis

Um caderno de encargos tem uma única função: permitir que vários parceiros compreendam o problema o suficiente para propor uma forma de o resolver, com uma estimativa fiável. Se cada parceiro preencher as lacunas com os seus próprios pressupostos, as propostas diferem no âmbito e não na qualidade, e a mais barata é muitas vezes a que pressupôs menos.

Por isso, o documento deve ser preciso quanto ao problema e modesto quanto à solução. Descreva o que tem de ser verdade quando o projeto estiver concluído e deixe os parceiros explicar como lá chegariam. As respostas a essa parte em aberto são o que de mais útil vai ler.

Começar pelo problema de negócio e por como se vai avaliar o sucesso

Comece pela razão de ser do projeto: o que não funciona hoje, quem é afetado e quanto custa deixar tudo como está. Dizer que a equipa de operações volta a escrever no ERP cada encomenda recebida por e-mail diz muito mais a um parceiro do que pedir um portal de gestão de encomendas.

Depois, diga como vai avaliar o sucesso. Escolha alguns resultados observáveis, como o tempo poupado por encomenda, os erros que deixam de chegar aos clientes ou uma data a partir da qual um sistema antigo pode ser desligado. Estes critérios tornam-se mais tarde os critérios de aceitação das etapas, por isso escreva-os em termos que alguém possa verificar.

Descrever utilizadores, sistemas e dados antes das funcionalidades

O trabalho de integração e de dados é fácil de subestimar quando um parceiro não o consegue ver. Antes de enumerar funcionalidades, descreva quem vai usar o software, com que sistemas tem de funcionar e que dados trata. As lacunas nesta parte regressam mais tarde sob a forma de pedidos de alteração.

• Utilizadores: quem são, quantos são aproximadamente, e onde e em que dispositivos trabalham.
• Sistemas existentes: quais são, a quem pertencem, e se oferecem uma API documentada ou apenas uma base de dados e exportações de ficheiros.
• Dados: o que é pessoal, confidencial ou regulado, onde está hoje e quanto tem de ser migrado.
• Operação: quem vai operar o software depois do lançamento, e que regras de alojamento ou de cloud a empresa já tem.
• Restrições: idiomas, requisitos de acessibilidade, normas de segurança e qualquer prazo que não possa mudar, com a respetiva razão.

Partilhar um intervalo de orçamento e o prazo que realmente importa

Muitos compradores guardam o orçamento para ver o que os parceiros propõem. O resultado são propostas para projetos diferentes: um parceiro desenha para o mínimo, outro para tudo o que foi mencionado. Um intervalo, mesmo largo, permite a cada parceiro propor o melhor projeto que nele cabe e dizer com franqueza se não cabe.

Faça o mesmo com o tempo. Diga que data é fixa e porquê, como um contrato que termina ou um prazo regulamentar, e que datas são apenas preferências. Um parceiro só consegue planear em função de uma data inegociável se souber qual é.

Assinalar o que é fixo e deixar o resto em aberto

Classifique cada requisito como fixo, preferido ou em aberto. Fixo significa que uma proposta não é válida sem ele, como o alojamento na UE ou o início de sessão através do fornecedor de identidade que a empresa já usa. Preferido significa que há uma razão, mas que uma alternativa seria considerada. Em aberto significa que se pretende a recomendação do parceiro.

Deixe a tecnologia em aberto, a menos que haja uma razão real para a fixar, como uma equipa interna que vai manter o código ou uma plataforma que a empresa adotou como padrão. Quando fixar uma escolha, explique porquê, para que os parceiros não gastem a proposta a argumentar contra ela.

Por fim, peça a todos os parceiros que respondam com a mesma estrutura: a sua compreensão do problema, a abordagem, as fases e etapas, os pressupostos, os riscos, a equipa e o modelo comercial. Uma estrutura comum é o que torna as propostas comparáveis na prática.

Erros que tornam as propostas impossíveis de comparar

Muitas propostas inutilizáveis são respostas a um caderno de encargos que as convidou. Elimine estes padrões antes de enviar o seu.

• Uma lista de funcionalidades sem definição do problema, pelo que cada parceiro adivinha as prioridades.
• Uma especificação longa que fixa a solução antes de alguém ter analisado o problema.
• Nenhuma referência aos sistemas existentes nem à migração de dados, que depois voltam como pedidos de alteração.
• Detalhes adicionais dados a alguns parceiros em chamadas, pelo que as suas propostas respondem a perguntas diferentes.
• Palavras como «simples», «padrão» ou «como uma app conhecida», que significam coisas diferentes para cada leitor.
• Nenhum prazo para perguntas, ou respostas partilhadas apenas com o parceiro que perguntou.

Abrir espaço a perguntas e lê-las como parte da avaliação

Dê aos parceiros um período definido para colocarem perguntas, responda por escrito e envie cada resposta a todos eles. As perguntas, por si só, dizem alguma coisa: um parceiro que pergunta pelos dados, pelos utilizadores e pelos critérios de aceitação já está a pensar na entrega.

Se o problema ainda for demasiado incerto para ser bem descrito, diga-o e peça uma fase de descoberta curta e paga em vez de uma proposta completa. Um orçamento fechado construído sobre suposições esconde as incógnitas na sua margem de risco; uma fase de descoberta substitui as suposições por factos. Se quiser que engenheiros leiam o seu caderno de encargos, ou lhe respondam, pode enviá-lo através do nosso formulário Iniciar um projeto.

Perguntas frequentes