# MAN-G-001-A-Manual de P&D # 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](https://wikivix.autvix.com.br/uploads/images/gallery/2026-04/scaled-1680-/kq8image.png)](https://wikivix.autvix.com.br/uploads/images/gallery/2026-04/scaled-1680-/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. [](https://wikivix.autvix.com.br/books/manuais-pd/page/5-processos-operacionais/edit?content-id=bkmrk-encerramentoregistro&content-text=EncerramentoRegistro%20do%20porqu%C3%AA%2C%20o%20que%20foi%20aprendid "Ir para a seção do editor") ****Encerramento**** Registro do porquê, o que foi aprendido, evidências e recomendações para não repetir. [![image.png](https://wikivix.autvix.com.br/uploads/images/gallery/2026-01/scaled-1680-/gqYimage.png)](https://wikivix.autvix.com.br/uploads/images/gallery/2026-01/gqYimage.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

[](https://wikivix.autvix.com.br/books/manuais-pd/page/6-interfaces-e-stakeholders/edit?content-id=bkmrk-observa%C3%A7%C3%B5esresposta-&content-text=Observa%C3%A7%C3%B5esResposta%20%C3%A9%20o%20tempo%20at%C3%A9%20o%20contato%20inicia "Ir para a seção do editor") ****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 [](https://wikivix.autvix.com.br/books/manuais-pd/page/7-governanca-e-riscos/edit?content-id=bkmrk-riscoimpacto-potenci&content-text=RiscoImpacto%20PotencialN%C3%ADvel%20de%20RiscoControles%20Prev "Ir para a seção do editor")

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) [](https://wikivix.autvix.com.br/books/manuais-pd/page/9-melhoria-continua-e-inovacao/edit?content-id=bkmrk-base-para-identifica&content-text=Base%20para%20identificar%20oportunidades%20de%20melhoria%3A%20t "Ir para a seção do editor") 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 [](https://wikivix.autvix.com.br/books/manuais-pd/page/11-controle-de-documento/edit?content-id=bkmrk-o-manual-deve-ficar-&content-text=O%20manual%20deve%20ficar%20dispon%C3%ADvel%20no%20reposit%C3%B3rio%20ofic "Ir para a seção do editor") - 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.