23 agosto, 2011 0 Comentários AUTOR: elemarjr CATEGORIAS: Sem categoria Tags:,

Afinal, o que são boas práticas?

Tempo de leitura: 3 minutos

Olá pessoal, tudo certo?

O post de hoje é uma espécie de provocação. Muitas vezes vejo discussões acaloradas sobre o que são boas práticas. No post de hoje, apresento minha visão sobre esse tema.

Relação entre boas práticas e eficácia

Para mim, boas práticas são aquelas que garantem a entrega do valor certo para o cliente com o menor custo para a empresa. Chamo essa relação de eficácia.

image

Logo,

Boas práticas sempre maximizam a eficácia.

Um desdobramento lógico é:

Boas práticas sempre colaboram para a entrega do valor adequado ao cliente e/ou para a redução do custo total de propriedade.

Vamos entender um pouco melhor o que quero dizer.

Valor correto para o cliente

Muitas vezes, quando desenvolvemos software, temos por hábito querer “superar” as expectativas do cliente. Isso gera encantamento. Na medida certa, isso não é errado.

O problema é que, muitas vezes (quase sempre), o cliente não vai estar disposto a pagar mais por esse encantamento. Quando incluímos features que não são percebidas estamos incluindo, na verdade, apenas custo direto de desenvolvimento.

Toda feature não percebida pelo cliente é apenas custo.

O melhor software é aquele que atende o cliente e entrega um pouco mais do que o necessário (suficiente para fidelizar).

Se o software (qualquer produto, na verdade) entregar muito mais do que o esperado, precisará reverter esse incremento também no seu preço. O problema é que nem sempre isso é possível. Seja porque o cliente não valoriza, seja porque ele não tem condições de pagar.

Por favor, perceba que

o valor correto nunca será nada abaixo de um software fazendo aquilo que se dedica, sem erros nem inconsistências.

Menor custo total propriedade

Software deveria ser projetado para reduzir seu custo total de propriedade. No caso de software, podemos assumir que o custo pode ser dividido entre o investimento inicial (custo para desenvolver) e o custo para manter (manutenção).

image

Não é raro que o custo de manutenção seja bem maior do que o custo de desenvolvimento. O motivo mais comum para isso é a dificuldade para entender o código existente. Depois, temos também que computar os custos da modificação em si, além dos testes necessários para garantir que esta alteração esteja conforme. Por fim, há os custos de atualizar a base instalada.

Vamos, por um momento, entender a composição do custo para manutenção.

image

Uma abordagem antiga, porém infeliz para reduzir o custo de manutenção é tentar investir mais no custo inicial de desenvolvimento tentando eliminar ou reduzir a necessidade de manutenção. Considere que:

Tentativas de antecipar “necessidades” futuras geralmente aumentam ainda mais a complexidade de implantar modificações que não foram planejadas.

Temos que considerar, além de tudo, que investir em demasia no desenvolvimento inicial contraria um importante princípio econômico: Dinheiro disponível hoje vale mais que o dinheiro disponível amanhã;

Antecipar um investimento implica em desperdício de dinheiro

Por outro lado, em projetos com certeza de manutenção futura, qualquer esforço para reduzir os custos para compreensão, modificação, teste e distribuição representam em um aumento de eficácia.

Questionando as boas práticas

Como desenvolvedores, temos pouca ou nenhuma condição de aumentar o “valor correto para o cliente”. Isso nasce de uma necessidade de negócio dele, não de nossas inspirações! São raros os casos onde conseguimos delinear claramente necessidades que um cliente nem sabia que possui e, além disso, está disposto a pagar para que sejam resolvidas. Esse é um tema de marketing e P&D, não de desenvolvimento.

Para colaborar com a eficácia, nosso foco, enquanto desenvolvedores, deve estar na certeza de que estamos entregando pouco mais que aquilo que o cliente espera.

