Capítulo 57 — Gestão de Projetos e Entregas

57.1 Objetivo do Capítulo

Este capítulo descreve o modelo de gestão de projetos e entregas adotado na parceria com a PRODEMGE para a Plataforma de Relacionamento Digital com o Cidadão. Ele define como o trabalho é planejado, organizado, executado, acompanhado e encerrado — desde a iniciativa no backlog até a entrega homologada em produção.

A gestão de projetos não é um processo isolado. Ela é o elo entre a governança estratégica — tratada no Capítulo 56 — e a execução técnica cotidiana das equipes. Sem esse elo, roadmaps tornam-se intenções, decisões de comitê tornam-se documentos sem consequência e entregas chegam sem rastreabilidade ao que foi acordado.

O modelo descrito aqui é pragmático, adaptado ao contexto de uma plataforma de missão crítica com múltiplos tenants em produção simultânea, SLAs contratuais ativos, e evolução contínua ao longo de sessenta meses de parceria. Não é um modelo genérico de gerenciamento de projetos — é o modelo específico que governa como a parceria transforma demanda em valor entregue com previsibilidade, qualidade e rastreabilidade.

57.2 Contexto

A execução da parceria combina dois fluxos de trabalho com naturezas distintas:

O primeiro é a operação contínua: sustentação da plataforma, suporte técnico, atendimento a incidentes, manutenção corretiva e monitoramento. Esse fluxo é permanente, não tem início e fim definidos, e é regido pelos processos descritos nos Capítulos 51, 52 e 53.

O segundo é a entrega por projeto: implantação de novos tenants, desenvolvimento de novas capacidades funcionais, integrações com sistemas externos, migrações, adequações regulatórias e iniciativas de evolução arquitetural. Esse fluxo é discreto — tem escopo, prazo, equipe, critérios de aceite e processo formal de encerramento.

Este capítulo trata do segundo fluxo. A distinção é deliberada: tratá-los com o mesmo processo geraria ou burocracia excessiva na operação cotidiana ou informalidade inadequada em entregas complexas que envolvem múltiplos times, dependências externas e compromissos com a PRODEMGE.

A plataforma opera sobre uma base já produtiva. Isso tem uma consequência direta para a gestão de projetos: toda entrega ocorre sobre infraestrutura em operação, com tenants em produção e SLAs ativos. Projetos que ignoram essa realidade geram risco operacional. O modelo de gestão descrito aqui integra essa restrição como princípio, não como exceção.

57.3 Escopo

Este capítulo cobre:

• tipologia de projetos gerenciados na parceria;
• estrutura de papéis e responsabilidades na gestão de projetos;
• ciclo de vida dos projetos: fases, gates e critérios de avanço;
• modelo de trabalho: cadência, cerimônias e artefatos;
• critérios de aceite e processo de homologação de entregas;
• gestão de dependências, impedimentos e escalação;
• encerramento formal de projetos e registro de lições aprendidas;
• rastreabilidade entre entregas e requisitos do Chamamento;
• decisões arquiteturais que governam o modelo de gestão.

Não estão no escopo deste capítulo: a gestão de mudanças técnicas (Capítulo 59), a gestão de riscos da parceria (Capítulo 60), os indicadores de desempenho (Capítulo 62), nem os processos de governança estratégica (Capítulo 56).

57.4 Tipologia de Projetos

Os projetos gerenciados na parceria são classificados em quatro categorias, cada uma com características específicas de escopo, duração e nível de formalização:

Projetos de natureza mista — por exemplo, implantação de tenant com desenvolvimento de funcionalidade específica para aquele órgão — são registrados como projetos compostos, com sub-escopos rastreados individualmente mas governados por um único Gerente de Projeto.

57.5 Estrutura de Papéis

57.5.1 Papéis na Parceira

Gerente de Projeto (GP): responsável pela condução integral do projeto — planejamento, acompanhamento, comunicação, gestão de riscos, escalação e encerramento. O GP é o ponto de contato primário com a PRODEMGE durante a execução do projeto. Para projetos de Implantação de Tenant e Entrega Funcional, o GP acumula ou coordina funções de Gestor de Produto quando o escopo é predominantemente funcional.

