Autonomia & Tecnologia

Será que você está desenvolvendo seus sistemas do jeito errado?

Conheça um dos principais erros no desenvolvimento de software, quais são os perigos de cometê-lo e como você pode evitá-lo!

3

É muito comum as pessoas usarem métodos de gestão para melhorar os processo do projeto de software. Mas só mexer na articulação entre as pessoas não basta. É fundamental mudar a forma como se cria o software.

Eu explico isso em detalhes no vídeo “As 4 estratégias do desenvolvimento eficaz”. Se você ainda não assistiu este vídeo, clique aqui agora e assista antes de continuar lendo este post. Você não vai se arrepender.

Para que seu projeto seja bem sucedido, é necessário fazer a coisa certa, do jeito certo e priorizando o problema a ser resolvido, em vez da solução idealizada.

Para demonstrar as sutilezas desse desafio, vou te contar uma história real com personagens fictícios.

Senta que lá vem a história…

Meu amigo Arnaldinho chegou animado no trabalho pela manhã enquanto ria de algum meme da internet. Ele mal sentou na cadeira e seu chefe, Bóris, o chamou para uma reunião para anunciar um novo projeto.

Perfeito! Ta aí a chance que Arnaldinho queria para começar algo novo, do zero, fazendo do jeito certo, sem se preocupar com legado.

Bóris explicou que no dia anterior fechou um contrato com o Clóvis, que é dono de uma imobiliária que é líder no bairro onde atua, mas deseja expandir a operação para outras regiões da cidade e até mesmo cidades vizinhas. Então ele precisa receber prospectos de venda dos imóveis pela internet.

Arnaldinho se empolgou com o projeto e começou a fazer anotações em seu caderno:

Certo… Vou precisar de uma tabela para armazenar os imóveis, com uma coluna para quantidade de quartos, outra para metragem e uma para o tipo do imóvel, afinal tem casa e apartamento.

Não posso esquecer do relacionamento para a tabela de endereços pra ficar normalizada como manda o figurino.

Pra tudo ficar seguro eu preciso criar um login para que apenas os funcionários do Clóvis consigam cadastrar e editar imóveis.

Vai ficar lindão!

Saindo da reunião ele começa o projeto, mas comete um erro crucial:

Arnaldinho começou o projeto implementando o cadastro no banco de dados. E você sabe o que acontece com quem faz isso?

Porque é um erro começar pelo cadastro?

Pense no problema do Clóvis, o dono da imobiliária. Qual o problema que ele precisa resolver? Vender mais imóveis.

Então dentre todas as coisas que o Arnaldinho pode implementar, qual é a mais importante?

A funcionalidade de vender o imóvel ou a de cadastrar o imóvel?

A de vender o imóvel!

Aí você pode perguntar: mas como eu vou vender um imóvel que não está cadastrado no sistema?

A resposta é simples: vendendo!

Não importa como, principalmente no início. Não importa se você fez uma lista manual ou se é um dicionário em memória. O que importa é que a primeira coisa que o sistema faça seja o fluxo de venda de um imóvel. Assim, logo nos primeiros dias o Clóvis pode começar a ter seu problema resolvido, obtendo valor do software e justificando o investimento no desenvolvimento.

Cadastrar imóveis é input, vender imóveis é output.

Um sistema de vender imóveis com a funcionalidade de venda (output), mas sem o cadastro (input) tem mais valor o que um sistema que cadastra (input), mas não vende (output).

Quando você começa desenvolvendo pelo cadastro (input) você se compromete tomando um monte de decisões desconectadas do propósito do sistema que é a venda (output). Este é o modelo empurrado, onde você trata o desenvolvimento como uma linha de produção em série. É aqui que ocorrem aqueles problemas de você desenvolver um monte de coisas e quando chega lá na frente as coisas simplesmente não encaixam.

A alternativa é realizar o desenvolvimento puxado pelo valor. Você começa de pela funcionalidade de venda (output) e vai melhorando o sistema continuamente tornando-o cada vez melhor em fazer o que se propõe que é vender.

Neste processo, você pode ou não chegar em um cenário onde muitos imóveis são cadastrados e/ou tem seus dados alterados frequentemente. Se isso ocorrer, para vender mais e melhor, o sistema precisará ter a capacidade de adicionar e alterar os imóveis com facilidade. Quando isso acontecer, você poderá decidir se vai ser um cadastro, uma carga de dados ou uma integração com outro sistema. Só o contexto poderá dizer. De toda forma, você só terá o custo de desenvolver o cadastro, quando ele for realmente necessário e não antes disso.

Isso significa que você pôde dedicar uma grande quantidade de tempo e energia resolvendo cada vez melhor o problema do cliente.

Você pode me perguntar:

Mas Henrique, se eu desenvolver dessa forma puxada como você sugere, significa que toda hora eu vou ter que mudar o sistema, enquanto da outra forma ele já estaria pronto, certo?

Errado! Só existe uma certeza na atividade de programação: Se alguém usa o seu software, ele vai mudar!

A pergunta que importa é: Como eu faço para que as mudanças no software não sejam uma atividade de risco?

A resposta está no início do artigo: Domine e aplique “As 4 estratégias do desenvolvimento eficaz” para manter o seu projeto estável e sempre conectado com o valor que você gera para o seu cliente.

Isso é exatamente o que eu abordo no Welcome to the Django e funciona para qualquer tecnologia. Eu uso Python e Django como meio para demonstrar estes processos em um grande nível de detalhe.

E aê? Curtiu? Você também já foi da turma do Arnaldinho? Eu já e depois que descobri como fazer desenvolver com eficácia, tudo melhorou infinitamente.

 

Abraços, HB!

 


Imagem retirada de The Register.

você pode gostar também
  • ian wanderson

    Rapaz Muito bom, continue com os posts!

  • Inácio Medeiros

    Artigo muito inspirador, parabéns por ele, Henrique.

    Aproveitando que você falou do Welcome to the Django, uma frase que gostaria de destacar: “Eu uso Python e Django como meio”.

    O que eu tiro dessa frase: todos esses (e vários) princípios de desenvolvimento (mais) eficaz (e eficiente) independem de linguagem. Não importa se você use Python, Java, ou até Haskell ou Assembly, valendo-se dessa conduta, no projeto que se utilizar elas, na linguagem que for, a coisa vai fluir, pois vai além de “apenas codificar”.

    Eu comento isso pois às vezes pode ser que a gente só queira aplicar isso em projetos Python, e em outras linguagens a gente fique mais desleixado, mas não, isso vale para qualquer projeto, em qualquer linguagem.

    • Perfeito, Inácio! A forma de fazer serve para qualquer linguagem. É uma habilidade que qualquer programador pode desenvolver em si.

      Verdade que as vezes uma ou outra tecnologia terá mais ou menos facilidades/ferramentas para te apoiar nesse processo. Mas ainda assim é completamente possível.