Como acompanhar um projeto de software terceirizado: rituais, métricas e entregas

Para acompanhar bem um projeto de software terceirizado, o cliente precisa de um responsável com autoridade para decidir, de rituais fixos com o fornecedor, de poucas métricas que mostrem progresso e qualidade e de um processo de aceite formal para cada entrega. A regra prática é avaliar o projeto por software funcionando, demonstrado com frequência, e não por relatórios de status. Quanto mais curto o intervalo entre as demonstrações, mais cedo os problemas aparecem.

Rituais, no vocabulário de gestão ágil, são as reuniões recorrentes com objetivo definido, como planejamento, acompanhamento e revisão. Entrega é uma parte do software pronta para ser testada e usada.

Quem deve acompanhar o projeto do lado do cliente?

O papel mais importante é o do responsável pelo produto, muitas vezes chamado de product owner. Essa pessoa define prioridades, esclarece regras de negócio e aprova entregas. Não precisa ser técnica, mas deve ter tempo dedicado e autoridade para decidir.

Em projetos maiores, vale ter também alguém com conhecimento técnico para revisar arquitetura, segurança e qualidade. Pode ser uma pessoa interna ou um consultor independente.

Quais rituais manter com o fornecedor?

A tabela resume um conjunto de rituais que funciona para a maioria dos projetos. A frequência pode ser ajustada, mas a regularidade importa mais que o formato.

A demonstração é o ritual mais valioso. Ver o sistema funcionando, em vez de ouvir que "está 80% pronto", revela problemas de entendimento muito antes do final.

Quais métricas acompanhar?

Poucas métricas bem escolhidas valem mais que painéis extensos. Algumas que costumam ser úteis:

• Entregas concluídas por ciclo: quantas funcionalidades foram aceitas, comparado com o planejado.
• Escopo restante: quanto falta, e se esse número está diminuindo ou crescendo.
• Defeitos encontrados: quantos problemas aparecem nos testes de aceite e em produção.
• Tempo de correção: quanto tempo leva para resolver defeitos críticos.
• Consumo do orçamento: quanto foi gasto em relação ao que foi entregue.

O sinal de alerta mais claro é quando o orçamento é consumido em ritmo maior que o escopo entregue. Esse descompasso deve ser discutido logo, e não no fim do projeto.

Como evitar que os relatórios escondam problemas?

Relatórios de status com percentuais de conclusão costumam ser otimistas, porque medem esforço e não resultado. Uma tarefa "90% pronta" pode esconder justamente a parte mais difícil. Por isso, prefira acompanhar funcionalidades aceitas, que estão prontas ou não estão.

Outra prática útil é pedir que o fornecedor mantenha uma lista de riscos atualizada, com probabilidade, impacto e ação prevista. Revisá-la na reunião semanal transforma riscos em decisões antes que virem atrasos.

Por fim, desconfie de semanas seguidas sem nada para demonstrar. Mesmo em fases técnicas, como a construção de integrações, é possível mostrar algo funcionando, ainda que em ambiente de testes.

Como fazer o aceite das entregas?

O aceite é o momento em que o cliente confirma que uma entrega atende ao combinado. Para funcionar, precisa de critérios definidos antes do desenvolvimento, e não depois.

Um processo simples de aceite pode seguir estes passos:

1. Para cada funcionalidade, registrar critérios de aceite claros, como "o usuário consegue cancelar um pedido até duas horas antes da entrega".
2. Receber a entrega em um ambiente de testes separado do ambiente de produção.
3. Testar com usuários reais ou representantes da área de negócio.
4. Registrar defeitos de forma objetiva, com passos para reproduzir.
5. Aprovar formalmente ou devolver com a lista de pendências.

Aceites informais, por mensagem ou em conversa, dificultam a resolução de divergências depois. Registrar por escrito protege os dois lados.

Como lidar com atrasos e mudanças de escopo?

Atrasos e mudanças são normais em software; o problema é quando aparecem tarde. Peça ao fornecedor que comunique riscos assim que forem identificados, com proposta de solução.

Para mudanças de escopo, estabeleça um processo: a mudança é descrita, o fornecedor estima o impacto em prazo e custo, e o responsável pelo produto decide. Exemplo hipotético: no meio do projeto, a área comercial pede um novo relatório. O fornecedor estima o esforço, o responsável pelo produto troca o relatório por uma funcionalidade menos urgente, e o prazo é mantido.

Que acessos o cliente deve ter durante o projeto?

Transparência depende de acesso. O cliente deve ter, desde o início:

• Acesso ao repositório de código, idealmente em conta própria.
• Acesso à ferramenta de gestão de tarefas usada pelo fornecedor.
• Acesso ao ambiente de testes.
• Contas de infraestrutura em seu nome, quando possível.

Esses acessos permitem verificar o andamento de forma independente e facilitam uma eventual troca de fornecedor. Vale prever isso no contrato; para a redação específica, consulte um advogado.

Próximo passo

Na hora de escolher, pergunte a cada fornecedor como ele conduz rituais, métricas e aceite, e compare as respostas. Encontre software houses verificadas na Citeo e confira os rankings, que não vendem posições e seguem critérios públicos.