Gestor de Produto (Product Manager): responsável pelo backlog do projeto — priorização, refinamento de requisitos, critérios de aceite funcionais e comunicação com stakeholders de negócio. Atua em estreita colaboração com o GP e com os representantes dos órgãos.

Arquiteto Técnico do Projeto: responsável pelas decisões arquiteturais específicas do projeto, revisão de ADRs gerados durante a execução e garantia de consistência com a arquitetura da plataforma. Toda mudança de impacto estrutural passa obrigatoriamente pelo Arquiteto Técnico antes de ser implementada.

Líder Técnico (Tech Lead): responsável pela qualidade de implementação, coordenação técnica da equipe de desenvolvimento, revisão de código e alinhamento com os padrões da plataforma.

Equipe de Desenvolvimento: engenheiros de backend (Java/Spring Boot), frontend (React), mobile (React Native), QA, SRE e especialistas de domínio conforme o escopo do projeto.

57.5.2 Papéis na PRODEMGE

Fiscal de Contrato: acompanhamento e fiscalização da execução, verificação de conformidade com as cláusulas contratuais, avaliação de resultados e atestação de entregas conforme definido na Minuta de Contrato.

Gestor Técnico da PRODEMGE: interlocutor técnico primário, participa das cerimônias de revisão, valida critérios de aceite e emite o aceite formal de entregas.

Representante do Órgão (em projetos de implantação): ponto de contato do tenant sendo implantado — participa da coleta de requisitos de configuração, validação de fluxos e homologação final.

57.5.3 Princípio de Responsabilidade Compartilhada

A gestão de projetos é exercida em parceria. A Parceira conduz a execução; a PRODEMGE participa da governança, valida entregas e é corresponsável pelo cumprimento das dependências que estão em seu lado — como disponibilização de acessos, fornecimento de dados de referência e liberação de ambientes nos órgãos.

Dependências não cumpridas pela PRODEMGE dentro dos prazos acordados são registradas formalmente e impactam o cronograma sem penalização à Parceira, conforme registrado nos ADRs deste capítulo.

57.6 Ciclo de Vida dos Projetos

O ciclo de vida é organizado em cinco fases com gates formais de passagem. Cada gate é uma verificação explícita de critérios antes de avançar — não uma formalidade, mas um mecanismo de controle de qualidade e alinhamento.

INICIAÇÃO
    │
    ▼ Gate 1: Escopo aprovado pelas partes
PLANEJAMENTO
    │
    ▼ Gate 2: Plano validado; dependências confirmadas
EXECUÇÃO
    │
    ▼ Gate 3: Entrega interna concluída; testes aprovados
HOMOLOGAÇÃO
    │
    ▼ Gate 4: Aceite formal emitido pela PRODEMGE
ENCERRAMENTO

57.6.1 Fase 1 — Iniciação

A iniciação cobre o entendimento do projeto, a definição preliminar de escopo e a formalização da abertura.

Artefatos produzidos:

• Termo de Abertura do Projeto (TAP): documento de uma a três páginas que registra objetivo, escopo preliminar, justificativa, stakeholders, premissas iniciais e critérios de sucesso. O TAP é assinado pelo GP e pelo Gestor Técnico da PRODEMGE.
• Registro de Partes Interessadas: mapeamento de todos os stakeholders com seu papel, nível de influência e canal de comunicação.

Critérios do Gate 1:

• TAP aprovado pelas duas partes;
• Gerente de Projeto designado;
• Gestor Técnico da PRODEMGE confirmado;
• Alinhamento inicial sobre prazo e recursos.

57.6.2 Fase 2 — Planejamento

O planejamento decompõe o escopo em entregas rastreáveis, mapeia dependências, estima esforço e produz o cronograma de referência.

Artefatos produzidos:

• Plano de Projeto: estrutura analítica do projeto (EAP), cronograma com marcos e datas, alocação de equipe, plano de comunicação e plano de gestão de riscos do projeto.
• Backlog do Projeto: lista de histórias de usuário, requisitos técnicos e tarefas priorizadas, com critérios de aceite definidos por item.
• Matriz de Dependências: mapeamento de dependências externas — sistemas de terceiros, ambientes de órgãos, dados de referência — com responsável e prazo de resolução para cada dependência.
• Plano de Testes: estratégia de cobertura de testes — unitários, integração, regressão, performance, segurança — com critérios de aceite quantitativos.

