O analista de sistemas e as regras de negócio
Antes de continuar com a série sobre stored procedures(o próximo post será sobre o MySQL), vou comentar sobre algo que pode tirar o sono de muitos programadores, que assim como eu, não tem a felicidade de trabalhar ao lado de um Analista de Sistemas Sênior com muita experiência e com vários sistemas desenvolvidos durante a carreira. Trata-se das regras de negócio! Você deve estar pensando: Não seria mais importante tratar de alguma tecnologia específica, como java, .net, ruby on rails, php etc? Eu te respondo: A tecnologia, plataforma em que um sistema será desenvolvido é apenas um detalhe do ponto de vista funcional do sistema, o que realmente importa é se o software atende as necessidades do usuário, se auxilia o negócio, para isso acontecer quem construiu o sistema teve que conhecer como funcionam os processos e as regras de negócio da empresa.
Conhecer bem as regras de negócio é tarefa simples quando se faz uma boa análise de requisitos e a empresa(negócio) tem suas regras bem definidas(maturadas), o problema maior é que muitas vezes o trabalho de desenvolver as regras, pensar como o negócio vai funcionar(não só tecnologicamente, mas também administrativamente) é responsabilidade do analista de sistemas. Como não somos mágicos e não conseguimos prever o futuro, uma boa dica é desenvolver incrementalmente, com base em alguma metodologia ágil. O sistema vai sendo desenvolvido e o cliente vai gerando feedback, assim é mais simpels para os desenvolvedores modificarem rapidamente o sistema, para ue o mesmo qagregue maior valor ao negócio.
Tratando-se do desenvolvimento web, muitas agências e empresas de desenvolvimento web não possuem uma pessoa com o conhecimento de analista(engenheiro de software), particularmente eu acho isso um problema, pois nem sempre se desenvolve sitesinhos/sisteminhas simples, às vezes nos deparamos com a necessidade de desenvolver sistemas mais complexos, onde o desenvolvedor é mais exigido. Como nem tudo nessa vida são flores, temos que chamar essa responsabilidade para nós, mesmo sendo apenas programadores temos que desenvolver tal conhecimento, pesquisando na internet, perguntando para amigos, perguntando para professores e principalmente para usuários de sistemas similares. Outro fator principal é estudar engenharia de software, após um tempo de experiência no desenvolvimento de sistemas é natural que as regras se tornem mais simples e cotidianas.
Um exemplo de uma regra de negócio bem simples e específa de um sistema de e-commerce seria por exemplo:
- se o cliente realizar uma compra com valor superior a X reais, o sistema automaticamente efetua um desconto de Y% e desconta o valor do frete.
esta regra poderia até estar ligada com CRM por exemplo.
Fica claro que muitas questões administrativas são de responsabilidade do desenvolvedor, seja um analista de sistemas ou programador, pensando bem acabamos virando consultores da empresa na parte administrativa, isso está totalmente ligado com o desenvolvimento de sistemas de informação. Se quisermos ser bons profissionais, teremos que saber sobre administração de empresas, contabilidade, questões tributárias etc. e não só sobre tecnologia.
Para saber mais leia: O Papel do Analista de Sistemas
Posts relacionados:
- O papel do analista de sistemas
- Analista de Sistema Sênior
- Vaga para Analista de Sistemas
- Paradigma da Orientação a Objetos
- Vaga Analista de sistemas no Rio de Janeiro
Tags: analista de sistema, analista de sistemas, lucas renan, o papel do analista de sistemas, programador, regras de negocio
Postado em sábado, março 14th, 2009 at 20:42 na categoria Dicas. Siga o RSS 2.0 feed. You can leave a response, or trackback from your own site.
23/03/2009 as 21:28
Preciso de um programador php urgente. Se puder me ajudar, entre em contato barbara.castro@atalhocomunicacao.com.br
Obrigada.
15/03/2010 as 11:34
Parabéns!!
9/07/2010 as 10:50
Como voce disse, só com tempo experiencia e muito trabalho (um bom curso tambem ajuda), conseguiremos entender mais sobre regras de negócios, pois cada empresa trabalha de um forma diferente, mesmo sendo de um mesmo seguimento.
Um abraço e parabens pelo artigo.
20/07/2011 as 17:39
Muitas empresas carecem mesmo de um pensar sobre o próprio negócio no que toca a ter rotinas mais eficientes e que funcionam. Ou ainda pior acontece, na maioria das pequenas empresas as coisas são feitas no empirismo, o mais urgente, do jeito que dá. É um atraso, realmente.
Mas tenho a discordar do último parágrafo. Penso que se o analista de software souber muito ou mesmo um pouco de administração ou de rotinas administrativas, vai ajudar no seu trabalho no momento de traduzir as regras do negócio no papel e, depois, em código, com certeza, mas de forma nenhuma cabe ao analista a responsabilidade de “ajeitar a casa” da administração de uma empresa, mesmo que tenha condições técnicas e de formação (por ter feito outra faculdade, na área administrativa).
Não se esqueçam, cada macaco no seu galho, um analista ou desenvolvedor de software cabe apenas saber traduzir as rotinas para um programa, pode até palpitar, mas não ele criar soluções para os “buracos negros” administrativos.
E não é um software salvador que vai “ajeitar” a casa, tapando buracos administrativos. Todo programa que vi sendo empurrado goela abaixo de alguém com rotinas implantadas que não existiam na vida da empresa, mesmo com o fim de ajudar a tornar a empresa mais eficiente, não funcionou, não pegou. Solução de cima para baixo não funciona.
Da mesma forma um excelente programador visual ou designer, que manja muito de Flash e CSS, é um craque nessa área, não é de bom senso exigir que ele aprenda uma linguagem de programação ou faça um curso de Engenharia de Software para dar uma solução de um projeto web completo para um cliente.
Você como analista ou desenvolvedor aceitaria a ideia que um artista (webdesigner) precise fazer um curso de PHP para atender bem o cliente, como alguns propagandeam por aí? Ou você mesmo se sentiria à vontade criando soluções de layout, com escolha de fontes, cores, animações, etc? São duas areas bem distintas de formação e habilidades, mas complementares para um grande projeto web. Para ser um bom webdeveloper, não se consegue só com um curso de uma linguagem de programação, você sabe disso, e para ser um bom webdeveloper não se precisa ser um webdesigner.
Fazendo a mesma comparação, um bom analista de sistemas não tem obrigação nenhuma de saber administração para o caso de, se precisasse, antes “ajeitasse a casa” do cliente. Que o cliente ajeite a casa com um especialista, antes de contratar um analista de sistemas.
Cada um fazendo bem aquilo que sabe é melhor para todo o mundo, principalmente para o cliente.
25/11/2011 as 9:42
Olá pessoal.
O artigo publicado está ótimo, mas desculpem, não aguento comentários como o do sr. Geraldo e sinto-me na obrigação de colocar um ponto de vista contrário.
O analista de sistemas e/ou programador realmente não tem que ser um especialista em contabilidade, tributos, administração etc, mas o fato é muuuuuuitas vezes mais fácil para o desenvolvidor quando ele conhece ou domina o negócio em si, pois, quando lê as regras, os diagramas de atividades e casos de uso, conseguirá claramente identificar pontos de deficiência ou ainda mais, pode aperfeiçoar itens que futuramente podem ser pontos flexíveis e passíveis de erros.
Tenho a experiência de analista de sistemas e de negócios, não fui programadora propriamente dita, mas aprendi com um cara incrível, um Analista de Sistemas do mais alto gabarito no mercado, ainda que seu nome não seja divulgado na “roda”, o sr. Cláudio Trafaniuc.
O cara conseguia agregar valor em tudo que ele batia o olho.
É maravilhoso quando se tem como “professor” um profissional que entende que não somente deve-se ficar no seu mundindo e não aprender o que está à sua volta.
Eu aprendi e continuo aprendendo a cada dia como analista de negócios e de sistemas e falo para meus colegas programadores, não basta ser um bom programador, leitor de regras e diagramas, mas é importante se conhecer o negócio para o qual se programa, assim sua aplicação será eficiente e eficaz, atendendo não apenas os requisitos básicos, mas cercando o máximo possível as possibilidades de falhas e evidênciando sua qualidade no software, conforme sua aplicação for sendo utilizada pelos usuários.