Skip to main content

MAN-G-001-A-Manual de P&D

Objetivo do Manual

Este manual define como o time de P&D trabalha para transformar ideias em evidências e evidências em entregas que geram valor para o Grupo. Ele existe para garantir previsibilidade, qualidade e rastreabilidade, reduzindo retrabalho e evitando que iniciativas de P&D virem “projetos eternos” sem transferência para operação.

Escopo e Fronteiras

O P&D cobre iniciativas de pesquisa aplicada, prototipação, provas de conceito, MVPs e pilotos em: IA, automações, integrações, software web e produtos digitais.
O P&D não é “operação” nem “suporte”. Quando algo está validado e pronto para uso recorrente, ele deve passar por um processo de transferência para o time responsável por operar e evoluir.

O Que é Considerado Entrega em P&D

Uma entrega de P&D precisa ter evidência e utilidade. Exemplos aceitos:

  • relatório de experimento com hipótese, método, métricas e conclusão;
  • protótipo funcional com limitação e próximos passos claros;
  • PoC com critérios de aceite e decisão de go/no-go;
  • MVP com usuários piloto e feedback registrado;
  • documentação de arquitetura, riscos e plano de industrialização;
  • repositório de código com instruções de execução e evidência de teste básico.
Princípios de Operação

P&D não é só “fazer funcionar”. É fazer funcionar com método.

  • rastreabilidade: toda iniciativa registrada e acompanhada;
  • evidência: decisões baseadas em métricas, não em opinião;
  • reprodutibilidade: experimento precisa poder ser repetido por outra pessoa do time;
  • segurança e conformidade: dados, acesso e uso de informações sob controle (LGPD e ISO 27001);
  • transferência: P&D termina com handoff para operação/produto ou com encerramento justificado.
Ferramentas Padrão

O time deve operar com ferramentas padrão para reduzir dispersão.

  • ClickUp para registro, triagem, prioridade e acompanhamento;
  • GitHub para código, versionamento, revisão e CI quando aplicável;
  • M365 para documentos, evidências, relatórios e arquivos de apoio;
  • Observabilidade padrão quando houver serviço executando (logs e métricas) conforme stack do grupo.
Glossário Mínimo (Termos Base)
  • hipótese: o que estamos tentando provar ou refutar;
  • experimento: teste controlado para validar hipótese;
  • baseline: referência mínima para comparar resultado;
  • PoC: prova de conceito com escopo limitado e critério de decisão;
  • MVP: mínimo produto viável para testar valor com usuários;
  • piloto: validação em ambiente real controlado;
  • handoff: transferência organizada para operação/produto.

1. Identidade Organizacional de P&D

Propósito e Missão do P&D

O P&D existe para transformar incerteza em decisão. Ele pega uma ideia, um problema ou uma oportunidade e responde, com evidência: vale a pena seguir ou não? E se vale, qual é o melhor caminho técnico e de produto para entregar valor.

A missão do P&D é criar soluções em IA, software web e produtos digitais que sejam:

  • úteis para o negócio, não apenas interessantes tecnicamente;
  • verificáveis por evidência (métricas, testes, validações);
  • transferíveis para operação e escala (documentação, padrões, segurança).
O Que o P&D Não é

P&D não é suporte. P&D não é “fazer uma feature rápida porque está urgente”.
Quando uma demanda é recorrente e operacional, ela deve ir para o time de produto/operação. O P&D pode ajudar a destravar o caminho, mas não pode virar “fila de emergência”.

Como o P&D Gera Valor na Prática

O P&D gera valor quando entrega pelo menos um destes resultados:

  • validação rápida de hipótese (para economizar tempo e dinheiro);
  • redução de risco técnico antes de investir pesado;
  • descoberta de uma arquitetura ou abordagem melhor para um produto digital;
  • melhoria mensurável de qualidade, custo, tempo ou segurança em um fluxo;
  • criação de um protótipo que realmente habilita um piloto com usuários.

Alinhamento ao SEA (Sistema de Excelência Autvix Group)

O P&D precisa entregar inovação com disciplina. O SEA ajuda a garantir que o esforço do time se conecte a valor real, com padrões e melhoria contínua.

Pessoas

O P&D desenvolve pessoas por prática orientada a evidência. Aqui, crescer significa: aprender a formular hipóteses, testar, documentar, colaborar e transferir conhecimento. O time evolui quando trabalha com rastreabilidade e quando aprende com erros sem repetir os mesmos problemas.

Processos e Inovação

P&D é, por natureza, inovação. Mas inovação sem processo vira tentativa e erro infinito. O P&D contribui quando estabelece um funil claro (ideia, discovery, PoC, MVP, piloto e transferência), com gates objetivos, documentação e padrões de reprodutibilidade.

Clientes e Mercado

Mesmo sendo interno, o cliente do P&D existe: áreas do Grupo e usuários reais. P&D entrega valor quando resolve dor concreta, reduz atrito e melhora decisão. Quando houver intenção de produto externo, o P&D deve manter postura de validação de mercado desde cedo, sem confundir experimento com promessa.

Sociedade

Em IA e produtos digitais, sociedade aparece como responsabilidade: privacidade, ética, segurança e uso adequado de dados. O P&D deve evitar atalhos que criem risco de exposição, discriminação, uso indevido de informação ou comunicação que prometa mais do que foi validado.

Resultados Estratégicos

P&D deve ser medido por impacto, não por volume de protótipos. O trabalho precisa gerar decisões, reduzir risco e acelerar entregas que importam. Isso inclui transferências bem feitas para operação, ganhos mensuráveis e redução de retrabalho técnico.

Tipos de Iniciativa em P&D

Nem tudo em P&D é igual. Para evitar confusão, toda iniciativa deve ser classificada em um tipo. Isso define expectativa, esforço e como medir sucesso.

Pesquisa aplicada

Quando o problema é real, mas o caminho técnico ainda é incerto. Aqui o objetivo é descobrir a abordagem mais promissora com evidência, sem compromisso de “entregar produto” de imediato.
Exemplos: testar modelos, avaliar técnicas, comparar arquiteturas, validar viabilidade.

Prototipação

Quando precisamos materializar uma ideia rapidamente para aprender. O protótipo é uma maquete funcional: serve para demonstrar, coletar feedback e reduzir risco de entendimento.
Prototipação não é “produto”. O foco é aprendizado, não robustez.

Prova de Conceito (PoC)

Quando existe uma hipótese concreta e um critério claro de “passou/não passou”. PoC sempre termina com decisão: seguir, ajustar ou encerrar.
PoC tem escopo limitado e métricas mínimas definidas antes de começar.

MVP

Quando a hipótese central já passou e precisamos validar valor com usuários reais, com o mínimo necessário. MVP tem uso em cenário real controlado, mesmo que com limitações e operação manual.
O objetivo é validar utilidade e caminho de produto, não “perfeição técnica”.

Piloto

Quando o MVP vai para um ambiente real com regras de operação e acompanhamento. Aqui a preocupação com segurança, dados, suporte e riscos aumenta.
O piloto prepara a transferência para operação e escala.

Melhoria Técnica Habilitadora

Quando não há “novo produto”, mas existe uma melhoria que destrava qualidade, custo, tempo ou segurança para sistemas já existentes.
Aqui o valor é medido por redução de retrabalho, performance, estabilidade, tempo de ciclo ou risco.

Critérios de Sucesso (O Que Significa “deu certo”)

Uma iniciativa em P&D só é considerada bem-sucedida quando gera pelo menos um destes resultados, com evidência registrada:

  • decisão clara: go, no-go ou pivot com justificativa;
  • redução de risco: técnico, de dados, de arquitetura ou de custo;
  • ganho mensurável: tempo, qualidade, custo, estabilidade ou segurança;
  • aprendizado reutilizável: documentação, baseline, lições aprendidas e padrões;
  • transferência planejada: handoff definido para operação/produto quando aplicável.
Critérios de Encerramento (quando parar é a decisão correta)

Encerrar também é resultado. Uma iniciativa deve ser encerrada quando:

  • a hipótese principal foi refutada e não há pivot razoável com custo aceitável;
  • o ganho esperado é baixo para o esforço e risco envolvidos;
  • dependências críticas não existem (dados, acessos, apoio de área) e não há perspectiva realista;
  • o problema deixou de ser prioridade estratégica;
  • não há caminho seguro e conforme (LGPD/ISO) para operar ou testar.

2. Estrutura Funcional P&D

Organograma de P&D

O organograma existe para deixar claro quem decide, quem executa e quem precisa ser envolvido quando houver risco, dado sensível ou necessidade de operação. Ele representa papéis, não necessariamente pessoas fixas. Em time enxuto, uma pessoa pode acumular mais de um papel, mas o “chapéu” precisa estar explícito em cada iniciativa.

Estrutura Base

Patrocínio (Diretoria/Gerência)
Garante prioridade e recursos quando P&D exigir investimento, mudança estratégica ou envolver risco relevante.

