Governança do SEI na APF: Proposta inicial para construção colaborativa

Aos gestores SEI, esse tópico é pra vocês:

Estamos estruturando um modelo de governança do SEI no âmbito da Administração Pública Federal, com um objetivo simples:

Tomar melhores decisões sobre a evolução do SEI, com base em problemas reais de uso, de forma transparente e coordenada.

Esta é uma versão inicial (V0), e queremos construir isso com vocês.

Como o modelo se organiza (visão geral)

O modelo tem 5 (cinco) peças principais:

1) Câmaras setoriais (GTs permanentes)

  • APF Direta;

  • APF Indireta;

  • Agências Reguladoras;

As câmaras têm o papel de consolidar problemas e demandas do seu segmento. A separação nasce da necessidade de já recebermos demandas mais qualificadas. Atender sugestões ou problemas a granel levaria a desvios de foco e menos isonomia. A ideia é gerar valor pra mais gente com menos esforço…

2) Câmaras temáticas (GTs temporários)

Criadas sob demanda para temas específicos, elas aprofundam as análises técnicas e ajudam na generalização de soluções. Seu papel não é o de atuar em todas as demandas, mas sim apenas quando estas exigirem aprofundamento técnico antes da tomada de decisão. Por exemplo:

  • Uma nova funcionalidade relevante;
  • Uma mudança significativa em regra de negócio preexistente;
  • algo que pode virar padrão nacional
  • algo já feito por um órgão, mas que precisa ser adaptado

3) Gerência de Projeto do SEI (estrutura recém-criada na DTGES/SEGES-MGI)

A Gerência terá o papel de organizar e estruturar as demandas, classificar os inputs recebidos (podem ser correções, melhorias, evoluções ou diretrizes) e preoarar insumos para tomada de decisão pelo Comitê de Governança do SEI. A gerência pode recorrer aos GTs para auxiliar no detalhamento da documentação das questões apresentadas (e posteriormente, na concepção das soluções).

4) Comitê de Governança do SEI (de caráter deliberativo)

O comitê tem o papel de decidir prioridades e diretrizes referentes ao SEI, resolver conflitos e deliberar sobre evoluções relevantes, com base em insumos estruturados pela Gerência de Projeto a partir das contribuições das câmaras setoriais e temáticas, assegurando a aderência do sistema à legislação vigente e às melhores práticas.

5) Execução + Monitoramento

  • O desenvolvimento das corretivas, melhorias e evolutivas pode ser feito diretamente pelo PEN e/ou por parceiros;

  • Cabe à gerência realizar o acompanhamento de resultados e coletar feedback dos órgãos usuários das soluções desenvolvidas;

  • A gerência é responsável também pela “retroalimentação” do ciclo: prestar contas ao Comitê e aos GTs para viabilizat ajustes e revisão de decisões.

Resumindo:

O modelo parte de uma premissa simples: quem está em contato com os usuários e suas dores cotidianas tem a primazia para apresentar os problemas a serem resolvidos. O PEN criou uma unidade (a gerência) exatamente para organizar e consolidar as demandas apresentadas. Propomos a criação de um comitê, com papel deliberativo, para decidir sobre prioridades e diretrizes. O PEN pode executar o desenvolvimento ou acionar órgãos parceiros que possam atuar nessa frente. A gerência monitora esse processo para prestar contas às partes envolvidas.

Desenhando o modelo:

Ponto chave:

Ao invés de ser uma via para “receber sugestões de funcionalidades”, o modelo é focado em:

identificar e qualificar problemas reais de uso do SEI, com potencial de solução compartilhada.

O que queremos validar com vocês:

  1. Estrutura das câmaras

  • Os grupos propostos (APF Direta, Indireta e Agências) refletem bem as diferenças de uso do SEI?
    Há algum recorte que faz falta ou que poderia ser simplificado?
  1. Entrada de demandas

  • Hoje, no seu órgão, é fácil descrever claramente um problema no uso do SEI?

  • O que costuma dificultar (ou ajudar) esse processo?

  1. Análise de demandas

  • Que tipo de demanda, na sua realidade, não poderia ser decidida diretamente e precisaria de uma análise mais aprofundada antes?
  1. Tomada de decisão

  • O que faria você confiar que as decisões sobre evolução do SEI estão sendo bem tomadas?
  1. Monitoramento e retorno

  • Quando uma melhoria é implementada hoje, vocês conseguem avaliar se ela resolveu o problema?
  • O que falta nesse acompanhamento?
  1. Viabilidade prática

  • Considerando a realidade do seu órgão, o que mais dificultaria a participação nesse modelo? (tempo, equipe, complexidade do processo etc.)

