Analista de Sistemas

Quando eu comecei a trabalhar com computação o mercado contratava Digitadores, Programadores e Analistas de Sistemas. Os digitadores só digitavam e os programadores só programavam os sistemas especificados por um “Analista de Sistemas”. Esse era “O Cara”.

Como vocês podem ver a divisão do trabalho e responsabilidades era bem diferente do que temos hoje. Hoje temos umas divisões meio esquisitas tipo “backend” e “frontend” e um eixo, e divisões bem nebulosas como “Júnior”, “Pleno” e “Sênior” em outro eixo. Tem uns caras que correm por fora também: “devops”, “architects”, “leaders”, …

Na mesma época em que comecei a trabalhar também já estava rolando um movimento onde contratavam os “Analistas Programadores”. Um cara que sabia fazer a análise de sistemas e a programação. Obviamente, como vivemos em um sistema capitalista, o salário desse profissional nunca era a soma dos salários de um programador e de um analista. Tipo um programador ‘fullstack’ recebendo salário de ‘front’ ou ‘back’. Precarização nunca foi um assunto novo.

Mas essa introdução toda é só pra falar que quando estudei Processamento de Dados (outro termo que foi caindo em desuso junto com CPD) em uma ETEC eu tinha uma matéria chamada “Análise de Sistemas”.

Naquela época eu já trabalhava com programação então eu matava boa parte das aulas para aperfeiçoar minhas técnicas em coisas importantes como jogar Truco. Com certeza valeu a pena.

Mas as aulas de “Análise de Sistemas” do professor Peccini eu fazia questão de assistir. Queria assistir porque logo nas primeiras aulas ele falou coisas bem intrigantes sobre “Sistemas”.

Uma das coisas que ele disse foi que “Sistemas” não tem uma relação direta com computadores. Sistemas sempre existiram e sempre vão existir. Com computadores ou sem eles.

O trabalho de um analista de sistemas, então, com o perdão da redundância, é analisar esses sistemas e, eventualmente, propor mudanças. Que tipo de mudanças? Mudanças que possam tornar os sistemas mais eficientes ou até mesmo extinguir eles completamente. Automatizar certos sistemas com o uso de computadores é apenas um tipo de mudança em um grande universo de possibilidades.

Ele também falava coisas como “Você não transforma um sistema ruim em um sistema bom colocando computadores e automatizações nele”. Ele falava que fazer isso era só “automatizar a burocracia”.

Temos vários exemplos disso em nossa vida. Basta ir em um cartório e ver quantos computadores eles tem lá dentro.

Naquela época a gente era jovem e adorava ficar de frente para o computador “codando” as coisas. Mas as aulas do Prof. Peccini eram na sala de aula normal. E ele dava coisas em papel pra gente estudar.

Modelagem de Dados

Algumas coisas que o Prof. Peccini ensinou pra gente é modelagem e normalização de tabelas.

Em uma das aulas ele pegou um “talão de pedidos” que ele tinha comprado em uma papelaria e levou para a sala de aula. Ele ia destacando as folhas do talão e entregando para cada um dos alunos da turma.

Depois que cada um de nós tinha uma folha dessas ele disse: quero que vocês criem uma ou mais tabelas no dBase III Plus (outro professor já tinha ensinado isso em outra matéria) para guardar informações de pedidos.

Muitos alunos da turma modelavam apenas uma tabela e repetiam os dados comuns em todos os registros. Não julguem! É um curso onde as pessoas estão aprendendo as coisas. Lembrem que o normal é não saber o certo até que se aprenda.

Eu, como já disse, por já estar trabalhando na área, fiz a minha modelagem certinha (pequeno ajuste aqui e ali). Mas confesso que fazia essas coisas por pura intuição.

O professor então revisou os trabalhos com cada aluno e foi dando as orientações necessárias para cada um deles pensar em melhorias. Ele só dava dicas e fazia perguntas para os alunos. Os próprios alunos acabavam chegando à modelagem mais adequada. Depois desse exercício ele corrigiu tudo e deu notas (boas) pra todo mundo.

A partir daí ele deu algumas aulas com exercícios mais convencionais sobre “normalização” de tabelas e usava sempre os erros iniciais dos alunos para ilustrar cada uma das técnicas de normalização.

As aulas eram incríveis. Melhor que as melhores partidas de Truco que disputei na escola.

Dicionário de Dados

Antigamente os analistas de sistemas produziam muitos documentos sobre… sistemas. Um desses artefatos era o Dicionário de Dados.

Um dicionário de dados servia para dar nomes, tipos, descrição e outras informações sobre entidades, relacionamentos, atributos, propriedades e domínio dos negócios.

Era um troço chato pra cacete de produzir. Mas era um ótimo exercício para “dar nome aos bois”. Servia para desambiguar nomenclaturas e chamar as coisas certas pelos nomes certos.

Ele dizia que se tá difícil achar bons nomes para algo ou se tinha duas coisas diferentes com o mesmo nome isso era um sintoma de problema no sistema.

Ele também falava que dar o mesmo nome para coisas diferentes em contextos ou com perspectivas diferentes era “ok”, mas o dicionário de dados devia deixar explícito esses contextos e perspectivas.

Exemplo disso? A palavra de “Produto” tem significados diferentes para o estoquista, pro operário da linha de montagem, pro profissional do marketing, etc. Em um sistema que envolva todos esses atores é importante mapear todos esses usos e significados.