Gestão de P&D
Dono do funil de P&D. Define prioridades, organiza gates de decisão, estabelece padrões de evidência e garante transferência para operação/produto.

Squad de P&D
Executa discovery, experimentos, PoCs, MVPs e pilotos em IA, software web e produtos digitais, com documentação e reprodutibilidade.

Interfaces e Aprovadores
Entram quando necessário: área demandante, TI/Infra, Segurança da Informação/LGPD e o time que vai operar o resultado depois.

kq8image.png

Papéis e Responsabilidades

Cada função em P&D tem papéis claros, alinhados ao SEA, ao Manual de Governança (N1–N6) e às práticas de gestão de tarefas. Como a estrutura é enxuta, parte das responsabilidades de supervisão e liderança operacional tende a ficar concentrada no nível de coordenação.

Estrutura em P&D por Nível

No eixo vertical, P&D normalmente não tem camadas intermediárias completas. Isso significa que o papel de coordenação precisa assumir protagonismo na gestão do funil, no desenvolvimento de pessoas e no controle de qualidade das entregas.

N1 — Diretoria (estratégico)
Define diretrizes e garante recursos quando P&D exigir investimento, mudança estratégica ou risco relevante.

N2 — Gerência (estratégico/tático)
Desdobra prioridades em temas e resultados esperados. Resolve conflitos de prioridade entre áreas, aprova escalonamentos e decisões de maior impacto.

N3 — Gestão de P&D (tático + operacional acumulado)
Responsável por manter o manual vivo, definir padrões e conduzir o sistema de P&D. Além disso, acumula responsabilidades típicas de níveis intermediários, como supervisionar execução, acompanhar evolução do time e garantir conformidade.

N6 — Time Operacional de P&D (execução)
Executa discovery, experimentos, PoCs, MVPs e pilotos com evidência, reprodutibilidade e documentação mínima para continuidade.

Papéis e responsabilidades por função

Diretoria (N1) — Patrocínio Estratégico
Responsabilidades:

  • definir direções estratégicas e prioridades macro;
  • garantir recursos quando necessário;
  • decidir sobre riscos estratégicos e posicionamento;
  • homologar investimentos relevantes.

Gerência (N2) — Alinhamento Estratégico/Tático
Responsabilidades:

  • traduzir metas do Grupo em objetivos para P&D;
  • garantir integração de P&D com áreas de negócio e operação;
  • acompanhar resultados estratégicos e remover bloqueios organizacionais;
  • apoiar decisões de go/no-go quando houver impacto alto.

Tech Lead / Gestão de P&D (N3)
Responsabilidades:

  • atualizar este manual e garantir padrão de execução;
  • organizar backlog de P&D, priorizar e definir trilhos das iniciativas;
  • definir hipóteses, critérios de aceite e métricas mínimas antes de executar;
  • conduzir gates de decisão: seguir, pivotar ou encerrar com justificativa;
  • garantir rastreabilidade: demanda no ClickUp, código no GitHub, evidências no M365;
  • garantir conformidade (LGPD/segurança) quando houver dados e risco;
  • revisar qualidade: reprodutibilidade, documentação, testes mínimos e padrões de entrega;
  • planejar e executar handoff para operação/produto quando aplicável;
  • desenvolver o time por feedback, PDIs e acompanhamento prático.

Time Operacional — Integração (N6)
Responsabilidades:

  • construir integrações e automações necessárias para PoCs, MVPs e pilotos;
  • garantir segurança e rastreabilidade em integrações (credenciais, logs, acesso);
  • documentar endpoints, fluxos e dependências para continuidade;
  • apoiar handoff com guias de execução e troubleshooting básico.

Time Operacional — Desenvolvimento Web (N6)
Responsabilidades:

  • construir front-end e back-end necessários para protótipos, MVPs e pilotos;
  • garantir padrões mínimos de qualidade (estrutura, revisão, testes básicos quando aplicável);
  • organizar deploy de piloto quando necessário, com orientação do Tech Lead;
  • documentar execução, variáveis, fluxos e limitações do protótipo.

Estagiários (N6)
Responsabilidades:

  • executar tarefas com escopo claro e acompanhamento;
  • aprender padrões do time: registro, versionamento, documentação e revisão;
  • apoiar na preparação de evidências (prints, logs, relatórios simples);
  • evoluir autonomia de cenários simples para complexos conforme matriz de competências.

3. Gestão de Pessoas e Competências

Matriz de Competências

A matriz de competências define o que cada função precisa dominar para entregar com qualidade e segurança. Ela é o ponto de partida para PDIs e para a Avaliação de Desempenho.

Como Ler a Matriz

Competências técnicas: IA, software web, integrações, dados, qualidade, segurança da informação e práticas de engenharia.
Competências comportamentais: comunicação, foco no cliente interno, colaboração e atitude de dono (DNA do Grupo).
Níveis de proficiência:

  • -1: não precisa saber (irrelevante);
  • 0: diferencial (não exigido, mas agrega);
  • 1: conhece o básico, precisa de bastante suporte;
  • 2: trabalha sozinho em cenários simples;
  • 3: autonomia em cenários complexos;
  • 4: mentor ativo, referencia boas práticas;
  • 5: referência estratégica, inova e cria caminhos.

Cada coluna representa um cargo, com os valores sendo o nível de proficiência esperada para cada cargo.

Gestão

Matriz de Competências de P&D

Competência

Tipo

Descrição

Estágio

Assistente

Analista Jr I

Analista Jr II

Analista Pleno

Analista Sênior

Tech Lead

Engenharia de software (bases)

Técnica

Estrutura de código, modularidade, padrões e boas práticas para manter e evoluir sistemas

0

1

2

2

3

4

5

APIs e serviços web (FastAPI)

Técnica

Construir e manter APIs com validação, autenticação básica e padrões de integração

0

1

2

2

3

4

5

Front-end e UX básica

Técnica

Construir interfaces de MVP com experiência mínima e consistência

0

1

1

2

3

4

4

Integrações e automações

Técnica

Webhooks, integrações com sistemas, credenciais, fluxos e rastreabilidade

1

2

2

3

3

4

5

Banco de dados e modelagem

Técnica

Modelagem, consultas, migrações, integridade e performance básica

0

1

1

2

3

4

5

Versionamento e GitHub

Técnica

Fluxo de branches, PRs, code review, tags e releases quando aplicável

1

2

2

3

4

4

5

Testes e qualidade mínima

Técnica

Testes básicos, critérios de aceite, validações e prevenção de regressões

0

1

2

2

3

4

4

Observabilidade básica

Técnica

Logs úteis, métricas mínimas e rastreio de erro em pilotos e serviços

0

0

1

2

3

4

5

Gestão de dados e LGPD (prática)

Técnica

Minimização, acesso, armazenamento seguro e cuidados com dados pessoais

0

1

2

2

3

4

5

Segurança da informação e ISO 27001 (aplicação)

Técnica

Controle de acesso, segredos, riscos e conformidade em protótipos e pilotos

-1

0

1

2

3

4

5

Experimentação com método

Metodológica

Hipótese, baseline, métrica, experimento e decisão baseada em evidência

1

1

2

2

3

4

5

Reprodutibilidade

Metodológica

Ambiente, dependências, instruções claras e repetição por outra pessoa

1

2

2

3

3

4

5

Documentação técnica e evidências

Metodológica

README, relatórios, limitações, decisões, prints/logs e conclusão

1

2

2

3

3

4

5

PDCA e melhoria contínua

Metodológica

Planejar, executar, medir e ajustar processos e entregas de P&D

0

1

2

3

3

4

5

Gestão de tarefas (ClickUp)

Metodológica

Registrar, priorizar, acompanhar e fechar com evidências

2

2

3

3

4

4

5

Aplicação do SEA

Metodológica

Agir conforme pilares e fluxos do SEA, mantendo padrão e melhoria contínua

1

2

2

3

4

4

5

Gestão de riscos e controles

Metodológica

Identificar, tratar e controlar riscos técnicos e de dados

0

1

2

2

3

4

5

Comunicação clara e assertiva

Comportamental

Comunicar status, riscos, trade-offs e decisões com objetividade

1

2

2

3

3

4

5

Organização e gestão do tempo

Comportamental

Planejar, priorizar e cumprir prazos com previsibilidade

1

2

2

2

3

4

5

Resolução de problemas e proatividade

Comportamental

Diagnosticar causa raiz, propor solução e evitar reincidência

1

2

2

2

3

4

5

Trabalho em equipe e colaboração

Comportamental

Compartilhar conhecimento e apoiar objetivos coletivos

1

2

2

3

3

4

5

Comprometimento com segurança e qualidade

Comportamental

Priorizar conformidade, revisão e padrão antes de velocidade

1

2

2

3

3

4

5

Valores e DNA (Cultural)

Valor / DNA

Tipo

Descrição

Estágio

Assistente

Analista Jr I

Analista Jr II

Analista Pleno

Analista Sênior

Tech Lead

Segurança

