Capítulo 55 — Gestão da Evolução da Plataforma

55.1 Objetivo do Capítulo

Este capítulo define os processos, rituais, critérios e mecanismos de governança pelos quais as iniciativas estratégicas do Roadmap Tecnológico — descritas no Capítulo 54 — são convertidas em entregas concretas: funcionalidades implantadas em produção, melhorias arquiteturais validadas, débito técnico reduzido e tenants informados sobre o que mudou e por quê.

A distinção entre roadmap e gestão da evolução é deliberada e estrutural. O roadmap é o instrumento estratégico — define direções, marcos de maturidade e horizontes de cinco anos. A gestão da evolução é o instrumento tático e contínuo — define como o trabalho é organizado, priorizado, desenvolvido, validado e entregue ciclo a ciclo, dentro das restrições operacionais vigentes.

Um roadmap sem gestão da evolução é intenção. Uma gestão da evolução sem roadmap é reatividade. A combinação dos dois é o que transforma compromissos de parceria em valor mensurável.

55.2 Contexto

A plataforma opera em ambiente multi-tenant de missão pública. Cada mudança pode afetar simultaneamente dezenas de órgãos e milhares de cidadãos. Isso cria uma exigência estrutural que distingue a gestão da evolução de uma plataforma pública de governo da gestão de um produto comercial comum: a evolução deve ser contínua sem ser disruptiva, rápida sem ser imprudente, e visível sem ser burocrática.

Ao mesmo tempo, a plataforma é produto de uma parceria entre a PRODEMGE e a parceira tecnológica — não de um único dono de produto com controle total das decisões. Isso exige que os processos de gestão da evolução incluam instâncias de alinhamento, aprovação e comunicação que preservem a clareza de papéis entre as partes ao longo dos sessenta meses de vigência.

O ponto de partida não é o zero. A plataforma parte de uma base já operacional, com arquitetura, módulos funcionais e processos de desenvolvimento estabelecidos. A gestão da evolução constrói sobre essa base, formalizando e evoluindo os processos que já existem e introduzindo os mecanismos de governança que a escala da parceria exige.

55.3 Escopo

O capítulo cobre:

• princípios que governam como a evolução é gerida;
• estrutura do backlog de evolução e suas fontes de alimentação;
• critérios de priorização de itens de backlog;
• cadência de ciclos de desenvolvimento e cerimônias associadas;
• critérios de aceite e processo de validação;
• processo de comunicação de evolução para tenants;
• gestão de dívida técnica dentro do ciclo;
• métricas de desempenho do processo de evolução;
• relação com o Roadmap Tecnológico (Capítulo 54), o processo de Gestão de Mudanças (Capítulo 59) e a Governança da Parceria (Capítulo 56).

Não são escopo deste capítulo: o conteúdo detalhado de cada horizonte do roadmap (Capítulo 54), os protocolos de mudança em produção (Capítulo 59), os processos de suporte a incidentes (Capítulo 52) nem os rituais de governança estratégica da parceria (Capítulo 56).

55.4 Princípios da Gestão da Evolução

A gestão da evolução é orientada por princípios que definem como as decisões são tomadas, não apenas o que é entregue.

Valor antes de volume. A quantidade de itens entregues por ciclo não é indicador de saúde do processo. O valor gerado para os tenants e para os cidadãos é. Um ciclo com três entregas de alto impacto é superior a um ciclo com doze entregas de impacto marginal.

Backlog como instrumento de decisão, não de acumulação. Um backlog que cresce indefinidamente sem critério de priorização e descarte é um depósito de intenções, não um instrumento de gestão. Itens sem data de relevância esperada e sem impacto estimado são removidos ativamente do backlog.

Dívida técnica como item de primeira classe. Refatorações, atualizações de dependências, melhoria de cobertura de testes e documentação de componentes são itens de backlog com a mesma dignidade de novas funcionalidades. Não são postergados indefinidamente para dar espaço a features — são garantidos por reserva mínima de capacidade por ciclo.

Transparência bidirecional. A PRODEMGE tem visibilidade sobre o que está no backlog, o que foi priorizado para o ciclo e o que foi entregue. Os tenants têm visibilidade sobre o que muda na plataforma antes que a mudança chegue à produção. Não há entregas surpresa.

Aceite como controle, não como formalidade. Cada entrega tem critérios de aceite definidos antes do desenvolvimento começar. O aceite é verificado por evidência — testes automatizados, validação funcional em homologação, confirmação de tenant quando aplicável — não por declaração.

