CRUDs… Cruzes! Fuja da armadilha de começar pelo mais fácil

Sapo-na-panela2

Vamos pensar em um sistema qualquer, deixa eu ver… algo de vendas. Bom, falando em vendas algumas palavras, quase obrigatórias, me vem à cabeça como: produto, loja, vendedor e cliente.

Se alguém falar apenas isso sobre o sistema eu já posso dizer algo de antemão: você vai ganhar um CRUD para cada um deles.

Uau! É mesmo? Que legal! Mas… CRUD é de comer ou de passar no cabelo?*

Bem, CRUD é uma sigla em inglês que agrupa as quatro operações ou funcionalidades básicas de um sistema: Criar, Ver, Alterar e Excluir (Create, Read, Update e Delete).

Cada uma daquelas palavras (no caso, entidades ou classes) ali de cima vai ganhar um CRUD. Isso acontece porque são entidades que freqüentemente são criadas, vistas e alteradas e que são, eventualmente, excluídas, como por exemplo, os produtos.

Ok, mas, por que esse título agressivo contra os CRUDs no seu artigo? Bem, os CRUDs em si não são o problema, o problema está na atenção e importância que damos a eles.

CRUDs são uma necessidade, contudo, raramente serão a funcionalidade mais importante de um sistema.

Alguém consegue me dizer de primeira aí qual é a principal funcionalidade do sistema de vendas? VENDER!

Eu já participei de discussões hercúleas com pessoas que estavam habituadas a começar pelos CRUDs, uma das melhores contando com a ajuda do Vitor Cavalcante (@vcavalcante) – interessante que nenhuma delas estava habituada a entregar os projetos – e reuni alguns argumentos que podem ser úteis:

 

“Vamos começar por algo que já conhecemos”

Lamento amigo, mas você não conhece. Você pode ter criado 50 sistemas para vendas e mesmo assim, não vai saber exatamente quais campos são necessários em um cadastro de clientes. Você só vai saber o que é necessário em um CRUD estudando as funcionalidades que consomem as informações do CRUD como, nesse caso, a venda em si e também os relatórios gerenciais.

Pense comigo: se seu sistema é tão genérico a ponto de conhecermos todos os cadastros necessários, será que não vale a pena comprar um de prateleira?

“Tudo bem, se faltar alguma coisa em um CRUD a gente muda depois”

É muito chato ficar parando no meio do desenvolvimento do que interessa para fazer ajustes nos CRUDs. Se deixar o CRUD para o final, você trabalha nele apenas uma vez, muito mais limpo, menos chance de gambiarras e retrabalho.


“Vamos fazendo aqueles que sabemos ser necessários”

Você não sabe quais são necessários até fazer as funcionalidades que os consumirão. Fazer um CRUD antes de fazer uma funcionalidade é jogar fora a chance de saber quais CRUDS devem ser feitos de fato e como eles devem ser.


“Vamos começar por algo fácil para ir acostumando o desenvolvimento”

Desenvolvedores não buscam coisas fáceis para fazer, é quase isso, mas não é igual. Eles buscam algo interessante, potencialmente divertido. Chame um grupo de desenvolvedores para conversar sobre o cadastro de clientes, chame outro grupo para conversar sobre a venda na loja com o apoio de um IPAD e observe a diferença nos comportamentos. Não trate o desenvolvimento como se fossem crianças mimadas preguiçosas.Mesmo se fossem, deixar a parte “difícil” para depois só irá garantir pânico de fim de projeto.

 

“É arriscado começar com algo que não conhecemos”

Amigo, arriscado é ficar se enganando trabalhando com algo sem impacto. Se você não tem idéia de como deve ser seu sistema de vendas, invista em duas coisas: análise de negócios e atacar os maiores riscos do projeto antes.

Se o seu projeto tem riscos de infra, por que não fazer algo como “acessar a ficha do cliente a partir de uma filial”? Monte a infra, implemente essa história simples de consulta, vá até a filial e acesse a ficha (ou simule centenas de acessos simultâneos). Ataque o problema.