Cultural

Age preventivamente e nunca sacrifica segurança e conformidade por velocidade

3

3

4

4

5

5

5

Inovação

Cultural

Testa com método, aprende rápido e padroniza o que funciona

1

2

2

3

4

5

5

Sustentabilidade

Cultural

Usa recursos com responsabilidade e pensa em longo prazo

2

2

3

3

4

4

5

Foco no cliente interno

Cultural

Entrega utilidade real e reduz atrito para as áreas do Grupo

2

3

3

4

4

5

5

Excelência

Cultural

Mantém padrão alto, consistência e melhoria contínua

2

3

3

4

4

5

5

Respeito

Cultural

Postura ética, colaboração e comunicação madura

4

4

4

5

5

5

5

Confiança

Cultural

Transparência, rastreabilidade e cumprimento de combinados

3

3

4

4

5

5

5

Atitude de dono

Cultural

Responsabilidade por ponta a ponta e busca por melhoria

2

3

3

4

4

5

5

Trilhas de Carreira

As trilhas de carreira em P&D existem para deixar claro como você pode crescer no time, quais competências precisa desenvolver e quais responsabilidades assume em cada etapa. A evolução é baseada na Matriz de Competências e em evidências de entrega com método, rastreabilidade e segurança.

Estrutura das Trilhas

Estágio → Assistente → Analista Jr I → Analista Jr II → Analista Pleno → Analista Sênior → Tech Lead

Cada nível representa um salto de autonomia, profundidade técnica, impacto no negócio e capacidade de transferir resultados para operação e escala.

Critérios de Progressão

A progressão acontece quando competência, evidência e comportamento andam juntos.

Domínio da Matriz de Competências
Você precisa atingir os níveis esperados para o seu cargo nas competências técnicas, comportamentais, metodológicas e culturais.

Evidências em serviço
Você precisa demonstrar entregas reais, registradas e reproduzíveis. Em P&D, evidência costuma ser:

  • hipótese e critério de aceite definidos antes de começar
  • experimento com baseline, métrica e conclusão
  • PoC com decisão clara e justificativa
  • MVP/piloto com feedback registrado e riscos mapeados
  • documentação mínima e instruções de execução
  • contribuição clara para handoff quando aplicável

Comportamentos do SEA (valores e DNA)
Evoluir exige prática real de segurança, excelência, confiança, respeito e atitude de dono. Em P&D, isso aparece como: não esconder risco, não forçar promessa sem evidência, registrar decisões e evitar soluções frágeis que ninguém consegue manter.

Atuação em rituais de gestão
Participação ativa nos rituais definidos no Capítulo 8. Evolução em P&D é visível na consistência: alinhamentos, decisões bem tomadas e melhoria contínua.

Necessidade do time e do Grupo
A evolução também considera demanda real. Em alguns períodos, o time precisa de mais força em integração, em web, em experimentação ou em transferência para operação.

O que Muda de Nível para Nível

Estágio
Você aprende o padrão do time. Entrega com supervisão, registra o trabalho corretamente e desenvolve base técnica e disciplina de documentação.

Assistente
Você executa sozinho em cenários simples e começa a dar previsibilidade. Você sabe registrar, versionar e documentar sem depender de “lembrar depois”.

Analista Jr I
Você entrega partes completas de uma iniciativa com orientação. Consegue executar, medir e documentar um experimento simples ou uma entrega técnica limitada.

Analista Jr II
Você tem autonomia em cenários complexos sob supervisão leve. Consegue conduzir uma PoC pequena ou um módulo de MVP com evidência e qualidade mínima.

Analista Pleno
Você conduz iniciativas com pouco suporte. Define critérios, executa com método, antecipa riscos e faz a ponte com integração, web e dependências.

Analista Sênior
Você é referência. Ajuda a decidir caminhos, define padrões, mentora pessoas, reduz risco e aumenta taxa de transferência para operação.

Tech Lead
Você lidera o sistema. Prioriza, define padrões, conduz gates de decisão, garante conformidade (LGPD/segurança), desenvolve pessoas e protege o foco do time.

Onboarding (Integração)

Onboarding Institucional

O Onboarding Institucional é a primeira imersão do colaborador na cultura da Autvix. Ele acontece logo após a admissão e tem como objetivo alinhar identidade, valores e normas que orientam a conduta de todos.

Objetivos

  • Apresentar a cultura do Grupo, com base no SEA e no Código de Excelência;
  • Formalizar compromissos éticos, de segurança e de confidencialidade;
  • Cumprir treinamentos normativos obrigatórios (Qualidade, Saúde e Segurança, LGPD, Segurança da Informação);
  • Garantir entendimento de direitos, benefícios e responsabilidades.

Conteúdo do Onboarding Institucional

  • Valores, DNA e pilares do SEA;
  • Políticas corporativas relevantes (governança, pessoas, segurança da informação, LGPD);
  • Condutas esperadas e não permitidas;
  • Treinamentos normativos aplicáveis;
  • Benefícios e direitos vigentes.

Marcos de avaliação

  • 45 dias: adaptação cultural e engajamento;
  • 90 dias: avaliação completa, consolidando o período de experiência.
Onboarding Técnico de P&D

O Onboarding Técnico é a etapa em que o colaborador, já alinhado à cultura da Autvix, passa a atuar dentro do P&D. Aqui ele aprende o modo de trabalho do time: método, evidência, rastreabilidade, segurança e transferência para operação.

Objetivos

  • Introduzir os processos e serviços do P&D;
  • Capacitar para executar com segurança e qualidade;
  • Acelerar curva de aprendizado e reduzir erros no início;
  • Ensinar a disciplina de evidência, versionamento e documentação.
Estrutura do Onboarding Técnico

Primeiro dia

  • Apresentação do Manual de P&D e do que é “entrega válida” no setor;
  • Apresentação da Matriz de Competências e trilha de carreira;
  • Configuração de acessos e ferramentas padrão: ClickUp, GitHub e M365;
  • Regras mínimas de segurança: dados, acessos, segredos, LGPD e cuidados com ambientes;
  • Como funciona o funil de P&D e os gates de decisão.

Primeira semana

  • Shadowing de uma iniciativa real: demanda → hipótese → execução → evidência → decisão;
  • Prática de registro no ClickUp com padrão de tarefa, status e evidência;
  • Prática de GitHub: clone, branch, PR e revisão;
  • Prática de documentação: README, instruções de execução e limitações;
  • Participação nos rituais do time e alinhamento de expectativas de qualidade.

Primeiro mês

  • Execução supervisionada de entregas de complexidade crescente, com critérios de aceite;
  • Primeira contribuição completa em uma iniciativa: código + evidência + documentação mínima;
  • Feedback estruturado com base em desempenho inicial e disciplina de registro;
  • Definição e acompanhamento do PDI inicial com foco nos principais gaps da matriz.
Condutas Esperadas
  • Registrar trabalho e decisões no lugar certo, evitando “conhecimento na cabeça”;
  • Versionar e revisar antes de integrar mudanças relevantes;
  • Não usar dados sensíveis sem autorização e controle de acesso;
  • Documentar como rodar, como validar e quais são as limitações;
  • Pedir ajuda cedo quando houver risco técnico, de prazo ou de segurança

PDIs e Avaliação de Desempenho

O desenvolvimento de pessoas em P&D é sustentado por um ciclo contínuo: identificar competências, planejar desenvolvimento e avaliar resultados. Esse processo garante evolução individual e fortalece a entrega coletiva com método, evidência e segurança.

Plano de Desenvolvimento Individual (PDI)

O PDI existe para fechar gaps identificados na Matriz de Competências, com prática real e evidência, não apenas estudo.

Objetivo
Fechar gaps técnicos, comportamentais e metodológicos que estejam limitando autonomia, qualidade, reprodutibilidade, segurança ou capacidade de transferência para operação.

Formato
Cada item do PDI deve conter:

  • competência alvo;
  • ação prática (treinamento, shadowing, projeto guiado, mini-entrega);
  • evidência de conclusão (o que prova que foi feito e aprendido);
  • prazo e responsável por acompanhar.

Ações práticas recomendadas em P&D

  • executar um experimento completo com hipótese, baseline, métrica e conclusão;
  • criar ou melhorar documentação de execução e validação de um protótipo;
  • implementar testes mínimos e critérios de aceite em uma entrega;
  • montar um relatório de PoC com decisão go/no-go justificada;
  • preparar um handoff mínimo com runbook e checklist de operação;
  • aplicar controles de segurança em credenciais, dados e acessos em um piloto.

Integração com entregas reais
O progresso do PDI deve refletir-se em entregas reais registradas: tarefa no ClickUp, código no GitHub e evidências no M365. PDI que não vira entrega mensurável não gera evolução consistente.

Avaliação de Desempenho

A avaliação acontece em dois eixos, com evidências objetivas.

Competências
Medidas pela Matriz de Competências. A pergunta aqui é: você aumentou autonomia e padrão, ou segue dependente de suporte para o mesmo tipo de tarefa?

