Politica de Gestão de Mudança
  • Entrar
    • ⚖️

    🧭 Política de Gestão de Mudanças de Software

    Versão: 1.1

    Data: 17/10/2025

    Responsável pela aprovação: Gestor de Projetos

    Revisão: Semestral

    1. Objetivo

    Esta política tem como objetivo padronizar o processo de Gestão de Mudanças de Software nos sistemas mantidos e desenvolvidos internamente, garantindo que todas as alterações sejam controladas, documentadas e rastreáveis, minimizando riscos e assegurando a qualidade das entregas.

    Inclui também o controle e a validação de mudanças em objetos de dados, views SQL e dashboards criados pela equipe de Análise de Dados dentro do Odoo e nos bancos de dados relacionados.

    2. Escopo

    Aplica-se a todas as mudanças realizadas no Odoo v17 e sistemas integrados, abrangendo:

    • Ajustes e melhorias evolutivas em módulos do ERP;
    • Desenvolvimento de novas funcionalidades e telas;
    • Criação e alteração de views no banco de dados;
    • Construção e atualização de dashboards e relatórios analíticos;
    • Correção de bugs e falhas em produção (hotfixes);
    • Alterações em configurações, integrações e dados críticos.

    Envolve os times de:

    • Suporte N1 (triagem e priorização);
    • Analistas de Sistemas (análise técnica e funcional);
    • Desenvolvedores (DEV) (implementação e testes);
    • Equipe de Análise de Dados (tratamento de dados, modelagem e visualização);
    • Gestor de Projetos (coordenação, acompanhamento e aprovação final).

    3. Classificação das Mudanças

    TipoDescriçãoExemploAprovação
    Evolutiva (Melhoria)Ampliação de funcionalidades existentes ou ajustes sugeridos por usuários.Novo campo em cadastro, ajuste em fluxo de compras.Gestor de Projetos
    Corretiva (Bug / Hotfix)Correção imediata de erros em produção.Erro em regra de cálculo, falha em relatório.Analista + Gestor
    Projetos EspecíficosMudanças estruturais ou de alto impacto, tratadas como projeto.Novo módulo, integração ou reestruturação de dados.Comitê do Projeto
    Configuração / ParametrizaçãoAlterações sem impacto direto de código.Ajuste de regra fiscal ou parâmetro de módulo.Analista
    Analítica / DadosCriação, ajuste ou exclusão de views SQL, consultas e dashboards analíticos.View para indicadores de vendas, painel de performance logística.Analista de Dados + Gestor

    4. Papéis e Responsabilidades

    PapelResponsabilidade
    Suporte N1Realizar triagem das solicitações e identificar se é suporte, melhoria ou bug crítico.
    Analista de Sistemas SêniorAvaliar impacto funcional e técnico, documentar requisitos, planejar implantação e validar entregas.
    Desenvolvedor (DEV)Implementar as mudanças no código, realizar testes e versionamento.
    Analista de DadosCriar, revisar e manter views SQL, consultas e dashboards; avaliar impacto em performance e segurança de dados.
    Gestor de ProjetosCoordenar o ciclo de vida das mudanças, aprovar liberações e validar release notes e documentação.

    5. Fluxo do Processo de Mudança

    5.1 Origem da Demanda

    • Todas as solicitações nascem no Suporte N1, via ticket no Odoo.
    • Caso a demanda envolva alteração funcional, de código ou de dados, é reclassificada como “Melhoria” e atribuída ao Analista de Sistemas ou ao Analista de Dados, conforme o caso.
    • Mudanças de grande impacto podem originar projetos específicos no Odoo.

    5.2 Análise e Planejamento

    • O responsável técnico avalia impactos, dependências e riscos.
    • A análise deve incluir:
      • Escopo da mudança;
      • Impactos funcionais e de dados;
      • Riscos de performance e integridade;
      • Plano de rollback;
      • Estimativa de esforço e prazo.

    5.3 Desenvolvimento e Testes

    • O DEV ou Analista de Dados implementa as alterações em ambiente de homologação.
    • São obrigatórios:
      • Versionamento no repositório;
      • Testes técnicos e funcionais;
      • Validação por pares ou Analista de Sistemas.

    5.4 Aprovação e Implantação

    • O Gestor de Projetos aprova a mudança e agenda a implantação.
    • Mudanças analíticas (views e dashboards) também passam por validação de performance e segurança antes de irem para produção.
    • Cada implantação deve ser registrada com seu respectivo Release Notes.

    5.5 Pós-Implementação

    • O responsável verifica o resultado em produção;
    • Documentação e versão são atualizadas;
    • Caso haja regressão ou impacto, aplica-se o rollback planejado.

    6. Gestão de Bugs e Hotfixes

    • Bugs críticos seguem fluxo emergencial;
    • O Suporte N1 aciona Analista e DEV ou Analista de Dados conforme o tipo de erro;
    • O hotfix é validado e aplicado em produção com registro no Odoo;
    • A correção é incorporada ao branch principal e documentada.

    7. Critérios de Aprovação

    Uma mudança só será aprovada se:

    • Tiver registro completo no Odoo;
    • Contiver evidências de teste e validação;
    • Estiver acompanhada de Release Notes;
    • Possuir plano de rollback;
    • No caso de dados, possuir validação de integridade e performance.

    8. Versionamento e Controle de Código

    Padrão: Semantic Versioning

    Formato: MAJOR.MINOR.PATCH (ex: v1.4.2)

    Branches:

    • main → Produção
    • develop → Homologação
    • feature/* → Novas funcionalidades
    • hotfix/* → Correções urgentes
    • data/* → Alterações específicas em views, queries e dashboards

    9. Release Notes

    Cada mudança registrada no Odoo deve conter:

    • Versão;
    • Data de liberação;
    • Descrição detalhada;
    • Responsáveis;
    • Ambiente de destino;
    • Tipo de mudança (Evolutiva, Corretiva, Analítica etc.);
    • Observações e plano de rollback.

    Exemplo:

    Versão: 1.4.2
Data: 23/10/2025
Tipo: Analítica
Descrição: Criação de view para acompanhamento de pedidos em atraso e novo dashboard logístico.
Responsáveis: Equipe de Análise de Dados
Ambiente: Produção
Status: Implantado

    10. Governança e Monitoramento

    • O Gestor de Projetos revisará mensalmente as mudanças aplicadas;
    • Indicadores de desempenho incluem:
      • Total de mudanças concluídas;
      • Percentual de sucesso sem rollback;
      • Tempo médio de aprovação;
      • Volume de hotfixes aplicados;
      • Volume de alterações analíticas implementadas.
    • Revisão formal da política a cada 6 meses.

    11. Boas Práticas Complementares

    • Padronizar nomenclaturas de views e dashboards para facilitar manutenção e rastreabilidade;
    • Evitar queries diretas em produção sem validação prévia de performance;
    • Documentar fontes de dados e indicadores em wiki interna;
    • Validar permissões de acesso a dashboards sensíveis;
    • Manter integração entre Análise de Dados e DEV para alinhar dependências de estrutura e versionamento.

    ✅ Conclusão

    Com esta atualização, a Política de Gestão de Mudanças passa a contemplar todo o ciclo de software e dados, garantindo que alterações em código, processos e informações analíticas sigam um mesmo padrão de qualidade, rastreabilidade e controle.