Arquiteto de Knowledge Base Interna

Passo 1 — Definir o escopo e o modelo de governança

Decisão estratégica antes de tudo:

Escopo:

- Full: KB cobre todo conhecimento operacional da empresa (operações, eng, ops, vendas, marketing, RH, finance). - Specialized: KB foca em um domínio (ex: só engineering, só customer-facing).

Modelo de governança: - Centralizado: existe time/papel dedicado de Knowledge Manager. Aprovação central de novas seções. Mais consistente, menos ágil. - Federado: cada área tem owner próprio. Padrões mínimos globais. Mais ágil, risco de inconsistência. - Híbrido: estrutura global definida centralmente; conteúdo descentralizado por área. Default recomendado para empresas de 50-500 pessoas.

Documentar a escolha e a justificativa. Sem isso, a KB cresce sem norte.

Passo 2 — Definir taxonomia top-level

Taxonomia top-level é a estrutura de navegação principal. Mantê-la estável (raramente muda) e rasa (3 níveis no máximo na maior parte).

Taxonomia padrão Gzero para empresa de software:

``

KB Interna ├── 1. Empresa │ ├── Quem somos / cultura / valores │ ├── Estrutura organizacional │ ├── Políticas (incluindo acceptable-use, ética) │ └── Onboarding (geral, primeira semana) ├── 2. Pessoas │ ├── Benefícios e remuneração │ ├── Férias e licenças │ ├── Carreira e mobilidade │ └── Saúde, segurança, ergonomia ├── 3. Operações │ ├── Runbooks │ ├── SOPs │ ├── Incident response │ └── Vendor management ├── 4. Engineering │ ├── Stack e arquitetura │ ├── Padrões de código e review │ ├── Deploy e release │ └── Onboarding engineering ├── 5. Produto │ ├── Roadmap (público interno) │ ├── Decisões de produto │ └── Pesquisa de usuário ├── 6. Comercial │ ├── Pricing e packaging │ ├── Sales playbook │ └── CS playbook ├── 7. Compliance / Segurança │ ├── Políticas formais │ ├── BCP, DR │ └── Auditoria └── 8. Arquivo └── Documentos arquivados (ver passo 5) `

A árvore real será ajustada pelo escopo. O importante é: top-level navegável, profundidade controlada, sem 47 nós no primeiro nível.

Passo 3 — Estabelecer ownership por seção

Cada seção (e cada documento crítico dentro dela) tem um owner. Owner é o papel responsável por:

- Manter o conteúdo correto. - Aprovar mudanças significativas. - Revisar segundo cadência definida. - Arquivar conteúdo obsoleto.

Owner é papel, não pessoa. "Gerente de Operações" sobrevive a turnover; "Maria Silva" não.

Output: matriz seção → owner_role → backup_role.

Documentos sem owner são considerados órfãos e entram em fila de arquivamento (ver passo 5).

Passo 4 — Definir templates obrigatórios

Documento sem template gera variância alta e qualidade baixa. Templates mínimos:

| Tipo | Quando usar | Skill relacionada |

|---|---|---| | SOP | Processo formal repetitivo | sop-writer | | Runbook | Procedimento operacional / on-call | runbook-writer | | Decision log / ADR | Decisão de produto, técnica ou operacional | (criar template Gzero) | | Meeting notes | Reuniões importantes | meeting-notes | | Postmortem | Pós-incidente | incident-postmortem | | Onboarding guide | Por papel | (template específico) | | Política | Documentos formais (AUP, conduta) | acceptable-use-policy | | Project status / brief | Documentos de projeto | project-status-report | | FAQ | Lista de perguntas comuns por área | (template simples) |

Cada template tem campos obrigatórios: título, owner, última revisão, próxima revisão, status, tags.



Passo 5 — Definir ciclo de vida do documento

Documentos têm vida útil. Estados explícitos:

`

[Draft] → [Active] → [Stale] → [Archived] ↓ (revisado → volta para Active) ``

- Draft: em construção, não confiável. Marcação visível. - Active: revisado e atualizado dentro da cadência. - Stale: passou da data de revisão sem update. Banner visível no topo. - Archived: obsoleto. Movido para seção "Arquivo" (não deletado, para histórico).

Cadência de revisão por tipo:

| Tipo | Cadência mínima | |---|---| | Política / SOP regulatório | Anual | | Runbook crítico (P0/P1) | Trimestral | | Runbook geral | Semestral | | Decision log / ADR | Imutável (mas linkável a sucessor) | | Onboarding | Trimestral | | FAQ | Trimestral | | Status de projeto | Quando muda |

Implementação técnica: campo de data de próxima revisão no template; automação (Notion automation, Confluence macro) muda status para Stale quando passa do prazo.

Passo 6 — Estabelecer padrão de navegação e busca

Navegação:

- Sidebar sempre visível com top-level expandido.

- Breadcrumbs em toda página. - Páginas índice para cada seção (não despejo direto de documentos sem rumo). - Links cruzados entre documentos relacionados (não duplicar conteúdo). - Limite de profundidade: 4 níveis. Acima disso, reestruturar.

Busca:

- Tags consistentes: taxonomia de tags definida e finita (~50 tags totais), não tag livre. - Títulos padronizados: começam com a "coisa", não com verbo. Ex: "Política de Senhas", não "Como gerenciar senhas". - Front matter / metadados: todo documento tem owner, tags, data, status visíveis. - Validação periódica: pesquisar por termos comuns; se a resposta não aparece nas três primeiras, há gap.

Passo 7 — Plano de migração (se houver KB legacy)

Se já existe KB anterior, migração precisa de plano:

1. Inventário: listar tudo que existe na KB atual.

2. Triagem: classificar em (a) migrar como está, (b) reescrever e migrar, (c) consolidar com outro doc, (d) arquivar. 3. Priorização: documentos mais acessados migram primeiro. 4. Map de redirect: URL antiga → nova, mesmo que apenas em planilha. 5. Janela de coexistência: KB antiga em read-only por X meses, com banner "este conteúdo migrou para [link]". 6. Sunset: KB antiga é desligada apenas quando >95% do tráfego está na nova.

Migração genérica ("vamos passar tudo") sem triagem entrega bagunça com outro nome.

Passo 8 — Estabelecer governança contínua

KB sem governança degrada em 6-12 meses. Estrutura mínima:

- Knowledge Manager (papel ou parte de papel): zela pela KB como um todo.

- Owners de seção: revisão e qualidade do seu domínio. - Comitê de KB (trimestral): reúne owners, revisa métricas, aprova mudanças estruturais. - Política de criação: novo documento exige template + tags + owner. - Política de arquivamento: documentos Stale por >90 dias entram em fila de revisão; sem ação, viram Archived.

Documentar tudo isso em um meta-documento (geralmente "Como usamos a KB").

Passo 9 — Definir métricas de saúde da KB

Sem métricas, KB degrada sem aviso. Métricas obrigatórias:

| Métrica | Como medir | Alvo |

|---|---|---| | % de documentos com owner | Audit periódica | ≥ 95% | | % de documentos Active (não Stale) | Audit periódica | ≥ 80% | | Buscas com resultado clicado | Analytics da ferramenta | ≥ 70% | | Buscas sem resultado | Analytics | < 5% das buscas | | Tempo desde última edição (mediana) | Audit periódica | < 90 dias | | Documentos com >12 meses sem edição em Active | Audit | < 10% | | NPS interno da KB | Pesquisa trimestral | ≥ 7 |

Dashboard simples com essas métricas. Revisado no comitê.

Passo 10 — Estabelecer cultura de uso

Arquitetura boa não basta sem cultura. Habilitar:

- Onboarding: todo novo colaborador faz tour pela KB na primeira semana.

- Slack norm: "está documentado em [link]?" antes de responder mesma pergunta pela quinta vez. - PR/MR norm: mudança em sistema/processo crítico exige update de documento como parte da entrega. - Reconhecimento: destacar contribuidores de docs no all-hands ou similar. - Anti-padrão a banir: "perguntou na Maria que ela sabe" → resposta padrão é "vamos achar/criar o doc".

Cultura emerge de ritual e exemplo. Liderança usar a KB ativamente é o sinal mais forte.