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?