Ciclo fechado com aprendizado. Cada ciclo termina com revisão retrospectiva: o que foi entregue, o que não foi e por quê, o que o time aprendeu e o que muda no próximo ciclo. Sem retrospectiva, o ciclo se fecha sem o aprendizado que justifica a disciplina.

55.5 Fontes de Alimentação do Backlog

O backlog de evolução é alimentado por cinco fontes estruturadas, cada uma com canal de entrada e critério de registro.

55.5.1 Roadmap Tecnológico

As iniciativas estratégicas dos cinco horizontes do Capítulo 54 são decompostas em épicos e histórias de usuário no backlog. Cada horizonte fornece o conjunto de itens candidatos para os ciclos que o compõem. A decomposição é responsabilidade da parceira, com revisão e alinhamento da PRODEMGE nas reuniões do Comitê de Evolução.

55.5.2 Demandas dos Tenants

Órgãos participantes encaminham solicitações de novas funcionalidades, ajustes de fluxo e melhorias de experiência por meio de formulário estruturado no Portal de Atendimento. O formulário captura: descrição da demanda, contexto de uso, impacto esperado, urgência estimada e se a demanda é exclusiva do tenant ou de potencial interesse para outros órgãos.

Demandas de múltiplos tenants sobre o mesmo tema são consolidadas antes de entrar no backlog — a versão consolidada representa a necessidade comum com escopo extensível, não a soma de implementações específicas.

55.5.3 Histórico de Operação e SLA

O histórico de incidentes, os desvios de SLA recorrentes e as análises de postmortem geram itens de backlog de melhoria arquitetural e operacional. Conforme o ADR-1606 do Capítulo 54, componentes com desvio de SLA recorrente têm prioridade máxima de melhoria — novas funcionalidades no mesmo componente são bloqueadas até estabilização.

55.5.4 Monitoramento Tecnológico e Regulatório

A parceira mantém processo contínuo de acompanhamento do ecossistema tecnológico — atualizações de frameworks, novas versões de dependências, mudanças em provedores de IA, novas vulnerabilidades — e do ambiente regulatório — mudanças na LGPD, novas normas de acessibilidade, diretrizes do governo digital. Itens identificados por esse monitoramento entram no backlog com categoria "adaptativa" e prazo de relevância estimado.

55.5.5 Revisões Internas de Qualidade

Revisões técnicas periódicas — auditoria de código, análise de cobertura de testes, revisão de documentação, avaliação de coesão arquitetural — geram itens de dívida técnica. Esses itens entram no backlog com categoria "técnica" e são agrupados por domínio para facilitar a alocação durante o ciclo.

55.6 Estrutura do Backlog

O backlog é organizado em quatro níveis hierárquicos, do mais estratégico ao mais operacional:

A PRODEMGE tem visibilidade até o nível de épico no backlog compartilhado. O nível de tarefa é interno à equipe de desenvolvimento da parceira.

O backlog compartilhado é mantido em ferramenta de gestão de produto acordada entre as partes, com acesso de leitura permanente para a PRODEMGE e acesso de escrita controlado para evitar modificações não coordenadas.

55.7 Critérios de Priorização

A priorização do backlog para cada ciclo considera cinco dimensões, ponderadas conforme a fase da parceria e o estado operacional da plataforma:

Itens com urgência regulatória ou de segurança têm override automático de prioridade — entram no ciclo corrente independentemente do planejamento existente, com realocação de capacidade quando necessário.

A priorização é realizada pela parceira com insumos da PRODEMGE e dos tenants. Divergências de prioridade entre parceira e PRODEMGE são resolvidas no Comitê de Evolução, com registro formal de decisão. Não há priorização unilateral de itens que afetem o escopo do roadmap sem alinhamento.

55.7.1 Reserva Mínima de Capacidade

Independentemente da priorização de funcionalidades, cada ciclo reserva capacidade mínima para categorias não negociáveis:

A reserva de 20% para dívida técnica é estabelecida no ADR-1602 do Capítulo 54 e não é negociável por pressão de prazo ou demanda de tenant. É a garantia estrutural de que a velocidade de entrega dos próximos horizontes não será comprometida pela acumulação de débito do horizonte atual.

55.8 Cadência de Ciclos

55.8.1 Estrutura de Ciclo

