Como medir o valor potencial da refatoração

Em um projeto grande e antigo, com dívida técnica, como você pode estimar ou medir com segurança os benefícios do código de refatoração?

Por exemplo, digamos que você tenha alguns componentes em uma solução de pilha de software escritos em um idioma mais antigo e alguns componentes posteriores em um idioma mais recente. Novos recursos e correções de bugs são constantemente adicionados a esta solução por uma equipe de desenvolvimento.

Os desenvolvedores sugerem que substituir os componentes do idioma antigo existente pela nova versão seria "uma coisa boa". No entanto, nenhum recurso extra seria adicionado por este trabalho e custará x dias de desenvolvimento.

Uma pessoa de vendas sugere adicionar "um ótimo novo recurso". a empresa mede o valor de sua sugestão usando uma fórmula. ie Ele ganhará à empresa um milhão de libras esterlinas, ao longo de t anos, ao custo de x dias úteis de trabalho

Como a empresa pode custar a proposta de refatoração de maneira significativa? e em que circunstâncias é provável que seja a opção mais rentável para a empresa?

Ele ganhará à empresa um milhão de libras esterlinas, ao longo de t anos, ao custo de x dias úteis de trabalho

Isso é ignorar os custos de manutenção, os custos de suporte, o custo das vendas / marketing e faz muitas suposições sobre como o recurso será utilizado no mercado.

Mas de qualquer forma; sua pergunta é clara o suficiente sobre o que você está procurando:

Como posso fazer um caso comercial para refatoração?

A principal coisa a perceber é que o tempo é igual a dinheiro. Você pode ir diretamente para "5 desenvolvedores 2 semanas = 80 horas * 5 desenvolvedores * US $ 50 / h -> US $ 20.000" e isso faz sentido para as pessoas de negócios. Pessoas de negócios inteligentes notarão que esses 5 desenvolvedores estão sendo pagos de qualquer maneira, com os quais você contraria que não está gastando / economizando os US $ 20.000 - está usando os US $ 20.000 da maneira mais lucrativa. De qualquer forma, com a lista.

• Eficiência - presumivelmente, você pode fazer mais coisas com C # que com VB6. Melhores ferramentas, melhores bibliotecas, qualquer que seja. As tecnologias mais recentes tendem a ser melhores nas coisas do que as mais antigas. Se você pode fazer coisas em menos tempo, isso significa que você está economizando o dinheiro da empresa.
• Despesas gerais - a codificação não é o único custo do software. Considere o que acontece quando o Windows 2020 é lançado. Quanto tempo e esforço você gastará para que o aplicativo VB6 funcione? Quanto mais tempo e esforço é isso do que um aplicativo C #? Isso economiza o dinheiro da sua empresa.
• Qualidade - Presumivelmente, você pode executar tarefas com qualidade superior em C # que o VB6 (ou com uma arquitetura mais limpa ou qualquer outra coisa que seu destino de refatoração) seja. Maior qualidade significa menos erros. Menos bugs significa menos custo para consertá-los, menos custos de suporte ao cliente para resolver esses problemas, menos perda de clientes devido a problemas de qualidade, aumento de vendas devido à reputação de qualidade ... todos os dólares para sua empresa.
• Economia de RH - Vamos encarar os fatos: ninguém quer trabalhar com esse aplicativo VB6 de merda. Isso significa que mais pessoas deixarão a empresa levando tempo e dinheiro gasto para substituí-las. Isso significa que leva mais tempo e dinheiro para contratar novos funcionários. Pior de tudo, isso significa que você terá desenvolvedores totalmente bem cometendo suicídio na carreira trabalhando com esse aplicativo VB6. Esses desenvolvedores, por sua vez, aceleram a espiral da morte dos problemas de qualidade. Reduzir os tempos de rotatividade e contratação economiza dinheiro da sua empresa. Manter afastados desenvolvedores complacentes e ruins poupa sua empresa.
• Moral - Da mesma forma, os programadores que já estão lá odeiam trabalhar no VB6. Eles farão isso, e podem até fazê-lo bem. Mas é uma merda. Talvez não para todos, mas certamente para alguns. Isso significa mais tempo navegando na web para recuperar a motivação. Significa almoços mais longos. Isso significa menos trabalho enquanto seus programadores levam mais tempo para se recuperar do trabalho pesado.
• Capacidade - Isso é menos aplicável aos refatores orientados a tecnologia, mas se aplica a tipos de refatores de arquitetura. Certos problemas de código impedem ativamente que você forneça o recurso interessante X para ganhar muito dinheiro. Talvez você não possa escalar. Talvez você não consiga acessar os dados para obter informações legais. Talvez o código seja um ninho de rato que seja proibitivamente difícil fazer o trabalho. Tanto faz. Às vezes você está nesse ponto, às vezes você está dirigindo diretamente para esse ponto. É difícil traduzir para falar em negócios, mas se você puder, "esse problema está nos impedindo de aproveitar as oportunidades X, Y e Z" pode ser poderoso.

