Dialética do software corporativo

Durante a implementação de uma série de regras de negócio ocorreu-me que seria muito mais interessante desenvolver software como uma ferramenta: o usuário que decida como usá-lo e o usuário que decida quais são as formas válidas de usá-lo.

Os usuários já se permitem pequenas transgressões como escrever nomes próprios em caixa alta e sem acentos. Na língua portuguesa, só há uma maneira de escrever João da Silva (exatamente essa). Tanto "joao da silva" como "JOAO DA SILVA" ou "XOAU d4 $y)v4" estão errados. Mas como não é prático implementar um conjunto de regras para validar os nomes próprios, essa tarefa raramente é ensaiada, embora frequentemente seja contemplada (principalmente quando alguém quer um relatório esteticamente aceitável).

Esse objetivo pode ser abandonado porque é claramente inatingível, mas por que o software continua sendo escrito sob a ilusão de que é possível (e desejável) limitar o usuário apenas a interações válidas (conforme o arcabouço vigente no momento de sua concepção)?

No momento em que o ambiente do software muda (muitas vezes antes que ele entre em produção), as regras de negócio precisam ser reavaliadas e recodificadas.

Creio que a resposta esteja na dinâmica das empresas. A criação de regras rígidas para a operação de sistemas está assentada sobre as disputas de poder. O analista de sistemas não tenta apenas sintetizar as regras de negócio, ele também frequentemente testemunha o processo de disputa de poder no qual duas ou mais partes tentam impor suas visões de mundo não com o intuito de produzir o melhor para a corporação, mas para validar e avançar seu poder.

Pode-se até dizer que alguns softwares incorporam as contradições internas de suas respectivas corporações e que num momento de realinhamento de forças eles serão, inevitavelmente, redesenhados.

Além disso, existe a falta de confiança explícita no proletariado da empresa. Já se espera que o usuário final vá subverter as regras usando o sistema de forma errônea e que, como acontece com frequência, a culpa será atribuida ao sistema. E isso é visto como natural, mesmo quando for provado que o usuário agiu de má-fé (ninguém culpa o fabricante de martelos quando o marceneiro erra o prego e quebra algo). Por isso, o próprio proletariado abdica de assumir responsabilidade pelo negócio e o delega todo ao sistema (já tratam o trabalhador com desconfiança desde o início e ele sabe igualmente que pode tercerizar qualquer culpa ao software).

Ocorre também que um proletário iluminado tente impor novas regras como forma de abraçar o sistema, tomar posse dele e do poder que ele representa. Já testemunhei, por exemplo, uma tentativa de eliminar colunas desnecessárias de um relatório que, no entanto, eram importantes para outras pessoas. Se o relatório fosse visto apenas como uma ferramenta, as colunas extras poderiam muito bem ser ignoradas, mas a posse do relatório servia também como delimitação de território. Evidentemente, esse tipo de atitude representa uma traição do trabalhador à sua própria classe, numa tentativa de emular a classe dominante e, quem sabe, um dia ser aceito nela.

As metodologias de gerência de projetos apontam como importante a definição dos stakeholders, porque as empresas de software já identificaram o problema dos conflitos internos e de como eles atrapalham o processo de análise. Para a fábrica de software, não é realmente importante qual regra de negócio será implementada, desde que algum representante do cliente aceite a responsabilidade de assinar o cheque.

O que precisamos agora é introduzir o marxismo nos cursos de informática.