¿Lo hice yo o el equipo? Cómo describir honestamente tu aportación en un portafolio

La mayoría de los productos, campañas, implantaciones y procesos valiosos se crean en equipo.

Por eso, mostrar únicamente el resultado final todavía no explica qué papel desempeñó realmente un especialista concreto.

Para quien revisa un portafolio, la diferencia es enorme:

"Trabajé en el rediseño del proceso de finalización de compra"

no significa lo mismo que:

"Dirigí la investigación, diseñé el nuevo recorrido de finalización de compra, preparé el prototipo y realicé pruebas de usabilidad. Un equipo separado de desarrollo de interfaz se encargó de la implementación."

La segunda descripción permite evaluar competencias reales sin restar mérito al trabajo de otras personas.

Este problema no es exclusivo de los portafolios profesionales.

En el ámbito de las publicaciones científicas existe, entre otros, CRediT - Contributor Role Taxonomy. Este estándar describe 14 tipos de contribución y se creó para aumentar la transparencia sobre quién fue realmente responsable de las distintas partes de un trabajo. CRediT permite asignar varios roles a una persona y un mismo rol a varias personas. También recomienda que los colaboradores puedan revisar y confirmar los roles que se les atribuyen. [1]

CRediT se refiere principalmente a la investigación y a las publicaciones científicas. No es un estándar para portafolios profesionales. Sin embargo, muestra un principio importante que puede aplicarse de forma más amplia: en lugar de decir vagamente "formé parte del proyecto", conviene indicar con claridad cuál fue la contribución real.

Una buena descripción de un proyecto en equipo puede construirse alrededor de seis datos:

1. Contexto del proyecto
2. Composición y alcance del equipo
3. Responsabilidad propia
4. Acciones y decisiones concretas
5. Artefactos o evidencias del trabajo
6. Resultado y forma de atribuirlo

No se trata de redactar un informe largo. Se trata de eliminar las ambigüedades más importantes.

Primero explica en qué estaba trabajando realmente el equipo.

Basta con indicar brevemente:

• el problema o el objetivo,
• el tipo de producto o servicio,
• la escala aproximada,
• las restricciones importantes,
• el periodo de ejecución, si es relevante.

Ejemplo:

El objetivo del proyecto era acortar el proceso de compra en una aplicación B2B. El producto funcionaba en varios mercados europeos y atendía a clientes empresariales.

Así, el lector entiende el entorno antes de evaluar la aportación individual.

No hace falta enumerar a cada persona por nombre y apellido.

En muchos casos basta con una estructura como:

Equipo: responsable de producto, diseñador de experiencia de usuario, 2 desarrolladores de interfaz, 2 desarrolladores de servidor y un especialista en calidad.

Esta sola información cambia la forma de interpretar toda la descripción del proyecto.

El lector ve que el resultado no surgió de forma aislada y que el especialista trabajaba dentro de una distribución concreta de responsabilidades.

Esta es la parte más importante.

En lugar de algo general como:

"trabajé en la interfaz"

escribe algo concreto:

"fui responsable de la arquitectura del módulo de pagos, de la implementación del proceso de finalización de compra, de la integración con la API de pagos y de la revisión del código de los cambios en esta área."

También puede ser útil indicar lo que no hiciste cuando podría resultar ambiguo:

"la capa de servidor y la integración del proveedor de pagos en el servidor fueron realizadas por otro equipo."

Eso no debilita el portafolio. Lo hace más creíble.

El nombre del puesto todavía no describe la aportación.

Un diseñador sénior de experiencia de usuario puede dirigir todo el proceso de investigación en un proyecto y, en otro, preparar únicamente las pantallas finales.

Por eso conviene mostrar acciones relacionadas con competencias concretas:

• preparé la arquitectura de la solución,
• realicé investigación,
• diseñé el flujo del proceso,
• analicé datos,
• escribí una parte clave de la implementación,
• preparé la estrategia de la campaña,
• dirigí negociaciones,
• coordiné dependencias entre equipos,
• verifiqué la solución antes del despliegue.

Los ejemplos más valiosos son aquellos en los que también puedes explicar por qué se tomó una determinada decisión.

Si el proyecto puede mostrarse, un artefacto ayuda a conectar la aportación declarada con el trabajo real.

Puede ser, por ejemplo:

• una pantalla del producto,
• un fragmento de la interfaz,
• un prototipo,
• un fragmento de código,
• un repositorio público,
• un informe,
• un diagrama,
• una publicación,
• material de campaña,
• una fotografía,
• un documento o un fragmento que pueda mostrarse de forma segura.

El artefacto no tiene que demostrarlo todo. Debe ayudar al lector a entender qué se creó realmente y cómo se relaciona con la aportación descrita.

El mayor riesgo de exagerar la aportación personal aparece al hablar de resultados.

Si la conversión de una empresa aumenta un 25% después de un proyecto, eso no significa automáticamente que una persona haya aumentado la conversión un 25%.

