A principal mudança que determina se um RFP será bem-sucedido ou falhará

A maioria dos RFPs falha por muitos motivos.

Eles atrasam, consomem mais esforço interno do que o planeado, os fornecedores prometem mais do que cumprem, a entrega fica aquém das expectativas e as discussões comerciais tornam-se adversariais poucos meses após a assinatura do contrato.

Mas, na nossa experiência em organizações de media, OTT, transmissão (broadcast) e publicação digital, os RFPs quase sempre falham no mesmo ponto, muito antes de os fornecedores serem selecionados, e frequentemente antes mesmo de o documento ser emitido.

Eles falham na forma como os requisitos são escritos.

Se há uma mudança que o autor de um RFP pode fazer que tem um impacto desproporcional no resultado, é esta:

Deixe de pedir aos fornecedores para descreverem capacidades e comece a forçá-los a prová-las através de requisitos claros, inequívocos e mensuráveis.

Tudo o resto no processo de RFP é secundário.

Por que os RFPs parecem justos mas produzem más decisões

A maioria dos RFPs com fraco desempenho não parece problemática à superfície. Na verdade, muitas vezes parecem minuciosos, estruturados e razoáveis.

Eles contêm perguntas sensatas, tais como:

• Descreva a sua capacidade de pesquisa dentro do CMS

• Explique como a sua plataforma suporta a localização

• Fale-nos sobre a sua abordagem à escalabilidade e ao desempenho

Estas perguntas parecem abertas, colaborativas e favoráveis ao fornecedor. Também parecem informativas.

Na prática, elas criam três problemas sistémicos.

Primeiro, convidam à interpretação. Cada fornecedor responde a uma pergunta subtilmente diferente.

Segundo, recompensam a força do marketing em vez da verdade do produto. As respostas narrativas parecem convincentes, mesmo quando a capacidade é parcial, baseada num roteiro (roadmap) ou assumida.

Terceiro, impossibilitam uma comparação objetiva. As discussões de avaliação rapidamente derivam de evidências para opiniões, e a pontuação torna-se um exercício de persuasão em vez de avaliação.

Neste ponto, o processo de RFP já está comprometido – mesmo que todos os outros passos sejam executados perfeitamente.

O momento em que tudo corre mal: requisitos subjetivos

O padrão de falha mais comum que vemos começa com uma única palavra:

“Descreva.”

Por exemplo:

“Descreva a funcionalidade de pesquisa no CMS.”

Este requisito não pode ser pontuado de forma objetiva. Não existe uma definição partilhada de sucesso, nenhum limite mensurável e nenhuma forma de determinar a conformidade com confiança.

Qualquer fornecedor pode responder positivamente sem se comprometer com nada verificável.

O que se segue é previsível:

• Os avaliadores preenchem as lacunas com suposições

• Os workshops são utilizados para clarificar capacidades básicas

• As negociações contratuais tentam fixar retroativamente o âmbito

• A entrega revela expectativas desalinhadas

O RFP não falhou porque os fornecedores foram desonestos. Falhou porque os requisitos permitiram que fossem vagos.

O que os grandes autores de RFPs fazem de diferente

Os autores de RFPs fortes abordam os requisitos de forma muito diferente.

Em vez de pedirem aos fornecedores para explicarem como algo funciona, começam por definir o que deve ser verdade para que a solução seja aceitável.

Eles pegam numa necessidade de produto de alto nível ou numa história de utilizador (user story) e decompõem-na num conjunto de declarações atómicas e testáveis.

Cada declaração é:

• Clara

• Inequívoca

• Mensurável

• Avaliada de forma independente

Crucialmente, cada declaração permite apenas uma de duas respostas: Verdadeiro ou Falso.

Por exemplo, em vez de perguntar sobre a capacidade de pesquisa:

• A solução DEVE suportar a pesquisa em todos os atributos de metadados armazenados no CMS para qualquer objeto.

• A solução DEVE suportar a pesquisa em todos os idiomas definidos num artigo multi-idioma.

• A solução DEVE devolver resultados no prazo de dois segundos para conjuntos de dados de até X milhões de objetos sob condições normais de funcionamento. (E não se esqueça de definir o que são condições normais de funcionamento!)

Não há margem para interpretações. Ou a capacidade existe, ou não existe.

Esta abordagem altera completamente a natureza do RFP.

Por que os requisitos binários transformam os resultados

Quando os requisitos são escritos como declarações objetivas em vez de solicitações narrativas, várias coisas acontecem imediatamente.

As respostas dos fornecedores tornam-se mais curtas e precisas. A linguagem de marketing desaparece porque deixa de ajudar.

As lacunas de capacidade surgem mais cedo. Os fornecedores são forçados a ser explícitos sobre limitações, dependências ou itens do roteiro (roadmap).

A pontuação torna-se mais rápida e defensável. As discussões de avaliação baseiam-se em evidências e não em opiniões.

Os workshops passam a focar-se na validação e na profundidade, e não em clarificações básicas.

Mais importante ainda, os contratos tornam-se mais fáceis de negociar. A matriz de requisitos já define a capacidade mínima aceitável, reduzindo a ambiguidade e o risco de litígios.

Esta é a forma isolada mais eficaz de reduzir pedidos de alteração futuros, atritos comerciais e desilusões na entrega.

Traduzir histórias de utilizador em requisitos, sem bloquear o futuro

Uma das preocupações mais comuns ao escrever requisitos altamente específicos e mensuráveis é que eles irão limitar demasiado a solução.