Pergunta

O que, na prática, faria esse modelo funcionar — ou não funcionar — no seu órgão?

Próximos passos

Vamos consolidar as contribuições e evoluir para uma versão 1.0 do modelo.

Participe(n)! :face_with_hand_over_mouth: Este é um espaço de construção coletiva!

Como uma demanda percorreria o modelo de governança do SEI?

Para complementar a proposta, segue uma descrição de como uma demanda evoluiria dentro do modelo.

1. O problema nasce no uso real

Um órgão identifica um problema concreto no uso do SEI.

:warning: Premissa importante: o ponto de partida é sempre o problema, não a solução. Por quê?

Porque soluções propostas isoladamente tendem a refletir contextos locais e podem não funcionar para outros órgãos. Partir do problema permite identificar padrões e construir respostas mais gerais, sustentáveis e aderentes ao ecossistema do PEN.

2. O tema é levado à câmara setorial

O problema deve ser discutido no Grupo de Trabalho (GT) do segmento (APF Direta, APF Indireta ou Agências - cabe revisão aqui se vocês acharem outros recortes melhores)

Esse GT vai:

  1. verificar a recorrência da demanda;
  2. consolidar demandas relacionadas, se tiver; e
  3. qualificar o contexto (aprofundar o entendimento o problema, comparar com outros órgãos ou cenários e se posicionar se a questão é local ou sistêmica)

3. A demanda é estruturada

Se o GT entender que vale dar seguimento à demanda, ele vai registrá-la de forma padronizada. Esse padrão pode e deve ser validado e aprimorado pelos GTs, para que tenha o formato que melhor detalhe as questões identificadas. E, claro, a Gerência de Projeto do SEI pode contribuir para uma coleta mais estruturada desses dados, por meio de formulários padronizados e até realizando oficinas para lidar com temas mais complexos.

Problema Impacto Quem é afetado? Exemplos

4. Encaminhamento à Gerência do SEI

Ao receber a demanda encaminhada pelo GT, caberá à Gerência de Projeto do SEI:

  • validar a consistência da demanda;

  • eliminar eventuais duplicidades (quando já existe demanda semelhante que pode absorver o que está sendo apresentado);

  • agrupar temas, em caso de demandas complementares de mesma natureza;

  • classificar (correção, melhoria, evolução ou diretriz):

    Tipo O que é Quando eu uso? Quem decide? Exemplo:
    Correção (Run) Ajuste de erro, comportamento inesperado Quando algo não funciona como deveria Gerência (com fluxo técnico) Bug em funcionalidade, erro de cálculo, falha de exibição
    Melhoria (Improve) Ajuste incremental em algo existente Quando há ganho claro sem alterar lógica central Comitê (pode ter fast-track) Ajuste de tela, melhoria de usabilidade, pequeno ganho de performance
    Evolução (Evolve) Nova funcionalidade ou mudança relevante de comportamento Quando há necessidade recorrente com potencial de generalização Comitê (com possível apoio de GT temático) Um novo módulo, uma nova forma de tramitação, uma nova integração relevante
    Diretriz (Govern) Definição de regra, padrão ou orientação Quando o problema não é (ou não é apenas) técnico Comitê (nível estratégico) Um padrão de uso, uma regra de interoperabilidade, uma orientação normativa sobre determinado tema.

:warning: Se a demanda exigir maior aprofundamento, a Gerência pode instaurar uma câmara temática (GT temporário)

A Câmara é criada para tratar aquele (e somente aquele) tema específico, para contribuir no aprofundamento da análise, ajudar a avaliar possibilidades de generalização da solução e evitar que uma solução local vire padrão sem as devidas adaptações.

5. O Comitê decide:

A Gerência submeterá a demanda, já devidamente estruturada, aprofundada e validada junto à origem, ao Comitê de Governança. O Comitê terá a responsabilidade de priorizar ou não a referida demanda frente às demais e decidir qual tipo de tratamento aquela demanda vai receber dentro do SEI. Por exemplo:

  • Não tratar no SEI, quando a demanda proposta está fora de escopo;
  • Criar funcionalidade como módulo, quando se tratar de questão restrita a grupo específico;
  • Evoluir o core, quando é algo que deve virar padrão nacional (adequação à legislação, padronização de UI etc.)
  • Tratar como diretriz (não desenvolvimento), quando se tratar de orientação ou regra de uso