Entrega
Medida por qualidade e previsibilidade das entregas, incluindo:

  • clareza de hipótese e critério de aceite antes de executar;
  • registro e rastreabilidade (ClickUp, GitHub, M365);
  • reprodutibilidade do que foi feito;
  • qualidade mínima (testes, validações, revisão);
  • segurança e conformidade (dados, acesso, segredos);
  • capacidade de transferir resultado para outra pessoa do time ou para operação.
Frequência

Feedback contínuo
Alinhamentos rápidos durante os rituais do time para ajustar rota antes de virar retrabalho.

Avaliação formal
Ciclo semestral, considerando histórico de PDIs, evidências registradas, indicadores do time e feedbacks acumulados.

4. Jornada de Valor e Catálogo de Serviços

O que é Gerar Valor em P&D

Gerar valor em P&D significa transformar recursos do time (tempo, conhecimento, tecnologia, dados e experimentação) em resultados que importam para a Autvix, com evidência e rastreabilidade.

No P&D, valor não está em “fazer protótipo” ou “treinar modelo”. Valor está em reduzir incerteza e risco, acelerar decisões e entregar caminhos viáveis para produtos digitais e IA, com documentação e possibilidade de transferência para operação.

Esse conceito está alinhado ao SEA: conectar insumos a resultados de forma clara, mensurável e repetível, com melhoria contínua.

Jornada Padrão de Geração de Valor em P&D

A geração de valor em P&D pode ser representada em cinco passos.

Entrada da demanda
A demanda nasce como um problema, hipótese ou oportunidade. Ela é registrada com contexto, objetivo, restrições de dados e critério mínimo de decisão.

Análise e priorização
O P&D valida impacto, urgência, esforço e risco. Aqui também se define o tipo de iniciativa: pesquisa aplicada, PoC, MVP, piloto ou melhoria habilitadora.

Execução com evidência
A execução é feita com método: hipótese, baseline, métrica, registro de experimento, validação e documentação. Em software, isso inclui padrões de versão e qualidade mínima.

Entrega do resultado
O resultado é apresentado como decisão e artefatos: relatório, protótipo, MVP ou piloto, com limitações, riscos e próximos passos claros.

Valor gerado
Valor aparece quando a organização consegue decidir e agir: seguir, pivotar, encerrar ou transferir. O aprendizado fica registrado para reaproveitar, evitando repetição.

Exemplos de Valor Gerado

Uma PoC que prova que uma abordagem não funciona não é “tempo perdido”: é economia de investimento e redução de risco.

Um MVP que valida uso real com poucos usuários não é “produto pronto”: é aprendizado com evidência e caminho de evolução.

Uma melhoria técnica que reduz retrabalho ou aumenta estabilidade não é “refatoração gratuita”: é eficiência e segurança para o negócio.

Categorias do Catálogo de Serviços de P&D

O Catálogo de Serviços de P&D está estruturado em categorias que representam os principais tipos de entrega do time. Elas existem para deixar claro o que P&D faz, como solicitar, quais entradas são necessárias e como medir sucesso com evidência.

Pesquisa Aplicada e Experimentação

Serviços relacionados a investigar abordagens e validar hipóteses técnicas com método e métricas.

  • experimentos controlados com hipótese, baseline e métrica;
  • comparativos de abordagens e arquitetura;
  • validação de viabilidade técnica com evidência.
Prototipação e PoC

Serviços voltados a construir prova funcional com escopo limitado e decisão clara de seguir ou encerrar.

  • protótipos funcionais para demonstrar conceito;
  • PoCs com critérios de aceite e decisão go/no-go;
  • documentação de limitações e riscos.
MVP e Piloto Controlado

Serviços focados em validação com usuários reais e aprendizado em ambiente controlado.

  • MVP com fluxo mínimo e coleta de feedback;
  • piloto com regras de operação e acompanhamento;
  • preparação para transferência ou evolução.
Engenharia de Produto e Arquitetura Habilitadora

Serviços para definir caminho de produto e arquitetura para escala.

  • desenho de arquitetura e padrões de integração;
  • definição de requisitos técnicos para operação;
  • decisão de build vs buy com evidência.
Integrações e Dados para P&D

Serviços voltados a habilitar P&D com dados e integrações seguras.

  • pipelines simples de dados para experimento e MVP;
  • integrações com sistemas internos (APIs, eventos, webhooks);
  • controles de acesso e rastreabilidade de dados.
Transferência para Operação e Gestão do Conhecimento

Serviços que garantem que o resultado não fique “preso no P&D”.

  • handoff para time responsável com documentação mínima;
  • runbook básico, checklist e plano de suporte inicial;
  • registro de lições aprendidas e evidências no repositório.

Catálogo de Serviços — Detalhado com SLA

O Catálogo de Serviços é o ponto único de referência para entender o que P&D entrega, como solicitar e qual o tempo esperado (SLA).
Todos os serviços devem ser registrados no ClickUp e seus artefatos devem ser versionados no GitHub e armazenados no M365, conforme o tipo de entrega.

Catálogo de Serviços de P&D — Detalhado com SLA

Serviço

Descrição

Quem pode solicitar

Inputs necessários

Outputs entregues

SLA Resposta

SLA Solução

Avaliação de viabilidade (Discovery)

Entender problema, hipótese e caminho inicial com riscos e plano

Lideranças e áreas demandantes via Gestão de P&D

Contexto, objetivo, restrições, dados disponíveis, prazo desejado

Nota de discovery com hipótese, plano e critérios de decisão

1 dia útil

5 dias úteis

Experimento controlado

Testar hipótese com baseline e métrica definida

Gestão de P&D

Hipótese, baseline, métrica, dataset permitido, ambiente

Relatório de experimento com resultados e decisão

1 dia útil

10 dias úteis

Benchmark de abordagem

Comparar técnicas/arquiteturas para escolher caminho

Gestão de P&D

Cenário, critérios de comparação, limitações

Comparativo com recomendação e evidências

2 dias úteis

10 dias úteis

Prototipação funcional

Protótipo simples para demonstrar conceito e coletar feedback

Gestão de P&D

Fluxo desejado, telas/inputs, restrições, dados permitidos

Protótipo + limitações + próximos passos

2 dias úteis

15 dias úteis

PoC com decisão go/no-go

Prova de conceito com critério de aceite e decisão clara

Gestão de P&D

Critério de aceite, métrica mínima, dados permitidos, dependências

PoC + relatório + decisão go/no-go

2 dias úteis

20 dias úteis

MVP (mínimo viável)

Versão mínima para validação com usuários reais controlados

Gestão de P&D + área demandante

Escopo mínimo, usuários piloto, canal de feedback, dados permitidos

MVP + feedback inicial + plano de evolução

3 dias úteis

30 dias úteis

Piloto controlado

Teste em ambiente real com regras de operação e monitoramento

Gestão de P&D + área operadora

Ambiente, acessos, controles, plano de suporte, riscos

Piloto executando + relatório de piloto + decisão de escala

5 dias úteis

45 dias úteis

Arquitetura habilitadora

Definir arquitetura e padrões para escalar solução validada

Gestão de P&D

Requisitos, restrições, integrações, segurança

Documento de arquitetura + riscos + plano de implementação

3 dias úteis

15 dias úteis

Integração para P&D

Integração com sistemas internos para experimento/MVP

Gestão de P&D

Sistemas alvo, credenciais, escopo, logs requeridos

Integração funcional + documentação

2 dias úteis

15 dias úteis

Pipeline simples de dados

Preparar dados para experimento ou MVP com controle de acesso

Gestão de P&D

Fonte de dados, regras LGPD, campos permitidos

Dataset/pipeline com rastreabilidade + documentação

3 dias úteis

20 dias úteis

Handoff para operação/produto

Transferir solução validada para quem vai operar e evoluir

Gestão de P&D + time receptor

Checklist de handoff, critérios de aceite, runbook

Runbook, documentação, plano de suporte inicial

2 dias úteis

10 dias úteis

Lição aprendida (registro)

Registrar aprendizado para evitar repetição e padronizar

Time de P&D

Evento e contexto, causa raiz, recomendação

Registro no repositório + ação de melhoria

1 dia útil

5 dias úteis

5. Processos Operacionais

SIPOC Geral de P&D

Os SIPOCs de P&D apresentam, de forma resumida, o processo que sustenta nossas operações. Cada SIPOC descreve fornecedores, entradas, etapas, saídas e clientes. Essa visão ajuda a entender como P&D transforma demanda em evidência, decisão e transferência.

SIPOC — Geral (P&D)

SUPPLIERS (Fornecedores)

INPUTS (Entradas)

PROCESS (Processo)

OUTPUTS (Saídas)

CUSTOMERS (Clientes/Usuários)

Diretoria/Gerência, áreas demandantes, Integração, Web, TI/Infra, Segurança/LGPD, usuários piloto, parceiros (quando existir)

Contexto do problema, objetivo, hipótese inicial, critério de decisão, dados permitidos, restrições (LGPD/segurança), prazo, dependências, recursos

Registro no ClickUp → Triagem e priorização → Definição do tipo (pesquisa, PoC, MVP, piloto) → Planejamento (métrica, baseline, dados, ambiente) → Execução (experimento/código) → Evidência e documentação → Gate de decisão (go/pivot/no-go) → Handoff ou encerramento → Lições aprendidas

Relatório de discovery/experimento, protótipo/PoC/MVP/piloto, decisão registrada, código versionado no GitHub, evidências no M365, checklist de handoff ou justificativa de encerramento, lições aprendidas

Áreas do Grupo, usuários internos, time que vai operar/evoluir, diretoria/gerência (para decisão e investimento)


Objetivo do Processo

OBJETIVO DO PROCESSO

Transformar demandas em decisões e entregas de P&D com evidência, rastreabilidade e segurança, garantindo que resultados sejam transferidos para operação/produto ou encerrados com justificativa clara.

Requisitos para as Entradas

REQUISITOS PARA INSUMOS

Demanda registrada com contexto e objetivo claro

Critério mínimo de decisão definido antes de executar

Dados permitidos e restrições de LGPD/segurança mapeadas

Dependências e aprovadores identificados quando aplicável

Prazo realista e prioridade definida

Requisitos dos Clientes para o Serviço

REQUISITOS DOS CLIENTES

Decisão clara (seguir, pivotar ou encerrar)

Evidência verificável e documentação mínima

Risco e limitações explicitados

Transferência organizada quando houver entrega operacionalizável

Regras de Registro e Prioridade

Por Que Existe

A prioridade de uma iniciativa de P&D é calculada a partir de Urgência × Impacto. Isso evita que P&D vire fila de urgência e garante previsibilidade.

Em P&D:
Urgência é informada por quem solicita, no momento do registro no ClickUp.
Impacto é definido ou validado pela Gestão de P&D na triagem.
O resultado determina prioridade, ordem de atendimento e SLA.

Registro Correto (Obrigatório)

Toda iniciativa deve ser registrada no ClickUp com informações mínimas para evitar retrabalho.

Deve conter:

  • problema e contexto;
  • objetivo do que se quer decidir ou validar;
  • tipo de iniciativa sugerida (pesquisa, PoC, MVP, piloto, melhoria habilitadora);
  • critério mínimo de decisão (o que significa “passou” ou “não passou”);
  • dados disponíveis e dados permitidos, com restrições de LGPD/segurança;
  • dependências (Integração, Web, TI/Infra, Segurança/LGPD, área demandante);
  • prazo desejado e justificativa;
  • responsável da área demandante e aprovador para decisões de go/no-go quando aplicável.

Demandas sem dados essenciais podem ser devolvidas para complementação ou reclassificadas.

Como o Solicitante Define a Urgência

Urgência reflete quanto tempo a decisão pode esperar sem prejuízo relevante.

Muito Alta
Precisa agora. Há janela crítica imediata ou risco de decisão atrasada causar prejuízo relevante.

Alta
Precisa hoje. Há impacto relevante se postergar, mas existe alternativa temporária.

Média
Pode aguardar até o próximo dia útil. Não há janela crítica imediata.

Baixa
Pode esperar alguns dias. É demanda importante, mas programável.

Muito Baixa
Sem urgência. É melhoria ou investigação sem prazo definido.

A Gestão de P&D pode ajustar urgência se a justificativa não sustentar o nível escolhido.

Como a Gestão de P&D Define o Impacto

Impacto mede alcance e efeito no negócio, risco evitado e valor potencial.

Muito alto
Afeta estratégia do Grupo, risco alto ou potencial de retorno relevante; várias áreas impactadas.

Alto
Afeta uma unidade inteira ou um processo crítico; alto ganho de eficiência ou redução de risco.

Médio
Afeta uma equipe, um fluxo específico ou um produto; ganho moderado.

Baixo
Afeta um caso pontual ou uma melhoria localizada; ganho pequeno.

Muito baixo
Preferência ou investigação sem impacto claro.

Matriz de Cálculo (Urgência × Impacto → Prioridade)

Urgência \ Impacto

Muito alto

Alto

Médio

Baixo

Muito baixo

Muito Alta

Muito Alta

Muito Alta

Alta

Média

Baixa

Alta

Muito Alta

Alta

Alta

Média

Baixa

Média

Alta

Alta

Média

Baixa

Baixa

Baixa

Média

Média

Baixa

Muito Baixa

Muito Baixa

Muito Baixa

Baixa

Baixa

Baixa

Muito Baixa

Muito Baixa

Resultado da matriz = prioridade da iniciativa (fila e SLA).

Tabela de Prioridade (níveis e exemplos em P&D)

Muito Alta
Janela crítica para decisão, risco elevado ou bloqueio de projeto estratégico. Atendimento imediato. Entrega alvo: decisão ou alternativa em até 4h úteis.

Alta
Decisão necessária no mesmo dia para destravar entrega relevante. Entrega alvo: até 1 dia útil.

Média
Iniciativa relevante sem janela crítica. Entrega alvo: 2 a 3 dias úteis para plano e próximos passos.

Baixa
Investigação programável. Entrega alvo: até 5 dias úteis para discovery ou planejamento.


Muito Baixa
Backlog. Execução conforme planejamento e capacidade.

Processos Operacionais

Esta é uma lista que centraliza o acesso a todos os procedimentos de P&D, garantindo padronização, rastreabilidade e reprodutibilidade.

Observação: aqui eu deixo a coluna “Link” como texto “Acessar”, sem URL, para não atrapalhar copiar e colar.

Gestão

Código

Nome do Procedimento

Link

CPR-PD-001

Registro de Demanda (Intake) no ClickUp

Acessar

CPR-PD-002

Triagem e Priorização (Urgência × Impacto)

Acessar

CPR-PD-003

Classificação da Iniciativa (Pesquisa, PoC, MVP, Piloto, Melhoria)

Acessar

CPR-PD-004

Definição de Hipótese, Baseline e Métricas (padrão de experimento)

Acessar

CPR-PD-005

Registro de Experimentos e Evidências (M365)

Acessar

CPR-PD-006

Padrão de Repositório e Versionamento (GitHub)

Acessar

CPR-PD-007

Code Review e Critérios de Qualidade Mínima

Acessar

CPR-PD-008

Gestão de Dados para P&D (LGPD, minimização, acesso e retenção)

Acessar

CPR-PD-009

Gestão de Segredos e Credenciais (ambientes, chaves e tokens)

Acessar

CPR-PD-010

Execução de PoC com Gate de Decisão (go/pivot/no-go)

Acessar

CPR-PD-011

Execução de MVP (validação com usuários e coleta de feedback)

Acessar

CPR-PD-012

Execução de Piloto Controlado (monitoramento e suporte inicial)

Acessar

CPR-PD-013

Integrações para P&D (webhooks, APIs internas e rastreabilidade)

Acessar

CPR-PD-014

Observabilidade Básica para Protótipos e Pilotos (logs e métricas)

Acessar

CPR-PD-015

Handoff para Operação/Produto (runbook e checklist)

Acessar

CPR-PD-016

Encerramento de Iniciativa (justificativa e lições aprendidas)

Acessar

CPR-PD-017

Gestão de Incidente em Piloto (erro crítico, rollback e comunicação)

Acessar

Funil de P&D

funil de P&D existe para garantir que iniciativas avancem com evidência, com decisões claras e sem virar projetos infinitos. Cada etapa tem um objetivo e um gate de decisão.

Visão Geral do Funil

Ideia → Discovery → PoC → MVP → Piloto → Transferência ou Encerramento

Ideia

Aqui nasce a iniciativa. A ideia pode vir de uma dor real, oportunidade, risco ou melhoria técnica habilitadora.

Objetivo
Registrar a iniciativa com contexto e intenção, sem tentar “resolver” ainda.

Entradas Mínimas
Problema e contexto, objetivo, tipo sugerido, urgência, impacto, dados possíveis, restrições e dependências.

Gate de Saída
Vai para Discovery quando a iniciativa tem impacto potencial e um dono de contexto (área demandante) disponível.

Discovery

Discovery transforma ideia em hipótese e plano.

Objetivo
Definir hipótese, critério mínimo de decisão, riscos e plano de execução.

Saídas Esperadas
Hipótese, baseline sugerido, métrica, dados permitidos, abordagem, riscos e esforço estimado.

Gate de Saída
Go para PoC quando existe critério de aceite e dados suficientes para testar.
No-go quando não há impacto, não há dados ou não há caminho seguro e viável.
Pivot quando o problema é válido, mas a hipótese inicial precisa mudar.

PoC

PoC prova se a abordagem funciona dentro de um escopo limitado.

Objetivo
Validar viabilidade técnica e critério mínimo de sucesso, com evidência.

Saídas Esperadas
Protótipo/experimento, relatório, métrica final, decisão go/no-go e riscos atualizados.