Além disso, quanto antes entregarmos aquilo que ele mais valoriza, mais cedo poderá computar o ROI. Logo, maior será a eficácia. Assim,

Se possível, devemos entregar o mais importante antes.

Quanto ao custo total de propriedade, temos que considerar o cenário em que estamos desenvolvendo. Considere, por exemplo, que estejamos fazendo um software que não terá manutenção futura. Considere um hot-site, ou um aplicativo para computar dados de uma pesquisa, por exemplo. Nesses casos, qualquer investimento em melhorar a manutenabilidade representam apenas incremento no custo. Logo, não são boas práticas para aquele projeto.

Uma prática só pode ser considerada boa quando analisada no contexto do projeto em que está sendo aplicada.

Por isso que:

Otimização prematura é raiz de todo mal (Donald Knuth)

Concluíndo e respondendo a pergunta do título

Para uma prática ser considerada boa, precisa colaborar com a eficácia. Seja através da maior assertividade nas entregas (entregar aquilo que resolve o problema que o cliente gostaria de resolver). Seja através da redução do custo total da propriedade – reduzindo o custo de manutenção (quando existir) ou reduzindo o custo de desenvolvimento (quando não inviabilizar manutenção futura necessária).

Você, concorda com isso?

Por hoje..

Smiley piscando

