Quantificando o valor da refatoração em termos comerciais [duplicado]

14

Aqui está o cenário clássico; Equipe de desenvolvimento constrói um protótipo. Negócio mgmt como ele e colocá-lo em produção. A equipe de desenvolvimento agora tem que continuar a oferecer novos recursos enquanto, ao mesmo tempo, paga a dívida técnica acumulada quando o código base era um protótipo.

A minha pergunta é esta (perdoe-me, é bastante aberto); Como o valor do trabalho de refatoração pode ser quantificado em termos comerciais?

Como desenvolvedores, podemos entender claramente e comunicar o valor em termos técnicos, como a remoção da duplicação de código, a simplificação de um modelo de objeto e assim por diante. Mas isso significa pouco para um executivo focado nos elementos comerciais. O que vai significar algo para este executivo é o dev. equipe sendo capaz de fornecer requisitos a uma velocidade mais rápida. Apenas fazer essa declaração sem métricas que quantifiquem claramente o retorno sobre o investimento (aumento da velocidade em retorno do recurso alocado à refatoração) tem pouco peso.

Estou interessado em ouvir de qualquer pessoa que tenha tido experiência, positiva ou negativa, em relação ao acima.

----------------- EDITAR ----------------

Obrigado pelas respostas até agora, todas as quais eu acho boas. O que eu quero desenvolver é uma métrica que prove (ou nega!) Todas essas declarações. Um relatório que vincula a velocidade à refatoração e mostra um efeito positivo.

    
por Myles McDonnell 28.10.2012 / 09:01
fonte

8 respostas

18

Eu obtive algum sucesso explicando essas vantagens:

  1. Menos bugs no futuro (até mesmo os vendedores sabem que os bugs são ruins).
  2. Mais fácil, mais rápido e mais barato para corrigir erros no futuro.
  3. Mais fácil, mais rápido e mais barato para melhorar o produto.
  4. Mais fácil, mais rápido e mais barato para adicionar recursos totalmente novos ao produto.
  5. Mais fácil, mais rápido e mais barato de integrar com sistemas de terceiros.
  6. Quanto mais cedo você puder começar a refatorar, menos débito técnico terá e melhor será o produto (1-5 será mais fácil).

Eu tive sucesso limitado com termos como dívida técnica, algumas pessoas comerciais entenderam, alguns acham que é apenas o pessoal técnico tentando justificar fazer suas próprias coisas, tudo depende da pessoa que você está tentando explicar para .

Uma estratégia que funciona bem (contanto que você não deixe a dívida técnica se acumular demais) está pagando um pouco de cada vez fazendo refatorações de pequeno e médio porte no início do próximo aprimoramento / recurso / mudança que os vendedores querem.
Faça parte de sua solicitação, "claro, podemos fazer isso, mas precisamos melhorar essa parte do sistema para suportar esse novo recurso".

Se você puder obter métricas reais de quanto tempo será economizado fazendo refatorações, então ótimo, pessoalmente, eu descobri que uma estimativa dupla funciona melhor, já que todos os comerciais sabem que as estatísticas podem ser manipuladas e estatísticas de desenvolvimento (dependendo do pessoa) pode ser visto como egoísta.
Por estimativa dupla, eu quero dizer "claro, o recurso X levará 3 dias se consertarmos o subsistema Y, caso contrário, você estará olhando para X + Z dias para contornar isso. Além disso, reduzirá nossas chamadas de suporte e fará o planejado recurso W mais rápido para adicionar. "

Se pessoas como métricas combinarem o tempo gasto em chamadas de suporte sobre recurso / produto X com minha estimativa dupla, você poderá produzir um gráfico / planilha / cálculo de custos para mostrar o custo do recurso X com base no suporte contínuo chama com uma estimativa de redução de refatorações.
Com o tempo, você poderia produzir números reais para o recurso X antes e depois da refatoração.

Obter números reais para custos de desenvolvimento é mais complicado, pois cada recurso é implementado apenas uma vez (espero!). Uma idéia é manter o tempo de refatoração e produzir um gráfico de estimativa dupla adicionando custos de refatoração como " o que teria custado sem refatoração ", o que é, esperamos, maior do que sua estimativa real, isso deve tornar a economia de tempo / custo muito óbvia.

Basicamente, com uma base de código mais limpa praticamente tudo pode ser feito mais rapidamente e, portanto, mais barato do que poderia, o que agrega valor extra e melhor ROI para os caras comerciais.

    
por 28.10.2012 / 09:44
fonte
6

Eu acho a resposta do SteB (que eu votei positivamente) muito boa. Eu gostaria de elaborar um ponto em sua resposta (como um exemplo que pode ser aplicado a outros pontos também).

Easier, faster and cheaper to made enhancements to the product.

Como convencer a administração disso?

Suponha que você acabou de ter o release 1 do produto X.

Você já sabe que o recurso Y está planejado para o release 2 e o recurso Z é quase necessário para o release 3.

Então você pode fazer uma estimativa (realizar uma sessão de preparação com cartões de pôquer) e depois ir até seus gerentes e dizer:

  • Com o código atual, o recurso Y levará oito semanas, o recurso Z levará seis semanas.
  • Com o código refatorado, o recurso Y levará quatro semanas, o recurso Z levará duas semanas. A refatoração levará 2 semanas.

Então você tem os seguintes cenários:

  1. Lançamento 2 com recurso Y. O recurso Y custa 8 semanas sem refatoração, 6 semanas com refatoração.
  2. Lançamento 2 e 3, com os recursos Y e Z. Os recursos Y e Z custam 12 semanas sem refatoração e 8 semanas com refatoração.

Isto é apenas um esboço, mas IMO, se você puder fazer uma análise similar, você pode ter mais chances de convencê-lo: significa que você tem uma idéia concreta dos benefícios de sua refatoração, mesmo que seja apenas uma estimativa. .

OBSERVAÇÃO : Se você achar difícil fazer uma análise semelhante, pergunte-se quais são as chances de você não precisar.

    
por 28.10.2012 / 11:52
fonte
6

Estou com o comentário de @ maple_shaft acima:

Não escreva código ruim , mesmo quando estiver criando um protótipo. Pense no seu protótipo de código como uma abordagem de marcador. Algo que se tornará o produto final, mesmo que ainda não esteja lá.

Você não precisa explicar ou justificar a refatoração para a administração - ela deve ser uma parte contínua do processo. Assim como você não explica por que você está fazendo uma estrutura de herança específica, usando uma estrutura específica, etc. Estes são detalhes técnicos. Seus clientes só se preocupam com o resultado, sejam eles gerentes ou clientes finais.

O que você quer evitar são longos períodos de inatividade, nos quais "nada" acontece no mundo exterior. Por exemplo. você não quer escrever uma quantidade enorme de código ruim, então levará 3 semanas para refatorá-lo para torná-lo bom. Primeiro de tudo, não vai funcionar muito bem; e, em segundo lugar, você pode ficar tentado a explicar que agora está demorando para refatorar. O que para um estranho soará como se você estivesse tirando umas férias geeks.

Refatorizar antecipadamente . Se você vê algo está errado, e seria um pouco doloroso para fazer o certo: fazê-lo. Adendo a isso: Se você não tem certeza de que algo está errado ou não sabe como melhorá-lo, deixe-o em paz até conseguir.

    
por 29.10.2012 / 05:55
fonte
4

Estive lá muitas vezes.

Existem algumas maneiras de lidar com isso, mas não é fácil.

Você quase disse você mesmo: eles só se importam em entregar o mais rápido possível. Mostre às partes interessadas um caso de negócios em que uma rodada de refatoração de X meses reduzirá o tempo necessário para desenvolver novas rodadas - e tentar estimar algum ROI - retorno do investimento, após um ano ou mais, para a refatoração.

Ou, se isso for muito difícil, existem outras implicações econômicas que podem ajudar - "Como estamos executando um protótipo em produção, precisamos contratar mais dois engenheiros para mantê-lo. Esse custo pode ser evitado se assumirmos um projeto de refatoração ".

Se você tiver centros de custo internos, etc., certifique-se de que as pessoas operacionais que dão suporte a esse aplicativo cobram mais por ele do que aplicativos similares de "produção digna".

Se sua equipe tiver algum controle, talvez seja possível incorporar a refatoração nas novas fases de desenvolvimento de recursos. Digamos que eles desejem inserir hierarquias complexas em um modelo de dados que já é ruim - inclua a refatoração como um requisito técnico para fazer alterações no modelo de dados. Um caso semelhante: se você pedir ao seu encanador para trocar o radiador, se o cano estiver enferrujado demais para funcionar corretamente, ele irá tentar. mude isso também, já que é sua profissão saber o que fazer. A mesma coisa (deveria) vale para desenvolvedores de software.

Se você acertar a parede, reúna estatísticas para seus argumentos. Marque cada bug / problema operacional relatado que poderia ter sido evitado pelo código digno de produção. Em seguida, você pode mostrar um caso comercial reduzindo os erros com% e assim aumentar o tempo de atividade / estabilidade em outro%.

No entanto, sempre há um fato de que o desenvolvedor de software deseja fazer a melhor solução possível, quando apenas "bom o suficiente" serve. Se você não pode criar argumentos econômicos para a refatoração, provavelmente não vale a pena e não deve ser feito.

    
por 28.10.2012 / 10:00
fonte
2

Colocar um protótipo em produção é pior do que um projeto de design ruim porque muitos tomadores de decisão acreditam que é melhor do que realmente é. Ao longo do processo de construção do protótipo, você estava lembrando a todos que não está pronto para produção ". As chances de chegar a esse ponto eram baixas porque não tinham certeza de que:

  • Poderia ser construído.
  • Qualquer um realmente precisaria / usaria.

