Sistemas, sistemas… quando vamos entende-los?
Então vamos ao segundo post desse blog… Como vcs podem ter notado, estou começando a escrever o meu blog, e como não tenho muito costume nisso, ainda tenho buscado inspiração em outros posts que encontro pelo caminho, acrescentando minha opinião sobre assuntos que estão sendo discutidos…
A bola da vez foi encontrada em um post do Phillip Calçado que trata sobre a existência da famigerada profissão de “analistas de sistemas”, e como essa profissão tem perdido seu valor. Só para deixar claro, concordo em gênero, numero e grau com o que o Phillip disse, e na verdade esse post é para expor mais um lado dessa situação, e explicar o porque da minha concordância.
Eu imagino que agora vcs devem estar pensando que os “sistemas” do título do post fazem referência ao “sistemas” do analista. Na verdade não. Na verdade eles fazem referência aos sistemas que são utilizados para desenvolver software, mais chamados na nossa área de processos, ou metodologias. Eu usei a palavra “sistema”, pq esse é o termo usado pelo William Deming, um dos primeiros escritores que falou sobre a visão sistêmica, tão em voga hoje em dia nos manuais de admistração, e no qual eu também me inspirei para escrever esse post.
A inspiração a qual me refiro eu tirei do livro The New Economics, no qual uma das afirmações feitas pelo autor é que se uma equipe não está fornecendo os resultados esperados, a culpa é sempre do sistema sobre o qual ela está trabalhando, e não dos seus membros.
E o que que isso tem a ver com os analistas de sistema, citados pelo Phillip? No meu ponto de vista, bastante coisa, pq eu acho q a simples existência de analistas de sistemas, é um dos grandes problemas das abordagens tradicionais de desenvolvimento.
Pq isso? Bom, vamos às explicações… Hoje em dia, todo mundo (agilistas ou não) concorda no ponto que os projetos devem ser desenvolvidos da forma mais simples possível, e que grande parte da complexidade do software é colocada nele desnecessariamente, complicando o seu desenvolvimento e principalmente sua manutenção, certo?
Mas agora, como se quer diminuir a complexidade de um projeto, se colocando uma pessoa que trabalhe especificamente para modelar um sistema? Imaginem se vcs fossem analistas de sistemas (talvez alguns o sejam…) e lhes fosse passado um projeto para vcs modelarem. Teria algum sentido vcs modelarem ele com diagramas extremamente simples, do tipo que o programador olha e diz: “Se era para fazer só isso, eu também poderia ter feito..”? Claro que não! Para manter a necessidade de existência do cargo, e até o seu status, todo analista vai propor um design que realmente mostre o seu valor, que realmente o diferencie dos seus colegas programadores, até pq essa e a grande contribuição que eles estão dando como membros da equipe, e tanto faz se aquilo vai ser extremamente dificil de implementar e manter. O melhor é enviar aquele calhamaço de folhas para impor respeito… : )
E ai que entra a sabedoria do Deming. A culpa dos analistas criarem modelos complexos não é deles, e dos gerentes e diretores que estabeleceram um processo de desenvolvimento onde o valor da contribuição que eles dão está baseada (mesmo que subconscientemente) na complexidade do que eles entregam. E esse é um dos pontos onde eu vejo grande vantagem nos métodos ágeis, justamente pq eles colocam sob responsabilidade do desenvolvedor a modelagem do sistema, e esse aí não tem nenhum compromisso com a utilização de padrões requintados, apenas com o funcionamento do software.
Que tal?
