PT
Rede modular de tubulações montada sobre uma bandeja com peças separadas por tipo.

Uma lista de skills não é uma arquitetura

Um catálogo responde quais skills existem e como encontrá-las. Uma arquitetura acrescenta as relações necessárias para interpretar expectativas, avaliar evidências, orientar o desenvolvimento e reconhecer caminhos entre funções.

PRYSMAP5 min de leitura

A diferença não depende do tamanho. Uma organização pode manter centenas de termos bem definidos e ainda assim não saber o que significam dentro de uma função. Também pode começar com poucas skills e construir relações suficientes para apoiar decisões reais.

O que uma lista faz bem

Os catálogos resolvem problemas específicos. Eles reduzem sinônimos, atribuem identificadores, agrupam conceitos e facilitam buscas. Sem essa base, cada área acaba nomeando capacidades semelhantes de maneiras diferentes.

ESCO, a classificação europeia de skills e profissões, é apresentada como um dicionário multilíngue. Seus conceitos possuem termos, descrições e relações que permitem utilizá-los em serviços de emprego, treinamento e análise. Sua utilidade pública revela duas camadas distintas: classificar as entidades e conectá-las para viabilizar outras decisões. Comissão Europeia, “O que é ESCO?”

Uma empresa não precisa copiar essa escala, mas precisa reconhecer o limite de uma linha isolada. O nome “gestão de riscos” pode estar corretamente definido e categorizado. Ainda assim, não indica a profundidade exigida por uma função, quais evidências demonstrariam domínio ou quanto dessa capacidade poderia ser reutilizado em outro contexto.

Dois modelos que parecem semelhantes de longe

No modelo de inventário, cada skill ocupa uma linha. Pode ter descrição, categoria e tags. Quando uma nova função aparece, a resposta usual é atribuir a ela um conjunto de linhas. Caso seja necessária maior precisão, são criadas variantes: gestão de risco júnior, sênior, estratégica ou especializada.

Esse caminho parece direto. Também fragmenta facilmente a mesma capacidade. As diferenças inerentes ao trabalho ficam escondidas em novos nomes. Comparar funções torna-se difícil porque uma progressão acaba representada como se fossem skills independentes.

O modelo relacional preserva um conjunto comum quando isso faz sentido e registra as diferenças em outro lugar. A skill se conecta a níveis, manifestações observáveis, tracks, funções, expectativas e evidências. As perguntas mudam:

  • O que permanece igual entre duas funções?
  • Que nível, autonomia ou abrangência cada um exige?
  • Que observações nos permitem sustentar esta diferença?
  • Que relação permite uma decisão de desenvolvimento ou de mobilidade?

O nível faz sentido dentro de uma relação

SFIA combina skills profissionais com sete níveis de responsabilidade. Os seus níveis descrevem mudanças na responsabilidade, prestação de contas e impacto, e servem como base para mapear estruturas e trajetórias. A estrutura insiste que a competência seja demonstrada em situações reais de trabalho, e não apenas por meio do conhecimento teórico. SFIA, “Como funciona a SFIA”

O exemplo não deve tornar-se uma regra universal. SFIA nasceu na área digital e utiliza arquitetura própria. Sua contribuição para esta discussão é mostrar que o nível não é um adjetivo acrescentado ao nome da skill. É uma relação com o tipo de responsabilidade exercida.

Dentro de um track, diversas funções podem compartilhar exatamente as mesmas skills. As suas diferenças aparecem na profundidade, autonomia, complexidade, escopo, liderança, impacto e evidência esperada. Isso evita a criação de um catálogo diferente para cada posição e preserva uma trajetória compreensível.

Fora do track, a arquitetura precisa de outro tipo de relação. Algumas skills serão compartilhadas; outras serão novas. Entre esses dois extremos existe uma zona menos confortável: capacidades já demonstradas que exigem adaptação antes de serem aplicadas em outro contexto. Uma lista costuma mostrar correspondência. A arquitetura também deve representar distância.

Relações contêm premissas

Conectar uma skill a uma função não prova que a pessoa a domina. Vinculá-la a uma categoria também não explica como avaliá-la. Atribuir um nível esperado não prescreve um plano de desenvolvimento.

Cada relação responde a uma pergunta e deixa outras em aberto. A categoria melhora a navegação. O nível distingue graus de desempenho. A expectativa situa esse grau dentro de uma contribuição. As evidências sustentam uma conclusão sobre uma pessoa. A transferibilidade estima o que poderia ser preservado em uma mudança de contexto. Quando o modelo confunde essas funções, as decisões herdam o erro. Um sistema pode inferir uma lacuna porque faltaram evidências. Pode recomendar treinamento quando o verdadeiro limite for a falta de autoridade. O sistema pode declarar duas funções “próximas” porque elas compartilham palavras, mesmo que as condições de aplicação sejam incompatíveis.

A arquitetura não elimina esses riscos. Torna-os visíveis e cria um espaço para discuti-los.

Pista modular de madeira que forma um circuito com desvios e uma ponte, com um vagão sobre um trecho.

Remover uma relação permite testar sua utilidade

Existe uma maneira prática de examinar uma arquitetura: remover mentalmente cada conexão e ver qual decisão não é mais válida.

Sem categorias, a manutenção e a navegação se deterioram. Sem manifestações observáveis, a skill mantém um nome, mas perde um objeto avaliável. Sem níveis, é difícil distinguir a progressão. Sem expectativas de função, um score não tem referência. Sem evidências, o domínio se torna uma mera afirmação. Sem relações entre funções e tracks, a mobilidade e a sucessão dependem de semelhanças superficiais.

O teste também evita complexidade desnecessária. Vale manter uma relação quando ela esclarece uma interpretação, evita uma inconsistência ou apoia uma decisão relevante. Se ninguém consegue explicar o que muda ao removê-la, talvez o modelo esteja apenas acumulando estrutura.

Uma arquitetura útil não é aquela que contém o maior número de nós e conexões. É aquela que permite passar, sem saltos ocultos, da definição à decisão. Manter essa utilidade exige distinguir os sinais que justificam uma correção daqueles que exigem revisão estrutural.

  4. A capa de Sorting Things Out sobre uma mesa de madeira, ao lado de uma pequena caixa de papel.

    Sorting Things Out: toda taxonomia descreve e também decide

    O livro Sorting Things Out examina como categorias e padrões organizam o mundo enquanto distribuem visibilidade, trabalho e consequências. Lê-lo sob a perspectiva de uma arquitetura de skills amplia a análise para as decisões que uma taxonomia torna possíveis.