A evolução da plataforma segue cadência regular de ciclos de desenvolvimento com cerimônias estruturadas. O ciclo padrão tem duração de duas semanas (sprint), com possibilidade de ciclos de quatro semanas para épicos de maior escopo que beneficiem de menor fragmentação.

A cadência é acordada entre parceira e PRODEMGE no início de cada horizonte e ajustada quando evidências operacionais indicam que a frequência corrente não é ótima.

55.8.2 Cerimônias

55.8.3 Comprometimento de Ciclo

O escopo comprometido para cada ciclo é definido no planejamento com base na capacidade da equipe (velocity medida nos ciclos anteriores) e na priorização do backlog refinado. O comprometimento é realista — não é meta de esforço máximo, é previsão de entrega com margem de confiança.

Itens não concluídos no ciclo são analisados na retrospectiva: se o impedimento foi técnico, regulatório ou estimativa imprecisa. A análise retroalimenta o refinamento do próximo ciclo — estimativas sistematicamente erradas indicam problema no processo de refinamento, não na equipe.

55.9 Processo de Desenvolvimento

55.9.1 Critério de Definição de Pronto (Definition of Ready)

Um item de backlog só entra no planejamento de ciclo quando satisfaz os critérios de Definition of Ready:

• descrição funcional clara com contexto de uso;
• critérios de aceite definidos e testáveis;
• dependências técnicas identificadas e resolvidas ou com plano de resolução no ciclo;
• estimativa de esforço acordada pela equipe;
• impacto em segurança, LGPD e multi-tenancy avaliado;
• impacto em outros tenants avaliado e comunicação planejada quando necessário.

Itens sem Definition of Ready não entram no ciclo — são retornados ao refinamento. Isso evita que trabalho mal especificado consuma capacidade sem gerar valor verificável.

55.9.2 Critério de Definição de Concluído (Definition of Done)

Um item de backlog é considerado concluído quando satisfaz todos os critérios de Definition of Done:

• código revisado por par (pull request com aprovação mínima de dois revisores);
• cobertura de testes unitários e de integração acima do limiar definido por módulo;
• testes de isolamento multi-tenant executados e aprovados;
• análise estática de segurança (SAST) sem bloqueadores;
• documentação técnica atualizada (OpenAPI, contratos de evento, ADR quando aplicável);
• deploy em Integration concluído sem regressão;
• deploy em Homologation concluído;
• release notes redigidos e publicados na Central de Conhecimento;
• aceite funcional registrado.

A Definition of Done é uniforme para todos os itens — não há itens "quase prontos" ou "prontos com ressalvas". Um item que não satisfaz todos os critérios não está concluído e não é contabilizado como entrega do ciclo.

55.9.3 Desenvolvimento em Branch

O desenvolvimento segue modelo de branching com branch principal protegida (main/trunk), branches de feature por item de backlog e integração contínua com execução automática de pipeline a cada pull request. Branches de longa duração são evitadas — itens grandes são decompostos em histórias menores que podem ser integradas incrementalmente com feature flags quando necessário para controlar a exposição ao tenant.

Feature flags permitem que código integrado seja desabilitado em produção até que a funcionalidade esteja completamente pronta para exposição. Isso desacopla o deploy do código da ativação da funcionalidade — uma prática que reduz o risco de rollback e permite rollout gradual por tenant.

55.10 Validação e Aceite

55.10.1 Ambientes de Validação

A validação de cada entrega percorre três ambientes antes de produção, conforme descrito no Capítulo 11:

Dados produtivos não são copiados para ambientes não-produtivos. Homologation usa dados sintéticos que representam a diversidade de cenários sem expor informações reais de cidadãos ou órgãos.

55.10.2 Processo de Aceite com PRODEMGE

Para itens de maior escopo funcional — novos módulos, mudanças significativas em fluxos existentes, capacidades de IA promovidas à produção — o aceite formal pela PRODEMGE é condição para o deploy em produção. O processo de aceite segue as etapas:

Demonstração em Homologation (revisão de ciclo)
        │
Período de validação pela PRODEMGE (mínimo 3 dias úteis)
        │
Registro formal de aceite ou lista de pendências
        │
        ├─ Aceite: item aprovado para deploy em produção
        │
        └─ Pendências: itens corrigidos e resubmetidos para validação
                │
                └─ Aceite após correção

O período de validação é proporcional à complexidade da entrega — itens simples podem ter aceite na própria reunião de revisão de ciclo; módulos novos ou mudanças arquiteturais podem requerer período de validação estendido acordado no planejamento.

