A pergunta que você deve fazer é como o vendedor sabe que o recurso custará x dias de desenvolvedor. Dado que nem bons gerentes de projeto com anos de experiência profissional costumam dizer isso, esses dados provenientes de um vendedor parecem extremamente ... especulativos .
De acordo com minha experiência, os vendedores geralmente não fazem estimativas, mas adivinha quanto é demais para a gerência ou o cliente: se a gerência estiver pronta para pagar 50 homens-semana de trabalho, mas rejeitará absolutamente 75 homens-semana, digamos que o recurso levará 70 semanas-homem enquanto estiver pronto para renegociar (algo que está fora de questão para uma estimativa real) até 55 semanas-homem.
Por um lado, você tem estimativas feitas por especialistas em TI dizendo algo como:
De acordo com essa auditoria específica, estamos desperdiçando US $ 8.000 por dia usando uma tecnologia desatualizada em comparação com projetos semelhantes de tamanho semelhante que usam tecnologias mais recentes. Parece também que levará de 50 a 80 semanas homem para migrar toda a base de código; durante esse período, não haveria novos recursos lançados. Há também um risco de 10% de que a migração de um componente específico possa resultar em 20 a 30 horas-homem adicionais de trabalho.
Por outro lado, você tem suposições feitas pelos vendedores, com base em sua influência ao negociar com a pessoa que eles precisam convencer.
É tudo sobre o quão influente você é em sua empresa. A comunicação é fundamental aqui, e é aqui que os vendedores geralmente conquistam os profissionais de TI quando se trata de explicar os benefícios de um recurso para a gerência (ou um cliente).
Observe que, no passado, suas estimativas eram bastante precisas, você ganha reputação e influência. Se suas estimativas estivessem sempre erradas, a gerência provavelmente ignoraria suas propostas.
Quanto às estimativas, é extremamente difícil criar uma valiosa aqui, pois há um grande número de parâmetros a serem levados em consideração. Entre outros:
Você realmente sabe o quão habilidoso é seu time em C # comparado ao VB6? É baseado em medições reais ou apenas suposições?
Essa equipe desenvolveu grandes projetos em C #? Eles conhecem as ferramentas que devem usar (IDE, depuradores, criadores de perfil etc.)? Você precisa de licenças adicionais (que, no mundo da Microsoft, significam milhares de dólares por máquina)?
O projeto atual é totalmente claro e você pode garantir que não haverá surpresas ao migrar? É fácil reescrever tudo , todos os recursos ou haveria surpresas?
Você tem a infraestrutura que suporta C #? E a integração contínua? E o seu servidor de compilação? Guias de estilo? Damas estáticas?
Na produção, os servidores (se for um aplicativo da Web) ou os PCs do cliente (se for um aplicativo de desktop) são capazes de executar a versão do .NET Framework que você espera usar?
Mas o mais importante é saber por que você deseja reescrever tudo. Qual é o problema que você está tentando resolver através de uma reescrita? Perda de produtividade? Como você mede isso? Como você mostra essa perda de produtividade para a gerência?
Depois de mostrar que está desperdiçando, digamos, US $ 8.000 por dia por causa do VB6 (o que significa que você economizará US $ 8.000 por dia após a migração para o C #), como explica o benefício de manter todos os novos recursos e desenvolvimento e com foco em uma reescrita completa? Qual é o benefício comparado à reescrita progressiva, na qual você migra seus componentes em pequenos pedaços, um por um, enquanto envia novos recursos?