Não se concentre em "Eu avisei", mas deixe claro que você não conseguirá manter o cronograma do protótipo nem pode usar qualquer uma dessas métricas para determinar como tempo que levará para criar recursos prontos para produção. Eles verão a função do produto, mas lembrarão problemas como:

  • Pode não ser capaz de lidar com um número maior de usuários
  • O tratamento de erros não é suficiente para o usuário típico
  • Não pode acomodar muitos dos recursos solicitados recentemente.
  • Há pouco ou nenhum teste

Os membros não técnicos da alta gerência não vão entender o conceito de refatoração. Eles têm em mente que isso "funciona" e eles não vão liberar esse pensamento por toda a extensão do projeto, não importa quantas vezes você diga algo para o contrário. Você só vai ter que fazer parte de suas especificações. Os gerentes técnicos podem estar sob strong pressão de tempo e podem tentar tirar muitas dessas tarefas das especificações do projeto. "Por que estamos trabalhando em recursos que já estão concluídos?" Alguns dos outros ansers fornecem algumas maneiras de explicar por que isso não é o caso.

Boa sorte

    
por 28.10.2012 / 15:55
fonte
1

Eu gosto de responder isso através de analogias não técnicas.

Alguns exemplos:

Você pode facilmente construir casas de até 5 andares com tijolos. Você pode facilmente adicionar em um único andar. Mas tente e vá para 20 ou 30 andares e de repente bam! as telhas estão explodindo porque você precisa de uma infraestrutura melhor, como vigas de aço. Acontece que a infra-estrutura é importante e acertar o mais cedo possível através da "refatoração" inicial ...

Você dirige seu gar. Tudo o que precisa para funcionar é gás! Bem, isso e ... o óleo muda com frequência. Ah, e com pouca frequência, pneus novos e, ocasionalmente, outros fluidos e peças. Acontece que a manutenção faz parte de ser um proprietário de carro responsável ...

    
por 28.10.2012 / 20:23
fonte
0

Você pode definir sem ambiguidade o que é refatoração? Mesclar dois procedimentos é provavelmente a refatoração. Mas e quanto a mudar o nome de um objeto? Um método? Uma variável pública? Uma variável privada? E se você alterar a implementação de um método sem alterar sua assinatura? E se essa alteração diminuir a velocidade de um determinado tipo de entrada, o que, por sua vez, causa uma alteração em uma parte distante do código? Eu acho que o que eu estou dizendo é que você precisa de uma definição muito clara do que você está tentando medir antes que você possa escolher uma forma ou algumas maneiras de medi-lo.

Isso também é difícil porque você não vê imediatamente o benefício da refatoração. Digamos que você transformou 5 objetos com 12 métodos em 3 objetos com 5 métodos. Isso economizará muito tempo no futuro, mas dobrou o tempo que você levou para entregar o recurso atual. Portanto, é uma perda de curto prazo para os negócios, por um ganho hipotético a longo prazo. Refatorar às vezes até piora as coisas, mesmo que isso as torne melhores.

Vamos supor que a refatoração signifique que uma alteração em uma parte do código exige que você altere outra parte do código de forma que a funcionalidade de todo o programa seja (mais ou menos) preservada, mas da maneira como é trabalha internamente é diferente. Por definição, o usuário final geralmente não verá o efeito da refatoração (a menos que melhore o desempenho ou permita uma simplificação da interface do usuário que ainda forneça a mesma funcionalidade de linha de base ao usuário).

Então você tem que medir as coisas a longo prazo para mostrar um impacto positivo e, por definição, é um impacto indireto. Pensei nisso o dia todo hoje e me lembrei de um estudo publicado na revista Time há alguns anos sobre o que faz as pessoas viverem mais tempo. Em vez de perguntar às pessoas o quanto fumavam ou bebiam refrigerantes ou qualquer outra coisa, analisavam as populações mais longevas do planeta e analisavam centenas (ou milhares) de dieta, estilo de vida e fatores ambientais para determinar quais eram comuns entre aqueles duradouro e raro para as pessoas em geral.

Sinto muito não poder pensar em uma métrica que você possa medir todo mês e mostrar, com um pequeno gráfico, como você está refatorando melhor do que nunca, ou correlacionar diretamente a refatoração com os resultados da empresa. Mas eu acho que você (ou um departamento de CS em uma universidade afiliada) poderia olhar para as características das equipes de software bem-sucedidas para ver se a refatoração é algo que as diferencia ou não. Eu suspeitaria que seria, mas estaria extremamente interessado em ver um estudo. Talvez alguém neste fórum possa apontar para tal estudo?

    
por 29.10.2012 / 03:20
fonte
0

Eu tenho estado em tais posições (suponho que todos nós tenhamos).

Muitas vezes, esta é uma resposta muito eficaz:

You have paying me for a year to develop this project. If I get hit by a bus tomorrow, do you want to pay someone for two more years, to figure out how to unravel the mess I left behind? Are you not better off paying me for three months, so that the next guy will be up to speed in one month?

Importante: Certifique-se de que você não recebe a bota quando ouvir que você passou um ano escrevendo código bagunçado, para que você possa obter um protótipo a tempo ...

    
por 27.07.2013 / 12:27
fonte