Checklist de RFP para fornecedores de software

Um RFP de desenvolvimento de software deve definir o problema, os requisitos funcionais e não funcionais, as necessidades de segurança e de dados, as condições comerciais e o método de pontuação antes de qualquer fornecedor responder. Pontue os critérios ponderados em vez de discutir depois, verifique as referências em vez de acreditar nos casos de estudo e faça um piloto pago antes de assinar o que comprometa o orçamento.

O que deve conter um RFP de desenvolvimento de software?

O documento existe para tornar as respostas comparáveis. Um fornecedor só pode responder ao que está escrito; um RFP que descreve uma visão e pede um preço convida propostas que todas parecem excelentes e nenhuma das quais pode ser avaliada em relação às outras. O conteúdo funcional, os constrangimentos e a regra de pontuação têm de estar fixados antes de chegar a primeira resposta, ou a avaliação se transforma numa negociação sobre critérios.

Há também uma questão de ordem que poupa meses: o RFP não é onde se descobre o que é preciso. Os requisitos vêm do trabalho interno — os responsáveis pelo processo a descrever como o negócio funciona na prática, as finanças a dizer o que tem de conciliar, as pessoas que vão usar o sistema todos os dias a indicar onde dói hoje. Esse trabalho é lento e político, e acontece antes de qualquer fornecedor entrar em cena. As equipas que o externalizam no primeiro fornecedor que chega acabam com requisitos escritos na linguagem do produto desse fornecedor, o que faz todas as outras propostas parecerem mal ajustadas — não porque sejam, mas porque a referência foi escrita à volta de um dos concorrentes.

Vale ainda distinguir três documentos que se confundem com frequência. Um RFI pergunta ao mercado o que existe; é curto, precede os requisitos e não compromete ninguém. Um RFP pede uma proposta contra requisitos definidos e um método de avaliação declarado. Um RFQ pede um preço contra um âmbito definido. Lançar um RFQ antes de o âmbito existir é a forma mais comum de comparar três números que significam três coisas diferentes.

Cinco coisas que um RFP completo faz e um incompleto não faz:

• Define o problema, não a solução. «Reduzir o tempo de compilação do relatório consolidado mensal de dias para um número definido de horas» é um enunciado do problema; «construa-nos um armazém de dados» é uma suposição de solução que pode não o resolver.


• Separa requisitos de preferências. O que é obrigatório decide se a proposta passa, o que é desejável decide a sua posição na classificação, e o que é opcional não decide nada. Os fornecedores só respondem a sério quando essa distinção está visível.


• Nomeia os constrangimentos. Sistemas existentes que têm de ser integrados, dados que têm de ser migrados, obrigações de auditoria e de conservação, janela de entrada em produção, quem aprova.


• Declara de antemão o método de avaliação. Critérios ponderados, quem avalia, que evidência é exigida, e quando os fornecedores não selecionados recebem um resumo das suas pontuações.


• Define as datas do processo. Prazo para perguntas, período de esclarecimentos, prazo de submissão, período de avaliação, data da decisão. Um processo sem datas atrai fornecedores que já estão ocupados.

Estrutura do RFP

Requisitos funcionais e não funcionais

Os requisitos funcionais descrevem o que o sistema faz: que processos, para que papéis, com que saídas. Os requisitos não funcionais descrevem o quão bem o fazem, e são os que mais vezes ficam de fora — e depois são exigidos tarde, com custo, ou não são exigidos de todo.

Vale a pena afirmar explicitamente na maioria dos projetos B2B:

• Desempenho. Tempos de resposta sob uma carga declarada, para as operações que contam — lançamento de encomendas, geração de relatórios, fecho do mês.


• Disponibilidade. Que disponibilidade o negócio precisa, janelas de manutenção, e o que acontece quando o sistema está em baixo — uma meta sem descrição de indisponibilidade aceitável não é um requisito.


• Recuperação. RTO e RPO em termos simples: quanto tempo demora a operação a retomar após um incidente, e quanto trabalho pode perder-se. Ambos os números pertencem à avaliação, e não apenas ao contrato.


• Rasto de auditoria. Quem alterou o quê e durante quanto tempo fica guardado, e por quem pode ser recuperado — sobretudo onde há dinheiro, stock ou dados pessoais em movimento.


• Acessibilidade e usabilidade. Quem usa o sistema, em que dispositivos, em que línguas; um sistema que o armazém não consegue operar não está implementado, por bem que pontue.