Critérios do Gate 2:

• Plano de Projeto revisado e aprovado pela PRODEMGE;
• Backlog refinado com critérios de aceite por item;
• Dependências externas mapeadas com responsáveis e prazos confirmados;
• Riscos iniciais identificados e com plano de resposta;
• Ambientes disponíveis ou com data de disponibilização confirmada.

57.6.3 Fase 3 — Execução

A execução é conduzida em ciclos iterativos de duas semanas (sprints). A iteratividade serve dois propósitos: entrega progressiva de valor com visibilidade contínua do progresso, e capacidade de incorporar aprendizados sem aguardar o final do projeto.

A execução não é uma caixa-preta entre planejamento e entrega. A PRODEMGE tem visibilidade contínua por meio das cerimônias e dos artefatos de acompanhamento descritos na seção 57.8.

Atividades centrais:

• desenvolvimento conforme backlog priorizado;
• execução de testes automatizados a cada ciclo;
• deploy progressivo em ambiente de staging;
• análise e resolução de impedimentos;
• atualização do registro de riscos;
• comunicação semanal de status.

Critérios do Gate 3:

• todas as histórias do escopo com status "concluído" conforme Definition of Done;
• cobertura de testes acima do threshold definido no Plano de Testes;
• zero defeitos bloqueadores abertos;
• testes de regressão no ambiente de staging aprovados;
• documentação de entrega produzida e revisada.

57.6.4 Fase 4 — Homologação

A homologação é o período em que a PRODEMGE e, quando aplicável, os representantes do órgão, validam a entrega em ambiente dedicado antes da promoção para produção.

A homologação não é um teste de qualidade — esse é papel do Gate 3. A homologação é a validação de conformidade funcional com os requisitos acordados e com os critérios de aceite definidos no backlog.

Estrutura da homologação:

Classificação de não conformidades:

Critérios do Gate 4:

• aceite formal emitido pelo Gestor Técnico da PRODEMGE;
• zero não conformidades bloqueadoras ou críticas abertas;
• não conformidades relevantes com prazo de resolução acordado e registrado;
• documentação final entregue e aceita.

57.6.5 Fase 5 — Encerramento

O encerramento formaliza o término do projeto, consolida os aprendizados e garante a transferência de artefatos e conhecimento.

Artefatos produzidos:

• Relatório de Encerramento: sumário do projeto — escopo executado vs. planejado, desvios de prazo e custo com justificativas, indicadores de qualidade, lista de entregas homologadas e pendências residuais com plano de resolução.
• Registro de Lições Aprendidas: o que funcionou, o que não funcionou, recomendações para projetos futuros. Alimenta a base de conhecimento da parceria.
• Transferência de Artefatos: documentação técnica, manuais de configuração, casos de teste, ADRs gerados — transferidos para repositório compartilhado com acesso da PRODEMGE.

O encerramento formal é assinado pelo GP e pelo Fiscal de Contrato. Projetos não encerrados formalmente permanecem como ativos abertos no registro da parceria e continuam consumindo capacidade de acompanhamento.

57.7 Definition of Done

A Definition of Done (DoD) é o contrato interno de qualidade que define quando uma história ou entrega está genuinamente concluída — não apenas codificada. Ela é aplicada pela equipe a cada item antes de declarar seu status como "concluído".

DoD padrão para histórias de desenvolvimento:

• código implementado, revisado (code review aprovado) e integrado ao branch principal;
• testes unitários escritos e aprovados com cobertura ≥ 80% do código novo;
• testes de integração executados e aprovados no ambiente de CI;
• análise estática de segurança (SAST) sem falhas críticas ou altas não justificadas;
• documentação de API atualizada (quando aplicável);
• registro de migration de banco de dados incluído e testado (quando aplicável);
• feature flag configurada e testada em staging (quando entrega é progressiva);
• critérios de aceite funcionais verificados pelo QA;
• nenhum defeito bloqueador ou crítico aberto relacionado ao item.

DoD adicional para entrega de módulo ou integração:

• testes de regressão completos no ambiente de staging aprovados;
• testes de carga executados para os cenários de pico definidos no plano;
• documentação funcional do módulo produzida e revisada;
• runbook operacional atualizado;
• alertas e dashboards de observabilidade configurados para os novos componentes;
• plano de rollback testado e documentado.

