Como saber se um fornecedor de software consegue mesmo construir

O site de todo fornecedor é igual. Cases com percentuais impressionantes, uma página de equipe, uma lista de tecnologias, um diagrama de processo com quatro ou cinco fases. Nada disso distingue um time que já operou sistemas em produção de um que nunca operou, porque nada disso é falsificável.

O que distingue é como respondem a perguntas sobre fracasso. Sucesso tem muitos narradores plausíveis. Fracasso só tem quem estava lá.

Seis perguntas

Faça estas a qualquer fornecedor que você esteja considerando a sério. O valor não está na resposta específica, está em ela ter textura ou não.

1. Conte um projeto que deu errado, e o que você faria diferente.

A resposta a esperar é específica e se implica: uma decisão que eles tomaram, por que parecia certa, o que custou e o que mudou depois. A resposta que deve preocupar culpa o cliente, culpa um fornecedor ou descreve uma dificuldade que não foi culpa de ninguém.

Todo mundo já teve um projeto ruim. Um time que não consegue nomear nenhum é inexperiente ou não está sendo franco, e nenhum dos dois é o que você quer.

2. Como é a escala de plantão de vocês, e quem está nela?

Times que constroem sistemas e entregam a chave não têm uma. Times que operam o que constroem têm, e explicam como funciona sem preparação, porque vivem isso.

3. Me conte o último incidente de produção de vocês.

Tempo de detecção, quem foi acionado, qual foi a correção, o que mudou depois. Um time que opera software tem essa história pronta. Um que não opera vai descrever um processo, e não um evento.

4. Como vocês lidam com um requisito que se mostra errado no meio do projeto?

Todo projeto tem esses. A resposta revela o modelo de contrato e a honestidade. "A gente levanta, precifica a mudança e você decide" é viável. "Isso não acontece, nosso discovery é minucioso" é uma afirmação que será testada e vai falhar.

5. O que vocês se recusariam a construir?

Um fornecedor sem resposta vai construir o que for pedido, inclusive a coisa que não deveria existir. A recusa específica importa menos do que ter uma.

6. Quem exatamente vai trabalhar nisso, e em que mais essas pessoas estão?

A distância entre quem aparece na apresentação e quem entra no projeto é o problema mais antigo do setor. Peça nomes, pergunte que percentual do tempo delas você recebe, e coloque isso no contrato. Se quiser fazer essas perguntas para a gente diretamente, é para isso que serve falar com um engenheiro.

O que pedir no lugar de um portfólio

Portfólios são curados. Estes são mais difíceis de encenar.

Peça	O que revela
Um trecho de código real, higienizado	Se o código tem testes, comentários que explicam o porquê e estrutura legível
Uma referência que encerrou a relação	Como se comportam quando o projeto acaba, que é quando mais importa
Um post-mortem que escreveram	Se as falhas são analisadas ou absorvidas
O processo de publicação, ponta a ponta	Se publicar é rotina ou é evento
Um discovery pago antes do compromisso todo	Se o pensamento deles vale o que cobram, com risco baixo
A resposta sobre acesso a dado em produção	Se o acesso é controlado ou é ambiente

Essa última linha merece ênfase. Pergunte quem no fornecedor consegue ler o seu dado de produção, como esse acesso é concedido e se é registrado. Um fornecedor cujos engenheiros têm todos acesso permanente à produção está dizendo que os controles dele são informais, seja lá o que diga a página de segurança. Os nossos estão descritos nas práticas de segurança.

Sinais que deveriam encerrar a conversa

Algumas respostas são desqualificantes por si só:

• Preço fechado para um sistema que não examinaram. Ou o preço está inflado, ou o escopo será renegociado. Os dois custam a você.
• Nenhum engenheiro nomeado, só papéis. Você está comprando capacidade de um pool, o que é ótimo se for isso que você quer e um problema se lhe disseram outra coisa.
• Nenhuma opinião sobre a sua arquitetura. Um fornecedor sem visão ainda não pensou no seu problema.
• Conformidade descrita como "a gente resolve". Para dado regulado, ou já fizeram sob contrato assinado ou não fizeram. Veja o que um BAA realmente obriga.
• Resistência a escrever premissas. Premissas por escrito são como um escopo fechado sobrevive ao contato com a realidade.

Comece menor do que a coisa toda

A avaliação mais confiável não é uma avaliação. É um projeto pago pequeno, com entrega real, feito antes do compromisso grande.

Duas semanas de discovery produzem um artefato que você julga pelo mérito: mostra que entenderam o sistema, encontrou coisas que você não sabia, o plano é algo que você seguiria. E se a resposta for não, você descobriu gastando uma fração do orçamento. O que esse projeto deve produzir está em o que uma discovery de duas semanas precisa entregar.

A questão da geografia é separada e costuma ser confundida com esta. Está em nearshore, offshore ou EUA.