• Integração e dados. Que sistemas se ligam, em que sentido os dados fluem, e quem é o responsável pelo registo mestre de cada entidade.

Perguntas de segurança e cumprimento

A segurança é melhor abordada como perguntas com evidência exigida do que como uma linha de sim/não. As que valem a pena incluir:

• ISO/IEC 27001 — o fornecedor tem a certificação, e o que é que o âmbito certificado cobre? Um certificado que cubra a organização de vendas mas não as equipas de entrega diz algo muito concreto.


• Desenvolvimento seguro — onde a segurança se situa na conceção, na revisão de código e nos testes; se a gestão de dependências e de vulnerabilidades é rotina.


• OWASP Top 10 — se faz parte da revisão do fornecedor para componentes expostos na web; uma questão concreta e respondível.


• Controlo de acesso — quem pode aceder aos seus ambientes e dados, como o acesso é concedido e revogado, e que registo de eventos existe.


• Obrigações de proteção de dados — KVKK e GDPR onde se aplicam; quem é responsável pelo tratamento, quem é subcontratante, e o que o acordo de tratamento de dados diz sobre subcontratantes e sobre a notificação de violações.

Termos comerciais, preços e SLAs

Peça preços numa estrutura comparável: o que está incluído, o que é cobrado à parte, e como são precificadas as alterações. Um número só, sem âmbito por trás, não pode ser comparado com outro número só; a página de custos e modelos de preços explica as estruturas comuns e as questões que cada uma levanta.

Os SLAs merecem a mesma precisão que os requisitos. Uma percentagem de disponibilidade só faz sentido com o seu método de medição, exclusões e forma de resolução; um tempo de resposta só faz sentido com as definições de severidade e o horário laboral. Peça a cada fornecedor que defina os termos dentro do SLA, em vez de aceitar uma página de percentagens sem definições.

Matriz de pontuação da avaliação

Um modelo copiável. Os pesos abaixo são um exemplo — defina os seus segundo as suas prioridades e mantenha o total em 100. Defina o que significam 1, 3 e 5 antes de alguém pontuar, e não depois de as discussões começarem.

Duas disciplinas fazem isto funcionar. Pontue de forma independente antes de discutir, para que a primeira voz confiante não imponha o tom à sala. E registe uma linha de justificação por pontuação — os fornecedores que recebem um resumo das pontuações com motivos aceitam o resultado muito mais facilmente, e a sua própria equipa consegue defendê-lo seis meses depois.

Uma terceira disciplina diz respeito a quem pontua. O painel deve incluir as pessoas que vão viver com o resultado — o responsável pelo processo, quem é responsável pelos dados, alguém de segurança ou de finanças quando essas funções existem —, e não apenas compras. As avaliações falham em silêncio quando o painel pontua o que consegue julgar (a estrutura da proposta, o polimento da equipa de vendas) e adia o que não consegue (se a abordagem de integração realmente se encaixa nos sistemas atuais). Uma pessoa técnica com autoridade para dizer «isto não vai funcionar com o que temos a correr» previne mais custo do que qualquer desconto.

Os pesos merecem ainda um aviso: são uma declaração de prioridades que fica visível para os fornecedores. Se a segurança pesa 5% e o preço 30%, fornecedores sérios preocupados com segurança vão notar, e a sua própria equipa também quando o contrato for assinado. Um peso definido às pressas, só para preencher a tabela, é lido como verdade por todos os que estão fora da sala; defina-o uma vez, com os decisores presentes, e mude-o apenas com a mesma formalidade com que o definiu.

Verificação de referências e piloto

Os casos de estudo são marketing; as verificações de referências são evidência. A chamada que funciona é curta e pergunta o que aconteceu, e não o que foi entregue: o projeto terminou, o que mudou no âmbito, quem esteve realmente na equipa, o que fariam de outra forma, e se voltariam a começar o projeto com este fornecedor. Respostas em tempo passado e respostas específicas são o sinal.

Peça uma referência de um projeto que se assemelhe ao seu em tamanho e complexidade, e não da obra de que o fornecedor mais se orgulha — uma implementação de topo duas vezes o seu orçamento ensina-lhe pouco sobre como a equipa se comporta à sua escala. E verifique a referência por si: um contacto que o fornecedor prepara antecipadamente é um testemunho, e não uma referência; a chamada útil é aquela em que o cliente toma conhecimento do que está a perguntar no momento.

