Sistema sob medida sem estourar prazo: o que decidir antes da primeira linha de código

A maioria dos projetos de software que atrasam não atrasa por causa do código. Atrasa por decisões que ficaram para depois: o que exatamente o sistema precisa fazer, quem aprova cada entrega, o que acontece quando surge uma ideia nova no meio do caminho.

Na MFactor Tecnologia, boa parte do trabalho de um projeto acontece antes de alguém abrir o editor. Estes são os pontos que mais pesam.

Comece pelo processo, não pelas telas

É comum o cliente chegar com uma lista de telas. Cadastro de cliente, tela de pedido, relatório. Só que tela é consequência. O que precisa ficar claro primeiro é o processo: quem faz o quê, em que ordem, com qual informação e onde ele trava hoje.

Com o processo desenhado, metade das telas se justifica sozinha e a outra metade se mostra desnecessária. Um fluxo de quatro passos descrito em meia hora de conversa evita semanas de retrabalho.

Uma primeira versão que resolva um problema inteiro

A primeira versão deveria resolver um problema por completo, e não metade de vários. Se o maior gargalo é o orçamento que demora dois dias, a versão um é a que gera o orçamento em dez minutos. Relatório gerencial, aplicativo e integração com a contabilidade podem vir depois.

Cortar parece arriscado, mas é o contrário. Uma versão menor entra em uso antes, e o uso real mostra o que de fato falta. A lista que parecia indispensável no começo costuma mudar bastante depois de um mês de sistema rodando.

Escreva o que significa "pronto"

Para cada entrega, vale combinar por escrito quando ela será considerada pronta. Não precisa de documento formal. Basta algo como: "o vendedor gera o orçamento, escolhe os itens do catálogo, aplica até 10% de desconto sem aprovação e envia o PDF pelo WhatsApp".

Isso evita a conversa mais desgastante de qualquer projeto, aquela em que um lado acha que entregou e o outro acha que falta tudo.

Combine como as mudanças entram

Ideias novas vão aparecer, e muitas são boas. O problema é quando entram sem que ninguém perceba o impacto no prazo. Uma regra simples resolve: toda mudança de escopo é registrada, estimada e aprovada antes de entrar. Às vezes ela troca de lugar com outra funcionalidade, às vezes vai para a próxima versão.

Planeje a manutenção desde o início

Sistema não é obra que termina na entrega. As bibliotecas recebem atualizações de segurança, o navegador muda, a regra fiscal muda, o negócio cresce. Um sistema sem manutenção começa a envelhecer no dia em que entra no ar.

Por isso o custo de manter (hospedagem, monitoramento, atualizações e pequenas melhorias) deveria entrar na conversa antes do contrato, e não aparecer como surpresa seis meses depois.

Garanta que o sistema é seu

Três perguntas que todo cliente deveria fazer: o código fica num repositório ao qual eu tenho acesso? A infraestrutura está numa conta em meu nome? Existe documentação suficiente para outra equipe continuar o trabalho, se um dia for preciso?

Um fornecedor que confia no próprio trabalho responde sim para as três sem hesitar.

Para levar para a próxima reunião

• Qual processo o sistema resolve, do começo ao fim?
• O que entra na primeira versão, e o que fica para depois?
• Como cada entrega será considerada pronta?
• Como uma mudança de escopo é aprovada?
• Quanto custa manter o sistema depois de entregue?
• O código e a infraestrutura ficam no nome de quem?