Politica Administração de Projetos de Sistemas
  • Entrar
    • 📘

    Documento de Referência – Administração de Projetos de Sistemas

    Versão 1.0

    Baseado no Odoo 17 + Framework Scrum Adaptado

    1. Objetivo

    Este documento estabelece padrões obrigatórios para a execução, acompanhamento e entrega de projetos de software na área de Sistemas, utilizando o módulo de Projetos do Odoo como ferramenta central de gestão.

    O objetivo é garantir:

    • Rastreabilidade de requisitos;
    • Conformidade com processos corporativos (ITs, LGPD, auditoria);
    • Entregas previsíveis e de qualidade;
    • Colaboração clara entre Analistas, Desenvolvedores, SGI, Stakeholders e Diretoria.

    2. Estrutura do Projeto no Odoo

    2.1 Estágios Padrão (Fases do Fluxo de Trabalho)

    Estágio

    Descrição

    Regras de transição

    A fazer

    Tarefas priorizadas, com requisitos claros, prontas para serem puxadas na Sprint.

    Só entra após aprovação do Analista de Sistemas e validação do backlog com stakeholders.

    Em Desenvolvimento

    Tarefa em execução pelo DEV. Inclui análise técnica, codificação e testes unitários.

    Só pode sair após conclusão da tarefaecriação da subtarefa de homologação.

    Bloqueado

    Tarefa impedida por dependência externa (ex: falta de dados, aprovação, ambiente).

    Deve conter no campo “Bloqueado por:” a causa e responsável pela desbloqueio.

    Homologação

    Tarefa pronta para validação pelosStakeholders(ex: Controladoria, Pricing, PMO).

    O Analista de Sistemas coordena o UAT (User Acceptance Test).

    Aguardando Deploy

    Tarefa validada e pronta para ir para Produção.

    Exige obrigatoriamente uma subtarefa chamada “Revisão das IT que envolvem esta tarefa”, atribuída àSGI, concluída antes do deploy.

    Finalizado

    Tarefa implantada em Produção com sucesso e aceita.

    Nenhum movimento após esse estágio, exceto para auditoria.

    ✅ Regra Crítica:

    Nenhuma tarefa pode ser movida para “Finalizado” sem passar por “Aguardando Deploy” e sem a conclusão da subtarefa de revisão das ITs pela SGI.

    3. Papéis e Responsabilidades

    Papel

    Responsabilidades

    Analista de Sistemas

    - Criar e organizar tarefas no Odoo com base no Kick-off;

    - Garantir que cada tarefa tenha: descrição clara, critérios de aceitação, horas alocadas, responsável, subtarefas obrigatórias (ex: IT);

    - Monitorar o cumprimento do escopo e prazo;

    - Garantir que cards não ultrapassem 20% do esforço estimado sem justificativa;

    - Acionar reuniões de alinhamento quando necessário.

    Desenvolvedor

    - Puxar tarefas da Sprint;

    - Validar se o escopo está claro e factível;

    - Alertar o Analista sobre requisitos ambíguos ou fora do escopo;

    - Movimentar o card entre estágios conforme o fluxo;

    - Criar a subtarefa “Homologação” ao final do desenvolvimento;

    - Garantir que o artefato atenda aos critérios de qualidade (testes, logs, performance).

    Analista de Projetos

    - Planejar e conduzir cerimônias Scrum;

    - Gerar Status Report Semanal para a Diretoria (visão macro: % conclusão, riscos, atrasos);

    - Gerenciar riscos de prazo e escopo;

    - Garantir que as entregas estejam alinhadas ao roadmap estratégico.

    Stakeholders (Áreas de Negócio)

    - Fornecer requisitos claros no Kick-off;

    - Homologar entregas no estágio “Homologação”;

    - Participar de reuniões de esclarecimento;

    - Reportar inconsistências ou falhas de entendimento imediatamente.

    SGI (Segurança/Gestão da Informação)

    - Revisar todas as tarefas em “Aguardando Deploy”;

    - Validar conformidade com as Instruções de Trabalho (ITs);

    - Concluir a subtarefa “Revisão das IT” antes do deploy;

    - Barrar o deploy caso haja não conformidade.

    4. Cerimônias Scrum Adaptadas

    Cerimônia

    Frequência

    Participantes

    Objetivo

    Sprint Planning

    A cada 15 dias (início de Sprint)

    Analista, DEV, Analista de Projetos, Stakeholders (opcional)

    Definir o que será entregue na Sprint, estimar esforço, criar cards no Odoo, atribuir responsáveis.

    Daily (Reunião Diária)

    Diariamente (15 min)

    Analista, DEV, Analista de Projetos

    Responder: O que fiz ontem? O que farei hoje? Há impedimentos? Atualizar status no Odoo em tempo real.

    Sprint Review

    Fim de cada Sprint

    Todos + Stakeholders

    Apresentar entregas da Sprint, coletar feedback, ajustar backlog.

    Sprint Retrospective

    Após Review

    Time de Sistemas

    Melhorar processos: o que funcionou, o que não funcionou, ações corretivas.

    5. Regras de Criação e Gestão de Tarefas (Cards)

    Toda tarefa no Odoo DEVE conter:

    Campo

    Obrigatório

    Detalhes

    Nome da tarefa

    ✅ Sim

    Deve seguir o padrão: Descrição curta(ex: Justificativa obrigatória em PC)

    Descrição

    ✅ Sim

    Em texto puro(sem HTML), com: objetivo, critérios de aceitação, regras de negócio, links para documentos (ex: Knowledge Base).

    Responsável (user_ids)

    ✅ Sim

    Apenas1 responsável principal (DEV ou Analista de Dados). Outros podem ser @mencionados.

    Horas alocadas

    ✅ Sim

    Estimativa realista, com base no planning.

    Subtarefas obrigatórias

    ✅ Sim

    - Para qualquer tarefa que vá para produção:“Revisão das IT que envolvem esta tarefa”(atribuída à SGI).

    - Para tarefas de desenvolvimento:“Homologação”(atribuída ao Stakeholder ou Analista).

    Etiquetas (tags)

    ✅ Sim

    Ex:Orçamento,Dashboard,Ciclo Financeiro,Bloqueio Externo

    Bloqueado por

    ❗ Se aplicável

    Preencherobrigatoriamenteao mover para “Bloqueado”. Ex: “Aguardando validação da Controladoria”

    6. Lançamento de Horas Trabalhadas

    • Todo colaborador deve registrar horas diárias diretamente na tarefa do Odoo;
    • O registro deve conter breve descrição da atividade (ex: “Desenvolvimento do cálculo do ciclo financeiro”);
    • A soma das horas lançadas não deve exceder 20% do estimado sem justificativa prévia;
    • O Analista de Projetos gera relatório semanal de horas vs. alocação.

    7. Governança de Deploy e Produção

    7.1 Checklist de Deploy (Obrigatório)

    Antes de mover para Finalizado, a tarefa deve ter:

    • Homologação aprovada pelos stakeholders;
    • Subtarefa “Revisão das IT” concluída pela SGI;
    • Documentação atualizada (Knowledge Base ou IT);
    • Comunicado de mudança enviado (se aplicável);
    • Testes de regressão executados (se impactar outros módulos).

    7.2 Responsável pela Liberação Final

    • O Analista de Sistemas é o gatekeeper: só libera o deploy após todos os itens acima estarem marcados.

    Obs.: Lembrando que será obrigatório seguir as politicas de 'Gestão de Mudança' da empresa.

    ⚖️Politica de Gestão de Mudança

    8. Modelo de Status Report Semanal (para Diretoria)

    Gerado pelo Analista de Projetos, com base nos dados do Odoo:

    9. Anexos e Referências

    • Padronização de nomenclatura de tarefas
    • Template de descrição de tarefa (Odoo)
    • Checklist de deploy
    • Modelo de Status Report
    • Fluxo de trabalho visual (diagrama de estágios)

    ℹ️ Este documento é vivo – deve ser revisado a cada 3 meses ou após lições aprendidas em Retrospectivas.