Um piloto pago e curto testa depois a parte que nenhuma referência testa: como esta equipa trabalha com as suas pessoas quando os requisitos estão incompletos. As regras de desenho são as mesmas que vale a pena definir para qualquer piloto — trabalho real, critérios de aceitação escritos, uma alteração a meio, e uma regra de decisão acordada de antemão. A página de outsourcing de TI aborda o desenho do piloto com mais detalhe.

Cláusulas contratuais a verificar

• Cessão de propriedade intelectual — os direitos sobre código, documentação e derivados transferem-se para si desde a criação, e não apenas no pagamento final.
• Propriedade dos dados — os seus dados continuam seus; os direitos do fornecedor limitam-se ao que é necessário para prestar o serviço.
• Aceitação — o que significa aceitação, quem a declara, e o processo quando algo falha.
• Controlo de alterações — como se pedem, precificam e aprovam alterações de âmbito; sem isso, cada alteração se transforma num litígio.
• Saída e transição — código-fonte, acesso, documentação e assistência no fim; como se transfere conhecimento se o fornecedor mudar.
• Depósito (escrow) — quando a continuidade do negócio depende de componentes mantidos pelo fornecedor, o que acontece se este não puder continuar.
• Responsabilidade — limites, exclusões e o que não está assegurado; leia com a mesma atenção que o preço.
• Rescisão — prazos de aviso, obrigações após a rescisão, e o processo de devolução ou eliminação de dados.

Perguntas frequentes

Devemos enviar primeiro um RFI ou um RFP?

Um RFI quando o mercado ou o problema não estão claros — está a perguntar o que existe e quanto custa. Um RFP quando os requisitos e o método de avaliação estão definidos; enviar um mais cedo apenas muda o trabalho de requisitos para dentro da proposta de cada fornecedor, nas palavras deles e nas prioridades deles.

Quantos fornecedores devemos convidar?

Poucos o suficiente para poder ler cada proposta corretamente e ligar a cada referência. A maioria das avaliações perde qualidade para além de meia dúzia; uma pré-seleção construída a partir de um RFI, de uma chamada de triagem e de um projeto de referência semelhante costuma ser mais útil do que uma lista longa de nomes famosos.

Como devem ser definidos os pesos?

A partir das suas prioridades, antes de ver qualquer proposta, e acordados entre as pessoas que vão viver com o resultado. Um erro comum é atribuir pesos iguais em tudo, que é uma forma de dizer que nada importa mais do que nada; se o preço ou o risco dominam para si, os pesos devem dizê-lo.

Deve-se pontuar o preço?

Sim, mas como um critério ponderado com o âmbito fixado, e não como toda a avaliação. Um preço pontuado sem âmbito por trás recompensa o fornecedor que assumiu menos trabalho; precifique primeiro os seus requisitos e compare depois os totais para a mesma coisa.

Como pontuar as respostas de segurança?

Com evidência, e não com tom. Três níveis funcionam: sem posição (1), políticas descritas (3), âmbito do certificado verificado mais desenvolvimento seguro descrito e evidência fornecida (5). Quando um fornecedor não tem certificado, pergunte que controlos equivalentes existem por escrito — um «não» honesto com controlos documentados pontua melhor do que um «sim» não verificável.

Podemos alterar os requisitos depois do RFP?

Antes das submissões, sim — com a alteração anunciada a todos. Depois das submissões, apenas através de um esclarecimento formal que todos os concorrentes recebem; alterar requisitos em silêncio para um fornecedor destrói a comparabilidade em que todo o processo se baseia. Depois do contrato, é para isso que serve o controlo de alterações.

Fontes e normas

• ISO — editora da norma ISO/IEC 27001 (gestão da segurança da informação); confirme a edição corrente e o âmbito de um certificado antes de depender dele.
• OWASP — editora da lista dos 10 maiores riscos de segurança de aplicações web referenciada nesta página.
• Os princípios da matriz de pontuação seguem a prática publicada de modelos de RFP; os pesos mostrados são um exemplo para editar, e não uma recomendação. Esta página é orientação de compras, e não aconselhamento jurídico, e não é afirmada qualquer certificação ou auditoria para a WorldwideTradeX.

Páginas relacionadas

Desenvolvimento de software · Outsourcing de TI a partir da Turquia · Custos e modelos de preços · Auditoria e consultoria de TI · Pedir orçamento