En ese mismo periodo pudieron cambiar:

• los precios,
• la oferta,
• el marketing,
• la experiencia de usuario,
• la infraestructura,
• la estacionalidad,
• las fuentes de tráfico,
• el trabajo de otros miembros del equipo.

Describe el resultado solo con el nivel de certeza que puedas justificar de verdad.

1. Responsabilidad directa
"Reduje el tiempo necesario para este proceso de 12 a 4 minutos automatizando los pasos de los que era responsable."

Úsalo cuando la relación entre tu propia acción y el resultado sea directa y pueda justificarse.

2. Resultado compartido
"Junto con el equipo rediseñamos el proceso de incorporación de usuarios. Tras el despliegue, la tasa de finalización aumentó un 18%."

Úsalo cuando el resultado sea fruto del trabajo de varias personas.

3. Aportación a un cambio más amplio
"Fui responsable de rediseñar el proceso de finalización de compra como parte de una optimización más amplia del proceso de compra. Tras desplegar todo el programa, la empresa registró un aumento de la conversión."

Úsalo cuando tu área fuera solo uno de varios factores.

4. Resultado como contexto del proyecto
"El proyecto terminó con un aumento de ventas del 40%. Mi alcance incluía la arquitectura del lado cliente y la implementación del proceso de finalización de compra."

Úsalo cuando conozcas el resultado global del proyecto, pero no tengas una base sólida para determinar qué parte se debió a tu trabajo.

Cuando un proyecto muestra a varias personas, la mejor descripción debería responder a dos preguntas al mismo tiempo:

¿Qué entregó el equipo?

y

¿De qué era responsable cada persona?

Ejemplo:

Proyecto: primera versión de una aplicación de logística
Equipo: diseñador de experiencia de usuario, desarrollador de interfaz, desarrollador de servidor
Resultado compartido: primera versión funcional del producto preparada para una prueba piloto
Diseñador de experiencia de usuario: investigación, recorrido del usuario, prototipo, diseño de interfaz
Desarrollador de interfaz: arquitectura del lado cliente, implementación de la aplicación web
Desarrollador de servidor: API, modelo de datos, integraciones

Una descripción así refuerza tanto al equipo como a los especialistas individuales.

En algunos proyectos resulta útil emplear descripciones sencillas del nivel de participación:

Rol principal - dirigí el área y fui responsable de las decisiones clave.
Responsabilidad compartida - compartí la responsabilidad con una o varias personas.
Rol de apoyo - apoyé el área, pero no era su responsable principal.

CRediT utiliza una distinción similar para los roles de los colaboradores. [1]

La regla más importante es sencilla: el nivel de responsabilidad debe poder entenderse.

En proyectos compartidos importantes conviene comprobar que la descripción de tu propia aportación no contradice claramente la manera en que los demás participantes entienden los roles.

CRediT recomienda que los colaboradores puedan revisar y confirmar los roles que se les atribuyen. [1]

En un portafolio profesional no tiene por qué existir un proceso formal de aprobación de cada frase. La regla práctica es más sencilla: no te atribuyas una responsabilidad que en realidad dirigió otra persona.

Describir tu propia aportación no debe confundirse con determinar los derechos de autor.

Según la legislación polaca sobre derechos de autor, los derechos corresponden en principio al autor y pertenecen conjuntamente a los coautores. En las obras creadas dentro de una relación laboral, el empleador puede adquirir derechos patrimoniales en el alcance previsto por la ley y por la relación laboral. [2]

En la práctica, conviene tratar por separado tres preguntas:

¿Participé en la creación del proyecto?
¿Soy autor o coautor de un elemento concreto?
¿Tengo derecho a publicar el material en mi portafolio?

Responder "sí" a la primera no determina automáticamente las otras dos.

No todos los proyectos pueden mostrarse o describirse con detalle.

La legislación polaca sobre competencia desleal protege la información que constituye un secreto empresarial, incluidas determinadas informaciones técnicas, tecnológicas, organizativas y otras con valor económico que se mantienen confidenciales. [3]

Por eso, en un proyecto confidencial, eliminar únicamente el nombre del cliente puede no ser suficiente. Otros detalles pueden seguir revelando información protegida.

Una regla más segura es:

describe solo aquello que realmente puedas divulgar según el derecho aplicable, los contratos, los consentimientos y los demás derechos que tengas.

Una descripción del proyecto normalmente no necesita datos privados de todo el equipo.

El RGPD exige, entre otras cosas, licitud, limitación de la finalidad y minimización de datos, es decir, que los datos personales se limiten a lo necesario para la finalidad correspondiente. [4]

Si basta con describir el equipo así:

1 diseñador de experiencia de usuario, 2 desarrolladores de interfaz, un desarrollador de servidor y un especialista en calidad

no existe una necesidad automática de publicar nombres, fotografías, direcciones de correo electrónico u otros datos personales de los compañeros.