Se você tem receio do que o presidente da empresa vai achar dos relatórios, faça um e mostre para ele. Não existe melhor medida para o progresso de um projeto do que software funcionando. Existe uma grande chance dele olhar para o relatório e apontar centenas de falhas, mas veja, você está no começo do projeto!

Planilhas de gráficos de Gantt não garantem nada contra seus riscos, apenas a ação garante. Você vai dormir melhor.



“Com um CRUD mostro algo funcionando rapidinho para o negócio”

Cuidado com as pessoas do negócio que estão muito interessadas em como serão as telas de cadastro. Usabilidade nos cadastros é fundamental, contudo, existem partes interessadas importantes que ficam de fora quando você só pensa em CRUDs como, por exemplo, quem vê relatórios gerenciais, ou mesmo o gerente da loja que quer acompanhar o movimento do dia ou a posição dos estoques.

Quer agradar rápido o negócio? Invista no que o sistema tem de mais interessante. Encontre onde aperta o sapato e resolva o problema.

 

“Como vou fazer uma venda se não tenho cadastro de produtos, clientes e vendedores?”

Simples: use um comando mágico chamado “INSERT INTO”. O “INSERT INTO” é o comando através do qual uma informação é inserida diretamente no banco de dados. É possível criar uma estrutura básica de dados de produtos, clientes e vendedores e alimentar essa estrutura de forma que uma ou mais vendas possam ser realizadas no sistema. É comum, nesses momentos, descobrir que precisaremos de diversas entidades e dados dos quais não havíamos pensado antes (o que faz cair por terra aquele orçamento inicial).

É possível desenvolver até mesmo relatórios gerenciais sem desenvolver um CRUD sequer. É trabalhoso, pois é importante que esses dados façam sentido para o negócio avaliar, mas compensa muito.

A maior parte dos projetos conta com uma etapa de testes no final, uma etapa na qual os analistas criam cenários de testes e criam cargas de dados para realizar esses testes. Chame esse pessoal para o começo do projeto, peça os cenários e as cargas já. Isso diminui muito os riscos.


“Vamos criar os cadastros antes para o pessoal ir alimentando o sistema”

Eu já vendi essa…Nunca aconteceu. Olha, me mostra uma empresa na qual as pessoas param o que estão fazendo para alimentar um sistema o qual nunca viram funcionando que eu te mostro um unicórnio. Além de você não saber bem o que precisa, correndo o risco de fazer as pessoas terem que retornar a cada cadastro para inserir uma ou mais informações que haviam ficado de fora, fica bem difícil motivá-las a parar o trabalho para fazer algo que não traz valor tangível.

 


Refazendo a frase do começo, acho que o maior problema de investir nos CRUDs no começo do projeto está justamente no risco. O Rodrigo Yoshima (@rodrigoy) tem um nome para isso que acho genial: “Síndrome da gestão covarde”.

Nas palavras dele:

“Devemos buscar e mitigar riscos e não temê-los. O gerente covarde natural geralmente inicia o trabalho pelas tarefas menos arriscadas para mostrar que o projeto andou.”

 

Além dos benefícios de atacar os riscos mais cedo, deixar os CRUDs para o final possui um efeito colateral maravilhoso.

Sabe aqueles momentos finais dos projetos, aquela tensão toda que vai envolvendo o time, o frio na barriga na hora de colocar algo em produção? Claro que sabe, eu costumava odiar aquilo.

Imagine você na última semana de um projeto tendo que concluir o desenvolvimento dos recursos mais críticos, como, no nosso exemplo, a venda? Loucura, muito arriscado.

Agora imagine você nessa fase apenas fechando o desenvolvimento de alguns CRUDs? Tudo que era arriscado já foi visto e validado. É uma beleza.

Eu digo isso porque deixamos os CRUDs para o final no projeto atual e é muito, muito bom não ter nada de crítico no nosso caminho nesse momento. Dá tranqüilidade até para escrever um artigo.

 

“Ahh, mas você está falando de projetos ágeis, para vocês é tudo diferente”