55.10.3 Aceite por Tenant

Para funcionalidades desenvolvidas com escopo específico de tenant — customizações de fluxo, integrações com sistemas do órgão, configurações particulares — o aceite do representante técnico do tenant é requerido antes da ativação em produção para aquele órgão. O aceite por tenant não bloqueia o deploy para outros tenants que não utilizam a funcionalidade em questão.

55.11 Gestão de Dívida Técnica

55.11.1 Identificação e Registro

A dívida técnica é identificada por três mecanismos:

• revisões de código que identificam oportunidades de refatoração não abordadas no momento por restrição de prazo;
• alertas de análise estática (SAST, SCA) sobre padrões de código que não atingem o limiar de qualidade definido;
• revisões técnicas periódicas de componentes — realizadas trimestralmente pela equipe de arquitetura — que avaliam coesão, cobertura de testes, documentação e aderência às decisões arquiteturais vigentes (ADRs).

Todo item de dívida técnica identificado é registrado no backlog com categoria "técnica", descrição do problema, componente afetado e impacto esperado se não tratado. Dívida não registrada não existe para o processo de priorização.

55.11.2 Priorização da Dívida Técnica

A dívida técnica é priorizada dentro da reserva de 20% de cada ciclo. A priorização considera:

• dívida que bloqueia ou desacelera entregas do roadmap corrente (prioridade máxima dentro da categoria);
• dívida em componentes com histórico de incidentes ou desvio de SLA;
• dívida com prazo de relevância — dependências próximas do fim de suporte, por exemplo;
• dívida de baixo custo com alto impacto na qualidade ou na velocidade futura.

Dívida de baixo impacto e sem prazo de relevância pode permanecer no backlog por múltiplos ciclos — mas não indefinidamente. Itens de dívida com mais de seis meses sem endereçamento são reavaliados: ou são priorizados, ou são explicitamente aceitos como risco gerenciado, ou são descartados por irrelevância.

55.11.3 Pagamento Planejado versus Emergencial

O tratamento ideal da dívida técnica é planejado: itens identificados, estimados e alocados na reserva do ciclo com antecedência. O tratamento emergencial — quando uma dívida não tratada causa incidente ou bloqueio — é mais custoso: interrompe o planejamento do ciclo, consome capacidade de imprevistos e muitas vezes exige retrabalho nos itens que dependiam do componente afetado.

O processo de identificação e registro contínuo de dívida técnica é a principal ferramenta para manter o tratamento no modo planejado.

55.12 Comunicação de Evolução para Tenants

55.12.1 Princípio de Antecipação

Tenants nunca são surpreendidos por mudanças na plataforma. A comunicação de evolução é proativa e antecipada — chega ao administrador do tenant antes que a mudança chegue ao ambiente de produção.

55.12.2 Release Notes

Para cada release com impacto funcional perceptível, release notes são publicados na Central de Conhecimento antes do deploy em produção. Os release notes incluem:

• versão e data prevista de deploy;
• resumo das mudanças por módulo;
• impacto por perfil de usuário (atendente, gestor, cidadão, administrador);
• comportamentos que mudam em relação à versão anterior;
• itens que requerem ação do administrador do tenant (reconfiguração, comunicação a usuários);
• link para materiais de capacitação atualizados.

Release notes são redigidos em linguagem funcional — acessível ao administrador do órgão, não apenas ao técnico. Jargão de implementação é removido ou explicado.

55.12.3 Comunicação Direta

Para mudanças que alteram fluxos críticos ou que requerem ação do tenant, a publicação de release notes é complementada por comunicação direta ao representante técnico do órgão:

55.12.4 Comunicação de Descontinuação

A descontinuação de funcionalidades ou comportamentos segue protocolo específico, alinhado ao ADR-1604 do Capítulo 54:

• notificação formal ao tenant com antecedência mínima de trinta dias úteis;
• período de coexistência entre o comportamento antigo e o novo, com data de remoção comunicada;
• confirmação de que o tenant não depende do comportamento descontinuado antes da remoção;
• suporte da parceira na migração quando a descontinuação exige adaptação pelo tenant.

Nenhuma funcionalidade é removida sem confirmação de que todos os tenants que a utilizam foram migrados ou estão cientes da descontinuação.

55.13 Comitê de Evolução

55.13.1 Composição