Em suma, tudo se resume a "essas coisas nos ajudarão a fazer melhor nosso trabalho; se fizermos melhor, podemos ganhar / economizar mais dinheiro".

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?

Em primeiro lugar, você precisa estimar o custo do desenvolvedor para a re-fatoração, como faria com a solicitação de recurso orientado a vendas.

Pode ser difícil obter precisão se for um trabalho grande, mas, supondo que você tenha pessoas suficientemente experientes nas 2 tecnologias, deve ser possível.

Em segundo lugar, você precisa de uma estimativa do custo de não re-fatorar. Se você estivesse fazendo as estimativas para mim, esperaria algum nível de métricas. Por exemplo, a diferença entre o custo médio do desenvolvedor para o código VB e o código C # em um quarto. Ou algo assim. Obviamente, dependerá da precisão com que você rastreia isso.

Com esses dois números, você pode estimar o período de retorno que o recoforização fornecerá, ou seja, em que momento o recoforamento passará de um custo líquido para um ganho líquido.

Só posso adivinhar o quão persuasivo qualquer resultado seria. No entanto, se for menos de um ano, provavelmente será bastante forte, muito mais que 2 anos, então você pode ter dificuldades.

Além disso, provavelmente vale a pena adicionar outras dimensões para ajudar a criar seu caso. Uma que eu usei no passado é ver se alguma entrevista de saída citou a tecnologia como um driver. Nesse caso, você pode argumentar que a re-fatoração reterá funcionários (a contratação e o treinamento são muito caros).

Obviamente, você pode argumentar sobre essas coisas sem apoiar evidências, mas acho que isso pode fazer uma enorme diferença no impacto do caso.

O valor da refatoração surge de várias maneiras diferentes.

Ele ajuda você a fazer outras alterações posteriormente, para que os X dias que o recurso levaria levariam 2 / 3X dias para serem concluídos. Para usar a terminologia ágil, aumenta a velocidade.

A alteração explícita listada ajudaria ao longo do tempo, pois não seria mais necessário manter os desenvolvedores com experiência em VB6, apenas aqueles com experiência em C #.

Também ajuda de outras maneiras menos tangíveis, como retenção e recrutamento de pessoal. Um trabalho executando C # e VB6 seria mais ou menos atraente do que um trabalho executando apenas C #? Você teria mais ou menos probabilidade de aceitar um emprego ou permanecer em um emprego trabalhando em uma boa base de código ou em uma péssima?

Eu acho que o ponto que as outras respostas perdem é que você precisa medir o custo da refatoração com a receita perdida e não a refatoração.

Refatorar para alterar o código é uma perda de tempo. Ele precisa agregar valor à mesa. Nesse contexto, não quero dizer passar uma hora refatorando uma classe problemática, mas a refatoração principal, como mudar para um idioma CLR diferente, como você usou no seu exemplo.

