Como escolher uma software house: critérios e perguntas

O que é uma software house?

Software house é uma empresa especializada em projetar, desenvolver e manter software para outras empresas. Ela reúne os papéis necessários a um projeto, como levantamento de requisitos, design de interface, arquitetura, programação, testes e implantação, e assume a responsabilidade pela entrega.

Contratar uma software house é diferente de comprar um produto. O resultado ainda não existe no momento da contratação, e a qualidade dele depende tanto do fornecedor quanto da clareza do problema e da participação de quem contrata. Por isso, a escolha deve avaliar o modo de trabalhar, e não apenas o preço e o portfólio.

O que definir antes de procurar fornecedores?

Antes de pedir propostas, a empresa precisa ter clareza mínima sobre o que quer resolver. Sem isso, cada fornecedor imagina um projeto diferente e as propostas se tornam incomparáveis.

Um briefing enxuto responde a:

• Qual problema de negócio precisa ser resolvido e quem é afetado por ele.
• Como o processo funciona hoje, inclusive com planilhas e controles paralelos.
• Quem vai usar o sistema e em quais dispositivos.
• Com quais sistemas existentes ele precisa trocar dados.
• Quais restrições existem: prazo imposto por um evento, exigência regulatória, orçamento disponível.
• Quem, dentro da empresa, vai acompanhar o projeto e tomar decisões.

Também vale confirmar antes se o desenvolvimento próprio é mesmo o caminho. Se ainda houver dúvida entre adotar uma ferramenta de mercado e construir, o artigo software pronto ou sistema sob medida ajuda nessa decisão.

Quais critérios usar para avaliar uma software house?

Os critérios abaixo cobrem os pontos que mais influenciam o resultado de um projeto. Para cada um, indicamos o que observar e como verificar.

Entendimento do problema

O primeiro indício de qualidade aparece antes da proposta. Um fornecedor que pergunta sobre o processo, os usuários, as exceções e os sistemas existentes está reunindo o que precisa para estimar com responsabilidade. Um fornecedor que apresenta preço e prazo após uma conversa curta está estimando sobre suposições, e a diferença será cobrada depois.

Processo e visibilidade

Um bom processo permite que o cliente veja o software funcionando em partes, ao longo do projeto, e corrija a direção cedo. Pergunte em que momentos haverá entregas para validação e onde será possível acompanhar o andamento. Projetos que só mostram resultado no final concentram todo o risco na última semana.

Experiência e referências

Portfólio mostra aparência; referência mostra comportamento. Ao conversar com um cliente anterior, pergunte como o fornecedor reagiu a problemas, se os prazos combinados foram cumpridos e como foi o atendimento após a entrega. Experiência no mesmo segmento ajuda, mas experiência com o mesmo tipo de complexidade, como muitas integrações ou regras fiscais, costuma pesar mais.

Quem vai trabalhar no projeto

É comum que a fase comercial seja conduzida por pessoas experientes e que a execução fique com outra equipe. Pergunte quem serão os responsáveis técnicos, se haverá terceirização e o que acontece se alguém da equipe sair no meio do projeto.

Quais perguntas fazer antes de contratar?

Fazer as mesmas perguntas a todos os fornecedores torna a comparação objetiva. Sugerimos as seguintes, agrupadas por tema.

Sobre o projeto

1. O que vocês precisam saber de nós para estimar com segurança?
2. O que está incluído e o que está explicitamente fora da proposta?
3. Quais são os maiores riscos deste projeto e como pretendem tratá-los?
4. Como serão as entregas parciais e quem as valida?

Sobre a técnica

5. Como vocês escolhem a tecnologia de um projeto e por que indicam esta?
6. Que tipos de teste são feitos antes de uma entrega?
7. Existem ambientes separados para desenvolvimento, homologação e produção?
8. Como será feita a integração com os sistemas que já usamos? Se esse ponto for relevante no seu caso, vale conhecer as etapas descritas em como integrar dois sistemas.

