Este post faz parte de uma série de pesquisas para possíveis melhorias no acompanhamento de proposições legislativas. Embora nossa meta seja submeter o projeto ao LABHacker (Laboratório de Inovação Cidadã da Câmara dos Deputados), trata-se atualmente de uma iniciativa independente. As informações foram coletadas do site Dados Abertos e do Portal da Câmara, sendo utilizadas aqui em conformidade com os seus termos de uso.
No ano passado, colaboramos com o STF para que fosse elaborada uma nova versão da Constituição Anotada. Esse projeto teve muitas peculiaridades, especialmente em razão do volume de informações: a Constituição é uma norma longa e cada fragmento poderia ter diversos julgados vinculados a ele.
O resultado pode ser conhecido no site oficial do Supremo: https://constituicao.stf.jus.br/
Para chegar até esse ponto, solucionamos muitas limitações técnicas. Além disso, criamos diversas funcionalidades, todas voltadas para a produtividade pessoal: busca exata, busca aproximada, buscas recentes, buscas favoritas, anotações privadas, anotações de grupo, etc. Assim, nos concentramos em potencializar produtividade do leitor, sem promover a interação entre eles e as instituições.
O manual das funcionalidades pode ser consultado da página mantida pelo Grupo de Pesquisa: http://cfa.direitotec.com.br/
Apesar de todos os avanços, tínhamos um projeto ainda maior, consistente e transpor para diversas leis a mesma experiência que criamos para consulta de uma lei apenas. Ou seja, solucionamos o problema de consulta a uma lei, mas nos faltava resolver o mesmo problema para um acervo de leis (o que se conhece por vade mecum).
E para fazer isso foi necessário repensar a forma pela qual faríamos a inclusão e a atualização do acervo de normas. Isso ocorreu, pois se revelou bastante trabalhoso o processo de transformação do texto comum de uma lei (sem organização hierárquica) em um texto estruturado. Uma tarefa que, a princípio, parecia singela, veio a se mostrar muito complexa ao ser tratada em escala.
Podemos então recolocar dessa forma: a organização das leis de uma forma mais moderna não é um problema de organização, e sim um problema de escala. Esse problema de escala surge na alimentação inicial das leis em uma base de dados e, em seguida, na sua manutenção, tendo em vista que as normas são um conteúdo em constante evolução.
Isso faz com que a abordagem à lei como um documento (que é a visão prevalecente) imponha uma série de limitações. Partir da lei como um documento, por mais organizados que sejam os metadados, é uma abordagem que inviabilizaria o nosso plano. Por isso, resolvemos investir na estruturação do conteúdo, desenvolvendo diversas versões de um parser capaz de hierarquizar a lei com um clique. Mas isso não seria suficiente.
Passados alguns anos, resolvemos substituir essa abordagem, colocando um "human in the loop", no sentido de que decidimos criar um papel de editor, cuja função seria corrigir as desconformidades residuais da estrutura legal em um arquivo de texto (.txt). Com isso, ganhamos a agilidade necessária e nosso sistema deixou de ser totalmente hermético e dependente da qualidade do parser. O parser precisa ser bom, precisa ser maduro. Ainda assim, será insuficiente, considerando a variabilidade (e desconformidades) das fontes de dados.
Como se nota, na nossa visão, a solução do problema não está apenas no desenvolvimento de um aplicativo, mas na gestão de um projeto. Esse projeto demanda a organização de papéis para usuários (com a especialização do editor, por exemplo, responsável por corrigir detalhes na hierarquização da lei). A equipe de desenvolvimento trabalha recebendo as demandas do editor, bem como propondo soluções para maior agilidade do seu trabalho. Não se trata, nesse sentido, de uma abordagem monolítica/estática - e sim de um fluxo de trabalho.
Seguindo essa abordagem, a ferramenta de edição gera uma série de notificações ao editor, sugerindo a verificação em alguns pontos da lei: quebra de numeração, tamanho atípico do fragmento, etc. Construímos um "dashboard" para validação de cada lei, cujo conteúdo é disponibilizado via nuvem, mas sempre em sincronia com a versão local do arquivo .txt. Em outras palavras, existe um domínio local sobre o conteúdo, em um formato aberto, sem qualquer limitação de edição. Ao mesmo tempo, a hierarquização ocorre "on the fly", interagindo com os arquivos em sincronia.
Pode parecer um fluxo de trabalho desproporcional ao objetivo, mas a verdade é que elaborar e manter um vade mecum atualizado não é tarefa trivial. No nosso modo de ver, é uma potencial armadilha a tentativa de resolver o problema de leitura e anotação das leis com um só golpe. Após muito refletir, resolvemos encarar o assunto de outra forma, transformando radicalmente o papel do editor, sem contudo extinguir a sua função. Nós criamos uma espécie de exoesqueleto para editor, de modo que ele seja auxiliado pela máquina naquilo que importa.
Em outras palavras, deixamos a força bruta para a máquina, ao mesmo tempo em que postergamos a necessidade de enfrentar o backlog. Afinal, nem todas as demandas levantadas pelo editor são solucionadas pela equipe de desenvolvimento, pois somente os defeitos replicáveis é que interessam. Assim, o editor se torna autônomo e apenas sugere melhorias ao desenvolvimento, sem se tornar dependente dele. Isso, por consequência, desonera o desenvolvimento, tornando o projeto mais barato e mais rápido.
O resultado final - aderente ao escopo da demo - é que conseguimos realizar projetos com agilidade, demonstrando desde o início a escalabilidade da proposta. A mobilização é rápida, assim como os testes iniciais. Isso garante a utilidade do projeto para o usuário, pois todos estão sempre em contato, antes que o desenvolvimento se descole da utilidade. Esse é o resumo.
No caso em discussão, o primeiro passo consistiu em baixar o arquivo .doc do Regimento Interno da Câmara dos Deputados. A tarefa seria ainda mais fácil se a fonte fosse uma endereço web, exigindo - para o caso do referido documento - uma leve transformação:
O próprio Word informa que se trata de um documento com 245 páginas e mais de 100 mil palavras. Ao copiar e colar o conteúdo em um editor de "plain text", foram geradas mais de 6 mil linhas.
Segue uma captura do ambiente que foi montado, aguardando o carregamento do arquivo gerado. O vídeo demonstra uma versão populada com duas leis e com a busca funcional:
O próximo passo é carregar o arquivo .txt. No caso, vamos ver, em tempo real, o quanto o editor leva para criar uma nova lei no acervo e o quanto o sistema demora para compilar o Regimento Interno. Em um primeiro momento (aos 55 segundos), a tela informa que o conteúdo está indisponível. Na sequência, já o Regimento Interno é exibido corretamente compilado e indexado, com a busca funcional:
A demo, cujo acervo está em construção e pode variar, pode ser consultada no seguinte endereço: https://app-camara.lexana.com.br/
Obrigado!
PS: Atualmente, o cadastramento de novos usuários e o login social não estão funcionando. Para testar essas funcionalidades por completo, sugerimos visitar a versão da Constituição do STF. Esta demo tem o propósito de demonstrar apenas a agilidade na inclusão de uma lei à plataforma.
