Como medir o valor potencial da refatoração

It will earn the company F million pounds, over t years at a cost of x dev-days work

O que está ignorando os custos de manutenção, os custos de suporte, o custo de vendas / marketing e faz muitas suposições sobre como o recurso será usado no mercado.

Mas seja o que for; sua pergunta é clara o suficiente sobre o que você está procurando:

How can I make a business case for refactoring?

A principal coisa a perceber é que o tempo é igual a dinheiro. Você pode ir direto para "5 desenvolvedores 2 semanas = 80 horas * 5 desenvolvedores * US $ 50 / hora - > 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 forma, com os quais você concorda que não está gastando / economizando os $ 20.000 - está usando os $ 20.000 da maneira mais lucrativa. De qualquer forma, com a lista.

• Eficiência - Presumivelmente, você pode fazer mais coisas com o C # do que com o VB6. Melhores ferramentas, melhores bibliotecas, o que for. Novas tecnologias tendem a ser melhores do que as antigas. Se você pode fazer coisas em menos tempo, isso significa que você está economizando o dinheiro da empresa.
• Sobrecarga - 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ê vai gastar para conseguir que o aplicativo VB6 funcione? Quanto mais tempo e esforço é isso do que um aplicativo C #? Isso está salvando o dinheiro da sua empresa.
• Qualidade - Presumivelmente, você pode fazer as coisas com maior qualidade em C # do que em VB6 (ou com uma arquitetura mais limpa, ou qualquer outra coisa que seu alvo de refatoração seja). Maior qualidade significa menos bugs. Menos bugs significam menos custo para corrigir esses bugs, menos custos de suporte ao cliente para solucionar esses problemas, menos perda de clientes devido a problemas de qualidade, aumento de vendas devido a uma reputação de qualidade ... todo o dinheiro da sua empresa.
• RH Savings - 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 para substituí-las. Isso significa que leva mais tempo e dinheiro para contratar novos funcionários. Pior de tudo, significa que você terá desenvolvedores que estão totalmente comprometidos com o suicídio de carreira trabalhando com esse aplicativo VB6. Esses desenvolvedores, por sua vez, apressam a espiral da morte em questões de qualidade. Reduzir o volume de negócios e o tempo de contratação economiza o dinheiro da sua empresa. Evitar que desenvolvedores complacentes e de baixa qualidade economizem sua empresa.
• Moral - Da mesma forma, os programadores que já estão lá odeiam trabalhar no VB6. Eles farão isso, e podem até fazer bem. Mas é uma merda. Talvez não para todos, mas certamente para alguns. Isso significa mais tempo gasto navegando na web para recuperar a motivação. Isso significa almoços mais longos. Isso significa menos fazer as coisas enquanto seus programadores demoram mais para se recuperar do trabalho ruim.
• Capacidade - Isso é menos aplicável a refatores orientados por tecnologia, mas se aplica a refatoradores de arquitetura. Certos problemas de código impedem ativamente que você ofereça o excelente recurso X para ganhar muito dinheiro. Talvez você não possa escalar. Talvez você não consiga pegar os dados para fazer informática legal. Talvez o código seja um ninho tão grande que é proibitivamente difícil fazer o trabalho. Tanto faz. Às vezes você está nesse ponto, às vezes você está dirigindo direto para esse ponto. É difícil traduzir para o mundo dos negócios, mas se você puder, o "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 o nosso trabalho; se fizermos melhor nosso trabalho, poderemos economizar mais dinheiro".

A pergunta que você deve fazer é como o vendedor sabe que o recurso vai custar x dias de trabalho para o desenvolvedor. Dado que nem sempre bons gerentes de projeto com anos de experiência profissional podem 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 o quanto é demais para a gerência ou cliente: se a gerência está pronta para pagar 50 homens-semana de trabalho, mas será absolutamente rejeitar 75 man-weeks, vamos dizer que o recurso levará 70 man-weeks enquanto estiver pronto para renegociar (algo que está fora de questão para uma estimativa real) para 55 man-weeks.

• Por um lado, você faz estimativas feitas por especialistas em TI dizendo algo como:

  According to this specific audit, we are wasting $8 000 per day using an outdated technology compared to similar projects of similar size which use newer technologies. It also appears that it will take from 50 to 80 man-weeks to migrate the whole code base; during this time, there would be no new features released. There is also a 10% risk that migrating a specific component may result in 20-30 additional man-weeks of work.

• Por outro lado, você tem palpites feitas por vendedores, com base em sua influência ao negociar com a pessoa que eles precisam convencer.

É tudo sobre como você é influente em sua empresa. A comunicação é fundamental aqui, e é aí que os vendedores costumam conquistar os profissionais de TI quando se trata de explicar os benefícios de um recurso para o gerenciamento (ou para um cliente).

Observe que, se no passado suas estimativas fossem 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 fazer uma valiosa aqui, já que há um grande número de parâmetros a serem levados em conta. Entre outros:

• Você realmente sabe quão habilidoso é seu time em C # comparado ao VB6? É baseado em medições reais ou apenas palpites?

• 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 (o que, no mundo da Microsoft, significa milhares de dólares por máquina)?

• O projeto atual é totalmente claro e você pode garantir que não haverá surpresas ao migrar? É simples reescrever tudo , todos os recursos, ou haveria surpresas?

• Você tem a infraestrutura que suporta o C #? E quanto à integração contínua? E quanto ao 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 dos clientes (se este for um aplicativo de desktop) podem executar a versão do .NET Framework que você espera usar?

Mas o mais importante é saber por que você quer reescrever tudo. Qual é o problema que você está tentando resolver através de uma reescrita? Uma perda de produtividade? Como você mede isso? Como você mostra essa perda de produtividade ao gerenciamento?

