Nós conhecemos a linguagem de programação, a sintaxe, os componentes e a ferramenta, mas para desenvolvermos um sistema é preciso conhecer também a Regra de Negócio do cliente, também conhecida como Domínio da Aplicação. Este é um dos desafios que todo programador encara no início de um projeto ou de um emprego, ao menos que ele já conheça a regra de negócio por experiências anteriores.
Bem, existem softwares para diversas finalidades, como controle de estoque, administração financeira, contabilidade, emissão de pedidos, recursos humanos, entre outros. Cada um desses sistemas respeita uma série de validações, restrições e funcionalidades para que a sua utilização seja objetiva, ou seja, atenda as necessidades apontadas pelo cliente. Em um sistema de controle de estoque, por exemplo, a regra de negócio basicamente consiste nas entradas e baixas da quantidade dos produtos quando uma nota entra no sistema ou quando o produto é vendido. Todo esse fluxo de entradas e saídas deve ser controlado pelo software por meio de banco de dados, funções e procedimentos implementados pelo programador. Um simples erro na semântica do código ou na execução de uma função pode afetar o controle desses dados no sistema, que por sua vez, não armazenará informações íntegras.
Já a regra de negócio de um sistema contábil é diferente. É preciso conhecer leis, tributações, códigos contábeis e impostos para desenvolver um sistema eficiente para este ramo. Eis que surge uma observação: nem todos os desenvolvedores conhecem as regras de negócio (ou domínio da aplicação) para qual o sistema será desenvolvido. Cabe a ele pesquisar, informar-se com outros profissionais e compreender como as engrenagens do sistema funcionam. Apesar da complexidade, existem regras de negócio que possuem características semelhantes e ajudam desenvolvedores a reduzir a dificuldade em aprender um novo segmento.
Na maioria das vezes, o desenvolvedor é contratado para trabalhar em um sistema que já está desenvolvido, e para isso, é preciso que ele conheça toda a regra de negócio antes de começar a produzir código. O tempo de adaptação é relativo, embora muitas empresas busquem reduzir este tempo por meio de cursos e treinamentos. Normalmente em dois ou três meses já é possível adquirir um conhecimento mediano sobre o domínio da aplicação do sistema.
Uma forma simples e rápida de abranger a regra de negócio é comunicar-se com o cliente. Agendar visitas e acompanhar, nem que for por um dia, os processos operacionais do cliente (ou empresa) já denota uma grande base de conhecimento. Conversar com o cliente também é essencial, pois, afinal, é ele quem está adquirindo o software e conhece completamente a área de negócio da empresa. E lembre-se: faça perguntas, peça explicações e simule cenários. Cada detalhe sobre a regra de negócio é muito importante!
Mesmo assim, se você é um desenvolvedor e atualmente se encontra no tipo de situação citada neste artigo, não há o que se preocupar. Nada como a prática do dia-a-dia para aprender cada vez mais sobre a regra de negócio do cliente. Em pouco tempo, você também estará sugerindo melhorias nos processos do cliente e criando novas rotinas para aprimorar o software.
Caro desenvolvedor, boa sorte no seu trabalho!
Publicado originalmente no blog SubRotina
13 Comentários
Olá André Luis,
Parabéns pelo artigo muito bom, realmente não é fácil abstrair as regras de negocio ainda mais se você trabalha por demanda. Mas, como foi exposto no seu artigo somente o tempo pode preencher essa lacuna. Por outro lado é exatamente isto que é tal interessante nesta área, ou seja, está sempre aprendendo e não somente sobre TIC.
Já estive envolvido no desenvolvimento de um sistema especifico para uma contabilidade, o maior desafio que encontrei foi realmente entender como tudo deveria funcionar, para isso eu fiquei perto de 3 semanas trabalhando lá junto com a empresa, para depois trazer as especificações para minha equipe e ajudar no desenvolvimento.
Por isso existe o Analista de Negócios, que vai entender e documentar as alterações e enviar para que o desenvolvedor desenvolva .
Ótimo artigo. Passei por uma situação idêntica ao assumir uma aplicação já existente relacionada a “order management” na área de telecom. Senti muita dificuldade no começo pois as reuniões eram cheias de conceitos e jargões que eu não conhecia, mas depois de algum tempo e dedicação consegui me situar. Acredito que conhecer o domínio da aplicação que se esta trabalhando torna-se essencial para propor soluções ótimas e muitos desenvolvedores não dão a necessária importância para tal.
Estes casos são específicos de empresas que ainda trabalham com o profissional Analista de Sistemas / Programador.
Durante muito tempo este foi um formato utilizado por todas as empresas quando não havia uma maturidade do setor de TI. Hoje especializamos os profissionais e dividimos as tarefas para que não haja este tempo de aprendizado. Muitos Analistas de Sistemas tornaram-se Analistas de Negócios, mas o problema continuou existindo porque o tempo gasto para se analisar um processo ainda é longo e, muitas vezes, ineficaz.
Gosto muito do Scrum porque a figura do PO é um profissional da área de negócios da empresa que melhor domina o assunto e fica responsável por passar seu know-how para a equipe de desenvolvimento que, por sua vez, é multitarefa. Hoje, quando estou responsável pela TI de um cliente, adoto esta estrutura que tem dado excelentes resultados e tem feito com que a TI deixe de ser a vilã da organização.
Excelente comentário, Fernando. Passei por situações parecidas e somente com o tempo me adaptei aos conceitos do negócio. Além da produtividade, eu também diria que o conhecimento da regra de negócio evita falhas no software, já que o desenvolvedor estará ciente das regras envolvidas na implementação.
Andrey, concordo plenamente com você. Sou um grande entusiasta em metodologias ágeis e já tive a oportunidade de conhecer o trabalho de alguns Products Owners. Realmente é um papel essencial para essa situação de transferência de conhecimento sobre o domínio da aplicação. Mesmo assim, acho importante que a empresa tenha algum programa de treinamento para auxiliar nesse processo de adaptação. Neste programa, por exemplo, os responsáveis poderiam apresentar o ramo de atividade dos clientes, os clientes potenciais, os principais processos de negócio e como o software atende os requisitos essenciais.
Obrigado a todos pelos comentários!
Por isso que cabe ao Analista Funcional transformar a regra de negócio em uma especificação técnica, em que o programador transformará em código. É assim que funciona com ERP’s de grande porte por anos: cada macaco no seu galho.
André,
Excelente e oportuno artigo, pois é necessário enfatizar o quão importante é a etapa “Requisitos”, que na minha visão, está diretamente ligado ao “conhecer/entender” o domínio ou regra de negócio do cliente, proporcionando uma dinâmica maior e melhor aos desenvolvedores e eficácia do software ou sistema, independente de se já existe um anterior ou é o desenvolvimento de um novo.
Obrigado pelo feedback, Antonio! Concordo com você, o conhecimento da regra de negócio proporciona vários benefícios tanto para a produtividade quanto para a qualidade do produto final. É importante buscar conhecimento nessa área.
Abraço!
Olá André, cara parabéns pelo post realmente muito válido e de grande utilidade quando se trata, de cenários onde o cliente precisa de agilidade por parte do desenvolvedor recém contratado que irá trabalhar em cima de um código desenvolvido por outro develop. Este é meu caso, cara! são 1:39 estou em apuros, recebi uma solicitação de modificação na logica do do sistema que abre em browser da empresa, uma plataforma que é o carro-chefe da operação, onde apenas eu serei responsável, desenvolvida em C# asp.net MVC4 Visual Estudio, tupi program guarani (rs brincadeira) o sistema precisa de alteração no formulário final, cara não sei por onde começar, como fazer o que mudar, como identificar e de que forma identificar a operação em Model. Preciso de ajuda, se alguém se simpatizar em ajudar também ficarei grato, pois realmente estou precisando, minha cabeça vai além pois preciso interagir com banco de dados, e seguir a regra de negócio no que se refere a entender como o cenário esta introduzido no sistema de forma a exercer a pro-eficiência espera para a operação.
Macetes, de usabilidade do visual estúdio 2013 também são muito bem aceitos por quem manja mesmo da coisa, muito grato meus amigos e ao autor, abraço quero ajuda!!! rsrs
Olá, Delson, tudo certo?
Entendo perfeitamente a situação em que você se encontra, pois também já me deparei com esse tipo de desorientação ao desenvolver um WebService. Delson, a minha sugestão é que você mantenha a calma e o foco no aprendizado. Ninguém consegue aprender as tecnologias e a regra de negócio de um projeto da noite para o dia. Conforme você for conhecendo o sistema, vai notar que tudo começa a se encaixar e, ao mesmo tempo, vai se tornando mais compreensível. Em pouco tempo, com o esforço necessário, você já estará produzindo código e apresentando soluções. É tudo questão de conhecimento.
Claro, é importante frisar que os gestores e superiores devem compreender a sua postura frente à responsabilidade do módulo e fornecer um prazo acessível para que você possa se alinhar ao projeto.
Boa sorte! Abraço!
Grande André
Parabéns amigo pelo ótimo trabalho
Grande Victor!
Obrigado pelo comentário, meu caro!