¿Cómo demostrar una habilidad? Modelo de 6 niveles de evidencia de competencias

El enfoque Skills First desplaza la atención de las etiquetas formales hacia las competencias que una persona puede demostrar. Sin embargo, esto no resuelve automáticamente cómo evaluarlas.

La OCDE describe skills-first como un enfoque en el que las prácticas de contratación y gestión del talento se adaptan para evaluar a las personas según las habilidades demostradas. El informe también señala la necesidad de herramientas de evaluación y marcos de competencias adecuados. [1]

Por tanto, sustituir una sección de "Education" por una lista más larga de "Skills" no es suficiente. También necesitamos explicar mejor por qué una competencia debería considerarse creíble.

Dos personas pueden indicar exactamente la misma competencia y, aun así, tener experiencias prácticas completamente distintas.

Imaginemos a dos especialistas que declaran:

Angular - avanzado

La primera persona terminó un curso, creó algunos proyectos propios y conoce los fundamentos del framework.

La segunda lleva tres años desarrollando una aplicación en producción, ha sido responsable de la arquitectura de parte del sistema, ha realizado migraciones entre versiones de Angular y puede señalar resultados concretos de ese trabajo.

En una lista tradicional de habilidades pueden parecer muy similares.

Solo la evidencia situada en contexto empieza a mostrar la diferencia real.

El modelo no pretende asignar a las personas una puntuación universal. Cada profesión genera tipos distintos de evidencia y no todos los proyectos pueden mostrarse públicamente.

Su objetivo es responder a una pregunta más sencilla:

¿qué tan sólida es la información que respalda la presentación de una competencia concreta?

El nivel más básico es la declaración de la propia persona.

Ejemplos:

• Angular
• Figma
• SEO
• liderazgo de equipos
• negociación B2B

La información resulta útil para búsqueda y descubrimiento, pero su valor probatorio es limitado.

Todavía no sabemos:

• dónde se utilizó la competencia,
• durante cuánto tiempo,
• a qué escala,
• con qué responsabilidad,
• con qué resultado.

La declaración es el punto de partida, no el final de la evaluación.

La evidencia gana fuerza cuando sabemos dónde y en qué contexto se utilizó la habilidad.

En lugar de:

Angular

podemos leer:

Angular utilizado durante 2 años en el desarrollo de una aplicación SaaS para el sector logístico.

Esto todavía no demuestra la calidad del trabajo, pero aporta contexto importante:

• un proyecto real,
• tiempo de uso de la competencia,
• área de aplicación,
• tipo de entorno.

En este nivel, la habilidad deja de ser solo una etiqueta.

El siguiente nivel aparece cuando la declaración y la experiencia pueden vincularse a un artefacto real de trabajo.

Según la profesión, puede ser:

• una aplicación funcional,
• una muestra de código,
• un repositorio,
• un diseño de interfaz,
• un prototipo,
• un informe,
• un análisis,
• una campaña,
• un artículo,
• documentación,
• un modelo financiero,
• una fotografía,
• un proyecto técnico,
• una grabación del trabajo realizado.

El artefacto responde a una pregunta importante:

¿podemos ver algo que realmente se haya creado utilizando esa habilidad?

Esto no significa que un portfolio sea una prueba formal de competencias. Sin embargo, la investigación sobre selección de personal indica que métodos estrechamente relacionados con las tareas reales, como las muestras de trabajo y las pruebas de conocimiento profesional, pueden ser predictores útiles del rendimiento. Los autores también subrayan que los resultados deben interpretarse teniendo en cuenta el contexto, el coste y las limitaciones de cada método. [2]

Un artefacto puede seguir sin responder a una de las preguntas más difíciles:

¿qué hizo exactamente esta persona?

Esto es especialmente importante en proyectos de equipo.

Una aplicación puede haber sido creada por 20 personas. Una campaña puede haber involucrado a 8. Un rebranding puede haber reunido a una agencia, un equipo interno de marketing y consultores externos.

Por eso una evidencia más sólida es un caso de estudio que identifique la contribución individual.

Un buen caso debería separar al menos:

• el problema u objetivo,
• el alcance del proyecto completo,
• la responsabilidad personal del especialista,
• las acciones realizadas,
• las competencias utilizadas,
• la colaboración con otras personas,
• el resultado.

En lugar de:

Creé una plataforma de e-commerce.

es mejor:

Fui responsable de la arquitectura frontend, la implementación del checkout y la integración del flujo de pago. El proyecto fue realizado por un equipo de cinco personas.

La segunda descripción es más útil porque no atribuye a una sola persona el trabajo de todo el equipo.

La evidencia se vuelve aún más sólida cuando el trabajo conduce a un resultado concreto que puede describirse sin generalidades.

Ejemplos:

Frontend
Reducir el tiempo de carga de la vista principal de 4,2 s a 1,8 s.

UX
Reducir el abandono del formulario de registro después de rediseñar el proceso.

Marketing
Reducir el coste por lead manteniendo una calidad de tráfico comparable.

Ventas
Abrir un nuevo segmento de clientes y cerrar un número definido de contratos.

Operations
Reducir un proceso de varios días a varias horas.

