De força ao Usuário com o Drools parte 1
Quem já não ouviu falar mal da TI? Provavelmente você já trabalhou em um empresa em que os outros setores não olham a TI com bons olhos. Talvez por que ali podem estar os salários mal altos da organização, salvo a alta diretoria. Mas o problema não é nem o valor que um profissional de TI chega a receber mas sim o que ele faz para merecer o mesmo.
Não venho neste post para falar de gestão de competências para isto deixo com meu amigo Cássio Dias. Mas vi falar em o que poderíamos fazer para dar mais poder ao usuário. Uma das primeiras ações já deve estar bem clara em sua cabeça não? Desenvolvimento iterativo incremental utilizando práticas e métodos. Mas só isso (Não que seja pouco ou fácil) não será o suficiente.
Parametrização?
Para resolver esse problema você que usar outro paradigma, o paradigma que estou falando é o BRMS o qual o Drools implementa.
Business Rules Management System?
Consiste em desenvolver, manter, versionar, testar, organizar e fazer o deploy de regras de negocio. O Drools oferece uma excelente solução neste sentido, na minha modesta opinião o melhor do mercado nesse sentido. Através do Drools podemos dar certos níveis de decisão para o usuário, que não é burro! É um grande erro tratar o usuário como ignorante! Logo com o Drools ele poderá mudar certos aspectos de comportamento do sistema tem ter que pedir a TI.
Assim vamos dar poder ao usuário. Esse poder pode ser obtido através de regras escritas com os objetos de domínio aplicando um bom DDD, ou através de DSLs escritas em um bom português com a linguagem do usuário. Ou até mesmo com uma boa planilha MS Excel.
Não venho neste post para falar de gestão de competências para isto deixo com meu amigo Cássio Dias. Mas vi falar em o que poderíamos fazer para dar mais poder ao usuário. Uma das primeiras ações já deve estar bem clara em sua cabeça não? Desenvolvimento iterativo incremental utilizando práticas e métodos. Mas só isso (Não que seja pouco ou fácil) não será o suficiente.
Parametrização?
A Luz no fim do Túnel?
Talvez. Todos querem um sistema parametrizável. Mas toda parametrizarão tem um custo e parametrizar todo o sistema não é viável e muito menos efetivo, por que tem coisas que mudam tão pouco que o retorno não pagaria o esforço, ainda mais por que as coisas mudam.
Uma vez que você ache "o que" parametrizar você terá que se preocupar com o "como". Essa também não é uma tarefa fácil. Muitas empresas adotam a solução de parametrização mais simples que é a do "Cada caso é um caso". Nesse modelo normalmente alguns tabelas são expostas através de telas de parametrizações. As vezes isso se mistura com os CRUDs.
Por que não parametrizar com Telas?
Você pode optar por essa abordagem. Em alguns casos ela será o bastante, em outro não. Por que esse tipo de abordagem tem problemas com flexibilidade. E qualquer mudança por mais simples que seja pode gerar uma nova demanda de desenvolvimento.
Qual o problema do Desenvolvimento?
Desenvolvedores planejando
Essa pode ser a solução para seus problemas. Qual o problema disso? Os analistas serão demitidos? Os usuário ganham a sua carta de auforia da TI? Não para os 2!Talvez. Todos querem um sistema parametrizável. Mas toda parametrizarão tem um custo e parametrizar todo o sistema não é viável e muito menos efetivo, por que tem coisas que mudam tão pouco que o retorno não pagaria o esforço, ainda mais por que as coisas mudam.
Uma vez que você ache "o que" parametrizar você terá que se preocupar com o "como". Essa também não é uma tarefa fácil. Muitas empresas adotam a solução de parametrização mais simples que é a do "Cada caso é um caso". Nesse modelo normalmente alguns tabelas são expostas através de telas de parametrizações. As vezes isso se mistura com os CRUDs.
Por que não parametrizar com Telas?
Você pode optar por essa abordagem. Em alguns casos ela será o bastante, em outro não. Por que esse tipo de abordagem tem problemas com flexibilidade. E qualquer mudança por mais simples que seja pode gerar uma nova demanda de desenvolvimento.
Qual o problema do Desenvolvimento?
Desenvolvedores planejando
A principio nem um. Mas desenvolvedores são mais caros do que um profissional que está na linha de produção e que conhece melhor o negocio. Certas coisas o usuário não tem vez mesmo que ele quisesse não poderia resolver. Outras ele poderia resolver sem passar pelo time de desenvolvimento e assim poupar dinheiro da organização e deixar que a equipe de desenvolvimento se foque no que realmente valhe a pena, ou que se pague!
Níveis de Decisão?
Essa é uma boa. Você precisa dar certos níveis de decisão ao usuário. Um sistema mais parametrizável por significar mais decisões para o usuário. Isso não necessariamente significa mais complexidade. Por que a complexidade vai depender basicamente da própria complexidade inerente do problema e da complexidade que você der na sua solução.
Você precisa dar ao usuário certos níveis de decisão, ou seja, nem tudo tem que entrar com uma solicitação de desenvolvimento. Ok. Já faço isso, tenho telas que o usuário escolhe como vão ser certas coisas no sistema. O problema é que esse tipo de abordagem pode ser custosa e nem sempre fica clara para o usuário. Estudos com experiências do usuário e usabilidade podem dar resultado nesse parte mas mesmo assim o custo é alto.
Por que não expor as regras de negócio?
Níveis de Decisão?
Essa é uma boa. Você precisa dar certos níveis de decisão ao usuário. Um sistema mais parametrizável por significar mais decisões para o usuário. Isso não necessariamente significa mais complexidade. Por que a complexidade vai depender basicamente da própria complexidade inerente do problema e da complexidade que você der na sua solução.
Você precisa dar ao usuário certos níveis de decisão, ou seja, nem tudo tem que entrar com uma solicitação de desenvolvimento. Ok. Já faço isso, tenho telas que o usuário escolhe como vão ser certas coisas no sistema. O problema é que esse tipo de abordagem pode ser custosa e nem sempre fica clara para o usuário. Estudos com experiências do usuário e usabilidade podem dar resultado nesse parte mas mesmo assim o custo é alto.
Por que não expor as regras de negócio?
Para resolver esse problema você que usar outro paradigma, o paradigma que estou falando é o BRMS o qual o Drools implementa.
Business Rules Management System?
Consiste em desenvolver, manter, versionar, testar, organizar e fazer o deploy de regras de negocio. O Drools oferece uma excelente solução neste sentido, na minha modesta opinião o melhor do mercado nesse sentido. Através do Drools podemos dar certos níveis de decisão para o usuário, que não é burro! É um grande erro tratar o usuário como ignorante! Logo com o Drools ele poderá mudar certos aspectos de comportamento do sistema tem ter que pedir a TI.
Assim vamos dar poder ao usuário. Esse poder pode ser obtido através de regras escritas com os objetos de domínio aplicando um bom DDD, ou através de DSLs escritas em um bom português com a linguagem do usuário. Ou até mesmo com uma boa planilha MS Excel.