O Comitê de Evolução é o fórum de governança tática do processo de evolução da plataforma. Reúne mensalmente representantes da parceira e da PRODEMGE para revisão de backlog, alinhamento de prioridades e decisões sobre desvios do planejamento.

55.13.2 Pauta Padrão

A pauta mensal do Comitê de Evolução cobre:

• revisão do ciclo concluído: o que foi entregue versus o que foi comprometido, e as razões de qualquer desvio;
• apresentação do estado atual do backlog: tamanho, composição por categoria, itens novos desde o último comitê;
• proposta de priorização para o próximo ciclo: itens candidatos com justificativa de prioridade;
• alertas de capacidade: itens do horizonte corrente em risco de não serem entregues no prazo esperado;
• demandas de tenant em análise: status de avaliação e expectativa de priorização;
• itens regulatórios ou de segurança identificados desde o último comitê.

55.13.3 Registro e Rastreabilidade

Cada reunião do Comitê de Evolução é registrada em ata com: participantes, decisões tomadas, itens priorizados, itens postergados com justificativa, e próximos passos com responsável e prazo. A ata é compartilhada entre as partes em até dois dias úteis após a reunião e integra o repositório de governança da parceria.

55.14 Métricas do Processo de Evolução

O desempenho do processo de gestão da evolução é medido por indicadores que cobrem tanto a eficiência do processo quanto a qualidade das entregas.

Os indicadores são revisados mensalmente no Comitê de Evolução. Desvios recorrentes de uma mesma métrica indicam problema no processo — não na equipe — e disparam revisão do mecanismo específico.

55.15 Relação com Outros Processos

55.15.1 Roadmap Tecnológico (Capítulo 54)

O roadmap fornece as iniciativas estratégicas que alimentam o backlog de evolução. A gestão da evolução converte essas iniciativas em itens de backlog, os prioriza por ciclo e os entrega. O roadmap é estático entre revisões trimestrais — a gestão da evolução é dinâmica a cada ciclo. Mudanças no roadmap requerem aprovação formal no Comitê de Revisão de Roadmap (Capítulo 56); mudanças na priorização interna de ciclos são responsabilidade da parceira com ciência da PRODEMGE no Comitê de Evolução.

55.15.2 Gestão de Mudanças (Capítulo 59)

O processo de Gestão de Mudanças do Capítulo 59 governa como cada entrega do ciclo é promovida ao ambiente de produção: aprovação do CAB, classificação de risco, janela de execução, comunicação e rollback. A gestão da evolução alimenta o pipeline de mudanças — cada item concluído no ciclo é um candidato à mudança em produção. Os dois processos são complementares e não sobrepostos: a gestão da evolução gerencia o que é desenvolvido; a gestão de mudanças gerencia como é implantado.

55.15.3 Sustentação e Suporte (Capítulo 52)

Chamados de manutenção evolutiva — solicitações de melhorias encaminhadas pelos tenants por meio do suporte — são promovidos ao backlog de evolução quando aprovados para desenvolvimento. O processo de suporte é o canal de entrada dessas demandas; o backlog de evolução é onde elas competem por prioridade com as demais iniciativas. Chamados de incidente que revelam dívida técnica relevante geram itens de backlog de categoria técnica.

55.15.4 Capacitação e Transferência de Conhecimento (Capítulo 50)

A cada release com impacto funcional, os materiais de capacitação da Central de Conhecimento são atualizados antes do deploy em produção. Esse requisito está incluso na Definition of Done de itens funcionais. A atualização de documentação técnica — OpenAPI, contratos de evento, ADRs, runbooks — também é critério de conclusão, não atividade opcional pós-entrega.

55.16 Gestão de Capacidade da Equipe de Evolução

55.16.1 Estrutura da Equipe

A equipe de evolução da plataforma é organizada por domínios funcionais alinhados à arquitetura de microsserviços, com squads responsáveis por conjuntos coesos de serviços e módulos. Cada squad tem autonomia para desenvolver e entregar dentro do seu domínio sem dependência operacional de outros squads — a coordenação entre squads ocorre por contratos de API e eventos, não por acoplamento de desenvolvimento.

55.16.2 Planejamento de Capacidade

A capacidade disponível por ciclo é planejada com base na composição atual das equipes, considerando férias, licenças e outros fatores de disponibilidade. O planejamento de capacidade é insumo direto do planejamento de ciclo — o backlog priorizado é comprometido até o limite da capacidade disponível, nunca além.