Sobre contrato e propriedade

9. De quem é o código-fonte ao final do projeto e quando teremos acesso ao repositório?
10. O sistema usa componentes de terceiros ou bibliotecas próprias de vocês? Em que condições de licença?
11. Como são tratadas as mudanças de escopo: quem aprova, como são estimadas e cobradas?
12. Qual é o critério de aceite de cada entrega?

Sobre o pós-entrega

13. Existe período de garantia para correção de defeitos? O que ele cobre?
14. Como funciona a sustentação: canais, horários e prazos de atendimento?
15. Que documentação será entregue?
16. Se decidirmos trocar de fornecedor, como é feita a transição?

A última pergunta é a mais reveladora. Um fornecedor seguro do próprio trabalho responde sem desconforto, porque não depende de reter o cliente pela dificuldade de sair.

Quais são os sinais de alerta?

Alguns comportamentos na fase comercial antecipam problemas na execução.

• Preço e prazo fechados sem levantamento. Estimar sem entender o escopo significa que o número foi escolhido para vencer a concorrência.
• Proposta genérica. Um documento que serviria para qualquer cliente indica que o seu problema não foi analisado.
• Tudo é possível, nada é risco. Todo projeto tem riscos; quem não os menciona não os avaliou ou prefere não falar deles.
• Resistência a falar de código e documentação. Evasivas sobre titularidade e acesso ao repositório tendem a virar conflito no fim do contrato.
• Ausência de validações intermediárias. Sem entregas parciais, o cliente só descobre desvios quando corrigir custa caro.
• Dependência de uma única pessoa. Se todo o conhecimento está concentrado em um profissional, a saída dele paralisa o projeto.
• Pressão para fechar rápido. Descontos com validade de poucos dias servem para impedir a comparação.

Como comparar propostas diferentes?

Propostas só são comparáveis quando descrevem o mesmo escopo. O primeiro passo é colocar lado a lado o que cada uma inclui: funcionalidades, integrações, migração de dados, design, testes, implantação, treinamento, garantia e hospedagem.

Em seguida, vale identificar as premissas. Uma proposta pode considerar que os dados serão migrados pelo cliente; outra, que a migração está incluída. Uma pode prever uma integração simples; outra, o tratamento completo de falhas. Essas diferenças explicam a maior parte das variações de preço.

Por fim, considere o custo após a entrega. Um sistema mais barato de construir, mas sem testes e sem documentação, custa mais para manter e evoluir. Sistemas nessa condição acabam exigindo retrabalho estrutural poucos anos depois, tema que tratamos em sistema legado: quando modernizar.

O que o contrato precisa conter?

O contrato transforma o que foi conversado em compromisso. Recomendamos verificar, com apoio jurídico, se ele trata ao menos de:

• Escopo e entregáveis, com referência a um documento descritivo.
• Titularidade do código-fonte e condições de acesso ao repositório. No Brasil, a Lei nº 9.609/1998 trata da proteção de programas de computador, e o contrato deve deixar explícito o que as partes combinaram.
• Critérios de aceite e prazo para o cliente validar cada entrega.
• Gestão de mudanças, com forma de estimativa e aprovação.
• Confidencialidade e proteção de dados pessoais, com as responsabilidades de cada parte perante a LGPD.
• Garantia e sustentação, com o que está coberto e por quanto tempo.
• Condições de encerramento, incluindo a entrega de código, documentação e dados.

Como avançar a partir daqui

Escolher uma software house é decidir com quem a empresa vai resolver um problema ao longo de meses ou anos. Os critérios e as perguntas deste artigo servem para qualquer fornecedor, inclusive para nós. Na página de desenvolvimento de software, descrevemos como conduzimos os projetos e os modelos de contratação. Se quiser nos incluir na sua comparação, solicite um orçamento com o seu briefing e faça a nós as mesmas perguntas da lista.