• Se continuarmos fazendo o que estamos fazendo, estamos perdendo alguma coisa? Existe um projeto antigo e sujo que está nos impedindo de realizar valor? Por exemplo, se queremos adicionar um recurso, é tão difícil que pode demorar, por exemplo, 100 horas para implementar, versus 50 horas para refatorar e 25 horas para implementar no novo design?

• O código existente possui dívida técnica que está nos custando dinheiro? Esse código antigo e ruim é a fonte dos bugs? Acabamos trabalhando de graça para corrigir problemas por causa disso? Ninguém gosta de dar horas lucrativas e faturáveis ​​gratuitamente.

• O custo da refatoração é igual ou menor que o custo da não refatoração?

• É possível amortizar o custo fazendo com que uma pequena equipe de rockstars refatore o código, causando mais problemas? Podemos espalhar o refator entre lançamentos? Existem pequenas ineficiências em todos os lugares: podemos "preencher as lacunas", por assim dizer, com esse trabalho extra?

Benefícios de ter um sistema refatorado

Você faz um argumento comercial para refatoração comparando os benefícios da linha de negócios entre fazer e não fazê-lo. Significa redução dos custos reais atuais ou aumento de entradas de caixa reais futuras.

Os principais itens de orçamento afetados pela refatoração são os seguintes:

• Custos de manutenção - se o sistema atual é uma pilha frágil de espaguete e é observável na prática que a correção de pequenos bugs (tanto no desenvolvimento quanto nas operações) leva uma grande quantidade de horas de trabalho, então é de se esperar que os custos de tais a manutenção será menor para um sistema "adequadamente redesenhado". Veja quais são seus custos anuais de manutenção pura e como eles podem mudar realisticamente após a reescrita.

• Custo da adição de novos recursos - novamente, se o design e a estrutura atuais do sistema exigirem excessivamente tempo para escrever novos recursos, uma reescrita poderá proporcionar economia. Dê uma olhada no seu orçamento planejado para novos recursos, mas seja realista - se você afirmar que verá uma melhoria de 50%, espere realmente desenvolver recursos em x homens-mês que antes levavam 2 * x homens-meses para serem realizados; essas promessas podem ser difíceis de cumprir.

• Impacto na qualidade do software nas vendas - se o sistema atual está freqüentemente causando problemas visíveis ao cliente, por exemplo, falhas ou tempo de inatividade, apesar do esforço de manutenção adequado, uma reescrita pode ser uma solução. Se esse for um problema importante, as mesmas pessoas de vendas poderão quantificar o valor de um "recurso" chamado "produto mais estável".

Se os três pontos acima não atingirem o custo esperado de reescrita (e mais; o custo de oportunidade de gastar x dias-dev em não recursos é igual ao valor desses recursos, que é maior que o custo puro do x dev dias), então, temo que seja isso - as economias esperadas não justificam a reescrita.

Além disso, se o seu roteiro não mostrar a necessidade de 'o máximo que você puder fornecer' novos recursos, as economias deverão ser de uma forma ', costumava levar 10 pessoas para fazer todo o material necessário, mas após a reescrita, será capaz de fazer o mesmo com apenas 6 pessoas ' . Se você pode "vender" mais projetos de desenvolvimento do que os desenvolvedores, o aprimoramento da eficiência permitirá que você desenvolva mais coisas, mas se o negócio com os recursos atuais já for capaz de desenvolver tudo o que agrega valor extra, o único benefício financeiro pode resultar em pagar menos pessoas ou ter pessoas mais baratas.

O valor da refatoração pode ser medido da seguinte forma: atualmente, o novo recurso x custará 5 devs 2 semanas. Se refatorarmos o componente antigo, o custo de novos recursos será reduzido em cerca de 20%. Portanto, o novo recurso x custará apenas 4 desenvolvedores em 2 semanas.

A refatoração é um investimento na redução do custo de desenvolvimentos futuros. Se você não pode argumentar para sua refatoração, provavelmente não há um argumento comercial para isso.