Deixar os CRUDs para o final ajuda também nos projetos cascata? Sim! Mudanças não são bem-vindas nesses projetos, justamente por isso é bem melhor fazer uma requisição de mudança mais cedo no projeto e alterar os requisitos dos CRUDs antes que eles entrem em desenvolvimento.

 

Por fim: nem todos os CRUDs precisam ser desenvolvidos.

Antes de desenvolver um CRUD é importante pensar em duas variáveis: freqüência de uso e perfil de quem usa.

Uma entidade que é raramente alterada, como, por exemplo, um cadastro de países, pode ser atualizada diretamente no banco de dados mediante um chamado aberto para a área de TI. O tempo de desenvolvimento pode ser várias vezes maior do que o custo total de um chamado para TI, se for, não desenvolva o CRUD, instrua as pessoas sobre o procedimento de chamado. É um serviço.

Se o usuário do CRUD for extremamente avançado, por exemplo, alguém da infra que precisa alterar parâmetros do sistema, ele que o faça diretamente no banco de dados. Você não precisa mimá-lo com uma interface colorida, a não ser que esteja sobrando tempo no desenvolvimento (sobra?).

 

Enfrente a realidade

Temos uma tendência forte de adiar a influência da realidade sobre os nossos projetos o máximo possível, contudo, sabemos por analogia com outros aspectos da nossa vida que essa não é uma boa prática.

Queremos dormir tranqüilos e ver progresso real no nosso trabalho e isso começa por fazer antes o que é mais importante e arriscado, deixando o conforto para o final.

Use os argumentos acima à vontade, experimente deixar os CRUDs para o final. Se você discordar de algum desses argumentos, coloque nos comentários, quero conhecer todos (vai que me faz mudar de idéia), se conhecer mais alguma razão para deixar os CRUDs para depois, comente também.

Esse é um movimento pelo bem do desenvolvimento de software e conseqüentemente para o bem dos negócios que o software apóia.

 

 

 

** Quem costuma usar essa expressão genial é a Suzandeise Thomé, presidenta do capítulo se São Paulo do IIBA.

 

 

 

