Então, já que o prazo informado é sempre uma “mentira” (e todos sabem que é, inclusive o cliente), não vejo problema em fornecermos alguma coisa para o cliente. A partir daí, o desafio é trazer produtividade para dentro do time com boas práticas de gestão e codificação (com SCRUM por exemplo), de forma a minimizar ao máximo o erro que com certeza existe no cronograma inicial.

A menos que o cliente pague por hora trabalhada, é muito difícil o cliente aceitar um “meio orçamento”.

As soluções propostas por metodologias ágeis podem aplicar-se a determinados modelos, mas não em todos.

A complexidade é achar um modelo em que é aceito tanto pela equipe técnica quanto a comercial.

Cuidado para não ser contaminado pela nova coqueluche do momento: a ‘padronite’. Todos dizem para usar padrões de projeto, todos enchem a boca ao falar de acoplamento e coesão (conceitos na verdade bem antigos, mas que só agora caíram na boca do povão), todos citam siglas misteriosas como GoF e PofEAA ou palavras pomposas como ‘Strategy’, ‘Abstract factory’, ‘Visitor’, etc, etc, etc.

Vou citar uma frase presente na série ‘Use a cabeça’ e que mantenho na frente de cada desenvolvedor da minha equipe: “O cliente não liga para os princípios OO nem para os diagramas que você cria. ELE SÓ QUER QUE O SOFTWARE FUNCIONE COMO ELE DEVE FUNCIONAR.”.

Não quero com isso jogar um balde de água fria nos ‘padronitizados’. Serve apenas para lembrar que nem tudo se resolve com os padrões. Eles são a ferramenta, e não a solução. Como o Douglas citou bem, de nada adianta seu código totalmente aderente as modernas práticas de programação, se você não pensou no seu cliente.

Abraços!