Uma vez que você tenha mostrado que está desperdiçando, digamos, US $ 8.000 por dia por causa do VB6 (o que significa economizar US $ 8.000 por dia depois de migrar para C #), como você explica o benefício de manter cada novo recursos de desenvolvimento e com foco em uma reescrita completa? Qual é o benefício em comparação com a reescrita progressiva em que você migra seus componentes em pequenos blocos, um por um, ao enviar novos recursos?

Em primeiro lugar, você precisa estimar o custo de desenvolvimento para o refatoração, como faria com a solicitação de recurso orientada por vendas.

Isso pode ser difícil de ser preciso se for um trabalho grande, mas, supondo que você tenha pessoas suficientemente experientes nas duas tecnologias, isso deve ser viável.

Em segundo lugar, você precisa de uma estimativa do custo de não refatoração. Se você estivesse fazendo as estimativas para mim, eu esperaria algum nível de métricas. Por exemplo, a diferença entre o custo médio de desenvolvimento para o código VB e para o código C # ao longo de um quarto. Ou algo assim. Vai depender, obviamente, da precisão com que você acompanha isso.

Com esses 2 números, você pode estimar o período de retorno que o re-factoring lhe dará, ou seja, em que ponto a refocalização irá mudar de um custo líquido para um ganho líquido.

Eu só posso adivinhar como persuasivo qualquer resultado dado seria. No entanto, se for menos de um ano, provavelmente será bastante strong, muito mais do que 2 anos, então você pode muito bem lutar.

Além disso, 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 citava a tecnologia como um driver. Se assim for, você pode argumentar que o re-factoring irá reter pessoal (contratação e treinamento sendo caro).

Obviamente, você pode argumentar essas coisas sem 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 mais tarde. Portanto, os X dias que o recurso levaria agora levaria de 2 a 3 dias para ser concluído. Para usar a terminologia ágil, aumenta a velocidade.

A alteração explícita listada ajudaria ao longo do tempo, já que você não precisaria mais manter desenvolvedores com experiência em VB6, apenas aqueles com experiência em C #.

Ele também ajuda em outras formas menos tangíveis, como retenção de pessoal e recrutamento. Um trabalho fazendo C # e VB6 seria mais ou menos atraente do que um trabalho fazendo apenas C #? Você estaria mais ou menos propenso a aceitar um emprego ou ficar em um emprego trabalhando em uma boa base de código ou péssima?

Eu acho que o ponto que as outras respostas erram é que você precisa medir o custo da refatoração contra a receita perdida de não refatorar.

Refatorar por alterar código é uma perda de tempo. Precisa trazer valor para a mesa. Nesse contexto, não estou pensando em gastar uma hora refatorando uma classe de problema, mas sim refatorando como mudar para uma linguagem CLR diferente da que você usou em seu exemplo.

• Se continuarmos fazendo o que estamos fazendo, estamos perdendo alguma coisa? Existe um design antigo e desleixado que está nos impedindo de perceber o valor? Por exemplo, se quisermos adicionar um recurso, é tão difícil que possa ser necessário, por exemplo. 100 horas para implementar, contra 50 horas para refatorar e 25 horas para implementar contra o novo design?

• O código existente carrega dívida técnica que está nos custando dinheiro? Este código antigo de baixa qualidade é a fonte de bugs? Nós acabamos trabalhando de graça para corrigir problemas por causa disso? Ninguém gosta de oferecer horas faturáveis lucrativas de graça.

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

• É possível amortizar o custo fazendo com que uma pequena equipe de rockstars refatorie o código, causando mais problemas? Podemos espalhar o refactor em todos os lançamentos? Há 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ê cria um caso de negócios para a refatoração comparando os benefícios básicos da empresa entre fazer e não fazer isso. Isso significa a redução dos custos reais atuais ou um aumento no fluxo real de caixa futuro.

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 consertar pequenos bugs (tanto em desenvolvimento quanto em operações) requer uma grande quantidade de horas-homem, então seria de se esperar que os custos dessa manutenção serão menores para um sistema "adequadamente reprojetado". Veja quais são os seus custos anuais de manutenção 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 o tornam excessivamente demorado para gravar novos recursos, a reescrita pode fornecer economia. Dê uma olhada no seu orçamento planejado para novos recursos, mas seja realista - se você alegar que verá uma melhoria de 50%, espere desenvolver recursos em x homem-meses que anteriormente levaram 2 x homens por mês para realizar; tais promessas podem ser difíceis de manter.

• Impacto na qualidade do software nas vendas - se o sistema atual estiver causando problemas frequentes ao cliente, por exemplo, falhas ou tempo de inatividade, apesar do esforço adequado de manutenção, então uma reescrita pode ser uma solução. SE esta é uma questão importante, então as mesmas pessoas de vendas podem quantificar o valor de um 'recurso' chamado 'produto mais estável'.

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

Além disso, se o seu roteiro não mostrar a necessidade de novos recursos, "o máximo que você pode fornecer", a economia deve estar em um formato 'para levar 10 pessoas a fazer todo o material necessário , mas após a reescrita, poderemos fazer o mesmo com apenas 6 pessoas '. Se você puder "vender" mais projetos de desenvolvimento do que os desenvolvedores, melhorar a eficiência permitirá que você desenvolva mais coisas, mas se os negócios com os recursos atuais já puderem desenvolver todas as coisas que geram valor extra, o único benefício financeiro pode vir de 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 refizermos 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 fazer esse argumento para a sua refatoração, provavelmente não há um caso de negócio para isso.