0 Comentários

  1. robsonvf 5 anos ago says:

    Infelizmente é o mal de uma boa parte das consultorias: projetos fechados, investem boa parte do tempo em documentação (zero ROI), atrasam o projeto - com o projeto atrasado ainda sugerem adicionais (perfumaria) antes de entregar o que REALMENTE importa para o cliente, muitas vezes o fazem sem o conhecimento do cliente e, para finalizar, entregam código pobre.

    []s @irobson

    Responder
  2. Juan Lopes (@juanplopes) 5 anos ago says:

    A frase "Otimização prematura é raiz de todo mal." não era do Knuth? Ou do Hoare (como o Knuth diz ser e o Hoare discordar)?

    Se não for, escrevi errado na minha LT no DNAD esse ano 😛

    Responder
  3. Elemar, Parabéns muito bem abordado esse tema, que muitas vezes causa discussões enormes na empresa em que trabalho. Só falta uma coisa que é uma crítica pessoal inclusive sobre a abordagem ágil e ás boas práticas: O Cliente. Muitas vezes o cliente assume os riscos das "más práticas", quando lança mão do "tem que ficar pronto hoje". Isso gera um ciclo vicioso onde nós fazemos de tudo pra "agradar o cliente" e cada vez mais deixamos de lado as boa práticas que reduzem o custo de menutenção, gerando aquelas dívidas técnicas "eternas". Quando dependemos do comprometimento e não apenas envolvimento do cliente, o buraco é sempre mais embaixo.

    Responder
    • elemarjr 5 anos ago says:

      Cara, o cliente não pode ser percebido como um mal necessário. O problema, penso eu, está nas praticas utilizadas para levantamento de requisitos.

      Quanto ao custo total de propriedade, o cliente não deveria ser influência direta. Não é parte do expertise dele.

      Responder
  4. Elemar, Parabéns muito bem abordado esse tema, que muitas vezes causa discussões enormes na empresa em que trabalho. Só falta uma coisa que é uma crítica pessoal inclusive sobre a abordagem ágil e ás boas práticas: O Cliente. Muitas vezes o cliente assume os riscos das "más práticas", quando lança mão do "tem que ficar pronto hoje". Isso gera um ciclo vicioso onde nós fazemos de tudo pra "agradar o cliente" e cada vez mais deixamos de lado as boa práticas que reduzem o custo de menutenção, gerando aquelas dívidas técnicas "eternas". Quando dependemos do comprometimento e não apenas envolvimento do cliente, o buraco é sempre mais embaixo.

    Responder
    • elemarjr 5 anos ago says:

      Cara, o cliente não pode ser percebido como um mal necessário. O problema, penso eu, está nas praticas utilizadas para levantamento de requisitos.

      Quanto ao custo total de propriedade, o cliente não deveria ser influência direta. Não é parte do expertise dele.

      Responder
  5. Entendo seu ponto de vista mas vejo ele destoando do senso comum.

    Acredito que boas práticas são observadas por nós como técnicas que visam a qualidade interna do software, o que não necessariamente determina a qualidade externa (aquilo que o cliente final geralmente dá maior valor).

    Seguindo esta minha interpretação gosto de dizer para meus colegas tomarem cuidado com as boas práticas:
    http://rafanoronha.net/boas-praticas-cuidado-com-elas/

    O que você acha?

    Responder
    • elemarjr 5 anos ago says:

      Repare que eu trouxe dois aspectos: valor entregue e custo total de propriedade.

      A dita qualidade interna só existe de fato se implicar na redução do custo de desenvolvimento ou de manutenção.

      Repare que destaco como custos de manutenção, entendimento do código, alteração em si, testabilidade/testes e distribuição.

      Responder
    • elemarjr 5 anos ago says:

      (cont) qualidade interna ou reduz custo inicial de desenvolvimento, ou reduz custo de manutenção.

      O que vale mais? Depende do projeto.

      Responder
  6. Entendo seu ponto de vista mas vejo ele destoando do senso comum.

    Acredito que boas práticas são observadas por nós como técnicas que visam a qualidade interna do software, o que não necessariamente determina a qualidade externa (aquilo que o cliente final geralmente dá maior valor).

    Seguindo esta minha interpretação gosto de dizer para meus colegas tomarem cuidado com as boas práticas:
    http://rafanoronha.net/boas-praticas-cuidado-com-elas/

    O que você acha?

    Responder
    • elemarjr 5 anos ago says:

      Repare que eu trouxe dois aspectos: valor entregue e custo total de propriedade.

      A dita qualidade interna só existe de fato se implicar na redução do custo de desenvolvimento ou de manutenção.

      Repare que destaco como custos de manutenção, entendimento do código, alteração em si, testabilidade/testes e distribuição.

      Responder
    • elemarjr 5 anos ago says:

      (cont) qualidade interna ou reduz custo inicial de desenvolvimento, ou reduz custo de manutenção.

      O que vale mais? Depende do projeto.

      Responder
  7. show de bola!
    eu penso na simplicidade, então sempre o foco no objetivo do software da forma mais simples possível, sem tonar o software "prolixo"!

    e agregar mais valor, eu penso que é como um carro: vc que se locomover, se vc quer mais luxo vc paga por isso, mas se só quer andar para um lado e para o outro sem fazer questao do luxo vc vai procurar a forma mais simples e barata =)

    Responder
  8. show de bola!
    eu penso na simplicidade, então sempre o foco no objetivo do software da forma mais simples possível, sem tonar o software "prolixo"!

    e agregar mais valor, eu penso que é como um carro: vc que se locomover, se vc quer mais luxo vc paga por isso, mas se só quer andar para um lado e para o outro sem fazer questao do luxo vc vai procurar a forma mais simples e barata =)

    Responder
  9. anonimo 5 anos ago says:

    Muito difícil aplicar boas práticas quando a sua empresa utilza GO HORSE como metodologia de trabalho..

    Responder
    • elemarjr 5 anos ago says:

      Concordo. Com XGH, fica difícil.

      Entretanto, considere a possibilidade de tentar apresentar boas práticas como alternativa para redução de custos e/ou ampliação da lucratividade .. Pode começar por aí ...

      O que acha?

      Responder
  10. anonimo 5 anos ago says:

    Muito difícil aplicar boas práticas quando a sua empresa utilza GO HORSE como metodologia de trabalho..

    Responder
    • elemarjr 5 anos ago says:

      Concordo. Com XGH, fica difícil.

      Entretanto, considere a possibilidade de tentar apresentar boas práticas como alternativa para redução de custos e/ou ampliação da lucratividade .. Pode começar por aí ...

      O que acha?

      Responder
  11. Alan Vasconcelos 5 anos ago says:

    Concordo, mas pior do que tudo isso aí é o caso em que nem mesmo o cliente sabe realmente o que ele quer..

    Responder
    • elemarjr 5 anos ago says:

      Cara .. o cliente nunca sabe. E nem precisa saber. Para isso serve a identificação das necessidades (ou problemas).

      Responder
  12. Alan Vasconcelos 5 anos ago says:

    Concordo, mas pior do que tudo isso aí é o caso em que nem mesmo o cliente sabe realmente o que ele quer..

    Responder
    • elemarjr 5 anos ago says:

      Cara .. o cliente nunca sabe. E nem precisa saber. Para isso serve a identificação das necessidades (ou problemas).

      Responder
  13. Daniel Moreira Yokoyama 5 anos ago says:

    Excelente post.
    Mais uma vez eu ressalto o dom que você tem para fazer bom uso das palavras. Eu normalmente preciso escrever muito mais que isso para conseguir falar a mesma coisa (e mesmo assim, correndo o risco de não ser entendido).
    De qualquer forma, o texto é uma grande lição pra muita gente. Tanto para os céticos que "nunca precisaram se preocupar com isso pra desenvolver sistemas" e estão construindo franksteins imortais por aí, quanto para aqueles que viajam nas firulas inventando todo tipo de coisa enquanto o cliente não obtem sequer o que ele realmente precisava.

    Responder
  14. Daniel Moreira Yokoyama 5 anos ago says:

    Excelente post.
    Mais uma vez eu ressalto o dom que você tem para fazer bom uso das palavras. Eu normalmente preciso escrever muito mais que isso para conseguir falar a mesma coisa (e mesmo assim, correndo o risco de não ser entendido).
    De qualquer forma, o texto é uma grande lição pra muita gente. Tanto para os céticos que "nunca precisaram se preocupar com isso pra desenvolver sistemas" e estão construindo franksteins imortais por aí, quanto para aqueles que viajam nas firulas inventando todo tipo de coisa enquanto o cliente não obtem sequer o que ele realmente precisava.

    Responder
  15. Marcelo Vieira 4 anos ago says:

    (só agora, depois de muito tempo que você escreveu o artigo, que o li)

    Gostei muito do artigo Elemar, parabéns!

    Se me permite até vou "twittar" sua fraze "Uma prática só pode ser considerada boa quando analisada no contexto do projeto em que está sendo aplicada", claro que dando os créditos.

    Muito interessante também a definição que você fez da eficácia do projeto de softwaer mediante o "custo total de propriedade" e "valor correto para o cliente".

    Responder
  16. Marcelo Vieira 4 anos ago says:

    (só agora, depois de muito tempo que você escreveu o artigo, que o li)

    Gostei muito do artigo Elemar, parabéns!

    Se me permite até vou "twittar" sua fraze "Uma prática só pode ser considerada boa quando analisada no contexto do projeto em que está sendo aplicada", claro que dando os créditos.

    Muito interessante também a definição que você fez da eficácia do projeto de softwaer mediante o "custo total de propriedade" e "valor correto para o cliente".

    Responder

Trackbacks para este post

  1. Afinal, por que odiamos gerentes? (e por que não deveríamos) « Elemar DEV
  2. Afinal, por que odiamos gerentes? (e por que não deveríamos) « Elemar DEV
  3. Não terceirize a gestão de sua carreira « Elemar DEV
  4. Não terceirize a gestão de sua carreira « Elemar DEV
  5. Melhorando a testabilidade através de classes Wrapper « Elemar DEV
  6. Melhorando a testabilidade através de classes Wrapper « Elemar DEV
  7. Sobre “design patterns” e “anti-patterns” « Elemar DEV
  8. Sobre “design patterns” e “anti-patterns” « Elemar DEV