A DoD é revisada e pode ser evoluída ao longo da parceria por decisão conjunta do Tech Lead e do Gestor Técnico da PRODEMGE, com registro formal.

57.8 Modelo de Trabalho: Cadência e Cerimônias

57.8.1 Cerimônias por Sprint (Ciclo de 2 Semanas)

57.8.2 Cerimônias de Acompanhamento do Projeto

57.8.3 Relatório de Status Semanal

O relatório de status semanal é o instrumento primário de transparência entre a Parceira e a PRODEMGE durante a execução de projetos. Ele é produzido pelo GP e entregue toda segunda-feira referente à semana anterior.

Conteúdo obrigatório do relatório:

• Indicador de saúde do projeto: Verde / Amarelo / Vermelho, com justificativa quando Amarelo ou Vermelho.
• Progresso do sprint corrente: percentual de histórias concluídas, histórias adicionadas ou removidas.
• Progresso do projeto: percentual do backlog total entregue vs. planejado; variação de prazo se houver.
• Impedimentos ativos: descrição, responsável pela resolução e prazo.
• Riscos relevantes: novos riscos identificados ou mudança de status em riscos existentes.
• Próximas entregas: o que será entregue nos próximos 14 dias.
• Decisões pendentes: pontos que aguardam decisão da PRODEMGE com impacto no cronograma se não resolvidos até data indicada.

O relatório é enviado por e-mail com cópia registrada no sistema de gestão da parceria. Projetos com indicador Vermelho ativam automaticamente a reunião de acompanhamento na semana corrente, independentemente do ciclo quinzenal.

57.9 Gestão de Dependências e Impedimentos

57.9.1 Tipos de Dependência

Dependências são classificadas por origem e por criticalidade:

Por origem:

• Interna: dependência entre times ou componentes da Parceira.
• PRODEMGE: dependência de ação, decisão ou fornecimento de recurso pela PRODEMGE.
• Órgão: dependência de ação do tenant sendo implantado ou integrado.
• Terceiro: dependência de fornecedor externo, sistema governamental ou provedor de infraestrutura.

Por criticalidade:

• Bloqueadora: impede o início ou a continuação de uma atividade do caminho crítico.
• Condicionante: não bloqueia imediatamente, mas precisa ser resolvida antes de uma data específica para não impactar o prazo.
• Informacional: necessária para refinamento ou tomada de decisão, sem impacto imediato no cronograma.

57.9.2 Processo de Gestão de Dependências

Toda dependência identificada é registrada no sistema de gestão com:

• descrição da dependência;
• origem (interna, PRODEMGE, órgão, terceiro);
• criticalidade;
• atividade bloqueada ou condicionada;
• responsável pela resolução;
• prazo limite para resolução sem impacto no cronograma;
• status atual.

Dependências externas (PRODEMGE, órgão, terceiro) são comunicadas ao responsável no momento do registro e acompanhadas a cada ciclo de status report. Dependências não resolvidas no prazo são escaladas automaticamente para o nível de gestão seguinte — GP para Gestor Técnico PRODEMGE; Gestor Técnico para Fiscal de Contrato.

O impacto de dependência não resolvida é registrado formalmente e refletido no cronograma. A Parceira não é responsabilizada por atrasos causados por dependências externas não cumpridas no prazo acordado.

57.9.3 Resolução de Impedimentos

Impedimentos internos — bloqueios que a equipe não consegue resolver autonomamente — são escalados ao GP no mesmo dia de identificação. O GP tem prazo de 24 horas para resolver ou escalar. Impedimentos não resolvidos em 48 horas são registrados no relatório de status e discutidos na próxima reunião de acompanhamento.

57.10 Gestão do Backlog de Projetos

O backlog de um projeto é gerenciado pelo Gestor de Produto com suporte do GP e do Tech Lead. Ele é organizado em três níveis:

Épicos: grandes blocos de valor — por exemplo, "Implantação do módulo de agendamentos para o órgão X" ou "Integração com o sistema Y".

Histórias de Usuário: unidades de valor entregável, escritas na perspectiva do usuário final ou do operador do sistema, com critérios de aceite explícitos. Toda história deve ser independente o suficiente para ser entregue e demonstrada isoladamente.

