Elemar DEV

Tecnologia e desenvolvimento

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

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

20 comentários em “Afinal, o que são boas práticas?

  1. robsonvf
    24/08/2011

    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

  2. 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 :P

  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.

    • elemarjr
      24/08/2011

      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.

  4. 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?

    • elemarjr
      24/08/2011

      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.

    • elemarjr
      24/08/2011

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

      O que vale mais? Depende do projeto.

  5. 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 =)

  6. anonimo
    24/08/2011

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

    • elemarjr
      24/08/2011

      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?

  7. Alan Vasconcelos
    24/08/2011

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

    • elemarjr
      24/08/2011

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

  8. Daniel Moreira Yokoyama
    26/08/2011

    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.

  9. Pingback: Afinal, por que odiamos gerentes? (e por que não deveríamos) « Elemar DEV

  10. Pingback: Não terceirize a gestão de sua carreira « Elemar DEV

  11. Pingback: Melhorando a testabilidade através de classes Wrapper « Elemar DEV

  12. Marcelo Vieira
    13/07/2012

    (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”.

  13. Pingback: Sobre “design patterns” e “anti-patterns” « Elemar DEV

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado às 23/08/2011 por em Sem categoria e marcado , .

Estatísticas

  • 626,851 hits
%d blogueiros gostam disto: