Objetivo: ao final, o consultor decide entre Project e Skill, e compartilha um Project com a squad com atenção ao conteúdo sensível.
| Project | Skill | |
|---|---|---|
| Responde | "De qual cliente / contexto estamos falando?" | "Como eu faço este tipo de trabalho?" |
| Muda de cliente para cliente | Sim | Não |
| Viaja com você entre clientes | Não | Sim |
| Como é ativado | Automático, dentro do Project | Automático, quando ele reconhece a tarefa |
| Exemplos | Org structure, escopo, glossário do cliente, restrições da fase | Checklist de revisão, template de spec, procedimento de cutover, formato de status report |
| Item | Onde | Por quê |
|---|---|---|
| Estrutura organizacional do cliente | Project | Específico daquele cliente |
| Glossário de siglas do cliente | Project | Idem |
| Restrições de escopo da fase | Project | Idem |
| BBP e documentos de desenho | Project | Idem |
| Seu checklist de revisão de spec | Skill | Viaja com você |
| Template de spec da Wayon | Skill | Vale em todos os clientes |
| Procedimento de cutover da casa | Skill | Idem |
| Formato do seu status report | Skill | Idem |
| Como você gosta que e-mails sejam redigidos | Skill | É preferência sua |
O que o outro recebe: as instruções, a base de conhecimento inteira, e acesso ao Project para criar conversas dentro dele.
O ganho: todo mundo na squad opera com o mesmo contexto. Elimina a situação em que dois consultores dão respostas diferentes porque um conhecia a restrição e o outro não.
Os cuidados:
Regra Wayon Project com dado de cliente é compartilhado apenas com a squad daquele projeto e o Flávio. Isso não é preferência — é aplicação da política de dados da aula 1.1.4: compartilhar um Project compartilha a base de conhecimento inteira, sem seleção de arquivo. Um documento que alguém subiu "porque era rápido" deixa de ser restrito no instante do compartilhamento. Quem compartilha: quem criou o Project. Antes de compartilhar, abra a base e olhe arquivo por arquivo — não existe compartilhamento parcial. Dono das instruções nomeado no ato. Project compartilhado sem dono desatualiza e ninguém percebe. Consultor que sai da squad tem o acesso revogado na saída, junto com os outros acessos do projeto. É a mesma lógica da revogação de conectores (aula 1.6.1): acesso que ninguém revoga permanece. Fim de contrato: arquivar. Excluir só depois de confirmar o que o contrato exige sobre devolução ou eliminação de material.
Você teria que duplicar em cada Project de cliente e manter todos em sincronia.
Correto. É como você trabalha, e vale em todos os clientes.
Você anexaria a cada revisão. É o caso central de skill.
Não viaja: as siglas do Meridiano não significam nada no Aurora.
Ele não tem como saber que "Fluxo Verde" é o fluxo simplificado até R$ 5.000.
Correto. Específico do cliente, estável, reutilizável em toda conversa daquele cliente.
Duplicação em N lugares; quando o template mudar você atualiza N vezes ou fica com versões divergentes.
Correto. Vale em todos os clientes. Como skill, ele aplica sozinho quando reconhece a tarefa.
Não é o mecanismo. O que existe é Project compartilhado ou skill compartilhada.
Correto. Quem recebe o Project recebe a base inteira.
Boa prática, mas não é o risco principal.
Não é. A base de conhecimento vai junto.
Os dois podem conter ambos.
Correto. Se muda, Project. Se é seu jeito de trabalhar e viaja com você, skill.
Confidencialidade é uma questão importante, mas ortogonal: existe Project sensível e skill sensível.