Tarefas Técnicas: decomposição interna da história para o time de desenvolvimento. Não visíveis externamente, mas rastreáveis internamente.

57.10.1 Critérios de Aceite por História

Toda história no backlog possui critérios de aceite definidos antes de entrar no sprint. Os critérios seguem o formato:

DADO [contexto ou estado inicial]
QUANDO [ação do usuário ou evento]
ENTÃO [resultado esperado]

Critérios ambíguos ou ausentes bloqueiam a inclusão da história no sprint planning. A responsabilidade de garantir critérios completos é do Gestor de Produto, com validação do Tech Lead para viabilidade técnica.

57.10.2 Priorização

A priorização do backlog considera quatro fatores:

• Valor ao negócio: impacto na operação do tenant ou na missão do órgão.
• Urgência: prazo contratual, regulatório ou operacional.
• Risco de adiamento: o que piora se não for feito agora.
• Esforço: custo de implementação em pontos de história, com preferência por alto valor / baixo esforço na ausência de outros critérios dominantes.

A priorização é de responsabilidade do Gestor de Produto, ratificada pelo GP, e comunicada à PRODEMGE nas reuniões de acompanhamento. Mudanças de prioridade que impactam escopo ou prazo são formalizadas como solicitação de mudança conforme o processo do Capítulo 59.

57.11 Fluxo de Entrega: Da Demanda à Produção

Demanda identificada (órgão, PRODEMGE, roadmap, incidente)
        │
Registro no backlog da parceria (Gestor de Produto)
        │
Refinamento e estimativa (GP, Tech Lead, equipe)
        │
Priorização e inclusão no sprint (Gestor de Produto)
        │
Sprint Planning → Sprint (2 semanas) → Sprint Review
        │
Definition of Done verificada (QA + Tech Lead)
        │
Deploy em staging + testes de regressão
        │
Gate 3: entrega interna aprovada
        │
Deploy em ambiente de homologação
        │
Validação pela PRODEMGE (D+5 a D+10)
        │
Gate 4: aceite formal emitido
        │
Deploy em produção (janela acordada, conforme Capítulo 59)
        │
Monitoramento pós-deploy (72 horas)
        │
Encerramento do item no backlog

O deploy em produção é um evento controlado, não uma consequência automática do aceite. Ele segue o processo de gestão de mudanças do Capítulo 59, com janela acordada, plano de rollback testado e monitoramento pós-deploy estruturado.

57.12 Gestão de Portfólio de Projetos

A parceria executa múltiplos projetos em paralelo ao longo dos sessenta meses. A gestão de portfólio garante que os projetos sejam gerenciados não apenas individualmente, mas em sua relação mútua — compartilhamento de recursos, dependências cruzadas e alinhamento com o roadmap.

57.12.1 Registro de Portfólio

O Registro de Portfólio é uma visão consolidada de todos os projetos ativos, com:

• nome e categoria do projeto;
• GP responsável;
• fase atual e indicador de saúde;
• data prevista de encerramento;
• recursos alocados;
• dependências com outros projetos ativos.

O registro é atualizado semanalmente pelo GP coordenador de portfólio e apresentado na Reunião de Governança mensal (Capítulo 56).

57.12.2 Priorização de Portfólio

Quando há conflito de recursos entre projetos, a priorização segue esta ordem:

1. Adequações regulatórias ou contratuais com prazo definido.
2. Projetos com impacto direto em SLA ou continuidade operacional.
3. Implantações de tenant com compromisso contratual de data.
4. Entregas funcionais do roadmap por horizonte.
5. Iniciativas arquiteturais e de pagamento de dívida técnica.

Conflitos que não podem ser resolvidos pelo GP coordenador de portfólio são escalados para o Comitê Executivo da parceria (Capítulo 56).

57.12.3 Capacidade de Desenvolvimento

A capacidade disponível de desenvolvimento por ciclo é rastreada e protegida conforme os seguintes limites:

Esses limites são verificados a cada sprint planning. Projetos que, somados, excederiam a capacidade disponível de novos desenvolvimentos são redimensionados ou repriorizados antes do início do sprint — não durante a execução.

57.13 Rastreabilidade de Entregas

Toda entrega produzida na parceria é rastreável à sua origem:

• Ao requisito: cada história no backlog referencia o requisito do Chamamento (Anexo III, IV ou V), o item do roadmap (Capítulo 54) ou a demanda operacional (Capítulo 52) que a originou.
• Ao código: cada história tem referência ao pull request ou tag de versão que a implementa.
• À entrega: cada item tem referência ao sprint e ciclo em que foi entregue.
• Ao aceite: cada entrega tem referência ao aceite formal da PRODEMGE.
• À produção: cada entrega tem referência à change request (Capítulo 59) que a levou a produção.

Essa cadeia de rastreabilidade permite, a qualquer momento, responder: "Qual versão em produção atende ao requisito X do Chamamento?" — e "Qual requisito do Chamamento está implementado nesta funcionalidade?"

57.14 Boas Práticas

A gestão de projetos nesta parceria é regida por princípios que derivam da experiência acumulada em projetos de plataformas governamentais de escala similar:

Escopo antes de prazo. O escopo é definido com clareza antes de comprometer qualquer data. Prazos negociados antes de escopo definido são estimativas de ficção.

Critérios de aceite antes de desenvolvimento. Nenhuma história entra em sprint sem critérios de aceite aprovados. Desenvolver sem critérios claros é construir para retrabalho.

Visibilidade contínua. A PRODEMGE nunca fica sem informação de progresso por mais de uma semana. Surpresas na entrega são o sintoma de transparência insuficiente durante a execução.

Impedimentos resolvidos, não gerenciados. Um impedimento gerenciado por semanas sem resolução não é gestão de impedimento — é tolerância a bloqueio. O GP tem responsabilidade ativa de remover bloqueios, não apenas de registrá-los.

Entregas funcionando, não concluídas. "Concluído" sem a Definition of Done verificada não é conclusão — é débito disfarçado. A DoD existe para proteger a cadeia de qualidade, não para burocratizar o fluxo.

Lições aprendidas como ativo, não ritual. O Registro de Lições Aprendidas alimenta o planejamento dos próximos projetos. Uma parceria de sessenta meses que não aprende sistematicamente dos próprios projetos desperdiça o principal ativo acumulado: o conhecimento sobre como executar neste contexto específico.

57.15 Justificativas Técnicas das Decisões

Ciclos de duas semanas. Sprints de duas semanas equilibram frequência de feedback com custo de cerimônia. Uma semana é curto demais para entregas com complexidade técnica; três semanas é longo demais para manter visibilidade e ajustar curso rapidamente. Para iniciativas arquiteturais de longa duração, o sprint de duas semanas entrega incrementos verificáveis do objetivo maior — não o objetivo completo.

Gates formais entre fases. Em um projeto isolado, gates podem parecer burocracia. Em um portfólio com múltiplos projetos ativos e uma plataforma em produção, gates são pontos de controle que evitam que trabalho de baixa qualidade avance e crie retrabalho cascata. O custo do gate é menor que o custo do defeito descoberto na homologação — ou, pior, em produção.

Homologação separada da validação interna. A equipe que desenvolve não pode ser o árbitro final da qualidade. A homologação pela PRODEMGE introduz o olhar externo que identifica desvios de requisito que testes internos não capturam — não por falha técnica, mas porque internamente há viés de confirmação sobre o que foi construído.

Relatório de status semanal escrito. Reuniões de status são lentas e difíceis de consultar retrospectivamente. Um relatório escrito é assíncrono, auditável e cumulativo — ao final do projeto, constitui um histórico completo do progresso. O GP que produz bons relatórios escritos geralmente gera menos reuniões, não mais.

57.16 Trade-offs

57.17 Alternativas Descartadas

Modelo de gestão waterfall puro. O waterfall — com fases sequenciais longas e entrega apenas ao final — não é adequado para uma plataforma em evolução contínua com múltiplos tenants em produção. O custo de descobrir um desvio de requisito após meses de desenvolvimento é proibitivo. A iteratividade não é uma preferência metodológica — é uma exigência do contexto operacional.

Kanban sem sprints fixos. O Kanban puro oferece fluxo contínuo sem cerimônias de comprometimento. Para equipes que trabalham apenas em sustentação (Capítulo 52), é adequado. Para projetos com prazo, escopo e stakeholders externos, a ausência de comprometimento por sprint dificulta a previsibilidade e a comunicação de progresso com a PRODEMGE.