Esta preocupação é válida – mas não é motivo para aceitar requisitos vagos. É um sinal de que os requisitos devem ser escritos com intenção.

Os requisitos específicos e objetivos não devem descrever como uma solução é construída. Devem definir o comportamento que deve ser verdadeiro, deixando deliberadamente espaço para evolução, reconfiguração e mudanças futuras.

Esta distinção é crítica.

Requisitos mal escritos fixam de forma rígida as suposições de hoje:

• Prescrevendo arquiteturas internas

• Impondo padrões de implementação

• Incorporando os constrangimentos organizacionais atuais como verdades permanentes

Requisitos bem escritos fazem o oposto. Definem resultados que suportam uma abordagem de arquitetura para a mudança.

Por exemplo:

Em vez de:

• A solução DEVE utilizar a tecnologia X para suportar a pesquisa multilingue.

Prefira:

• A solução DEVE suportar a pesquisa em todos os idiomas definidos num artigo multi-idioma, sem exigir desenvolvimento personalizado para cada idioma adicional.

In vez de:

• O CMS DEVE ser configurado com um modelo de conteúdo fixo definido na implementação.

Prefira:

• O CMS DEVE permitir que utilizadores autorizados estendam e modifiquem modelos de conteúdo sem alterações de código ou nova implementação da plataforma.

Em ambos os casos, o requisito continua a ser binário e testável, mas preserva a liberdade de adaptação.

É assim que a mudança futura é gerida de forma responsável. Não está a prever o que a plataforma se deve tornar. Está a garantir que ela se possa tornar noutra coisa quando o negócio inevitavelmente mudar.

As histórias de utilizador de alto nível continuam a desempenhar um papel importante. Expressam intenção e direção. Mas o mecanismo de avaliação continua a ser o conjunto de requisitos, escrito para testar a capacidade comportamental, não a preferência de design.

Este equilíbrio é difícil de alcançar. Requer experiência para saber quais os constrangimentos que protegem o negócio e quais os que apenas protegem o pensamento atual.

Esse julgamento é a diferença entre requisitos que envelhecem bem e requisitos que se tornam obsoletos antes mesmo de o contrato ser assinado.

Por que escrever excelentes requisitos é genuinamente difícil

Existe uma razão pela qual esta abordagem raramente é bem executada.

Escrever requisitos que sejam específicos, claros, mensuráveis e objetivos não é uma tarefa administrativa. É uma disciplina analítica que se situa na interseção entre o pensamento de produto, a engenharia de sistemas, a realidade operacional e o risco comercial.

Na maioria das organizações, simplesmente não vemos muitas pessoas que consigam fazer isto de forma consistente.

É por isso que as organizações que gerem programas complexos de media e plataformas frequentemente recorrem a especialistas em RFP e processos de concurso quando a decisão acarreta riscos a longo prazo.

Os autores de requisitos devem ser capazes de:

• Compreender as necessidades dos utilizadores sem copiar as histórias de utilizador palavra por palavra

• Traduzir objetivos de negócio abstratos em comportamentos de sistema concretos

• Antecipar escala, casos limite e modos de falha

• Eliminar a ambiguidade sem restringir excessivamente a entrega

• Escrever declarações que sejam testáveis, defensáveis e prontas para contrato

Essa combinação de competências é rara. Como resultado, os requisitos são frequentemente escritos por comités, diluídos através de consensos ou delegados a equipas sem a experiência necessária. O resultado é previsível: documentos bem-intencionados que não conseguem proteger o negócio.

Esta é também a razão pela qual os requisitos fortes muitas vezes parecem desconfortáveis internamente. Eles forçam decisões mais cedo do que muitas organizações estão habituadas a tomar. Expõem a incerteza. Retiram a rede de segurança da linguagem vaga.

Por que tudo o resto continua a importar... mas não tanto

Os prazos importam. A governação importa. A comunicação importa. A equidade importa.

Mas nada disto pode compensar requisitos fracos.

Um processo de RFP perfeitamente executado, mas baseado em requisitos ambíguos, continuará a produzir um resultado fraco. Um processo menos elegante, construído sobre requisitos rigorosos e objetivos, frequentemente é bem-sucedido apesar de imperfeições noutras áreas.

Esta hierarquia é desconfortável, particularmente em ambientes liderados pela área de compras. Mas reflete a realidade.

Se vai mudar apenas uma coisa, mude isto

Se está prestes a emitir um RFP, reveja-o com uma pergunta em mente:

Todos os requisitos podem ser pontuados de forma objetiva, sem debate?

Se a resposta for não, é aí que deve concentrar o seu esforço.

Fazer isto bem requer tempo e disciplina. Exige resistir à linguagem vaga e forçar a clareza mais cedo do que parece confortável.

O retorno é significativo.

A Spicy Mango mantém estruturas de RFP abrangentes e bibliotecas de requisitos para plataformas de OTT, streaming e publicação digital, construídas a partir de experiência real de entrega. Licenciamos material de referência que traduziu centenas de requisitos funcionais e não funcionais de alto nível em milhares de declarações distintas, claras e mensuráveis. Esta profundidade é uma das razões pelas quais organizações de media de Nível 1 (Tier 1) nos contratam para moldar e entregar programas de transformação estratégica, não apenas para gerir compras, mas para definir como é realmente o sucesso ao nível dos requisitos. Se deseja acelerar este trabalho sem sacrificar o rigor, entre em contacto para ver como é a excelência na prática.