Recentemente, no trabalho, um amigo citou um outro professor (Prof. Imre Simon da USP). Segundo esse amigo o Prof. Imre havia dito algo como “Um dos grandes problemas da computação é dar nomes diferentes para a mesma coisa e dar o mesmo nome para coisas diferentes” (não encontrei a citação original, então, me perdoem por eventuais equívocos).

Na primeira edição do livro eXtreme Programming do Kent Beck e no livro Domain-Driven Design do Eric Evans também se fala um pouco sobre esse nivelamento de termos usando o conceito de metáforas de sistema (System Metaphor). Isso mostra que comunicar um sistema é um problema bastante antigo mas ainda presente e importante para o nosso trabalho.

Modelagem de Sistemas em Software

Se tem uma coisa que faço bem é modelar sistemas em software. Não consigo explicar porquê e nem tenho plena consciência do que eu faço para executar essa tarefa tão bem. A coisa simplesmente acontece. Acho que é o que chamam de “intuição”.

Não sou infalível e já cometi muitos erros nessa tarefa. Mas na mediana eu tenho um saldo positivo.

Sonho em, algum dia, ter uma consciência maior sobre o processo que acontece no meu cérebro quando estou modelando um software. Gostaria muito de escrever e ensinar isso para outras pessoas igual o Prof. Peccini fazia.

Mas enquanto isso não acontece eu vou falar uma coisa ou duas aqui que eu acho que fazem parte desse conhecimento.

Quando o professor falou que sistemas existem independentemente de computadores ele destravou algum circuito no meu cérebro que me permite observar um sistema funcionando e então partir desse sistema para guiar a minha modelagem. Independentemente de falhas e ineficiências ele é um sistema que já está sendo usado.

Então eu sempre começo a modelar um sistema de software partindo do sistema real. Esse processo inclui a modelagem de dados, processos e o dicionário de dados.

Aí eu lembro que o professor falou que colocar um software que reproduz problemas e ineficiências de um sistema é meramente “automatizar a burocracia”. A imagem de um cartório invade minha mente e eu inicio a busca por problemas, ineficiências e o que eu chamo de “armadilhas de modelagem”.

Quando estamos modelando um sistema de software é bastante comum olhar para outros sistemas similares como referência (benchmark) e é bem comum a gente cair em armadilhas nessa brincadeira. Vou dar um exemplo.

Uma vez (mentira… foram várias) precisei modelar um sistema de gestão de pedidos para um site de e-commerce. Pedidos nascem quando você finaliza sua compra e, geralmente, possuem um workflow que é implementado com uma máquina de estado. Então o pedido transiciona de “novo” para “pago” e para “faturado“, “enviado“, “entregue“, etc. Tem o estado “cancelado” também. Quase todo mundo modela assim e aí vários problemas começam a acontecer.

Você percebe, por exemplo, que a gente não “envia um pedido”. A gente “envia pacotes com produtos pedidos”. Onde o estado “enviado” (e o “entregue”) deveria estar? No pedido? No “pacote”? A solução correta depende muito do significado de cada modelo de negócio. Mas a mensagem aqui é: pare para pensar no que acontece na vida real antes de colocar isso no seu software.

Outro exemplo nesse mesmo sistema: cancelamento. Quando você para pensar na vida real você percebe que um pedido pode ser cancelado a qualquer hora. Pelo código de defesa do consumidor o cliente poderia cancelar esse pedido até 7 dias depois que o produto chegou na casa dele. Então a máquina de estado (bem simplificada) ficaria mais ou menos assim:

Parece certo isso? Não, né? Ah! E as ações para cancelar um pedido variam dependendo da etapa em que ele foi cancelado. Imagine a complexidade disso.

E se a gente quiser implementar o conceito de suspender um pedido sem cancelar (para conversar com o cliente sobre alguma dúvida que ele tenha)?

Você vai modelar um sistema de gestão de pedido e quando olha em volta todo mundo modela mais ou menos desse jeito. É muito fácil cair nessa armadilha. Eu mesmo caí várias vezes.

Talvez, e só talvez, “cancelado” não seja um estado dessa máquina de estado? Será que não poderíamos usar outro workflow/máquina-de-estado para gerenciar suspensões e cancelamentos?

Outra armadilha no mesmo domínio de negócio tem relação com os termos usados para se conversar sobre o sistema. Uma frase como “Vou colocar o produto pra vender no site” pode induzir o analista de sistemas a criar uma entidade Product no site de comércio eletrônico quando na verdade você não tem um produto de verdade lá. O que a gente tem em um site de comércio eletrônico são anúncios de itens (SKUs – Stock Keeping Unit) de um produto (GTIN/EAN/ISBN) produzida por uma marca.

Entendem o problema que a ambiguidade da palavra “produto” pode trazer pra sua análise?

Óbvio que eu caí nessa armadilha inúmeras vezes. Honestamente eu caí nessa armadilha *todas as vezes* que tentei modelar esse software.

Então… esse casos servem para ilustrar, na prática, algo que acontece intuitivamente no processo de análise de sistemas que eu faço. Como não consigo fundamentar essas explicações eu espero que os exemplos ajudem vocês de algum modo.

É certo que tem mais técnicas e processos que eu uso e conforme eu for tomando consciência deles vou tentar trazer aqui pra vocês.