Resumen ejecutivo

• Un proyecto grupal suma mucho a tu portfolio si dejás claro qué hiciste vos, con qué decisiones y con qué resultado. Si no, un recruiter lo lee como un trabajo ajeno.

• La evidencia está en lugares verificables: commits, pull requests, issues, tablero del proyecto, documentación y demos.

• Te dejamos una plantilla de «tarjeta de proyecto» con rol, alcance, decisiones, resultado y links, lista para copiar.

• También vas a ver qué frases conviene evitar para no inflar tu CV ni quitarle mérito al equipo.

En bootcamps, cursos y primeros trabajos, casi todo lo que construís es en equipo: un e-commerce con tres compañeros, un dashboard para una ONG, una app de la hackatón. El problema aparece al pasarlo al portfolio. O lo presentás como si lo hubieras hecho solo, y en la entrevista te preguntan por partes que no conocés, o lo describís tan en plural («hicimos», «armamos») que nadie entiende tu aporte. Con más candidatos junior compitiendo por los mismos puestos y procesos que incluyen preguntas técnicas sobre tu propio código, mostrar con precisión qué hiciste dentro de un equipo se volvió una ventaja concreta. Esta guía te muestra cómo hacerlo con honestidad y con pruebas.

Por qué los proyectos grupales valen (y por qué generan dudas)

Un proyecto en equipo demuestra cosas que un proyecto individual no puede: que sabés trabajar con Git sin pisar el código de otros, que podés revisar y recibir revisiones, que coordinás tareas en un tablero y que respetás convenciones compartidas. Para un puesto junior, eso pesa tanto como la parte técnica.

La duda del lado de quien contrata es simple: ¿qué parte hizo esta persona? Si tu portfolio no lo responde en pocos segundos, el proyecto pierde valor. Tu trabajo es responder esa pregunta antes de que te la hagan.

Paso 1: definí tu aporte real antes de escribir

Antes de redactar, hacé un inventario honesto. Respondé por escrito:

• Rol: ¿cuál era tu responsabilidad principal? (frontend del checkout, modelado de la base, diseño de la UI, testing, coordinación).

• Alcance: ¿qué módulos, pantallas o endpoints construiste de punta a punta? ¿En cuáles colaboraste?

• Decisiones: ¿qué elegiste vos y por qué? Una librería, una estructura de carpetas, un patrón de estado, un criterio de validación.

• Problemas resueltos: un bug difícil, una integración que no andaba, un cuello de botella de rendimiento.

• Resultado: qué quedó funcionando y cómo se puede comprobar (demo, deploy, tests que pasan).

Si te cuesta separar tu parte, revisá el historial del repositorio y el tablero de tareas: ahí está la respuesta.

Paso 2: juntá evidencia verificable

Lo que convence no son los adjetivos sino los links. Estas son las fuentes más útiles:

Commits y pull requests

Filtrá los commits por autor y elegí 2 o 3 pull requests representativos: los que muestran una funcionalidad completa o una revisión con discusión técnica. Si trabajaron en pareja, GitHub permite registrar commits con varios autores mediante la línea Co-authored-by, lo que deja trazado el trabajo compartido. Si el equipo usó mensajes claros, como los que propone la convención Conventional Commits, tu historial se lee mucho mejor.

Issues y tablero

Las tarjetas asignadas a vos en GitHub Projects, Trello o Jira muestran qué tomaste y cuándo lo cerraste. Una captura del tablero con tus tareas resaltadas sirve como apoyo visual.

Documentación y demos

Si escribiste la sección de instalación del README, la documentación de la API o un video de demo, linkealo. La documentación es una de las pruebas más claras de que entendés el sistema. Te puede servir nuestra guía para escribir un buen README de proyecto.

Paso 3: usá esta plantilla de tarjeta de proyecto

Copiá esta estructura para cada proyecto grupal de tu portfolio o README:

• Nombre del proyecto y una línea de contexto: «Tienda online para un emprendimiento de cerámica, desarrollada por un equipo de 4 personas en 6 semanas».

• Mi rol: «Desarrollo frontend del carrito y el checkout».

• Lo que hice: 3 a 5 bullets con verbos en primera persona del singular: «Implementé…», «Diseñé…», «Escribí los tests de…».

• Una decisión técnica y por qué: «Elegí manejar el estado del carrito con Context en lugar de una librería externa porque el alcance era chico y reducía dependencias».

• Con quién colaboré: «Coordiné con el backend la forma de los datos de la API de pedidos».

• Resultado: «Checkout funcional con validación de formularios y pago de prueba».

• Links: demo, repositorio, 2 o 3 pull requests destacados.

• Créditos: nombres o perfiles del resto del equipo.

Esa última línea parece un detalle, pero transmite madurez profesional: reconocer al equipo no te resta, te suma.

Frases que conviene evitar (y cómo reemplazarlas)

• «Desarrollé una plataforma de e-commerce» cuando hiciste una parte. Mejor: «Desarrollé el módulo de checkout de una plataforma de e-commerce hecha en equipo».

• «Participé en el desarrollo de…»: es tan vaga que no dice nada. Mejor: nombrá la pieza concreta que construiste.

• «Lideré el proyecto» si solo organizaste reuniones. Mejor: «Coordiné el tablero de tareas y las revisiones semanales».

• «Hicimos todo entre todos»: es humilde, pero borra tu aporte. Mejor: separá tu parte y después mencioná la colaboración.

• Métricas inventadas («mejoré el rendimiento un 80%») sin haberlas medido. Si no tenés el número, describí el cambio: «reduje las llamadas a la API cacheando el catálogo».

Cómo contarlo en una entrevista

En la entrevista te van a pedir que expliques el proyecto. Prepará un relato de dos minutos con la estructura del método STAR (situación, tarea, acción, resultado), centrado en tu acción. Tené abierto un pull request tuyo para mostrar código si te lo piden, y prepará una respuesta para «¿qué harías distinto hoy?». Si surge un conflicto de equipo, contalo con foco en cómo lo resolvieron, sin culpar a nadie.

Para ordenar el resto de tu perfil, revisá cómo usar GitHub como portfolio y nuestra guía de portfolio para programadores junior.

Curso recomendado de Coderhouse

Si querés sumar proyectos en equipo con revisión de código y entregas reales, la Carrera de Desarrollo Full Stack te lleva del frontend al backend construyendo proyectos que podés mostrar con esta misma plantilla. Si recién empezás, el curso de Desarrollo Web es el primer paso.

Preguntas frecuentes

¿Puedo poner en mi portfolio un proyecto grupal si el repositorio es de otra persona? Sí. Linkeá el repositorio original y tus pull requests. Si es privado, pedí permiso para mostrarlo o hacé un fork con autorización del equipo.

¿Cuántos proyectos grupales conviene mostrar? Uno o dos bien documentados alcanzan, combinados con al menos un proyecto individual que demuestre que podés resolver algo de punta a punta.

¿Qué hago si mi aporte fue chico? Mostralo igual, con precisión. Un aporte chico bien explicado vale más que uno grande inflado que no podés defender en la entrevista.

¿Tengo que nombrar a mis compañeros? Es recomendable. Darles crédito muestra profesionalismo, y a quien te evalúa le da contexto sobre el tamaño del equipo.