No todas las profesiones pueden o deben expresar un resultado como porcentaje o importe. No conviene inventar métricas solo para que el perfil parezca más impresionante.

La pregunta útil es:

¿qué cambió gracias a este trabajo?

El nivel más sólido del modelo aparece cuando al menos una parte de la información puede verificarse independientemente de la declaración del autor del perfil.

Puede tratarse de:

• un proyecto accesible públicamente,
• un repositorio con historial de contribuciones,
• una publicación pública,
• participación confirmada en un proyecto,
• una referencia de cliente o colaborador que pueda publicarse legalmente,
• un resultado que pueda confirmarse de forma independiente,
• una credencial oficial cuando sea realmente relevante,
• otra fuente que confirme un trabajo concreto.

Esto no significa que todo proyecto deba ser público.

Muchos trabajos valiosos están sujetos a NDA, secreto empresarial u otras obligaciones de confidencialidad.

Por eso la falta de evidencia pública no significa falta de competencia.

Significa únicamente que el grado de verificabilidad independiente es menor.

Nivel 1 - declaración
Angular.

Nivel 2 - contexto
Angular utilizado durante 3 años en aplicaciones SaaS.

Nivel 3 - artefacto
Una aplicación pública, un repositorio u otra muestra de trabajo que pueda enseñarse.

Nivel 4 - contribución individual
Responsabilidad sobre la arquitectura de determinados módulos, componentes compartidos y migración de la aplicación.

Nivel 5 - resultado
Una optimización redujo el tiempo de arranque del módulo principal de 4,2 s a 1,8 s. Los valores son ilustrativos.

Nivel 6 - verificación
El resultado y la contribución pueden confirmarse además mediante un proyecto público, historial de cambios, referencia u otra fuente independiente.

Dos evidencias situadas en el mismo nivel pueden tener un valor muy diferente. Cinco dimensiones adicionales ayudan a interpretarlas.

1. Relevancia - ¿la evidencia se refiere realmente a la competencia que se quiere evaluar?

2. Actualidad - ¿cuándo se utilizó la competencia y cuánto importa la recencia en ese ámbito?

3. Autoría y responsabilidad - ¿sabemos qué hizo realmente la persona?

4. Contexto - ¿cuál era la escala, complejidad, responsabilidad, recursos y condiciones de trabajo?

5. Verificabilidad - ¿existe una forma independiente de confirmar al menos parte de la información?

Relevancia

Un proyecto en el que una tecnología tuvo un papel marginal es una evidencia más débil que otro en el que esa competencia fue central.

Actualidad

La importancia de la recencia depende del ámbito. En algunas áreas, una experiencia de hace diez años sigue siendo muy valiosa. En otras, las herramientas y prácticas cambian tan rápido que el uso reciente importa mucho.

Autoría y responsabilidad

Cuanto mayores sean el proyecto y el equipo, más importante es separar el resultado global de la contribución individual del especialista.

Contexto

El mismo resultado puede tener distinto peso según la escala del proyecto, las restricciones de tiempo, los recursos, el nivel de responsabilidad y la complejidad del problema.

Verificabilidad

La verificación independiente no siempre es posible ni debería ser siempre obligatoria. Cuando existe una fuente independiente que confirma el resultado o la contribución, aumenta la credibilidad de la evidencia.

Una persona puede realizar muy bien su parte de un proyecto que finalmente fracasa desde el punto de vista comercial.

También puede trabajar en un proyecto muy exitoso teniendo solo una pequeña influencia en su resultado final.

Conviene separar tres elementos:

1. Competencia
¿Puede la persona realizar un determinado tipo de trabajo?

2. Contribución
¿De qué parte fue realmente responsable?

3. Resultado
¿Qué cambió como consecuencia de ese trabajo?

La combinación de estos elementos ofrece una imagen más completa.

Un certificado u otra credencial formal puede ser una evidencia útil, pero su valor depende de qué confirma realmente y cómo se obtuvo.

Puede confirmar, por ejemplo:

• finalización de una formación,
• logro de determinados resultados de aprendizaje,
• superación de una evaluación concreta,
• conocimiento de un estándar,
• cumplimiento de requisitos formales.

La Comisión Europea describe las microcredenciales como registros de resultados de aprendizaje adquiridos mediante una experiencia breve de aprendizaje. El enfoque europeo destaca, entre otros aspectos, la transparencia y la calidad. [3]

No debería asumirse automáticamente que un certificado demuestra la capacidad de realizar de forma autónoma un trabajo complejo en un entorno profesional real.

Una credencial es uno de los posibles elementos de evidencia, cuyo significado depende del contexto.

No poder mostrar un proyecto públicamente no debería borrar una experiencia valiosa.

Al mismo tiempo, los NDA, las obligaciones de confidencialidad, el secreto empresarial, los derechos de autor y la protección de datos tienen prioridad sobre el deseo de mostrar un portfolio.

El especialista debe describir un proyecto únicamente en la medida permitida por sus contratos, la legislación aplicable y los derechos de otras personas y organizaciones. Eliminar el nombre del cliente no siempre es suficiente si el resto de la información permite identificar el proyecto, al cliente, la tecnología, los resultados o métodos confidenciales.

