Plenário Fácil

Em 2020, o LAB desenvolveu o projeto Plenário Fácil, em resposta ao seguinte desafio proposto no Planejamento Colaborativo Nós do LAB, de 2019: “Como podemos melhorar a linguagem de comunicação da Câmara com o cidadão?” 

Depois de uma etapa de Design Sprint e a definição de um recorte no desafio, o resultado era no sentido de desenvolver um protótipo de site que permitisse o acompanhamento, em tempo real, das sessões no plenário.

Assim o projeto evoluiu de "linguagem simples" para "Plenário Fácil". O objetivo era que os cidadãos pudessem acompanhar, num mesmo lugar, as fases da sessão de votações; saber facilmente qual era o item da pauta em discussão; além de permitir acesso a resultado de votações e trechos específicos de discursos. 

E, para facilitar a compreensão do processo legislativo, o Plenário Fácil traz uma experiência parecida com a de sites jornalísticos que permitem acompanhar um evento ao vivo, com informações minuto a minuto, e explicações e vídeos de momentos importantes, utilizando o tempo real e recursos multimídia: tudo que é produzido pelos profissionais que cuidam do processo legislativo e da comunicação da Câmara.

O desenvolvimento desse projeto foi marcado por um envolvimento ativo de jornalistas da Casa — que permitiram testar e conceitualizar a área de interface de edição e gestão dos conteúdos —, além de duas rodadas de testes remotos com cidadãos de vários perfis.

Metodologias ágeis

Antes de começar as sprints de desenvolvimento, fizemos pequenos treinamentos com toda a equipe do Plenário Fácil — gerentes, designers, desenvolvedores, etc — em que nos aprofundamos na metodologia ágil e  no Scrum. Após debates, propomos algumas modificações nas atribuições de cada ator do processo e nas políticas que consideramos necessárias para o nosso contexto, chegando às seguintes definições:

• O papel de PO (Product Owner) seria feito pelo gestor do projeto, visto que ele tinha um conhecimento melhor do modelo de negócio, assim como um maior poder de negociação com outras partes necessárias;

• O papel de SCRUM Master seria feito por um membro da equipe técnica. Esta atribuição seria rotativa ao longo do projeto, para não sobrecarregar nenhum membro;

• Como o SCRUM Master seria um dos membros da equipe técnica, somente os desenvolvedores e o designer estariam presentes nas daily’s (reuniões diárias);

• Caso o SCRUM Master notasse empecilhos que dependessem de uma maior articulação para serem resolvidos, isso seria informado ao PO (gestor do projeto) para que as providências necessárias pudessem ser tomadas em conjunto.

Importante ressaltar que, além do teste com metodologias ágeis, o protótipo foi desenvolvido durante a pandemia, com a equipe em home-office, o que significou um ajustamento de todo o processo, inclusive na realização de testes on-line com usuários.

Definições técnicas

Optamos por uma arquitetura com o frontend e o backend desacoplados, possibilitando, assim, que as equipes trabalhassem de maneira paralela ao longo do projeto. 

O frontend seria implementado utilizando ReactJS e o backend em Django. Esta seria a primeira vez que trabalharíamos com essa stack — conjunto de tecnologias para criar aplicações — em um projeto dentro do LAB.