Gate de Saída
Go para MVP quando a PoC atingiu critério e existe valor claro para testar com usuário.
No-go quando não atingiu ou quando custo/risco não compensa.
Pivot quando a hipótese é parcialmente válida, mas precisa ajuste de abordagem.

MVP

MVP valida valor com usuário real em cenário controlado.

Objetivo
Testar utilidade, fluxo e aceitação, com o mínimo necessário.

Saídas Esperadas
MVP funcional, feedback registrado, riscos operacionais mapeados e plano de evolução.

Gate de Saída
Go para Piloto quando há sinais de valor e há condições de operar com segurança.
No-go quando usuários não validam valor ou risco operacional é alto.
Pivot quando valor existe, mas o formato ou solução precisa ajuste.

Piloto

Piloto testa em ambiente real com regras de operação e monitoramento.

Objetivo
Validar estabilidade mínima, operação e impacto em um ambiente controlado.

Saídas Esperadas
Pilotando com acompanhamento, indicadores mínimos, incidentes e lições aprendidas, decisão de escala.

Gate de Saída
Go para Transferência quando há valor validado e operação viável.
Encerrar quando o piloto não se sustenta ou risco supera benefício.
Estender piloto apenas com justificativa e plano claro.

Transferência ou Encerramento

Toda iniciativa precisa terminar em uma dessas duas saídas.

Transferência
Entrega organizada para o time responsável operar e evoluir: documentação, runbook mínimo, checklist e suporte inicial.

Encerramento
Registro do porquê, o que foi aprendido, evidências e recomendações para não repetir.

image.png

6. Interfaces e Stakeholders

Lista de Stakeholders

O setor de P&D se conecta diariamente com diferentes áreas do Grupo. Cada interação possui um papel definido, garantindo clareza sobre responsabilidades, fluxos e frequência de contato. Como P&D trabalha com incerteza e evidência, essas interfaces existem para acelerar decisão e reduzir risco.

Gestão

Stakeholder

Papel

Tipo de Interação

Frequência

Diretoria Executiva

Patrocínio Estratégico

Direcionamento, priorização macro, decisões de investimento e escalonamentos

Mensal ou sob demanda

Gerências / Lideranças Táticas

Cliente Interno

Demandas estratégicas, definição de problemas e validação de valor esperado

Sob demanda

Áreas demandantes (negócio)

Cliente Interno

Contexto, regras do processo, critérios de sucesso e feedback de uso

Semanal ou sob demanda (por iniciativa)

Desenvolvimento Web

Executor / Parceiro técnico

Construção de MVPs, integração com sistemas e handoff de produto

Diária ou semanal (por iniciativa)

Integração

Executor / Parceiro técnico

Integrações, automações, conectores, pipelines e dependências

Diária ou semanal (por iniciativa)

TI / Infra

Parceiro operacional

Ambiente, deploy, acesso, redes, observabilidade e suporte à operação

Sob demanda

Segurança da Informação / LGPD

Validador

Orientação, validação de riscos, controles e conformidade em dados e acessos

Sob demanda (por critério)

SGI / Compliance

Validador

Padrões, auditoria, políticas, documentação e condutas

Sob demanda

Marketing

Parceiro de comunicação

Divulgação responsável de resultados, linguagem, posicionamento e controle de claims

Sob demanda

Comercial

Cliente interno indireto

Requisitos de materiais, provas, casos e mensagens quando houver produto digital com impacto comercial

Mensal ou sob demanda

Usuários piloto

Cliente/validador

Testes controlados, feedback, aceitação e usabilidade

Conforme o piloto

Fornecedores / parceiros (quando houver)

Fornecedor

Dados, APIs, licenças, serviços especializados

Conforme contrato

Política de Atendimento

O setor de P&D pauta suas interações por princípios que garantem qualidade, previsibilidade e segurança. P&D lida com incerteza e experimentação, mas isso não significa falta de método ou de rastreabilidade.

Clareza

Comunicação objetiva e transparente, com registro claro no ClickUp. O solicitante deve entender o que será decidido, quais são as etapas, quais evidências serão geradas e quais são os critérios de go/no-go.

Agilidade

Resposta no menor tempo possível, sempre respeitando a prioridade definida por Urgência × Impacto e os SLAs do catálogo. Agilidade em P&D significa acelerar decisão e reduzir risco, não prometer entrega sem evidência.

Cordialidade

Atendimento respeitoso e colaborativo, mesmo sob pressão. P&D deve facilitar o entendimento e orientar o solicitante sobre como formular uma demanda bem definida.

Rastreabilidade

Toda iniciativa deve ser formalizada: demanda no ClickUp, código no GitHub quando aplicável e evidências e relatórios no M365. Decisões de gate devem ser registradas para auditoria e reaproveitamento.

Foco na Solução

Atuação proativa para resolver a causa raiz: problema bem definido, dados corretos, experimento reprodutível e decisão clara. P&D evita reincidências por meio de lições aprendidas e atualização de procedimentos.

Centralidade no Usuário

Mesmo sendo P&D, o valor final é percebido por pessoas: áreas do Grupo, usuários piloto e time que vai operar a solução. O resultado precisa ser útil e compreensível, não apenas “tecnicamente interessante”.

Canais de Atendimento e Acordos de Nível de Serviço

Canais de atendimento e Acordos de Nível de ServiçoCanais formais

ClickUp — Canal Oficial de Abertura e Acompanhamento
Toda demanda de P&D deve ser registrada como tarefa, com contexto, objetivo, critério mínimo de decisão, dados permitidos e dependências. É a fila única e a base de rastreabilidade.

Microsoft Teams — comunicação rápida e alinhamentos
Usado para tirar dúvidas, destravar dependências e alinhar contexto. O Teams não substitui registro: se virou iniciativa, precisa estar no ClickUp.

E-mail — Uso Restrito a Exceções
Apenas quando houver impossibilidade temporária de registro ou necessidade de formalização específica. Mesmo assim, a tarefa deve ser criada no ClickUp assim que possível.

Canal de Urgência — Exclusivo para Prioridade Muito Alta
Usado apenas quando houver janela crítica imediata, risco de dados, ou bloqueio de iniciativa estratégica. Após o acionamento, a demanda deve ser registrada no ClickUp.

SLAs de Atendimento (P&D)

Prioridade

Tempo de Resposta

Tempo de Solução

Muito Alta

30 minutos

4 horas úteis

Alta

1 hora

8 horas úteis

Média

4 horas úteis

24 horas úteis

Baixa

8 horas úteis

2 a 3 dias úteis

Muito Baixa

16 horas úteis

Conforme disponibilidade

Observações
Resposta é o tempo até o contato inicial após registro da demanda.
Solução é o tempo até entrega de alternativa validada, plano de execução ou decisão inicial registrada, conforme a natureza de P&D.
Descobertas e execuções longas são controladas por gates e SLAs do Catálogo de Serviços do Capítulo 4.

7. Governança e Riscos

Matriz de Alçadas do Departamento

A matriz de alçadas define quem pode decidir e aprovar atividades críticas em P&D. Ela existe para dar autonomia com controle, proteger segurança e conformidade (LGPD/ISO) e garantir decisões rápidas nos gates do funil.

Atividade / Decisão

Estagiário

Assistente

Analista Jr

Analista Pl

Analista Sr

Tech Lead

Gerência

Registro de demanda e organização de evidências

Executa

Executa

Executa

Executa

Executa

Define padrão

Homologa padrão

Priorização (Urgência × Impacto)

Não

Sugere

Sugere

Recomenda

Recomenda

Decide

Homologa em conflito

Definição do tipo de iniciativa (pesquisa, PoC, MVP, piloto)

Não

Sugere

Sugere

Recomenda

Recomenda

Decide

Homologa quando estratégico

Definição de hipótese, baseline e métricas mínimas

Apoia

Executa com orientação

Executa

Executa

Revisa e orienta

Aprova padrão

Homologa em iniciativas críticas

Gate Discovery (go/pivot/no-go)

Não

Não

Sugere

Recomenda

Recomenda

Decide

Decide em iniciativas críticas

Gate PoC (go/pivot/no-go)

Não

Não

Sugere

Recomenda

Recomenda

Decide

Decide em iniciativas críticas

Gate MVP (go/pivot/no-go)

Não

Não

Sugere

Recomenda

Recomenda

Decide

Decide em iniciativas críticas

Gate Piloto (transferir/encerrar)

Não

Não

Não

Recomenda

Recomenda

Decide

Decide sobre escala

Uso de dados sensíveis / pessoais

Não

Não

Não

Não

Recomenda controles

Autoriza com validação

Homologa quando crítico

Aprovação de acesso a ambientes e credenciais críticas

Não

Não

Executa conforme autorização

Executa conforme autorização

Recomenda

Autoriza

Autoriza acesso global

Definição de arquitetura para escala

Não

Não

Contribui

Propõe

Recomenda

Aprova

Homologa quando estratégico