Cuando la divulgación sea legalmente posible, puede considerarse describir:

• el sector con un nivel de generalidad adecuado,
• la naturaleza del problema sin revelar información confidencial,
• la función y responsabilidades propias,
• las competencias utilizadas,
• la escala del trabajo solo en la medida permitida,
• el tipo de resultado sin publicar datos protegidos,
• el enfoque con un nivel de detalle adecuado.

Si existe alguna duda sobre si una información puede publicarse, lo más seguro es no divulgarla hasta revisar el contrato o contar con autorización del titular correspondiente.

Un sistema de evidencia de competencias no debería diseñarse como si todas las profesiones fueran desarrollo de software.

Un diseñador puede mostrar el proceso, decisiones de diseño, prototipo y resultado.

Un desarrollador puede mostrar un producto, código, arquitectura o alcance técnico de responsabilidad.

Un profesional de marketing puede presentar una campaña, enfoque, responsabilidad y cambios en resultados.

Un profesional de ventas puede describir el segmento, el proceso comercial, su papel y el resultado sin revelar datos confidenciales de clientes.

Un Project Manager puede mostrar el alcance del proyecto, organización del trabajo, limitaciones e influencia en la entrega.

Un fotógrafo puede presentar trabajos realizados sin inventar KPI artificiales.

El modelo puede ser común en sus principios y flexible en el tipo de evidencia utilizada.

1. Comprueba dónde se utilizó realmente la competencia.

2. Busca un artefacto de trabajo o un ejemplo concreto de ejecución.

3. Separa la contribución del especialista del trabajo del equipo completo.

4. Revisa el resultado cuando pueda describirse de forma significativa.

5. Valora la actualidad y la similitud de la experiencia previa con el problema que necesitas resolver.

6. Busca confirmación independiente cuando sea posible y apropiado.

Así, la evaluación se desplaza de las palabras clave del perfil hacia el ajuste real entre competencias demostradas y una necesidad concreta.

El modelo está pensado para organizar información y apoyar el criterio humano. No debería tratarse como un veredicto automático para contratar, rechazar a una persona o iniciar una colaboración profesional.

No hace falta disponer de evidencia de nivel 6 para cada competencia.

Es más útil revisar las habilidades más importantes y preguntarse:

• ¿dónde la utilicé?
• ¿qué problema estaba resolviendo?
• ¿qué hice exactamente?
• ¿tengo un artefacto de ese trabajo?
• ¿cuál fue el resultado?
• ¿puedo describirlo sin incumplir la confidencialidad?
• ¿hay una persona o fuente que pueda confirmar mi contribución?

Incluso pasar de:

Figma - avanzado

a:

Diseñé el proceso de onboarding de una aplicación B2B y fui responsable de research, prototipado, pruebas de usabilidad y el design system final

mejora de forma clara la calidad de la información disponible para quien visita el perfil.

El enfoque Skills First solo tiene sentido si la palabra "skill" representa algo más que otra etiqueta.

Si las competencias deben ser una de las principales formas de descubrir y comparar especialistas, conviene conectarlas con el mejor contexto disponible:

experiencia -> portfolio -> contribución individual -> resultado -> verificabilidad.

No todas las competencias alcanzarán el nivel más alto, ni deberían tener que hacerlo.

El objetivo no es crear burocracia obligatoria alrededor de cada elemento del perfil.

El objetivo es permitir a los especialistas explicar por qué una habilidad debería resultar creíble y ayudar a quienes buscan experiencia a tomar decisiones mejor informadas.

1. Concreción en lugar de declaración - muestra dónde y cómo se utilizó la competencia.

2. Contribución individual en lugar del éxito de todo el equipo - separa tu trabajo del resultado de toda la organización.

3. Resultado en lugar de lista de tareas - cuando sea posible, muestra qué cambió gracias al trabajo.

4. Contexto en lugar de un número aislado - una métrica sin condiciones puede conducir a conclusiones incorrectas.

5. Verificación cuando sea posible - una confirmación independiente aumenta la credibilidad, pero su ausencia no invalida la competencia.

Un perfil profesional no debería obligar al lector a adivinar qué hay realmente detrás de una lista de habilidades.

La declaración permite descubrir una competencia. La evidencia permite entenderla.

Los seis niveles pueden resumirse en un recorrido sencillo:

1. Digo que sé hacerlo.
2. Muestro dónde lo utilicé.
3. Muestro qué creé.
4. Explico qué hice exactamente.
5. Muestro el resultado.
6. Facilito confirmación independiente cuando es posible.

Cuantas más respuestas podamos aportar, menos dependeremos únicamente de una declaración.

Es entonces cuando Skills First significa algo más que cambiar el orden de la información en un perfil.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Abrir fuente

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Abrir fuente

[3] European Commission - A European approach to micro-credentials
Abrir fuente

Nota metodológica: las fuentes [1]-[3] aportan contexto general sobre Skills First, evaluación de competencias y credenciales. El Modelo de 6 niveles de evidencia de competencias es un modelo conceptual original descrito en este material y no se presenta como resultado de esas publicaciones.