Ir para o conteúdo principal

[EM EDIÇÃO] Autonomia do DIOF no tratamento da formatação das matérias publicadas

- Introdução

- As funcionalidades necessárias para atender a necessidade.

- Complexidade de cada funcionalidade

- Possíveis problemas.

- Valor agregado

- e conclusão do estudo

DADO QUE o diof receber matérias de ultima hora para serem publicada no mesmo dia
QUANDO houver matéria sem está no padrão de formatação do diof
ENTÃO a equipe técnica do DIOF poderá ajustar a matéria na formatação correta.

OBJETIVO

Melhorar a autonomia do DIOF em relação a formatação das matérias, através da detecção de funcionalidades necessárias para que a necessidade seja atendida.

VISÃO GERAL

Hoje em dia a grande maioria das matérias vem do SEI, onde não temos controle sobre o editor de texto, muito menos sobre o padrão de classes css e formatação em geral. Então hoje em dia fica praticamente totalmente na responsabilidade do usuário criar uma matéria nos padrões especificados pelo Diof. Ainda conseguimos fazer algumas adaptações e formatações automáticas, a partir que a matéria já foi agendada, identificamos alguns padrões de classes css e sobre escrevemos essas classes, porém não cobre todos os problemas, pq como falei se o usuário errar, não temos como consertar, só ele fazendo de novo. O que é um processo burocrático, principalmente quando a matéria tá assinada. O diof desde do principio queria interferir nesses casos e de alguma forma editar. Passou 3 anos e ainda continuamos tendo problemas de formatação, o interessante é deixar o diof com essa liberdade. Uma das soluções que penso é o diof poder interferir nas matérias ou no diário como um todo. Acredito que o mais tranquilo, seria interferir por matéria, onde ele a gente iria pegar o conteúdo daquela matéria, jogar no editor do govdoc o diof iria formatar E a gente salva essa matéria como matéria formatada lá no gov doc e na hora de renderizar o diário pegava de lá, as matérias que tivessem a condição materiaFormatada como verdadeiro.

CONSIDERAÇÕES FINAIS

 

RESPONSÁVEIS

  • Alexandre Santos Freire (Analista de Desenvolvimento);

  • André Henrique Cortez (Analista de Desenvolvimento Full-stack);

  • Denise Jeane (Product Owner);

  • Jorge Luiz de Jesus Paiva Junior (Analista de Desenvolvimento Full-stack).

GLOSSÁRIO
  1. Product Owner: O Product Owner representa os interesses de todos os envolvidos, define as funcionalidades do produto e prioriza os itens de Product Backlog. Fonte: (https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html).
  2. Product Backlog: É uma lista priorizada, contendo breves descrições de todas as funcionalidades desejadas para o produto. Fonte: (https://www.culturaagil.com.br/product-backlog-o-que-e/).
  3. Scrum Master: O Scrum Master é o membro do time que detém, em geral, maior conhecimento sobre o Scrum (“framework que ajuda as equipes a trabalharem juntas”). Logo, ele é responsável por potencializar o trabalho da equipe. Fonte: (https://www.voitto.com.br/blog/artigo/scrum-master) (https://www.atlassian.com/agile/scrum).
  4. Framework: Estrutura é feita para resolver um problema específico. Fonte: (https://www.lewagon.com/pt-BR/blog/o-que-e-framework).
  5. Full-stack: O desenvolvedor Full-stack é aquele que pode atuar em qualquer etapa do desenvolvimento de sistemas. Fonte: (https://www.proway.com.br/blog/dev-full-stack-o-que-e-isso)

Estudo Técnico – 03/02/2022

 

 

Voltar ao topo