Publicação externa de resultados (comunicação)

Não

Não

Não

Sugere

Recomenda

Autoriza com Marketing

Homologa quando necessário

Contratação de serviços/fornecedores

Não

Não

Sugere

Sugere

Recomenda

Recomenda

Decide

Ferramentas e licenças para P&D

Não

Não

Sugere

Sugere

Recomenda

Aprova dentro da alçada

Homologa/decide

Handoff para operação/produto

Apoia

Executa parte

Executa parte

Executa

Lidera com o time receptor

Aprova checklist

Homologa transição crítica

Encerramento de iniciativa

Não

Sugere

Sugere

Recomenda

Recomenda

Decide e registra

Homologa quando necessário

Matriz de Riscos Operacionais

Risco

Impacto Potencial

Nível de Risco

Controles Preventivos

Plano de Contingência

Uso indevido de dados pessoais (LGPD) em experimento ou piloto

Exposição legal e reputacional, sanções, perda de confiança

Alto

Minimização de dados, controle de acesso, autorização formal quando necessário, revisão de dataset permitido, registro de evidências no M365

Interromper uso, remover dados, registrar incidente, acionar responsáveis, revisar processo e treinar envolvidos

Vazamento de credenciais/segredos (tokens, chaves, senhas)

Comprometimento de sistemas, acesso indevido, incidente de segurança

Alto

Segredos fora do código, rotação periódica, acesso mínimo, revisão em PR, MFA, segregação de ambientes

Revogar/rotacionar imediatamente, auditar acessos, corrigir repositório, registrar incidente e reforçar controles

Protótipo/MVP vira “produção” sem governança

Instabilidade, suporte implícito, risco operacional e reputacional

Alto

Gates claros, política de handoff, checklist mínimo de operação, observabilidade básica

Congelar rollout, definir responsável operacional, executar handoff emergencial ou desativar

Experimentos não reprodutíveis

Perda de confiança, retrabalho, decisões ruins

Médio

Template de experimento, baseline obrigatório, registro de ambiente e dependências, revisão técnica

Reexecutar experimento com padrão, ajustar documentação, revisar práticas do time

Escolha de solução tecnicamente boa, mas sem valor real

Desperdício de tempo, baixa adoção, frustração de stakeholders

Médio

Discovery com problema bem definido, critério de decisão e validação com usuário

Encerrar com justificativa, pivotar para dor real, registrar lição aprendida

Dependência de uma pessoa para rodar/manter

Risco de continuidade, gargalo e atraso

Médio

Documentação mínima, pares, PRs obrigatórios, padronização de repositório

Transferência interna emergencial, reforço de documentação e revisão do processo

Integração frágil com sistemas internos

Falhas recorrentes, incidentes em piloto, retrabalho

Médio

Contratos de API, testes de integração básicos, logs e monitoramento

Rollback, isolar integração, criar fallback manual temporário e corrigir

Falha em piloto por falta de monitoramento

Indisponibilidade e baixa confiança no resultado

Médio

Observabilidade mínima, alertas básicos, logs estruturados, plano de suporte inicial

Desativar piloto, restaurar versão anterior, corrigir e retomar com controle

Exposição de IP ou informação estratégica

Perda de vantagem competitiva, risco legal/contratual

Médio

Controle de acesso no M365/GitHub, classificação de informação, revisão antes de divulgar

Remover acesso, registrar incidente, revisar permissões e reforçar regras

“Escopo infinito” sem gate de decisão

Projetos intermináveis e sem entrega útil

Alto

Stage-gate obrigatório, critérios de go/no-go, timebox por etapa

Encerrar ou pivotar formalmente, replanejar com critérios objetivos

Falha de alinhamento entre P&D e time receptor

Handoff falho, solução não operada, retrabalho

Médio

Incluir receptor cedo, checklist de handoff, documentação e suporte inicial

Reunir com receptor, ajustar pacote de entrega, reexecutar handoff ou encerrar

Comunicação externa indevida (claims sem evidência)

Dano reputacional e risco comercial

Alto

Governança de comunicação com Marketing, evidência obrigatória, alçadas claras

Retirar/ajustar comunicação, corrigir formalmente e registrar lição aprendida

8. Rituais de Gestão

Rituais do P&D

Ritual

Objetivo

Frequência

Participantes

Pauta padrão

Entregas (Outputs)

Alinhamento rápido (Daily)

Sincronizar execução, destravar bloqueios e alinhar prioridade do dia

Diária ou 3x/semana

Tech Lead / Gestão de P&D, Integração, Web, envolvidos nas iniciativas

Status curto, bloqueios, dependências, decisões rápidas

Lista do dia, bloqueios registrados, decisões de prioridade

Reunião semanal de operação

Revisar andamento, evidências, riscos e próximos gates por iniciativa

Semanal

Tech Lead, Integração, Web, stakeholders pontuais

Progresso por iniciativa, evidências geradas, riscos, próximos gates

Plano da semana, ajustes de escopo, decisões de pivot/encerrar quando aplicável

Gate de decisão (Discovery/PoC/MVP/Piloto)

Decidir go/pivot/no-go com base em evidência

Conforme necessidade

Tech Lead, envolvidos, área demandante, receptor (quando houver)

Critério de aceite, resultados, riscos, custo e próximos passos

Decisão registrada, próximos passos, atualização no ClickUp e M365

Revisão quinzenal de qualidade

Garantir padrão de reprodutibilidade, documentação e segurança

Quinzenal

Tech Lead, referências técnicas

Revisão de repositórios, documentação, evidências, segredos, padrões

Lista de ajustes, melhorias de padrão, ações de qualidade

Reunião mensal com liderança

Alinhar prioridades estratégicas, investimentos e riscos

Mensal

Tech Lead, Gerência/Diretoria, convidados

Resultados do mês, decisões tomadas, riscos, necessidades

Relatório gerencial, decisões homologadas, prioridades do próximo ciclo

Retrospectiva por iniciativa

Encerrar e registrar lições aprendidas

Ao final de cada iniciativa

Time envolvido + stakeholders

O que funcionou, o que falhou, ações de melhoria

Lição aprendida registrada, ajustes em procedimentos, ações no backlog

Revisão trimestral de portfólio

Avaliar carteira, métricas e governança

Trimestral

Tech Lead, liderança, stakeholders chave

KPIs, taxa de transferência, riscos, alinhamento

Portfólio atualizado, mudanças de direção, melhorias no manual

Boas Práticas para Condução de Reuniões

Além de manter reuniões no calendário, é essencial conduzi-las de forma eficiente para gerar valor real e não se tornarem custo de tempo e energia. Em P&D, reunião boa termina com decisão, próximos passos e evidência registrada.

Avalie Se a Reunião Precisa Existir

Antes de convocar, confirme se o tema pode ser resolvido por mensagem no Teams. Se precisar de reunião, garanta objetivo claro e verificável. Se não há decisão a tomar, risco a tratar ou bloqueio a remover, a reunião provavelmente não é necessária.

Prepare uma Pauta

Compartilhe a pauta com antecedência. Ordene por prioridade e deixe claro quais itens são decisão e quais são atualização. Convide apenas quem é necessário para cada item e libere quem não precisa ficar até o fim.

Controle de Tempo

Tempo é restrição explícita. Use blocos curtos de foco e um guardião do tempo para manter ritmo e evitar dispersão. Em gates de decisão, defina um limite de tempo por iniciativa.

Defina Papéis

Toda reunião deve ter papéis claros:
líder da reunião, que conduz a pauta e protege o foco
guardião do tempo, que controla o cronômetro e alerta desvios
escrivão, que registra decisões, responsáveis e prazos

Mantenha o Foco

Evite conversas em círculo. Se a discussão não converge, volte ao objetivo e ao critério de decisão. Em P&D, a pergunta central é sempre: o que a evidência permite decidir agora?

Formalize em Ata

Registre decisões, planos de ação, responsáveis e prazos. Leia o resumo ao final para validar entendimento. Armazene o registro no repositório oficial do setor e garanta que o ClickUp reflita a decisão.

Checklist Rápido

Antes de marcar

  • preciso mesmo da reunião
  • o objetivo é claro
  • convidei apenas quem precisa estar

Antes de iniciar

  • pauta compartilhada e ordenada
  • papéis definidos

Nos primeiros minutos

  • reforço do objetivo
  • regras de tempo

Ao encerrar

  • decisão e próximos passos registrados
  • responsáveis e prazos definidos
  • tarefas e evidências atualizadas

9. Melhoria Contínua e Inovação

Processo de Gestão de Sugestões

Objetivo: capturar, avaliar e implementar ideias de melhoria ou inovação apresentadas por membros do time, mantendo rastreabilidade e priorização justa.

Fluxo do Processo

Registro da Sugestão
A sugestão deve ser registrada no ClickUp como “Melhoria/Ideia”, com contexto, problema, proposta e benefício esperado. Materiais de apoio ficam no M365.