Quando iniciativas do roadmap demandam capacidade além da equipe corrente — por complexidade técnica ou prazo acumulado —, o planejamento de reforço de equipe é iniciado com antecedência mínima de dois ciclos, para que o onboarding de novos membros não impacte a entrega do ciclo em curso.

55.16.3 Dependências Externas

Itens de backlog com dependências de sistemas externos — APIs da PRODEMGE, sistemas legados dos órgãos, provedores de IA, integrações com ecossistema de governo — têm rastreamento explícito de status da dependência. Itens bloqueados por dependência externa são sinalizados no backlog e comunicados ao Comitê de Evolução. O rastreamento de dependências externas é responsabilidade do Product Owner da plataforma.

55.17 Riscos e Mitigações

55.18 Decisões Arquiteturais — ADR

55.19 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• Evolução tecnológica contínua e incorporação de novas funcionalidades ao longo da vigência: a gestão da evolução é o processo que operacionaliza esse compromisso ciclo a ciclo.

Plano de Negócio (Anexo I):

• Item 3.4.5 — Evolução e Melhoria Contínua: os rituais de ciclo, o backlog compartilhado e o Comitê de Evolução são a implementação concreta da evolução e melhoria contínua.
• Item 5.11 — Estratégia de Evolução da Plataforma: backlog priorizado e compartilhado, implantação incremental com rollback e monitoramento contínuo são cobertos pelos processos deste capítulo.

Funcionalidades (Anexo III) — impacto na pontuação de 60%:

• Bloco 6 — Infraestrutura e Governança: gestão de mudanças estruturada, capacidade de incorporar novas funcionalidades sem comprometer a operação, versionamento controlado e evolução contínua são capacidades de governança avaliadas no Anexo III.

Capacidades (Anexo IV):

• Capacidade de entrega contínua com qualidade verificável por critérios de aceite formais.
• Capacidade de comunicação proativa de evolução para os tenants.

Sustentabilidade (Anexo V):

• A sustentabilidade do processo de desenvolvimento é garantida pela reserva de dívida técnica, pelos critérios de Definition of Done e pela retrospectiva sistemática — mecanismos que preservam a velocidade de entrega ao longo dos sessenta meses sem acumulação silenciosa de débito.

55.20 Referências Internas

• Capítulo 5 — Modelo de Negócio: estratégia de evolução e ciclo de vida da plataforma
• Capítulo 40 — DevSecOps: pipeline de entrega contínua que implementa o fluxo de desenvolvimento descrito neste capítulo
• Capítulo 50 — Capacitação: atualização de materiais como critério de Definition of Done
• Capítulo 51 — Operação: cadência de releases e comunicação de mudanças aos tenants
• Capítulo 52 — Sustentação: chamados de manutenção evolutiva como fonte de backlog
• Capítulo 53 — SLA: histórico de cumprimento como insumo de priorização
• Capítulo 54 — Roadmap Tecnológico: fonte das iniciativas estratégicas que alimentam o backlog
• Capítulo 56 — Governança da Parceria: instâncias de aprovação de mudanças no roadmap
• Capítulo 59 — Gestão de Mudanças: processo de implantação em produção das entregas do ciclo

55.21 Considerações Finais

A gestão da evolução da plataforma é o elo entre intenção e resultado. Um roadmap tecnológico ambicioso, sem o processo que converte suas iniciativas em entregas verificáveis a cada ciclo, é apenas uma declaração de intenções. Um processo de desenvolvimento disciplinado, sem o direcionamento estratégico do roadmap, é reatividade sem propósito.

Este capítulo define o processo que sustenta essa conexão: um backlog estruturado com fontes claras de alimentação, critérios de priorização explícitos, ciclos com comprometimento realista, Definition of Done que não negocia qualidade, e rituais de governança que mantêm parceira e PRODEMGE alinhadas ao longo dos sessenta meses.

A medida de sucesso desse processo não é a quantidade de itens entregues. É a trajetória de maturidade da plataforma ao longo dos cinco horizontes — funcionalidades mais ricas, arquitetura mais sólida, operação mais confiável e tenants mais capazes de servir seus cidadãos. É isso que a gestão da evolução deve produzir.

55.22 Próximo Capítulo

O Capítulo 56 — Governança da Parceria — define as instâncias, papéis, responsabilidades e mecanismos de decisão que governam a relação entre PRODEMGE e a parceira ao longo dos sessenta meses, incluindo as instâncias de aprovação de mudanças no roadmap e de resolução de divergências.

55.23 Controle de Versão