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.

[post originalmente publicado em 26/08/2011 no site http://blog.claudiobr.com/cruds-cruzes-fuja-da-armadilha-de-comecar-pel]