Si quieres publicar una recomendación, declaración, imagen u otros datos de una persona concreta, comprueba la base jurídica adecuada y el alcance en el que puede utilizarse el material.

Si las condiciones de colaboración permiten una descripción general de la experiencia, puedes considerar mostrar:

• el tipo de problema sin identificar al cliente,
• tu propio rol,
• las categorías de competencias utilizadas,
• el tipo de responsabilidad,
• el proceso de toma de decisiones a un nivel suficientemente general,
• el resultado solo hasta el grado en que pueda divulgarse.

No inventes capturas de pantalla, datos ni resultados para sustituir material confidencial.

Si no tienes claro si una determinada información puede divulgarse, es más seguro no publicarla hasta que la cuestión quede aclarada.

Pequeñas diferencias de redacción pueden mostrar muy bien el nivel de responsabilidad.

Fui responsable de... - asigna claramente tu propio ámbito.
Dirigí... - sugiere responsabilidad sobre la dirección o ejecución de un área concreta.
Cocreé... - muestra que el resultado tuvo más de un autor.
Apoyé... - describe honestamente una contribución de apoyo.
Formé parte del equipo que... - separa la participación individual del resultado global del equipo.
Después del despliegue del proyecto, la empresa registró... - presenta el resultado como contexto sin atribuirte automáticamente todo el efecto.

Evita decir automáticamente "lo hice yo" cuando el alcance real fue compartido.

1. Usas el singular para un proyecto realizado por muchas personas.

2. Muestras un resultado empresarial, pero no explicas tu propio alcance.

3. Presentas las tecnologías de todo el producto como competencias propias aunque no hayas trabajado con todas ellas.

4. Muestras el diseño visual final, código o estrategia sin indicar qué partes creaste realmente.

5. Omites colaboradores clave cuando su participación es necesaria para entender el proyecto.

6. Sugieres una relación causal entre tu trabajo y un resultado que no puedes justificar.

Proyecto
¿Qué se estaba creando y qué problema debía resolver?

Equipo
¿Qué roles participaron en el proyecto?

Mi responsabilidad
¿De qué área fui personalmente responsable?

Mis acciones y decisiones
¿Qué hice o dirigí concretamente?

Colaboración
¿Qué elementos se crearon junto con otras personas?

Artefactos
¿Qué puedo mostrar legalmente?

Resultado
¿Qué consiguió el proyecto y cómo se relacionó mi aportación con ese resultado?

Limitaciones
¿Hay elementos que no puedo divulgar por confidencialidad o por derechos de otras personas?

Hazte siete preguntas:

1. ¿Sabe el lector qué tamaño tenía el equipo?

2. ¿Está claro exactamente de qué era responsable?

3. ¿He evitado atribuirme trabajo realizado por otras personas?

4. ¿Está descrito el resultado con un nivel de prudencia adecuado?

5. ¿Puedo publicar legalmente los materiales utilizados?

6. ¿Evito revelar innecesariamente datos personales o información confidencial?

7. ¿Podría una persona externa decir, a partir de esta descripción, qué competencias utilicé realmente?

Si las respuestas son claras, la descripción del proyecto empieza a funcionar como evidencia de competencia y no solo como una historia atractiva.

La mejor descripción de un proyecto no tiene que elegir entre:

"lo hice yo"

y

"lo hizo el equipo."

Puede mostrar ambas verdades al mismo tiempo:

el equipo entregó un resultado concreto y yo fui responsable de una parte específica, de determinadas decisiones y de su ejecución.

Ese nivel de precisión permite evaluar al especialista sin quitar mérito a los demás.

Un portafolio no debería ser una competición por formular la afirmación más grandiosa posible.

Su valor aumenta cuando la persona que lo revisa puede entender:

qué se creó, quién trabajó en ello, de qué eras responsable, qué hiciste personalmente y qué resultado puede relacionarse razonablemente con tu aportación.

Una descripción precisa no debilita un logro.

Al contrario. Demuestra que entiendes tu propia responsabilidad, sabes trabajar con otras personas y presentas honestamente los resultados de tu trabajo.

[1] CRediT - Contributor Role Taxonomy, NISO
Ir a la fuente

[2] Ley polaca de derechos de autor y derechos conexos - arts. 8-12, ELI
Ir a la fuente

[3] Ley polaca de lucha contra la competencia desleal - art. 11, texto consolidado publicado en 2026
Ir a la fuente

[4] Reglamento (UE) 2016/679 - RGPD, art. 5, EUR-Lex
Ir a la fuente

Nota metodológica: CRediT es un estándar sobre roles de colaboradores en investigación y publicaciones científicas. Este artículo lo utiliza como ejemplo de atribución transparente de contribuciones, pero no lo presenta como un estándar para portafolios profesionales. Los seis elementos de descripción de un proyecto y las cuatro formas de describir la relación con los resultados constituyen un modelo editorial propuesto en este material.