Cuando escuchas por primera vez eso de «trabajar en grupo» crees que va a ser genial: repartición del trabajo, colaboración entre los compañeros y buen rollito. Al final compruebas que la repartición de trabajo se queda en un «si quieres aprobar hazlo tú mismo», la colaboración entre compañeros en «a este imbécil no le pienso decir nada, que se joda» y el buen rollito en una tensión abismal que parece que el mundo vaya a crujir y partirse por la mitad.
Después tienes a tus magnánimos profesores que te dicen que hay que hacer la práctica en grupo, para así familiarizarse con lo que nos espera en el mundo laboral. Claro, mientras tú piensas qué se han fumado, ellos se frotan las manos pensando que si los grupos son de 5-6 personas van a corregir 5-6 veces menos prácticas.
El asunto de la sincronización es otro tema que me da risa cuando dicen que con las prácticas en grupo vamos a aprender a trabajar como en el mundo laboral. Supongo que habrán pasado por alto que, en una empresa, los trabajadores pasan sus 8 horas en ella con sus compañeros. En cambio, en la universidad cada uno tiene un horario de prácticas y teoría diferente, viven en lugares diferentes y por tanto la sincronización puede llegar a ser horrible. Así que no vengan con la excusa de la empresa.
Al final, acabamos haciendo uso de herramientas de Internet. Empezando por listas de correo para mantenernos informados como Google Groups, espacio virtual para subir los ficheros que necesitemos como 4Shared y si el proyecto tiene grandes dimensiones habría que optar por montarse un servidor de trabajo en grupo como por ejemplo eGroupWare.
Y después de todo este follón viene lo divertido: los compañeros. Hay de todos los tipos, colores y tamaños. Desde los que no hacen nada hasta los que tienen la fuerza de arrastrar el proyecto hasta la meta.
El desaparecido: aquel que no hay forma de localizar.
El promesas: el que dice que va a hacer tal y cual y después nada.
El estresado: al que no le puedes decir nada porque va tan saturado de trabajo (o eso dice) que parece que vaya a explotar si le dices de cambiar una línea de código.
El echa-pestes: cuando ve que algo le falla empieza a maldecir la mala programación del resto del grupo hasta que alguien le explica que el problema viene de su propio código.
El presencial: aquel que no trabaja por su cuenta. Si no está el grupo al completo no mueve un sólo dedo.
El howtus: o le das un enlace a un tutorial en internet donde se explique a la perfección lo que debe hacer o dirá que no ha sabido hacer su parte.
El destroyer: junta su código con el resto y como ve que aquello no compila decide modificar el código del resto de compañeros para adaptarlo al suyo, lo sube como una versión reunificada y omite el pequeño detalle de las modificaciones.
El no-comments: el que es incapaz de comentar ni una sola línea de su propio código. Después para corregir un problema tiene que rehacer el código desde el principio porque no lo entiende.
El contramedidas: es capaz de desviar todo su trabajo al resto y dar una sensación de que lo ha hecho todo él. Se llega a dar el caso de que hasta sus propios compañeros creen que, sin él, no habrían podido hacer la práctica.
El pacificador: el único que se mantiene con la suficiente frialdad para dialogar con los compañeros que se intentan agredir con los teclados y explicarles que tiene el mismo objetivo: aprobar las prácticas (aunque algunos se empeñen en dificultar la tarea).
El listillo: el que se espera a que termines tu código para después copiarlo, hacerle ciertas modificaciones y, si algo falla o no entiende, llamarte por teléfono a la hora que sea. Si con la llamada no consigue solucionarlo te pide disimuladamente que le eches un vistazo.
Podría seguir incorporando más tipos y subtipos pero acabaría siendo una labor muy extensa, lástima que no tenga a ningún/a becari@ que lo haga 🙂 .
Lo último de lo que quiero dejar constancia es que un grupo mal hecho de 6 personas puede rendir mucho menos que uno de 3 bien hecho…..y creo que por ahí tengo un ejemplo 😉 .
Comentarios recientes