O eSocial realmente foi mal desenvolvido?

Em meio a uma enxurrada de críticas e opiniões que colocam em xeque a qualidade empregada no desenvolvimento do novo sistema do governo federal, precisamos ter um olhar crítico sobre os fatos.

A aproximadamente 30 anos atrás (1983) o primeiro caixa eletrônico era inaugurado dentro de uma agência em território brasileiro e com esta novidade um pequeno conjuntinho de palavras em nosso vocabulário ganhava mais força: “fora do ar”. Consigo me lembrar de familiares tentando insistentemente realizar um simples saque ou extrato sem ter sucesso ou outra saída. Tentar outra agência não resolvia o problema pois geralmente a falha advinha dos mais “básicos” mecanismos gerando efeito em cadeia de proporções nacionais.

Fonte: Acervo Estadão (http://acervo.estadao.com.br/pagina/#!/19830414-33159-nac-0015-999-15-not)

Desde então, nossa relação com os erros gerados por sistemas computacionais tem se estreitado e as tentativas de adivinhar o problema que ocorre por trás das mensagens vem se tornando quase uma ciência de domínio comum — um dos produtos finais disso é uma enxurrada de “achismos” e críticas que vemos crescentemente nas mídias e no “boca a boca” diário.

Mas como a pauta não é esta, vamos falar do eSocial.

Antes de tratarmos qualquer tema, deixo claro que meu intuito não é criticar ou colocar em xeque qualquer prática, equipe ou tecnologia utilizada. Pretendo apenas com uma visão de desenvolvedor (pessoal) comentar pontos encontrados durante minha navegação no sistema eSocial.


Plataforma utilizada?

Utilizando a extensão Wappalyzer para o Google Chrome (navegador utilizado durante os testes), vamos discutir as tecnologias e plataformas utilizadas atualmente no eSocial.

Windows Server 2012: considerando que a última distribuição comercial liberada pela Microsoft para o Windows Server é a 2012, não podemos apontar o uso de sistema operacional defasado. O único ponto em que poderia recair nossas dúvidas seria qual a versão utilizada, dentre: Foundation, Essentials, Standard, Datacenter. Cada uma dessas opções impõe restrições que devem sempre ser analisadas. Como não tenho acesso ao servidor utilizado (ainda bem) não tenho nada mais a comentar por aqui.

IIS 8.5: apesar de termos o IIS 10 já publicado pela Microsoft a última versão que temos a disposição é a Express. Esta versão (10) não é desenhada para aplicações em produção e por isto devemos adicionar mais um ponto para o sistema do eSocial que está utilizando mais uma versão recente e estável, a 8.5.

Microsoft ASP.NET 4.0.30319: talvez aqui sim encontremos um pouco de defasagem. A versão utilizada atualmente pelo eSocial foi lançada pela Microsoft em Abril de 2010 e já sofreu atualizações — para termos um parâmetro, a última versão (4.6) foi lançada em Julho de 2015. Considerando o bom suporte entre atualizações de versões desde os últimos frameworks liberados pela Microsoft, uma justificativa para o não uso da versão mais atual poderiam ser componentes antigos ainda sendo utilizados e sem suporte as novas versões do ASP.NET. Poderia caber aqui uma atualização pela equipe de desenvolvimento.

Banco de dados: quanto ao banco de dados utilizado não tenho nada a declarar pois não tenho acesso a este nível de informação com o tipo de acesso que tenho — usuário comum como todo contribuinte.

Se você chegou até aqui e não entendeu bem como tudo funciona e onde cada parte acima se encaixa, imagine que para que um site abra no seu navegador, um servidor deverá estar ligado utilizando sistema operacional determinado (neste caso Windows Server ) para receber sua requisição e dentro deste servidor um determinado "programa" chamado Servidor Web (neste caso o IIS) deverá estar aberto para tratar esta chamada, processar o que foi programado para o site utilizando determinada linguagem / plataforma (neste caso ASP.NET) e gerar a saída que você visualiza em sua tela. Algo mais o menos assim:

Fonte: http://cotidiano.soeirosantos.com.br/2013/07/26/guiawebdev-entendendo-o-desenvolvimento-web/

Diferentemente do que imaginava ao começar a analisar o sistema do eSocial, a plataforma utilizada para o desenvolvimento não foi a que estamos acostumados a ver em uso pelos governos em geral, o JAVA. Em contrapartida encontrei outra plataforma profissional e robusta sendo utilizada — a famosa "dobradinha" da Microsoft: Windows, IIS e .NET. E antes que más línguas comentem de maneira fervorosa contra o uso desta plataforma, encontramos hoje no mercado uma série de serviços e grandes players que utilizam esta mesma combinação e com muito sucesso.


Em resumo, acredito que o ecossistema para um bom trabalho foi disponibilizado para este projeto e não podemos encontrar neste aspecto um problema grave de escolha de tecnologia.

O que não podemos afirmar ou discutir sem mais informações (que não temos) são os recursos físicos disponibilizados para estes servidores — número de processadores, memória, discos, cache em SSD etc. Fator que pode ser decisivo para um bom funcionamento.

Agora que falamos um pouco de plataforma e infraestrutura vamos a um pouco de código e por menores relacionados ao desenvolvimento.

Detalhes que saltam os olhos

É intrínseco ao analisar um site, abrirmos o seu código fonte para ver o HTML, CSS, JS e dinâmicas utilizadas em sua montagem — como se fosse um mecânico dando uma geral no seu carro. Durante estas voltas pelos códigos fontes do eSocial e observando aspectos gerais, alguns poucos pontos foram encontrados:

Comentários misturados ao HTML: quando temos marcações complexas dentro de um site ou dinâmicas que devem ser bem apontadas, é rotineiro que deixemos alguns comentários próximos até mesmo para auxiliar nosso desenvolvimento em equipe. Porém, estes comentários devem ser regidos por alguns padrões e cuidados. Vejamos abaixo alguns tipos de comentários encontrados:

Neste caso temos o nome de um dos membros e a data de criação do componente que está sendo utilizado. Apesar de parecer inofensivo algumas informações podem ser suprimidas por quesitos de segurança
Neste caso temos sim um problema mais grave. Durante um projeto geralmente precisamos desabilitar uma opção de menu ou tela durante o andar da carruagem. Porém suprimir da visualização mas manter a referência em código não é uma boa prática. Se tentarmos acessar o link comentado, ele ainda existe e pode ser acessado.

Considerando que temos formas automatizadas de retirar estes comentários tanto dos arquivos HTML, quanto JS, acredito que este cuidado poderia ter sido tomado — exemplos utilizando GULP podem ser encontrados facilmente na internet.

Emissor de certificado não confiável: quando vemos especialistas em nossas televisões falando sobre o famoso "cadeadinho" que as páginas seguras devem exibir estamos falando do certificado SSL. Um certificado para ser reconhecido como seguro, deve ter sido emitido por um órgão confiável. Me estranha muito o governo federal lançar uma plataforma de amplo uso nacional e com um certificado sem este pré-requisito.

Entendo que este certificado é emitido pelo governo federal e que por este motivo a segurança está garantida. Mas realmente não consigo entender o porque de não utilizar instituições pagas que emitiriam o certificado e evitariam uma mensagem tão negativa em relação a segurança.


Com o objetivo de encontrar impedimentos de uso do sistema eSocial, somaria pontos positivos no desenvolvimento visto que novamente nenhum detalhe discrepante foi encontrado analisando códigos e chamadas ao servidor.

Vamos falar agora de experiência do usuário?

Devemos pensar na experiência do usuário durante um erro

O que não faltam na internet são relatos de usuários que tentaram acessar a plataforma eSocial ou emitir suas guias e não conseguiram sucesso terminando em uma mensagem de erro. Vamos analisar algumas delas para entender melhor o que estava acontecendo:

Sessão expirada: talvez o maior erro aqui tenha sido a falha de comunicação e não uma falha de sistema. Como caráter de segurança o sistema eSocial após 30 minutos logado no site, emite esta mensagem abaixo informando o usuário para que se autentique novamente. Mas o que seria sessão? Expirar? Por que não optar por uma mensagem mais amigável: "Seu usuário está autenticado a mais de 30 minutos, para sua segurança informe novamente seus dados de acesso" ?

Fonte: G1, Globo: http://g1.globo.com/economia/noticia/2015/11/3-dias-do-prazo-final-patroes-relatam-problemas-com-esocial.html

Erro interno: penso que não há pior mensagem de erro do que a abstrata — sem detalhe algum do que está acontecendo ou do que devemos fazer. Neste tipo de erro temos sim uma falha de sistema e também uma completa falta de orientação ao usuário do eSocial. Por que não adicionar pelo menos um telefone de contato ou um mínimo detalhe do que ocorreu?

Fonte: G1, Globo: http://g1.globo.com/economia/noticia/2015/11/3-dias-do-prazo-final-patroes-relatam-problemas-com-esocial.html
Aqui mais um exemplo. Como faço então para reabri-la? Fonte: G1, Globo: http://g1.globo.com/economia/noticia/2015/11/3-dias-do-prazo-final-patroes-relatam-problemas-com-esocial.html

Tickets ininteligíveis: acredito fortemente que o rastreio de um erro ocorrido com um usuário é fundamental para dar o tratamento personalizado que ele merece e até mesmo para mapear uma determinada rotina ou fluxo que possa existir problema. Mas exigir que o cliente anote determinados tipos de código não parece de muita ajuda e sem uma orientação como o número de telefone para contato, torna-se tudo pior ainda.

http://g1.globo.com/economia/noticia/2015/11/3-dias-do-prazo-final-patroes-relatam-problemas-com-esocial.html
http://g1.globo.com/economia/noticia/2015/11/3-dias-do-prazo-final-patroes-relatam-problemas-com-esocial.html

Se analisarmos o público que utiliza e utilizará o eSocial, veremos uma grande heterogeneidade de idades, acesso a internet e conhecimento prévio de leis trabalhistas. O cuidado então com a navegabilidade e com as orientações ao usuário é fundamental e parece ter sido esquecido em alguns pontos do sistema.

No geral a simplicidade está presente na navegabilidade pelo eSocial e é um ponto positivo (já que evita gerar dúvidas), porém devido a densidade de campos a serem preenchidos (mesmo que utilizando guias de progresso) aliados a erros não esclarecedores, tornam a tarefa de realizar um novo cadastro e emissão de uma guia de pagamento um trabalho árduo.

A equipe responsável deveria ter tomado maior cuidado com a comunicação pensando nos diversos públicos utilizadores do eSocial.

Agora que passamos por alguns pontos analisados, vamos caminhando para as conclusões!

Tempo!

O tempo que você gosta de perder não é tempo perdido. — Bertrand Russell.

Buscamos cada vez mais realizar nossas obrigações de maneira rápida e objetiva, uma busca incessante por "não perder tempo" com nada que não seja essencial ou prazeroso. Isto se reflete em tudo que fazemos e especialmente no que fornecemos como prestadores de serviços.

As tecnologias não ficariam de forma alguma de fora desta nova onda e na verdade se tornaram um grande aliado no ganho de tempo e aumento de nossa produtividade. O detalhe aqui é que as tecnologias são vistas como ferramentas infalíveis na otimização de processos e o contrário não pode ser aceitável! Onde já se viu perder tempo utilizando algo tecnológico? Tudo deveria funcionar perfeitamente e rapidamente.

Que falhas ocorreram no sistema eSocial é inegável. Indisponibilidade de acesso, falha ao localizar CEPs com sucesso, campos que não funcionavam como esperado e principalmente a lentidão foram os pontos altos de muitos que passaram pelo seu caminho. O que ocorre aqui é que estávamos lidando com dados contábeis, dados que poderiam gerar multas e demais implicações jurídicas caso não funcionassem bem — um stress que intensifica qualquer falha.

As falhas e correções de sistemas permeiam o mundo da computação desde os cartões perfurados em que precisávamos esperar dias para saber se sequer um programa havia compilado. Este tópico não é novidade e todos que estão na área da computação sabem que um sistema em produção será arduamente massacrado por milhares e milhares de testes que sequer as vezes foram imaginados (mas que os usuários fazem).

Por isto temos a obrigação de tornar este processo de correção e acima de tudo de resposta rápida algo tão natural quanto o aparecimento de erros em um sistema. Não podemos tentar tapar o sol com a peneira e dizer que está tudo bem quando sabemos que o algo está funcionando mal e talvez aqui tenha sido o maior o erro da equipe de gerenciamento do eSocial.

Considerando termos visto que tecnologias robustas foram utilizadas durante o desenvolvimento do projeto, que absurdos não foram encontrados nos vestígios que tínhamos acesso, só consigo imaginar que o problema se encontrou no mal dimensionamento de uso esperado na plataforma eSocial — a famosa "sobrecarga".

Um sistema a ser utilizado (obrigado por lei) por todos os empregadores de trabalhadores domésticos do território nacional, com prazo curto e que envolveria o preenchimento de campos complexos e consultas a bases de dados de vários órgãos federais simultaneamente, deveria ter a devida atenção — mesmo que fosse após os problemas começarem.

O certo seria que testes de carga fossem realizados com afinco durante meses que antecedessem a entrada em produção. Mas a partir do momento que o problema se deu com milhões de usuários interagindo com a plataforma, uma resposta imediata era exigida. Convenhamos que falta de recursos não seria um problema para o governo federal.

Tecnologias de ponta e escolha de plataformas robustas não "ganham campeonato" sozinhas se os recursos necessários para sua execução não forem monitorados em tempo real e as medidas necessárias também sejam tomadas em tempo hábil.

Deveríamos ter contado com um contingenciamento e acionamento de recursos extras durante os picos de uso da plataforma eSocial.

O que aprendemos com isto?

Como desenvolvedores devemos aprender a mensurar o tamanho de nossos projetos, públicos que serão atingidos e principalmente a nossa comunicação com cada um deles. Se estamos prestando um serviço devemos trabalhar para nosso cliente e não transmitir a sensação de que ele está trabalhando para nós.

Devemos constantemente aprender com os erros passados e utilizar estes conhecimentos para evitar recaídas no futuro.

Observação: reforço que nenhum acesso especial foi fornecido a mim para montagem deste post e que não pretendendo defender lado algum neste debate e sim somente expor pontos que possam ser úteis como aprendizado para futuros projetos de T.I.

Este post foi escrito por Matthaus Schall Lopez

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.