Como convencer o cliente de que o back-end de seu aplicativo precisa ser reescrito?

4

Eu tenho apoiado uma aplicação de winforms LOB para um cliente nos últimos 3 anos. O aplicativo é construído com uma arquitetura monolítica simples e usa o .NET 2.0.

A aplicação é uma parte essencial de suas operações e sua longevidade é primordial. Ele precisa evoluir com os processos de negócios em evolução, além de implementar funcionalidades aprimoradas, etc. Isso me faz acreditar que esse aplicativo precisa de uma revisão geral do back-end.

O problema é mudar um back-end que é "invisível" ... ou seja, o usuário nunca realmente vê isso. É uma qualidade do sistema que está mudando (estabilidade, facilidade de manutenção, confiabilidade, longevidade), e não algum requisito funcional que será facilmente visto ... ou seja, o ROI não é óbvio.

Também há muitas novas funcionalidades a serem adicionadas ao front-end (experiência do usuário). Eu estou pensando em uma estratégia de mudar o back-end ao longo do tempo ... ou seja, ao fazer uma alteração ou adicionar um recurso ao front-end, alterar esses componentes no back-end que são afetados, eventualmente você começa a tudo.

Como faço para convencer o cliente de que precisamos reconstruir o back-end?

    
por richard 28.06.2012 / 10:57
fonte

4 respostas

14

Se você discutir a forma como a pergunta é feita, não pode. O que o cliente vai ouvir é "bla bla bla, eu quero brincar com um novo brinquedo brilhante, bla bla bla, vai te custar um monte de dinheiro, bla bla bla"

O que você precisa fazer é colocar no contexto do que é importante para eles. "O backend está chegando ao fim de sua vida útil. Se você quiser continuar a fornecer serviços básicos aos seus usuários finais de maneira econômica e ter a capacidade de suportar os novos recursos que eles esperam e aproveitar o mais rápido e mais barato desenvolvimento de ciclos fornecidos por ferramentas modernas, é necessário planejar um caminho de migração para uma plataforma mais moderna que seja bem dimensionada. Fico mais do que feliz em elaborar uma proposta "

Se você precisar falar sobre tecnologia nesta fase, você vai (e deve) perder. Muitos sistemas de missão crítica foram escritos 20 ou 40 anos atrás, e apesar da retórica, é mais rentável pagar programadores Cobol do que reconstruí-lo usando [Insira aqui a última palavra da buzz / silver bullet]

Leia Coisas que você nunca deve fazer, parte I

    
por 28.06.2012 / 11:11
fonte
8

when making a change or adding a feature to the front-end, change those components in the back-end that are affected, eventually you get to everything.

How do I convince the client that we need to rebuild the back-end?

Essas duas afirmações parecem estranhas para mim. Uma reescrita é muito diferente do que evoluir uma aplicação de tal forma que seja diferente daqui a um ano. Uma reescrita completa é quase uma falha garantida.

Você não diz que vai reescrever o back-end. Você faz exatamente o que você disse antes, conserte o código apodrecendo quando chegar a ele. Eventualmente o back-end pode evoluir para outra coisa, mas uma reescrita completa significa 1) Seu "novo" back-end não estará funcionando por um longo tempo 2) O back-end existente não será consertado por um longo tempo. É uma situação de perder-perder para fazer uma reescrita completa.

    
por 28.06.2012 / 11:14
fonte
5

Ao mostrar a eles como eles economizarão dinheiro ou ganharão mais dinheiro ao fazer essa reescrita, e desde que você diga que é essencial para a operação deles - eles não serão incomodados de forma alguma enquanto a reescrita estiver acontecendo.

    
por 28.06.2012 / 11:04
fonte
0

Uma reescrita não é o mesmo que um reengenheiro.

Eu postei isso em outras perguntas semelhantes.

Este gráfico pode ajudar a vender a ideia de reescrever / substituir / reengenharia, é uma função da qualidade da base de código e do valor comercial da aplicação:

    
por 26.12.2012 / 23:02
fonte

Tags