Papéis, Responsabilidades e Matriz RACI

1. Descrição Detalhada dos Papéis

O modelo operacional do e-SUS AF é composto por seis papéis principais de engenharia e produto, complementados pela camada de atendimento de suporte funcional (N1/N2):

flowchart TD
    subgraph Negocio_Gov["Governança e Produto"]
        PO["Equipe de Negócio / PO
• Visão de Produto & Priorização
• Critérios de Aceite & BDD
• Homologação & Aceite de Releases"]
        TL["Líder Técnico (Tech Lead)
• Arquitetura & Governança OneFlow
• Code Review Crítico & Hotfixes
• Gestão de Crise (Swarming)"]
    end

    subgraph Operacao_Suporte["Operação & Diagnóstico"]
        N1N2["Suporte N1/N2 (NQS)
• Atendimento ao Usuário
• Triagem Funcional & FAQ"]
        N3["Suporte N3 (2 membros dedicados)
• Análise Técnica de Logs & BD
• Reprodução em Homologação
• Scripts Corretivos Operacionais"]
    end

    subgraph Engenharia_Execucao["Engenharia & Entrega"]
        SUST["Sustentação (Célula Kanban)
• Correções Críticas (Sev 1 / Sev 2)
• Testes Automatizados de Regressão
• Releases Patches (vX.Y.Z)"]
        EVO["Time de Dev - Evolução (Scrum)
• Features & Débitos Técnicos
• Release Train 2+1 (4+2 sem)
• Testes Unitários e E2E"]
        QA["Qualidade (QA)
• BDD no Refinamento
• Testes de Regressão na Estabilização
• Validação Técnica de Releases"]
    end

    N1N2 -->|Escalonamento Técnico| N3
    N3 -->|Bugs Sev 1/2 com Código| SUST
    N3 -->|Bugs Sev 3/4 & Débito| EVO
    PO <-->|Alinhamento Contínuo| TL
    TL -->|Supervisão Técnica| SUST
    TL -->|Direcionamento Arquitetural| EVO
    QA <-->|Validação Cruzada| SUST
    QA <-->|Regressão & Homologação| EVO

1.1. Equipe de Negócio / Product Owner (PO)

A Equipe de Negócio e o Product Owner representam a voz dos usuários do Sistema Único de Saúde (SUS), dos gestores municipais, estaduais e do Ministério da Saúde.

• Missão Principal: Definir o valor de negócio a ser entregue, priorizar o backlog do produto e assegurar que as soluções atendam com exatidão às políticas públicas de assistência farmacêutica.
• Principais Atribuições:
  • Gerenciar e priorizar o Backlog de Produto da frente de Evolução;
  • Detalhar regras de negócio e critérios de aceite no formato BDD (Behavior-Driven Development) durante as sessões de refinamento;
  • Realizar a homologação funcional e aceitar/rejeitar entregas durante a Sprint de Estabilização;
  • Conceder a aprovação negocial para o corte e publicação de releases oficiais (vX.Y.0) e autorizar o escopo negocial de Hotfixes (vX.Y.Z+1).
• Poder de Decisão:
  • Definir a ordem de prioridade de novas histórias e defeitos Sev 3/Sev 4;
  • Aprovar ou reprovar entregas funcionais na homologação;
  • Autorizar o adiamento ou cancelamento de itens que não atinjam o Definition of Ready (DoR).
• Anti-Escopo (O que NÃO faz):
  • Não atribui tarefas diretamente aos desenvolvedores fora das cerimônias ou do fluxo oficial;
  • Não altera código-fonte nem executa scripts em bancos de dados de produção;
  • Não cancela cerimônias ágeis ou altera o escopo da Sprint em andamento sem alinhamento prévio com o Líder Técnico.

1.2. Líder Técnico (Tech Lead)

O Líder Técnico é o guardião da integridade arquitetural, da qualidade do código e da disciplina de engenharia de todo o projeto e-SUS AF.

• Missão Principal: Garantir que as soluções técnicas sejam robustas, escaláveis, seguras e aderentes aos padrões de engenharia, coordenando tecnicamente as frentes de Evolução, Sustentação e Suporte N3.
• Principais Atribuições:
  • Definir padrões arquiteturais de front-end, back-end e banco de dados;
  • Gerenciar a governança de branches e a estratégia OneFlow (com branch perpétua única main);
  • Realizar a revisão técnica final (Code Review) em Pull Requests de alta complexidade ou de Hotfixes;
  • Avaliar e autorizar tecnicamente a execução de scripts em banco de dados preparados pelo Suporte N3;
  • Acionar e liderar o protocolo de Swarming (mobilização de crise) em incidentes Sev 1;
  • Gerenciar a escala de rotação técnica da Célula de Sustentação.
• Poder de Decisão:
  • Vetar merges de Pull Requests que violem padrões de qualidade, cobertura de testes ou arquitetura;
  • Acionar mobilização extraordinária de desenvolvedores para resposta a incidentes críticos;
  • Definir estratégias técnicas de refatoração, atualização tecnológica e pagamento de débitos técnicos.
• Anti-Escopo (O que NÃO faz):
  • Não altera prioridades de negócio unilateralmente sem alinhamento com o PO;
  • Não realiza atendimento direto a usuários finais nos canais de suporte N1/N2;
  • Não aprova Hotfixes sem validação técnica mínima e testes automatizados de regressão.

1.3. Suporte N3 (2 Membros Dedicados)

O Suporte N3 é a linha avançada de diagnóstico técnico, composta por 2 profissionais dedicados exclusivamente à investigação técnica de chamados escalonados pelo Suporte N2.

• Missão Principal: Realizar a triagem profunda de falhas, identificar a causa raiz por meio de análise de logs e dados, reproduzir comportamentos anômalos em homologação e solucionar inconsistências operacionais via scripts de dados aprovados, evitando a contaminação do fluxo de desenvolvimento.
• Principais Atribuições:
  • Recepcionar chamados técnicos do N2 que cumpram o Definition of Ready (DoR) de entrada;
  • Inspecionar logs de aplicação, traces de exceções, payloads de requisições HTTP e tabelas do banco de dados;
  • Reproduzir erros em ambiente de Homologação/Staging para isolar as condições de falha;
  • Elaborar scripts SQL de correção de inconsistências operacionais e submetê-los para aprovação técnica;
  • Abrir issues técnicas detalhadas (com causa raiz, logs e massa de teste) e roteá-las para a Sustentação (Sev 1 / Sev 2) ou para o Backlog de Evolução (Sev 3 / Sev 4 / Débito Técnico);
  • Cumprir os SLAs de resposta técnica e diagnóstico (até 4h para Sev 1/2 e até 12h para Sev 3/4).
• Poder de Decisão:
  • Classificar a Severidade Técnica do chamado (Sev 1 a Sev 4);
  • Devolver tickets ao Suporte N2 caso faltem evidências mínimas obrigatórias;
  • Decidir se uma demanda é resolvida operacionalmente sem necessidade de alteração de código.
• Anti-Escopo (O que NÃO faz):
  • Não altera código-fonte da aplicação nem abre Pull Requests de código de produto;
  • Não atende dúvidas operacionais básicas de usuários finais (atribuição exclusiva do N1/N2);
  • Não executa scripts corretivos diretamente em produção sem validação em homologação e aprovação do Líder Técnico.

1.4. Sustentação (Célula de Engenharia)

A Sustentação é a célula de desenvolvimento focada em pronto atendimento a defeitos críticos e graves que exigem alteração no código-fonte da aplicação.

• Missão Principal: Resolver de forma ágil, segura e cirúrgica os bugs de alta severidade (Sev 1 - Hotfixes e Sev 2 - Bugfixes Urgentes), operando sob fluxo contínuo Kanban com limites estritos de trabalho em progresso (WIP).
• Principais Atribuições:
  • Puxar itens priorizados na esteira Kanban de sustentação conforme capacidade e limites de WIP;
  • Implementar correções de código pontuais e seguras para incidentes Sev 1 e Sev 2;
  • Escrever testes automatizados (unitários e/ou ponta a ponta) cobrindo obrigatoriamente o cenário do bug para evitar reincidências;
  • Submeter Pull Requests para Code Review e acompanhar a validação técnica junto ao QA;
  • Executar o procedimento de sincronização OneFlow (garantindo que o patch seja integrado à main e replicado na branch de release/* ativa, se existente).
• Poder de Decisão:
  • Definir a abordagem técnica mais segura para estancar o defeito reportado;
  • Puxar o próximo item do topo da fila Kanban de sustentação, respeitando a severidade.
• Anti-Escopo (O que NÃO faz):
  • Não desenvolve novas funcionalidades de negócio ou melhorias estéticas;
  • Não realiza atendimento ou esclarecimento de dúvidas diretamente com municípios;
  • Não realiza bypass de testes automatizados ou de Code Review para agilizar deploys.

1.5. Time de Desenvolvimento (Evolução)

O Time de Desenvolvimento da Evolução é o motor de construção e entrega de valor contínuo do e-SUS AF, operando na cadência fixa do Release Train (2+1).

• Missão Principal: Desenvolver com alta qualidade as histórias de usuário planejadas, refatorar componentes e pagar débitos técnicos, mantendo ritmo sustentável e previsibilidade de entrega.
• Principais Atribuições:
  • Planejar e estimar a capacidade da Sprint durante a Sprint Planning;
  • Implementar funcionalidades aderentes aos critérios de aceite BDD especificados;
  • Construir testes automatizados (unitários e ponta a ponta) como parte indispensável da entrega da história;
  • Participar ativamente da revisão de código cruzada entre pares (Code Review);
  • Atuar na correção de bugs detectados durante a Sprint de Estabilização;
  • Realizar o pagamento de débitos técnicos e refatorações planejadas.
• Poder de Decisão:
  • Estimar o esforço e a complexidade técnica das histórias de usuário;
  • Propor abordagens técnicas, arquiteturas de módulos e refatorações no refinamento;
  • Sinalizar impedimentos técnicos que comprometam a meta da Sprint.
• Anti-Escopo (O que NÃO faz):
  • Não é interrompido por chamados cotidianos de suporte ou dúvidas funcionais (blindagem de contexto);
  • Não realiza commits ou merges diretos na branch perpétua main sem abertura de PR e aprovações;
  • Não inicia desenvolvimento de itens que não cumpram o Definition of Ready (DoR).

1.6. Qualidade (QA)

O time de Qualidade atua transversalmente como garantidor dos critérios de aceitação, da estabilidade global da plataforma e da prevenção de regressões em produção.

• Missão Principal: Assegurar que o software entregue funcione com confiabilidade, integridade de dados e aderência às regras de negócio antes de cada deploy em produção.
• Principais Atribuições:
  • Apoiar o PO e os desenvolvedores no detalhamento de cenários BDD durante o refinamento;
  • Desenhar e executar baterias de testes de regressão funcionais e exploratórios durante a Sprint de Estabilização;
  • Realizar a validação técnica independente de pacotes de release (release/*) e de correções emergenciais (Hotfixes);
  • Monitorar a taxa de bugs reabertos, bugs escapados para produção e cobertura de testes;
  • Manter e evoluir suites de testes automatizados integrados aos pipelines de CI/CD.
• Poder de Decisão:
  • Apontar impedimentos formais de qualidade (No-Go) para o corte ou deploy de uma release;
  • Definir o escopo da matriz de testes de regressão prioritária para cada ciclo de release.
• Anti-Escopo (O que NÃO faz):
  • Não assume de forma isolada a responsabilidade pelos testes (o desenvolvedor é responsável por testar seu próprio código);
  • Não substitui a homologação negocial e funcional soberana da Equipe de Negócio/PO;
  • Não aprova releases com defeitos bloqueantes (Sev 1 / Sev 2) em aberto.

2. Tabela Estruturada de Papéis e Limites de Atuação

A tabela a seguir consolida as fronteiras de atuação, responsabilidades, autonomia decisória e interações de cada papel:

3. Matriz RACI do Ciclo de Vida de Demandas

A Matriz RACI mapeia a responsabilidade sobre as 11 etapas-chave do ciclo de vida de uma demanda no e-SUS AF, evitando sobreposição de funções e lacunas operacionais:

3.1. Definições da Convenção RACI

• R — Responsible (Responsável): Quem executa a tarefa ou atividade para atingir o objetivo.
• A — Accountable (Aprovador / Prestador de Contas): Quem responde pelo resultado final, possui autoridade de veto/aprovação formal. Deve haver idealmente um único Accountable primário por etapa.
• C — Consulted (Consultado): Especialistas ou papéis que fornecem insumos, informações e pareceres técnicos/negociais prévios.
• I — Informed (Informado): Partes interessadas mantidas notificadas sobre o progresso e a conclusão da etapa.

3.2. Tabela da Matriz RACI

3.3. Detalhamento Operacional por Etapa

1. Triagem Inicial & Dúvidas Básicas:
   • O Suporte N1/N2 é o primeiro ponto de contato com estados e municípios. Identifica se a demanda trata-se de dúvida funcional (FAQ) ou parametrização incorreta, respondendo diretamente e encerrando o chamado.
2. Diagnóstico Técnico & Análise de Logs:
   • O Suporte N3 assume a responsabilidade de auditar logs, stack traces e reproduzir a falha. Consulta o Líder Técnico ou a Sustentação quando necessita de entendimento aprofundado do código-fonte.
3. Execução de Script Corretivo Operacional:
   • Quando a causa raiz for inconsistência de dados operacionais sem necessidade de release de código, o N3 elabora o script SQL. A aprovação técnica do Líder Técnico (A) é obrigatória antes de qualquer execução controlada em produção (R).
4. Classificação de Severidade & Prioridade:
   • O Suporte N3 classifica a severidade técnica (Sev 1 a Sev 4) com base no impacto no sistema (R). A Equipe de Negócio/PO valida e aprova a priorização comercial/negocial do backlog (A).
5. Correção de Hotfix (Incidente Sev 1):
   • A Célula de Sustentação atua no desenvolvimento imediato da correção em branch hotfix/* derivada da main (R), sob supervisão e aprovação arquitetural do Líder Técnico (A).
6. Validação Técnica de Hotfix:
   • O time de Qualidade (QA) valida a correção em ambiente isolado de Staging, executando testes funcionais e conferindo os testes automatizados adicionados (R), com chancela final do Líder Técnico (A).
7. Homologação Negocial de Hotfix/Release:
   • A Equipe de Negócio/PO realiza os testes de aceitação formal, conferindo se os fluxos de assistência farmacêutica atendem aos requisitos estipulados (R / A).
8. Desenvolvimento de Features (Evolução):
   • O Time de Desenvolvimento da Evolução executa as histórias de usuário refinadas durante a Sprint de Desenvolvimento, entregando código com testes unitários e e2e (R / A).
9. Testes de Regressão (Sprint de Estabilização):
   • Durante a Sprint de Estabilização, o time de QA lidera a execução da matriz de regressão completa na branch de release (release/*) para assegurar que novas funcionalidades não inseriram efeitos colaterais (R / A).
10. Autorização de Release para Produção:
    • Ocorre em consenso formal entre o Líder Técnico (atestando estabilidade técnica, CI verde e ausência de bugs graves) e a Equipe de Negócio/PO (atestando aderência funcional e valor de negócio) (R / A conjunto).
11. Comunicação Final ao Usuário/Município:
    • O Suporte N1/N2 recebe as notas de versão atualizadas e notifica os canais solicitantes sobre a conclusão e resolução da demanda (R / A).

4. Mecanismos de Handoff e Acordos de Convivência

Para garantir que a transição de responsabilidade entre as equipes ocorra sem ruídos, foram estabelecidos os seguintes pontos de transferência (Handoff):

sequenceDiagram
    autonumber
    actor User as Usuário / Município
    participant N1N2 as Suporte N1/N2
    participant N3 as Suporte N3
    participant Sust as Sustentação (Kanban)
    participant Evo as Evolução (Scrum)
    participant QA as Qualidade (QA)
    participant PO as PO / Negócio
    participant TL as Líder Técnico

    User->>N1N2: Abertura de Chamado
    N1N2->>N1N2: Triagem Básica & FAQ
    alt Ticket Técnico com DoR
        N1N2->>N3: Escalonamento com Evidências
        N3->>N3: Análise de Logs & Diagnóstico
        alt Resolução por Script de BD
            N3->>TL: Submete Script para Aprovação
            TL-->>N3: Script Aprovado
            N3->>N3: Executa Script em Produção
            N3-->>N1N2: Devolve chamado resolvido
        else Defeito de Código Sev 1 / Sev 2
            N3->>Sust: Abre Issue no Kanban de Sustentação
            Sust->>Sust: Correção + Teste Automatizado
            Sust->>QA: Solicita Validação Técnica
            QA->>PO: Validação Concluída -> Solicita Homologação
            PO-->>TL: Homologado -> Autorização de Deploy
            TL->>TL: Merge OneFlow na main + Deploy Patch
            TL-->>N1N2: Notifica publicação de Patch
        else Defeito Sev 3 / Sev 4 ou Débito Técnico
            N3->>Evo: Abre Issue no Backlog de Evolução
            PO->>Evo: Prioriza no Ciclo de Release Train
        end
    else Falta de Evidências
        N3-->>N1N2: Devolve ticket para complementação
    end
    N1N2-->>User: Comunicação e Encerramento

Regras de Ouro de Convivência Operacional

1. Nenhum desenvolvedor atende suporte direto: Dúvidas e chamados devem sempre percorrer a cadeia N1 -> N2 -> N3. O time de desenvolvimento não deve ser acionado por canais informais.
2. Nenhuma alteração de código sem Issue: Toda linha modificada na base de código deve estar associada a uma issue no Jira/GitLab/GitHub com histórico e diagnóstico registrado.
3. Todo bug corrigido exige teste automatizado: Correções de incidentes (Sev 1 e Sev 2) e bugs de estabilização exigem a inclusão de um teste de regressão automatizado que comprove que a falha não ocorrerá novamente.
4. Respeito aos Limites de WIP: O time de Sustentação não deve puxar novas correções caso os limites de Trabalho em Progresso das colunas estejam no teto, concentrando esforços em desbloquear itens em revisão ou teste.