Ao Comitê cabe, ainda, deliberar sobre evoluções do sistema, decidindo se uma demanda deve resultar em mudança ou ampliação do SEI, definindo sua relevância, abrangência e diretrizes gerais de implementação.

6. Mas essa decisão precisa virar uma entrega

A Gerência volta à cena, traduzindo as decisões do comitê em um backlog, detalhando ou coordenando o detalhamento das especificações, requisitos, estórias de usuário, regras de negócio etc, e planejando, junto ao responsável designado ao desenvolvimento da demanda, sua execução - em termos de roadmap, prazos, marcos, épicos, sprints etc.

7. O uso gera aprendizado

Após a entrega, a solução é disponibilizada para utilização pela comunidade, e a gerência inicia o processo de coleta de feedback a respeito do produto, a fim de identificar eventuais ajustes e pontos de evolução para melhoria contínua dos serviços.

Essas informações geram insumos para a gerência, para eventuais ajustes no backlog, e para comitê de governança, para avaliação da estratégia e das prioridades em face do novo cenário.

E aí? Pode funcionar? Onde dá pra melhorar?

Temos uma V1: o desenho amadureceu :slightly_smiling_face:

Então: Depois da publicação do V0, a gente seguiu trabalhando no modelo e chegamos a uma reflexão que vale colocar abertamente na thread. Esta é a V1, com duas mudanças estruturais em relação ao que está logo acima.

  1. Uma simplificação deliberada. As câmaras setoriais (GTs permanentes da APF Direta, e Indireta) e as câmaras temáticas (GTs temporários) saíram da estrutura de partida. Não jogamos elas fora, guardamos para quando a comunidade do ParticiPEN ganhar tração e essa instância de triagem for mais necessária. Criar três câmaras hoje, neste primeiro momento, ia ser exagero. Vamos com uma abordagem menos complexa, de saída.
  2. Detalhamento de método operacional. A V0 descreveu bem a estrutura, mas deixou implícitos alguns aspectos que precisam ser explícitos… Tipo: como uma demanda é priorizada? Quem tem assento no Comitê? Como esse assento é ocupado? Como fazer um modelo que seja isonômico, que não dê margem para “minha demanda morreu e ninguém me explicou por quê”? E ainda, como o modelo lida com soluções que não são “mexer no core” — porque a maior parte da inovação distribuída no ecossistema do SEI e das soluções do PEN não é…

Detalhando: o modelo tem 5 peças

  • ParticiPEN. Plataforma de construção coletiva para as demandas que entram em fila de priorização (“Improve”, “Evolve”, “Govern”). Aqui é importante destacar: o ParticiPEN não é caixa de sugestões. É infraestrutura de participação. O que entra fica registrado, vira curadoria, e a decisão sobre o destino é pública.

  • Central de Atendimento, em portaldeservicos.gestao.gov.br. Canal para reportar erro ou dificuldade operacional (o que a gente classifica como “Run”. A separação tem razão de ser: ninguém vai abrir tópico no ParticiPEN pra avisar que o sistema caiu) que precisa de atendimento. O ParticiPEN entra como espelho, mostrando o que está sendo resolvido, para que a comunidade tenha visibilidade sem precisar operar o canal de chamados.

  • Gerência de Projeto SEI (GP SEI). Faz a curadoria técnica das demandas. Classifica por trilha (Run/Improve/Evolve/Govern), agrupa duplicatas, devolve o que é inviável com justificativa pública, monta o backlog que vai pro Comitê. E aqui vai um ponto: a GP SEI não decide o que entra ou sai. Ela traduz e organiza. Quem decide é o Comitê.

  • Comitê de Governança do SEI. Instância deliberativa, com paridade entre MGI e comunidade — três cadeiras para o MGI (CGIMP, CGSIS, GPSEI) e três cadeiras da comunidade. As cadeiras da comunidade são eleitas pelos admins SEI principais designados pelos órgãos, em eleição setorial. E sem voto de minerva: se o Comitê empata, a pauta volta no ciclo seguinte, com posição pública de cada cadeira.

  • Catálogo de soluções. Registro vivo do que existe no ecossistema do PEN - módulos, APIs, extensões, integrações, bases de referência, customizações locais, e soluções que podem (ou não) crescer pra outras escalas. Cada item com tipo, mantenedor, status, órgãos usuários, compatibilidade. Quem alimenta é a GP SEI; quem vê é todo mundo. A ideia é aproveitar a página atual do PEN sobre módulos como ponto de partida e expandir o escopo. O catálogo é o que torna a governança defensável quando a solução não é “mexer no core” — e a maior parte da inovação distribuída no ecossistema não é.

1 curtida