Autogestão sem GP designado. A ausência de um GP designado por projeto transfere o custo de coordenação para o Tech Lead — que passa a fazer gestão em vez de engenharia. Em projetos simples, isso pode funcionar temporariamente. Em projetos com dependências externas, múltiplos stakeholders e gates formais, a falta de um responsável dedicado pela gestão gera atrasos e desgaste que custam mais do que o papel do GP.

Homologação incorporada ao ciclo de desenvolvimento. Integrar a validação da PRODEMGE dentro do sprint elimina a separação entre execução e aceite. Na prática, cria pressão para que o representante da PRODEMGE participe de cada sprint review como árbitro de aceite — o que não escala para múltiplos projetos simultâneos e mistura dois papéis distintos: o de quem constrói e o de quem valida.

57.18 Riscos e Mitigações

57.19 Benefícios

Previsibilidade de entrega. O modelo de ciclos fixos com gates formais gera ritmo e previsibilidade. A PRODEMGE sabe quando esperar uma entrega e o que ela conterá — não por estimativa, mas por comprometimento verificável a cada sprint.

Qualidade controlada. A Definition of Done e os gates impedem que trabalho de baixa qualidade avance na cadeia. O custo de qualidade é pago no início — onde é menor — não na homologação ou em produção.

Transparência bilateral. O relatório de status semanal e as cerimônias regulares garantem que nenhuma das partes seja surpreendida. Problemas são identificados e comunicados quando ainda são gerenciáveis.

Rastreabilidade auditável. A cadeia requisito → história → código → aceite → produção permite demonstrar, a qualquer momento, que a plataforma atende aos requisitos do Chamamento — e onde cada requisito está implementado.

Aprendizado acumulado. O Registro de Lições Aprendidas transforma a experiência de execução em ativo da parceria. Ao longo de sessenta meses, esse ativo tem valor crescente — cada projeto subsequente se beneficia do conhecimento acumulado nos anteriores.

57.20 Impactos Arquiteturais

A gestão de projetos e entregas tem impacto direto sobre decisões arquiteturais:

Sobre ambientes: o ciclo de vida exige pelo menos três ambientes estáveis — desenvolvimento, staging e produção — com promoção controlada e processos de deploy alinhados com o pipeline de CI/CD (Capítulo 40).

Sobre feature flags: entregas progressivas — onde uma funcionalidade é entregue tecnicamente mas ativada gradualmente — dependem de infraestrutura de feature flags integrada ao ciclo de deploy. O framework de feature flags descrito no Capítulo 40 é condição habilitante para esse modelo.

Sobre versionamento: a rastreabilidade entre história e código pressupõe versionamento semântico consistente e tags por entrega, conforme tratado no Capítulo 58.

Sobre observabilidade: o monitoramento pós-deploy de 72 horas pressupõe dashboards e alertas configurados para os novos componentes antes da promoção para produção, conforme o Capítulo 41.

57.21 Integrações com Outros Componentes

A gestão de projetos e entregas integra-se com os seguintes processos e sistemas:

57.22 Relacionamento com Outros Capítulos

• Capítulo 54 — Roadmap Tecnológico: as iniciativas do roadmap são a origem primária dos projetos de entrega funcional e arquitetural.
• Capítulo 55 — Gestão da Evolução da Plataforma: define o processo de priorização de backlog que alimenta os projetos; complementar ao presente capítulo no que tange à cadência de evolução.
• Capítulo 56 — Governança da Parceria: instâncias de decisão que os projetos ativam em escalação; o portfólio de projetos é insumo da governança estratégica.
• Capítulo 58 — Gestão de Configuração e Custódia de Código: suporta a rastreabilidade entre entregas e versões de código.
• Capítulo 59 — Gestão de Mudanças: processo que governa a promoção das entregas para produção.
• Capítulo 60 — Gestão de Riscos: o registro de riscos do projeto é subconjunto do registro de riscos da parceria.
• Capítulo 61 — Matriz de Responsabilidades: papéis e responsabilidades na gestão de projetos são detalhados na matriz RACI.
• Capítulo 62 — Indicadores e Métricas de Desempenho: indicadores de desempenho de projetos — velocidade de entrega, taxa de sucesso de homologação, aderência a prazo — são apurados conforme o Capítulo 62.

57.23 Referências Internas