32 ideias sobre “CRUDs… Cruzes! Fuja da armadilha de começar pelo mais fácil

  1. Pois é Cláudio, inclusive eu já tinha comentado com pessoal da equipe que eu achei esta abordagem muito boa. Dito e feito, final de projeto, pessoal tranquilo somente fazendo cruds.Outro aspecto importante que vejo nesta abordagem é o fato de reduzir as chances de desperdício. Já trabalhei em um sisteminha de pedidos no qual começamos com vários e vários cruds que supostamente seriam usados dentro da principal feature, a retirada de pedidos. No final do projeto, quando estávamos trabalhando naquilo que realmente tinha valor, descobrimos que vários cruds não eram necessários. Além de ter sido um belo desperdício, o nível de stress no final do projeto foi evidente.

  2. Meu amigo Cláudio! Você traz um tema legal que remete ao negócio e o valor de entrega, razão do nosso trabalhinho divertido de todos os dias.Concordando com o ponto de vista, mas quero refletir para pontos onde não são gastos tempos com CRUDs.Se modelo a DB e tenho CRUDs dinâmicos em função de um framework ágil, a entrada de dados é mais ágil que um INSERT INTO e sem que eu tenha envolvido recursos, não acha?

  3. @Otavio Medeiros: tu sabe que sou seu fã. Pensar em disperdiçar o talento do pessoal da Oncast com "trabalho de chinês aposentado" seria algo muito triste!Vamos trabalhar para que todos os POs do Grupo RBS saibam instigar o que os times tem de melhor.

  4. @Gilmar Pupo bahhh, você tem toda razão! Um framework que permita a criação fácil (e atualização dinâmica) diminui drasticamente o potencial de desperdício dos CRUDs. Agora fiquei curioso com o assunto e você fica devendo um artigo!

  5. Parabéns pelo seu artigo, Kerber.Concordo com 100% e vou na onda do Gilmar: Já existem diversos geradores de CRUD. Em Java Swing, o netBeans faz isto para você, gerando até as telinhas. Um amigo já fez isto para PHP tbm. ABS

  6. Excelente tema…. Analogicamente à construção de uma casa. Ninguem sai construindo o Banheiro, a Garagem … a Piscina, … apesar de já existir na Planta. Mas "levanta-se" todas as paredes e, só depois então, é que essas dependências vão "tomando" forma. CRUD, realmente é algo que só serve para "enrolar" o cliente e "ganhar" tempo para o verdadeiro desafio – A Solução. É uma grande verdade quando você diz que deixar os CRUDs para depois, os deixa muito enxutos e simples, uma vez que já sabemos o que existe no sistema. Evitaremos CRUDs que jamais serão usados. Parábens Claudio por mais um tema de Efeito.

  7. Cláudio, Sua abordagem está perfeita, vem mesmo de encontro com o que idealizo para os projetos. Tem tudo a ver com DDD, pois não começar no CRUD significa orientar o desenvolvimento ao domínio da aplicação. Tem tudo a ver com TDD pois testar antes reduz dos riscos e faz a equipe conhecer melhor o domínio. E finalmente tem tudo a ver com entrega de valor, afinal CRUD é na maioria das vezes uma infra do sistema, e não o seu principal propósito. Talvez você nem precise modelar o banco se tiver um mock consistente. Ai a abordagem fica ate mais "code first".

  8. Oi Cláudio, é um bom post mesmo!Concordo completamente quando você diz para não começar os sistemas pelos CRUDs, mas apenas discordo da abordagem de colocar os CRUDs no *final* do projeto.Acho que isso deve funcionar em alguns casos, mas na forma como eu gerencio os meus projetos isso não seria possível. Os CRUDs são feitos à medida que as funcionalidades que os utlizam são desenvolvidas — portanto durante o desenvolvimento.Tenho uma boa razão pra isso: fazemos deploy dos projetos muito cedo, desde a primeira versão minimalista que agrega valor. Dessa forma, muitas vezes até para que uma funcionalidade mais complexa tenha valor, é necessário que usuários finais (e não o cara da TI) possam adicionar dados.De qualquer forma, inserts e updates são *sempre* considerados como um dos approaches mais simples quando são dados "internos" (pré-cadastrados?) e medidos em valor e custo comparando com a implementação da funcionalidade.Assim, vai que vai. ;-)Ceci – @cecifernandes

  9. Muito bom Claudio!!!!!NÃO PRIORIZAR DO PONTO DE VISTA TÉCNICO, E SIM, PRIORIZAR DO PONTO DE VISTA DO NEGÓCIO!Eu ainda acrescentaria duas coisas sobre CRUD: (1) é possível fatiar uma user-story CRUD, e normalmente o que mais agrega valor é o R (ler). Isso é um ótimo exemplo de priorização do ponto de vista do negócio, pois do ponto de vista técnico, o C faria mais sentido ser o primeiro…(2) Deixar o CRUD para o final minimiza/evita os malditos campos opcionais. Os campos opcionais são uma praga para a interface e para os testes, além de normalmente camuflarem um mal entendimento sobre o negócio e seus perfis de usuários.Meu blog:rtoledo.scrumban.com.br[]s,Rodrigo de Toledo

  10. @Jean Streleski Valeu Jean, pois é, acho que o pessoal do negócio (que seja da análise de negócios) tem que prestar atenção nesses quitutes tecnológicos, afinal, não adianta descobrir se não entregar.

  11. @Luisão Rodrigues, é isso amigão. Você sabe bem como se sofre com essa enrolação, não serve para ninguém, afinal, eu te conheço e sei que você quer desenvolver funcionalidades que encham os olhos de quem usa e não apenas quadradinhos em um gráfico de andamento do projeto.

  12. É isso aí @aliodoro, tudo a ver com DDD e TDD. Acho que esses argumentos para deixar CRUDs para depois são uma porta de entrada para essas ferramentas de pensamento e ação.

  13. Ahhh @cecifernandes sem dúvidas seu time está em outro nível :) Não vou negar que estava com projetos de ilusão de escopo fechado em mente quando escrevi. Quem faz entregas contínua de valor nem se estressa com siglas como "CRUD", só quer saber de valor, e ele pode vir nos pedaços dos CRUDs como lembrado pelo @toledorodrigo.Fico feliz em ver gente trabalhando bonito assim!

  14. @toledorodrigo, perfeito, eu pensei em falar em fatiar os CRUDs como fazemos com as histórias e também em deploy automático, aí pensei que como eram argumentos para falar com quem não entende muito da coisa (até por querer os CRUDs no começo), poderia ficar menos genérico (fora que, como sempre, o texto ficou grande, hehe).Campos opcionais… hum… dá para tirar uma boa reflexão daí. Se pensarmos em termos de MVP – Minimum Viable Product, demoraria um bocado na vida de um produto para eles aparecerem. Tô com uma pulga atrás da orelha agora.

  15. Muito bom artigo, Claudio!Apesar de eu concordar em tudo, estou sofrendo hj em dia por falta total de CRUD nos sistemas com que trabalho. Outro dia inventei de criar um teste em LIVE, na certeza que de que daria pra excluir depois (de tao obvia que era a necessidade de um CRUD para a entidade que eu estava usando) e para minha surpresa: nao tinha. Tive que pedir pro desenvolvedor deletar direto no banco da dados… Um mico, mas tudo bem. Gostei de ver nos comentarios do artigo as sugestoes de geradores automaticos de CRUD. Apesar de eu nao lidar muito com codigo, acho que talvez valha a pena levar isso como sugestao para o time de desenvolvimento, e quem sabe ate usar como argumento o baixo custo para convencer a gerencia a investir em melhorias futuras no sistema. Um dia quem sabe…AbracosJuliane

  16. Oi Claudio! Adoro a sua forma simples de escrever dando tantas dicas em um só texto.O que mais me chama atenção, indo na linha do que disse o Rodrigo de Toledo, é como muitos times de desenvolvimento ainda focam em si mesmos. Esquecem totalmente de onde vem o dinheiro que paga o trabalho deles… Postergar o desenvolvimento de CRUDs requer reconhecer que isso não trás valor para o negócio.Adorei o trecho "Alguém consegue me dizer de primeira aí qual é a principal funcionalidade do sistema de vendas? VENDER!" Eu diria o "objetivo"…É tão óbvio, certo? Nem tanto… já cansei de entrevistar potenciais Analistas de Negócios que não sabiam me explicar o objetivo de seus projetos. A fama que TI tem de não entregar valor não mudará enquanto não mudarmos o "time da linha de frente", aquele que conversa com o cliente, pra incluir somente pessoas que tenham real interesse em resolver o problema do negócio.Eu falo muito na teoria, aí você vai lá e dá um exemplo prático. Sensacional!-Suzandeise

  17. Cara gostei muito do post, muito bacana e real, eu particularmente ja cometi esse erro algumas fazes. Porém existe algumas situações que nw tem como fugi dos CRUDS da vida.E outra, teve um amigo acima que uso o termo "sisteminha", na minha visão não existe sisteminha e sim sistemas mais ou menos complexos.Valeu pelo post Claudio isso ajuda a todos nos, desenvolvedores, analistas, projetistas, gerentes e afins e cada dia melhorarmos nossa visão.

  18. oi Hugo! Se CRUDs fossem SEMPRE inúteis duvido que existiriam. A questão é a priorização, a importância que damos a eles. Se queremos atacar os riscos rapidamente, não vai ser justamente onde temos menos "emoção" que vamos trabalhar, certo?

  19. Embora eu concorde em número, gênero e grau sobre a forma que devemos seguir, determinadas situações são complicadas demais para utilizar esta técnica.Explico: Participei de um projeto em que o Framework tinha acabado de ser planejado, precisava de retoques finais e um sistema como seu piloto. Pra quem já conhece o ritmo dos contratos com o Governo, tudo é pra ontem e a data de entrega já havia sido discutida entre as gerências, dada uma série de fatores. A equipe de desenvolvedores já havia sido selecionada, destacada e pronta para o trabalho, mas embora sejam excelentes profissionais de Java, ainda não haviam tido seu primeiro contato com o Framework.Desta forma, acabei por tomar a decisão de focar inicialmente nos casos de uso mais simples (CRUD) para que os desenvolvedores tivessem seu primeiro contato com a nova tecnologia sob acompanhamento do Arquiteto, enquanto eu me preocupava com o levantamento das funcionalidades mais complicadas.Resultado: Várias falhas foram corrigidas durante o início do projeto, mas ainda passamos por mal bocado nas funcionalidades mais complicadas, que ainda acredito que teriam sido piores se fossemos direto ao ponto. No fim das contas, conseguimos desenvolver um sistema de grande porte em quatro meses, sendo que a contagem de PF indica que esse tempo seria apenas para a parte de levantamento.Quanto ao texto do post: Lido, aprovado e divulgado. Excelente. Parabéns!!!

  20. Cláudio,Muito legal o seu post. Venho nessa briga faz tempo. O pessoal adora criar frameworks pra entregar alguma coisa rápido, mas entregar o que? CRUD. Já estou até vendo uma tela de consulta com filtros, um link para incluir registro novo, um grid com os registros que satisfazem o filtro com links para alterar e excluir. Na tela de Cadastro / Alteração deve ter um botão "Salvar". O que é "Salvar" para o negócio?O que mais temo nos sistemas que desenvolvo são aqueles relatórios com poucos campos mas que para serem montados são muito complexos. Esses, normalmente ficam para o final.Estou no "movimento pelo bem do desenvolvimento de software e conseqüentemente para o bem dos negócios que o software apóia".Abcs

  21. sethsoul, esse projeto no qual você caiu tinha tantas premissas e coisas já definidas que não sobrou muito para você fazer, talvez a questão seja: por que aceitamos trabalhar assim?Estou cansado de ver coisas absurdas sendo feitas com a justificativa de que "já foi decidido".Uma vez eu caí em um projeto no qual "estava decidido" que o framework seria Cake PHP, decisão sem fundamento, é claro que não ajudou nada.

  22. Antonio Castro Jr, bem-vindo ao movimento pelo bem do desenvolvimento de software!Ótima pergunta, "o quê é salvar para o negócio?"Vi no seu blog que você já tem algum tempo de estrada (desde 81, certo?), fico imaginando como você foi tomando consciência dessas coisas uma vez que não é algo tão claro para quem está concentrado nas técnicas de desenvolvimento.

  23. Oi Claudio, só dando parabéns. Infelizmente só li agora o artigo, estava na minha lista a seis meses, realmente coloca em cheque vários lugares comuns que vemos tanto na análise, quanto no desenvolvimento e no gerenciamento dos projetos de TI. Pois a grande maioria acha que projeto é que nem uma história a ser contada, você tem a introdução, o desenvolvimento e por fim o climax. Quando na verdade o produto de TI é uma coisa que gera informação, basta somente saber quais informações precisam ser colocadas primeiro para gerar as informações que preciso com mais urgência

  24. Sobre geradores de CRUD, na minha empresa usamos o admin do framework Django (https://docs.djangoproject.com/en/dev/ref/contrib/admin/). É lindo! O melhor que eu já vi :-)Mas, até onde eu conheço, o estado da arte em termos de geração de CRUDs ainda não é assim tão bom para gerar CRUD suficientemente bonitos e usáveis para você entregá-los diretamente para o seu cliente, de forma que ainda gastamos algum esforço com eles. E isso sem dúvida alguma é o tipo de atividade que deve ficar pro final do projeto.E mais: para que os CRUDs sejam gerados automaticamente, é necessário primeiro modelar todo o banco. E isso pode ser extremamente trabalhoso, dependendo da complexidade do negócio. Dessa forma, acredito que mesmo tendo o facilitador de geração de CRUD, é válida a abordagem de pensar primeiro no transacional, e deixar que ele guie a necessidade de modelagem das tabelas, e não tentar pensar primeiro no modelo completo de entidades, para gerar os CRUDS.

    • Parece que esse problema com os CRUDs nos projetos vai dar pano para manga por muitos anos ainda. Agora me fala: esse problema não te deixou em paz nem no natal? hehehe

      Um abraço!

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *