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 porque ali podem estar os salários mais 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 artigo para falar de gestão de competências, isto deixo com meu amigo Cássio Dias. Mas vim 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 porque 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. Às 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 outros não. Porque 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 princípio, nenhum. Mas desenvolvedores são mais caros do que um profissional que está na linha de produção e que conhece melhor o negócio. Em certas coisas o usuário não tem vez; mesmo que ele quisesse, não poderia resolver. Em outras, ele poderia resolver sem passar pelo time de desenvolvimento e assim poupar dinheiro da organização, além de deixar que a equipe de desenvolvimento se foque no que realmente valha 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. Porque isso 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 serão 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?

Essa pode ser a solução para seus problemas. Qual o problema disso? Os analistas serão demitidos? Os usuários ganham a sua carta de alforria da TI? Não, para os dois!

Para resolver esse problema você quer 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 negócio. 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 sem 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.