• Capítulo 40 — DevSecOps: pipeline de CI/CD e feature flags que habilitam o fluxo de entrega
• Capítulo 41 — Observabilidade: monitoramento pós-deploy e alertas de novos componentes
• Capítulo 48 — Implantação e Onboarding: projetos de implantação de tenant são uma categoria específica gerenciada por este capítulo
• Capítulo 50 — Capacitação: entregas com impacto em usuários acionam o processo de capacitação
• Capítulo 52 — Sustentação: interface entre chamados de manutenção e projetos formais
• Capítulo 53 — SLA: entregas não podem comprometer os SLAs ativos; janelas de deploy são acordadas com base nos compromissos de disponibilidade
• Capítulo 56 — Governança da Parceria: instâncias de escalação e revisão de portfólio
• Capítulo 59 — Gestão de Mudanças: processo que recebe as entregas homologadas para promoção a produção

57.24 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• A gestão estruturada de projetos e entregas operacionaliza o compromisso de execução ordenada e previsível da parceria ao longo dos sessenta meses de vigência.

Plano de Negócio (Anexo I):

• Item 5.11 — Estratégia de Evolução da Plataforma: gestão de backlog priorizado e compartilhado, processos formais de gestão de mudanças e implantação incremental são componentes do modelo de gestão de projetos descrito neste capítulo.
• Risco: Risco de execução na implantação — mitigado pela metodologia estruturada de implantação, fases de validação, cronograma com marcos e acompanhamento contínuo definidos neste capítulo.
• Risco: Desalinhamento na governança da parceria — mitigado pela definição clara de papéis (seção 57.5), cerimônias regulares (seção 57.8) e gates formais (seção 57.6).

Funcionalidades (Anexo III):

• Bloco 6 — Infraestrutura, Segurança e Governança: capacidade de incorporar novas funcionalidades de forma controlada e com rastreabilidade é evidenciada pelo ciclo de vida de projetos e pelo processo de rastreabilidade de entregas descritos neste capítulo.

Capacidades (Anexo IV):

• Bloco 3 — Capacidade de Implantação, Operação e Escala: o modelo de projetos de implantação de tenant (seção 57.4) e o ciclo de vida formal (seção 57.6) evidenciam capacidade de implantação estruturada e escalável.
• Bloco 4 — Capacidade de Atuação em Parceria: a estrutura de papéis compartilhados (seção 57.5), as cerimônias conjuntas (seção 57.8) e o processo de homologação pela PRODEMGE (seção 57.6.4) evidenciam modelo de parceria operacional e não apenas formal.

Sustentabilidade (Anexo V):

• A gestão estruturada de projetos com gates, Definition of Done e rastreabilidade garante que as entregas ao longo da parceria mantenham qualidade consistente — condição para a sustentabilidade técnica e operacional da plataforma ao longo dos sessenta meses.

57.25 Decisões Arquiteturais — ADR

57.26 Resumo

A gestão de projetos e entregas na parceria PRODEMGE é um processo estruturado, iterativo e transparente que cobre o ciclo completo desde a demanda até a entrega homologada em produção. O modelo organiza os projetos em quatro categorias — implantação de tenant, entrega funcional, iniciativa arquitetural e adequação regulatória — e os conduz por cinco fases com gates formais de passagem e critérios explícitos de avanço.

A execução em ciclos de duas semanas garante visibilidade contínua e capacidade de ajuste de curso. A Definition of Done protege a qualidade interna. A homologação pela PRODEMGE garante conformidade com os requisitos acordados. O relatório de status semanal assegura transparência bilateral sem depender de reuniões. A rastreabilidade full-chain vincula cada entrega ao requisito que a originou e à change request que a levou a produção.

O modelo não é uma abstração metodológica — é o mecanismo pelo qual a parceria transforma sessenta meses de vigência em valor entregue, rastreável e auditável.

57.27 Próximo Capítulo

O Capítulo 58 — Gestão de Configuração e Custódia de Código — descreve como o código-fonte, os artefatos de build, as configurações de ambiente e os contratos de API são versionados, custodiados e disponibilizados para a PRODEMGE ao longo da parceria, garantindo que a rastreabilidade de entregas descrita neste capítulo tenha a fundação técnica necessária no controle de versão.

57.28 Controle de Versão