Avaliação Preliminar
A Gestão de P&D verifica alinhamento com objetivos do setor, viabilidade inicial, dependências e riscos (dados, segurança, esforço).

Análise de Impacto
A análise considera custo, prazo, benefício e risco evitado. Quando for necessário, envolve Integração, Web, TI/Infra ou Segurança/LGPD para validar implicações.

Priorização
Sugestões são classificadas por impacto e urgência e entram no backlog com prioridade e janela de execução.

Implementação
As aprovadas viram itens de melhoria contínua ou entram como parte de uma iniciativa. Mudanças de padrão devem atualizar procedimentos internos.

Monitoramento
Resultados são acompanhados nos rituais: redução de retrabalho, ganho de tempo, aumento de reprodutibilidade e melhoria de handoff.

Feedback ao Proponente
O proponente recebe retorno claro: aprovada, rejeitada ou postergada, com justificativa objetiva e próximos passos quando aplicável.

Processo de Gestão do Conhecimento (Lições Aprendidas)

Objetivo: documentar e compartilhar aprendizados, erros e acertos para evitar repetição e potencializar eficiência e segurança. Em P&D, lição aprendida é um ativo: melhora reprodutibilidade, reduz retrabalho e acelera decisões futuras.

Fluxo do Processo

Identificação do Evento
Qualquer experimento, PoC, MVP, piloto, incidente, falha de segurança, mudança de abordagem ou handoff que gere aprendizado relevante deve ser sinalizado.

Registro da Lição Aprendida
A lição é registrada em formulário padrão com foco em ação: contexto, causa raiz, solução aplicada e recomendação para evitar reincidência. Evidências e arquivos de apoio ficam no M365.

Validação
A Gestão de P&D revisa o registro para garantir clareza, ausência de exposição sensível e aplicabilidade prática. Quando envolver dados, acessos ou risco, a validação inclui quem for necessário.

Armazenamento
A lição é inserida no repositório oficial de conhecimento do setor. O link interno e a evidência correspondente devem estar organizados no M365 e referenciados no registro.

Disseminação
O aprendizado é compartilhado nos rituais do time, principalmente reunião semanal e retrospectiva, e quando necessário vira microtreinamento.


Aplicação
Aprendizados que mudam padrão devem atualizar procedimentos internos, checklists e templates. Lição que não altera prática vira registro histórico, mas não melhora o sistema.

Ferramentas de Apoio

As ferramentas abaixo sustentam a melhoria contínua em P&D, garantindo registro, rastreabilidade, colaboração, reprodutibilidade e aprendizado reaproveitável.

ClickUp

Registro e acompanhamento de sugestões, iniciativas, ações de melhoria e decisões de gate. É o ponto de controle para prioridade, prazos, responsáveis e status.

GitHub

Repositório oficial de código, versionamento, pull requests, revisão e histórico técnico. Também sustenta rastreabilidade e qualidade mínima por meio de padrões de repositório e revisão.

Microsoft 365 (Teams e SharePoint)

Colaboração do dia a dia e centralização de artefatos: relatórios, evidências, documentos de arquitetura, registros de gates, lições aprendidas e materiais de apoio. O SharePoint é a fonte da verdade para documentos e evidências.

Dashboards e Indicadores (M365)

Base para identificar oportunidades de melhoria: tempo de ciclo, taxa de transferência, retrabalho, taxa de iniciativas encerradas com justificativa, incidentes e conformidade. Indicadores devem ser lidos nos rituais do time e usados para ajustar processos.

10. Gestão de Desempenho

Indicadores de Desempenho (KPIs) — Rotina Operacional

Os KPIs abaixo medem previsibilidade, qualidade, segurança e valor entregue por P&D. Eles seguem a lógica dos manuais anteriores: metas objetivas, frequência de medição e responsável.

KPI

Descrição

Meta

Frequência de medição

Responsável

Taxa de iniciativas dentro do SLA

Percentual de entregas que cumprem SLAs do Catálogo de Serviços

≥ 85% (inicial)

Mensal

Tech Lead

Tempo médio de resposta

Tempo entre registro no ClickUp e primeiro contato do P&D

Muito Alta ≤ 30 min; Alta ≤ 1h; Média ≤ 4h

Mensal

Tech Lead

Tempo médio de ciclo (por etapa)

Tempo médio para concluir Discovery, PoC, MVP e Piloto

Conforme catálogo

Mensal

Tech Lead

Taxa de gates com decisão registrada

Percentual de iniciativas com decisão go/pivot/no-go registrada no gate

100%

Mensal

Tech Lead

Taxa de reprodutibilidade

Percentual de entregas com instruções e evidência suficientes para outra pessoa repetir

≥ 90%

Mensal

Time de P&D

Taxa de handoff bem-sucedido

Percentual de transferências aceitas pelo time receptor sem retrabalho crítico

≥ 85% (inicial)

Mensal

Tech Lead + receptor

Retrabalho por iniciativa

Número médio de ciclos de ajuste por falta de evidência, escopo ou dependência

≤ 2

Mensal

Tech Lead

Incidentes de segurança/dados

Incidentes envolvendo credenciais, dados sensíveis ou violações de processo

0 incidentes

Mensal

Tech Lead

Percentual de iniciativas encerradas com justificativa

Iniciativas encerradas com lição aprendida e recomendação registrada

100%

Mensal

Tech Lead

Satisfação do solicitante (CSAT interno)

Avaliação do solicitante sobre utilidade da decisão/entrega

≥ 4,5/5

Mensal

Tech Lead

Objetivos e Resultados-Chave (OKRs) — Avanço Estratégico

O Que São OKRs
  • OKRs conectam direção estratégica a resultados mensuráveis;
  • Objetivo define a direção;
  • Resultados-chave traduzem em números verificáveis;
  • Eles devem ser revisados periodicamente para manter alinhamento entre o P&D e as prioridades do Grupo.

OKRs do P&D (versão inicial)

Objetivo 1 — Aumentar previsibilidade e qualidade do P&D como sistema de decisão
  • KR: Garantir que 100% das iniciativas tenham gate com decisão registrada (go/pivot/no-go) no mês;
  • KR: Atingir taxa de iniciativas dentro do SLA ≥ 85% por dois ciclos mensais consecutivos;
  • KR: Atingir taxa de reprodutibilidade ≥ 90% por dois ciclos mensais consecutivos.
Objetivo 2 — Aumentar Taxa de Transferência para Operação/Produto com Baixo Retrabalho
  • KR: Atingir taxa de handoff bem-sucedido ≥ 85% por dois ciclos consecutivos;
  • KR: Reduzir retrabalho crítico no handoff para ≤ 1 ocorrência por mês;
  • KR: Garantir que 100% dos handoffs tenham runbook e checklist mínimos.
Objetivo 3 — Reduzir Risco de Dados e Segurança em Iniciativas de IA e Produtos Digitais
  • KR: Manter 0 incidentes de segurança e dados sensíveis por trimestre;
  • KR: Garantir que 100% das iniciativas com dados tenham registro de restrições e controles aplicados;
  • KR: Treinar 100% do time em checklist de dados, segredos e conformidade no semestre.
Objetivo 4 — Aumentar Impacto no Negócio com Iniciativas de Alto Valor
  • KR: Entregar pelo menos 2 PoCs com decisão clara por trimestre;
  • KR: Entregar pelo menos 1 MVP ou piloto por trimestre com feedback registrado;
  • KR: Garantir que 100% das iniciativas tenham critério de decisão definido no Discovery.

11. Controle de Documento

Responsável pelo Documento

O responsável por atualizar e manter este manual é o Tech Lead / Gestão de P&D. Alterações com impacto estratégico, conformidade, dados sensíveis ou mudanças relevantes de governança devem ser homologadas pela Gerência.

Cadência de Revisão

Revisão periódica para manter aderência à prática e às mudanças do Grupo.

  • Revisão trimestral: processos, SLAs, riscos e rituais;
  • Revisão semestral: matriz de competências, trilhas, PDIs e avaliação;
  • Revisão sob demanda: após incidentes relevantes, mudanças de ferramenta, mudanças de governança ou lições aprendidas críticas.
Controle de Versões

Toda atualização do manual deve registrar:

  • Versão;
  • Data;
  • Responsável pela alteração;
  • Resumo do que mudou;
  • Motivo da mudança;
  • Capítulos impactados.
Changelog (modelo)

Versão

Data

Responsável

Resumo da mudança

Motivo

Capítulos impactados

0.1

Preencher

Tech Lead

Primeira versão operável

Implantação

Todos

0.2

Preencher

Tech Lead

Ajuste de catálogo e SLAs

Capacidade real do time

Cap. 4

0.3

Preencher

Tech Lead

Ajuste de riscos e controles

Incidente / auditoria

Cap. 7

Regras de Publicação do Manual

  • O manual deve ficar disponível no repositório oficial de documentação do Grupo;
  • Não é permitido manter versões paralelas sem controle;
  • Templates, checklists e evidências devem estar centralizados no M365 e referenciados no manual.