En el segundo día, continué trabajando en los casos de uso que había planteado en el primer día. Comparé mis casos de uso con los presentados en la charla del Microsoft Innovation Summit el 5 de julio. Durante este proceso, revisé mis notas y encontré similitudes y diferencias respecto a lo que se había discutido en la conferencia.
Los casos de uso que planteé se centran en el entrenamiento de un modelo de inteligencia artificial (AI) para realizar múltiples tareas, sin necesidad de alterar el entrenamiento del motor de lenguaje natural. Durante la conferencia, se expusieron varios ejemplos de aplicaciones de AI que siguen un esquema similar. Entre ellos, el Copilot de Microsoft, que permite la creación de texto basado en un contexto determinado, o la creación de ofertas para clientes basadas en un catálogo de productos y un roadmap empresarial. Estos ejemplos, y otros similares, demuestran que la IA generativa basada en texto puede desempeñar diversas funciones, muchas de las cuales se alinean con los casos de uso que planteé. Entre los ejemplos que se mostraron durante la conferencia, destaco lo siguientes: Repsol ha desarrollado un bot de gestión documental que encuentra respuestas en una base de conocimientos compuesta por documentos en Word y PDF. Técnicas Reunidas ha desarrollado una plataforma que le permite encontrar el documento relevante a una pregunta y luego proporcionar información relevante dentro de ese documento. Además, durante la conferencia se mostraron ejemplos de clasificación de texto basados en características o temas específicos, una tarea que también forma parte de mis casos de uso. Un ejemplo de National Netherlands involucra la transcripción automática de llamadas de teléfono y la clasificación automática de correos electrónicos. En resumen, mi segundo día de trabajo me permitió confirmar que los casos de uso que planteé son viables, ya que existen ejemplos de empresas que están implementando estrategias similares. Sin embargo, una pregunta que aún queda por responder es cuánto costaría desarrollar estas soluciones, teniendo en cuenta que los proyectos que se mostraron durante la conferencia fueron realizados con la ayuda de consultoras, que suelen tener precios elevados. A pesar de algunas dificultades, como no poder registrarme exitosamente en Azure, estoy satisfecho con el progreso que logré durante el segundo día. En los días siguientes, planeo continuar investigando y profundizando en los temas que identifiqué durante este día.
Os presento un proyecto de 21 horas en 21 días para explorar cómo funciona la inteligencia artificial generativa utilizando modelos de lenguaje. Voy a probar varios casos de uso utilizando plataformas como Chat GPT, Claude, y Llama, dentro del contexto de poe.com.
El primer caso de uso es alimentar un chat con un contexto dado y poder interrogar al bot dentro de ese contexto. Voy a probar diferentes tipos de documentos para ver cuánto contexto puede manejar cada plataforma.
El segundo caso de uso es clasificar documentos en diferentes tipos utilizando el modelo de lenguaje natural por defecto de la plataforma. Quiero probar cuántos textos son necesarios para alimentar el contexto para que la clasificación sea fiable y si es posible obtener la probabilidad de pertenencia a cada uno de los tipos. Una variante de este caso es identificar los criterios que diferencian un tipo de otro utilizando un conjunto de documentos y que sea la plataforma la que los identifique en función de los temas que tocan esos documentos. La salida esperada es la probabilidad de que un nuevo texto sea de un tipo u otro (por ejemplo, interesa o no interesa).
Por último, quiero comparar cómo funciona Chat GPT4 respecto a Poe.com a la hora de resolver estos casos de uso y ver cuál de las dos plataformas encaja mejor.
En el futuro, fuera de este reto de 21 horas, quiero programar directamente con Python utilizando las APIs de Chat GPT o de Anthropic (Claude) directamente para pasarle los parámetros y que sean procesados.
Hay varias formas de definir un texto que puedas reutilizar automáticamente en otras secciones de un documento WORD.
Una de ellas es utilizar los controles de contenidos en modo diseño de la barra de programador para la introducción de la primera instancia de un dato a repetir.
Y luego usar Marcadores (para cambiar o etiquetar el nombre de un dato) -si el nombre que etiqueta por defecto el control de contenidos no es interactivo) e insertar/elementos rápidos/campo y el tipo de campo REF
PD: para identificar el marcador de los controles de contenidos, puedes ir a marcadores seleccionar uno y que te lleve (ir) para ver cuál es
“Mejorar” + objetivo buscado + “qué pretendes conseguir con lo que dices”
“Mejorar” + objetivo buscado + expresión detallada del objetivo
“Mejorar” + objetivo buscado +” implementando” + establecer lo que quieres hacer para conseguirlo
“Mejorar” + objetivos buscado + “garantizando” + establecer un objetivo contradictorio o limitante
A mi me gusta que la estructura 4 porque establece cual es el objetivo y cual es la primera restricción.(la tres, en el fondo lo que vincula son iniciativas, y las iniciativas para mi van separadas del objetivo porque pueden cambiarse sin cambiar el objetivo).
Ejemplo: “Diseñar una oferta flexible garantizando que el estudiante sabe navegar por la misma”
Otro ejemplo (que incluye un poco de versión 3, porque muestra iniciativas a implementar): Aumentar la cantidad y calidad de las decisiones tomadas a partir de evidencias, utilizando sistemas de escucha compartidos, abiertos y transparentes (captando, desarrollando, transformando y gestionando el conocimiento) que permitan que la UPV se adapte con suficiente rapidez a los cambios.
Gracias a @UPV, @DOE, @VPT, y @Dadelos Charter el día 16 de junio 2022 participé en un evento de exteriores para reforzamiento de equipos de proyectos.
He intentado «aterrizar» lo observado durante la actividad de una de las tripulaciones para llevarlo al terreno del día a día de los proyectos en los que participo (muchos de ellos en la UPV; en todos ellos influyendo, tanto si lidero formalmente, como si influyo desde un rol menos destacado). Os comparto algunas reflexiones que espero que sirvan como lecciones aprendidas de la actividad.
En primer lugar, quiero contextualizar la actividad en el marco de participación en proyectos. Quizás algunas cosas de lo que hayamos aprendido se pueda aplicar a cualquier actividad laboral. No obstante, haré mis reflexiones pensando en proyectos que cumplan estas características:
Aunque parezca obvio, que sea un proyecto (no la cosas que se hacen en el día a día normal para hacer funcionar el servicio). Es decir, una agrupación de recursos (personas y otros recursos) durante un tiempo definido, con la finalidad de entregar uno o más «productos» (en el sentido más amplio de la palabra) que cumplan o superen las expectativas de las personas usuarias.
Tienen una duración de más de 4 semanas y necesitan la implicación de 3 o más personas
Afectan a un conjunto de personas interesadas y/usuarias internas (y puede que también externas)
Se llevan a cabo dentro de la UPV y pueden ser objeto de auditorias internas o externas
Precisan de una estructura de gobernanza y de unos roles y responsabilidades claramente establecidos
Requieren de una aprobación del alcance y del presupuesto del proyecto
Necesitan cierto nivel de control y trazabilidad
Puede ser necesaria la colaboración de varias organizaciones, o varias unidades organizativas
Incluye actividades adicionales a las de simple construcción/entrega
He agrupado las reflexiones en varios epígrafes.
Tantear el nuevo entorno
Los grupos estaban compuestos por personas que no todas se conocían. La UPV es una organización muy grande y muchas de ellas nunca habían interactuado entre sí. Otras no se habían visto nunca cara a cara, aunque podían haber intercambiado correos o hablado alguna vez por teléfono. De hecho, es posible que durante algún tiempo no sepas el nombre de las personas que te acompañan o la unidad en la que trabajan o las tareas que realizan (una ronda de presentaciones breves suele resolver esta situación).
Esto condiciona las primeras intervenciones en el grupo. Es más probable que haya gente reticente a dar su opinión, o a asignarse un rol, o prestarse voluntaria para responsabilizarse de una tarea. Esto se nota aún más si los roles o las tareas no están muy bien definidas o nadie se siente especialmente capacitado para llevarlas a cabo.
La inercia
Los equipos, como los barcos, tienen su inercia. Cuesta arrancarlos, cuesta pararlos y tardan cierto tiempo en responder a las señales de cambio. Tienes que tener en cuenta esos tiempos de reacción.
Pero la inercia es asimétrica. Las cosas malas, abandonadas a la rutina, tienden a ir a más. Las cosas buenas, abandonadas a la rutina, tienden a ir a menos. O dicho de otro modo. No necesitas esforzarte para que una cosa mala vaya a peor. Sin embargo, tienes que esforzarte continuamente para que algo bueno simplemente se mantenga siendo bueno y no se degrade.
Relacionado con esto, el estilo con el que las personas del grupo se comunican (tanto la persona responsable como todos los participantes) debe adaptarse a la situación. Cuando todo va bien y el grupo experimenta orgullo y satisfacción por estar en el proyecto, es mucho más sencillo. Quizás no tengas que preocuparte demasiado por el estilo que usas porque casi todos se toleran y se integran bien dentro de un ambiente positivo (incluso ciertas ironías o estilos un poco más bruscos). Sin embargo, cuando las cosas se tuercen y el grupo se enfrenta a la frustración de no avanzar al ritmo o en la dirección deseada, es preciso usar estilos que no levanten ampollas en «pieles» que se han convertido en ultrasensibles. Considero que los estilos asertivos funcionan siempre bien en ambas situaciones, pero en las malas, seguramente hay que añadir mas palabras de lo habitual para que el mensaje se entienda y se interprete del modo adecuado.
Comunicación
Una de las barreras de comunicación que se ha visto muy claramente durante la travesía es el empleo de jerga específica y desconocida para muchas de las personas participantes. El uso de terminología específica es muy útil cuando todas las personas la pueden entender porque permite que con una palabra clave se transmita mucho significado. Pero cuando carece de significado para las personas que tienen que intervenir genera confusión. Virar, orzar, trasluchar, escorar tienen un significado claro para las personas habituadas a navegar. Son una barrera infranqueable para las que no están acostumbradas («Órzale…Pero…¡¿Por qué me viras?!»)
En nuestros proyectos debemos hablar en el lenguaje que nos permita a todos entendernos. Si es relevante el conocimiento de una jerga específica se tiene que aprender e interiorizar. Pero hasta que no se consiga interiorizarla debemos aplicar la frase con la que se inicia este párrafo.
Además, en los proyectos los problemas de jerga no son solo de lenguaje… también son de puntos de vista (las diferencias experiencias de uso de la persona responsable funcional, de la usuaria, de la analista, de la programadora…).
Otra barrera es la comunicación incompleta porque damos por supuesto que todas las demás personas pueden completar las frases o descripciones de tareas, porque en el contexto donde la comunicamos es «evidente» que no hay otras opciones. Pero nos olvidamos que es «evidente» solo para personas con cierta experiencia que son capaces de interpretar la situación y filtrar de todas las posibilidades la única que aplica con ese mensaje en ese contexto. Por ejemplo, en una maniobra de viraje, con tres personas sujetando tres cabos distintos, una orden como «afloja» puede significar muchas cosas para personas inexpertas: que afloje la persona A, la B o la C. O que aflojen dos de ellas o que la aflojen las tres. Sin embargo, si las tres son expertas, sabiendo la maniobra que se está realizando y de donde viene el viento, «afloja» solo significa una sola cosa, porque en ese contexto solo hay una opción razonable y descartan cualquier otra opción.
Por lo tanto, debemos acompañar a nuestra «tripulación» del proyecto dando las instrucciones en el formato y con la cantidad de palabras necesarias para que se puedan procesar adecuadamente. Por ejemplo: «Carmen afloja un poco el cabo» o «Manolo y Carmen liberad completamente el cabo».
Un último detalle sobre comunicación. Los «plops». Esas comunicaciones que son como pompas de jabón que chocan contigo, explotan y desaparecen y ni te enteras. Por ejemplo: «¡que alguien me diga algo!» tic, tac, tic, tac, tic tac… y nadie dice nada.
Implicación y aprendizaje organizativo
En los primeros 7-8 minutos de de la tercera regata (desde la preparación para la salida) han aprendido más que toda la hora anterior (o por lo menos han experimentado que tenían ese aprendizaje). Y sin duda han disfrutado más (se notaba en el tono de la voz, actitud y como se animaban entre ellos). En esos minutos han estado pilotando la nave ellos solos, tomando decisiones (más o menos correctas) y poniéndolas en marcha (con más o menos eficiencia).
Tras unos minutos de trabajo intenso y comprometido, ha habido unos minutos de de diversión hablando y bromeando con las tripulaciones de otros barcos. Se trataba de un momento de transición donde estaba todo el trabajo hecho y donde solo se necesitaba la atención de dos o tres tripulantes hasta que llegara el momento de un nuevo viraje. En el momento que se ha solicitado la atención toda la tripulación ha vuelto a su concentración de antes. Eso me lleva a pensar en la importancia de celebrar los hitos intermedios. Un proyecto tiene varias fases y es bueno identificar los momentos donde se han conseguido resultados intermedios y aprovechar para felicitar, animar y distender. Eso no solo recarga las energías para los momentos más intensos, también ayuda al equipo a disfrutar del proceso y no solo de los resultados finales del proyecto.
También he podido observar lo complicado que es recuperarse de un «jarrazo de agua fría». Cuando mejor iba el barco, pilotado por los participantes en posiciones intermedias y luchando por situarse en cabeza, a punto de llegar a la boya de mitad de la manga… Justo en ese momento, una mezcla de decisiones no acertadas junto con una ejecución no muy brillante hacen que el barco pierda viento y se genere una sensación de caos e impotencia. Agravada por el hecho de que el patrón toma las riendas y desplaza al equipo de su posición de «autonomía».
Es como cuando en los proyectos aparece alguien que bloquea el proyecto o cuando, tras muchas horas de trabajo intenso, presentas orgulloso tu trabajo al cliente y te dice que eso no se parece en nada a lo que esperaba y cuando te dice lo que quiere te das cuenta que no es lo que te había dicho, o tu habías interpretado, seis meses antes).
Pero la reflexión que yo me hago es. Si han podido tener momentos buenos alguna vez, esos se pueden repetir. Descubramos las cosas que nos han permitido lograr esos momentos.
Exceso de información vs aprendizaje
En varios momentos de la actividad me ha dado la sensación de que el equipo estaba desbordado de información que no se transformaba en aprendizaje. Por un lado no se digería tanta información de golpe: más de dos o tres instrucciones no se recuerdan si no las conviertes en habito y para convertirla en hábito debes ejecutarlo/ponerlo en acción varias veces. Una vez asentado algo (por ejemplo el efecto de virar de una forma u otra, o el de cazar un cabo mas o menos rápido), puedes pasar a entender y practicar el siguiente aspecto.
Por otro lado, parecía como que la información que llegaba a la tripulación no estaba filtrada por importancia/necesidad para el éxito de la travesía. Por ejemplo, se aportaban muchos datos de cultura general náutica o anécdotas irrelevantes para las tareas a realizar. La tripulación novata estaba 100% atenta intentando recordar cada palabra y darle sentido práctico, pero el continuo chorreo de contenidos irrelevantes hace que se pierda la capacidad de atención para las cosas importantes. Cuando llegaba la instrucción útil, las mentes estaban agotadas y, además, no había tiempo para repetir y asentar la práctica del conocimiento.
Esto es algo que veo en muchas reunión de proyectos. No se va al grano, divagamos y nos perdemos en detalles no urgentes o no relevantes y cuando llega el momento de la información importante ya hemos perdido la atención del equipo o no queda tiempo para asentar esa información de manera adecuada y terminamos la reunión abruptamente confiando en que el equipo sabrá usar la información recibida para trabajar autónomamente hasta la siguiente reunión (la realidad nos suele sacar de ese sueño, una semana o quince días más tarde).
También me puedo aplicar esta regla a mis clases. Todos sabemos que el aprendizaje no consiste en embutir más conocimientos de los que el estudiante puede procesar, practicas e integrar en sus conexiones con conocimientos previos o creando nuevos conocimientos. Por eso dar una lección magistral vomitando aceleradamente la mayor cantidad de conocimientos posibles por minuto, no suele dar mejores resultados que otras formas de instrucción. Ni siquiera cuando los conocimientos «vomitados» hayan sido adecuadamente filtrados e incuestionablemente relevantes, esenciales y pertinentes. Mucho menos si, encima, no se ha hecho un esfuerzo por filtrar aquello que es realmente necesario para el éxito y desarrollo de la persona que aprende.
Aprender a Mirar
Si no somos capaces de fijar un punto que nos sirva de referencia es muy fácil perder el rumbo, ir dando bandazos e, incluso, frenar el barco porque acabas perdiendo grados respecto al viento y te quedas justo en la dirección del viento. Del mismo modo en los proyectos debemos tener señalas claras de los puntos intermedios de llegadas. Por ejemplo pantallas, pequeños desarrollos, prototipos funcionales, etc. En este sentido la metodología scrum/sprints puede ser de gran ayuda al marcar revisiones frecuentes (una, dos o tres semanas) con implementación modular de las funcionalidades.
Las entregas intermedias o los prototipos son como las «lanas» de la Génova. Te dan señales sobre si está alineado o si necesitas hacer unos ajustes finos para optimizar los resultados.
Lecciones aprendidas
Los trabajos de plegar las velas y dejar el barco preparado para el atraque son también funciones esenciales para poder salir a navegar en condiciones la próxima vez. Puede parecer que no es navegar, pero lo es y se nos olvida.
Es lo mismo que pasa en los proyectos, cuando hacemos un cierre adecuado del proyecto (revisando las expectativas cumplidas de las personas usuarias, el esfuerzo y el dinero invertido), extraemos unas lecciones aprendidas y celebramos que se ha completado el proyecto. Todo esto nos permite aprender de la experiencia y abordar el siguiente proyecto con más energía, entusiasmo, seguridad, eficacia y eficiencia.
Si no lo hacemos es probable que se cuelen pensamientos como los que se verbalizaron en mi equipo al acabar la regata: «está claro que navegar no es lo nuestro». Cuando mi visión como observador era radicalmente diferente:
En una hora, un conjunto de novatos habían aprendido a navegar y pilotar un barco
Han descubierto que cosas tienen que practicar para mejorar
Y si hubieran contado con más tiempo para «iterar» el conocimiento, habrían aprendido a navegar con autonomía en mares en calma con poco viento (seguirían siendo novatos en otras condiciones, pero autónomos en esta)
En definitiva, sea cual sea el resultado de un proyecto (incluso si se tiene que cancelar a mitad, o si tardamos mucho más de lo previsto o nos gastamos mucho más dinero del esperado o si no se logra cumplir las expectativas de las personas usuarias), solo se puede considerar un fracaso si no hemos aprendido nada de él. Si, a pesar de no tener éxito, conseguimos aprender cosas para no cometer los mismos errores en el futuro, ya ha sido útil en algún sentido. Obviamente esto no puede servir de excusa para incumplir expectativas continuamente, entonces tendríamos un problema y realmente no habríamos aprendido nada. Pero debemos asumir como normal cierto numero de proyectos sin el éxito esperado, siempre que podamos obtener lecciones aprendidas útiles de ellos.
Otros aprendizajes
El anticiparse (como cuando no esperas a que la vela o la botavara cambie de lado por su cuenta e intentas forzarla con los cabos) frena el proyecto. Tienes que dejar que los usuarios digan lo que quieren y no anticipar soluciones si aún no tienes la información (forzar a que el usuario te diga lo que quiere ayuda a avanzar -es como iniciar una maniobra de viraje o de trasluchada-, pero intentar programar cosas antes de que te digan lo que necesitan o lo que quieren, es como tirar de los cabos antes de tiempo… luego tienes que deshacer el camino, y has perdido tiempo y energías).
Algunas metáforas/analogías entre navegación y proyectos
El viento son los estudiantes y/o empresas (las personas usuarias externas a las que proporcionamos servicio de aprendizaje o transferencia), las velas son el personal que ofrece el servicio directamente (normalmente PDI o personal de investigación), el resto es barco.
La sensación de ir deprisa (el viento en la cara) es una ilusión. Vamos más deprisa cuando nos desplazamos más rápido, no cuando tenemos sensación de ir rápido (o hacemos muchas cosas que en el fondo no generan ningún movimiento).
A veces nuestra única función es hacer peso para que el barco vaya más equilibrado (es una función que puede parecer aburrida o que no haces nada o que, aparentemente, no aporta, pero es necesaria para ganar algo de velocidad extra).
Asumir el trabajo del día a día de otra persona, para que esa otra persona –con capacidades diferentes a las mías- haga lo que sólo ella sabe/puede hacer, también es ayudar a que salga adelante un proyecto (que es necesario para nuestra unidad). A veces mi papel en el equipo es permitir que otra persona libere el tiempo para poder hacer otras cosas por el equipo.
Durante esta semana he estado observando diversas reuniones (como participante o simplemente analizando cómo trabajan mis estudiantes). Algunas de esas reuniones se han realizado presencialmente y otras en modo remoto. Os comparto mis lecciones aprendidas sobre cosas que yo daba por supuesto y la realidad me ha mostrado que, en estos ejemplos de conveniencia (y para nada generalizables), no se cumplían.
Lección 1. No está claro que cualquier persona con varios años de formación universitaria sabe trabajar en grupo.
La tendencia es a pensar que, aunque no hubieran aprendido en su etapa de formación en el instituto, está claro que tras varios años en la universidad, con las tareas en grupo que se les encargan (tanto en prácticas como en dinámicas de aula) y saldrían de serie con unos comportamientos básicos aprendidos. Si estamos pensando en profesores o investigadores o profesionales que estudiaron hace años en la universidad, como continuamente hay que trabajar en grupo, todos deben ser expertos.
Pero la realidad es que si planteas una tarea en grupo sin dar unas directivas específicas de qué hacer en cada momento y cómo (es decir tele-dirigiendo completamente al equipo), muchas veces observas comportamientos individuales. Cada uno hace «lo suyo», sin interaccionar con los demás, y sin tener muy claro qué es lo que los demás esperan de su tarea y, al final juntan las partes y ya está (grupos «grapadora»: se juntan solo para grapar o encuadernar las partes). El resultado es un poco «monstruo de Frankenstein».
Y si el grupo está en remoto, esta «tendencia» a hacer las cosas individualmente y no interactuar con el resto de personas del grupo se acreciente mucho. Esto me lleva a reflexionar sobre si los patrones de interacción en los grupos remotos y en los grupos presenciales son distintos (en el mismo contexto de discrecionalidad de tarea y con mismas personas, solo cambiando de presencial a remoto).
Voy a ver si alguien ha escrito algo sobre «interaction paths in remote meetings»
Lección 2. Desempeñarte muy bien en reuniones presenciales no garantiza que seas capaz de trasladar los comportamientos adquiridos en presencial a entornos remotos.
Esto lo he podido comprobar ampliamente durante los últimos años (en pandemia) y sigo observándolo en casi todas mis reuniones remotas actuales (en las de esta semana también).
Gente a la que conozco y he visto interactuar en reuniones presenciales, olvidan muchas de las «buenas prácticas» cuando se embarcan en una reunión remota.
Por ejemplo, dar «feedback» a los demás participantes (reformulando las ideas, asintiendo/negando con la cabeza o siendo expresivo con el lenguaje no verbal, manteniendo el contacto visual periódico con todas las personas participantes…). Todas las reuniones donde he participado en remoto eran lo más parecido a una partida de póker (o de «truc») profesional. Nadie expresaba «emociones», todos los canales de comunicación rica cortados… Un desastre.
Se podría alegar que la tecnología no lo permite. Pero no es cierto. Acepto que la riqueza del canal mediado por una pantalla y un teclado (mas una cámara y un micro), no es la misma que un presencial cara a cara. Pero entre blanco que negro hay un conjunto de grises, y otros colores. Por ejemplo:
¿Por qué no usas los emoticonos disponibles en todas las plataformas de videoconferencia? Al menos para demostrar tu apoyo tienes varias opciones (aplauso, corazón, caritas sonrientes). Cierto que no hay ninguna para mostrar desacuerdo. Pero ya llegarán o puedes usar algunas de las otras opciones que comento a continuación
¿Por qué apagas tu cámara cuando los demás hablan -y la conectas cuando vas a hablar tu-? ¿Es que no consideras relevante mostrar tu escucha activa a la persona que habla?
¿Por qué no sonríes, disientes, asientes, levantas tu pulgar, muestras el pulgar hacia abajo, o expresas con cara y manos durante la reunión? Obviamente si eres de los del punto anterior (que apagan la cámara en las reuniones) todo esto ya no aplica
¿Por qué no usas el chat para reformular ideas o mostrar «emociones» o tu punto de vista sobre lo que se está hablando? Algunas personas han llegado a pedir que no se use el chat porque «despista» al que habla. Vale, lo entiendo en un contexto de «monólogo», pero no en una reunión de grupo. Precisamente estos «despistes» son los que permiten enriquecer la comunicación y que el esfuerzo de reunirnos síncronamente se compense de alguna forma. Si no, con grabar un video y distribuirlo te ahorras una buena parte de la reunión (cada uno se ve el vídeo por su cuenta y luego planteas una reunión corta donde se va a hablar exclusivamente de las dudas o contrastar opiniones sobre lo expuesto)
¿Por qué no hay forma de saber cuántas personas están realmente conectadas en la reunión y no solo una sesión abierta? Esas veces donde preguntas a una de las personas que supuestamente está conectada y pasan segundos o minutos o cuartos de hora y no contestan (ni siquiera un mensaje en el chat)
Lección 3. No todo el mundo es capaz de mantenerse centrado en las tareas del grupo cuando estás en remoto (ni cuando estás en presencial)
En presencial es común desde hace años que los estudiantes (y también los profesionales en sus grupos de trabajo) se dispersen atendiendo sus dispositivos móviles mientras otras personas están intentando participar en una reunión. Yo creo que el tiempo de grupo es sagrado porque representa mucho esfuerzo sincronizar las agendas para tener un tiempo de intercambio común. Sin embargo, hay personas que consideran que contestar cualquier mensaje que les llegue a su móvil (de redes sociales o de comunicación instantánea), o revisar quién llama o incluso atender una llamada es más importante que el tiempo de las otras personas de la reunión. No estoy hablando de asuntos importante que se haya advertido al principio de la reunión que es posible que interrumpan nuestra atención.
Pues en remoto ya os podéis imaginar lo que puede llegar a pasar con personas sin los hábitos adecuados de respeto al grupo.
Una de las cosas que me ha sorprendido esta semana es que los estudiantes que estaban en una actividad de grupo presencial (en un entorno mucho más incómodo y ruidoso) rendían como el doble o el triple que los que estaban en la misma actividad en remoto (en la tranquilidad de sus casas, en habitaciones individuales y, aparentemente, sin distracciones). En el mismo tiempo, los primeros leían una media de dos o tres documento y los segundos sólo uno y no llegaron a completar su lectura.
Lección 4.Tras dos años trabajando en grupo en remoto muchas personas siguen sin saber utilizar las aplicaciones
Antes de que me hagáis una crítica fácil. No me refiero a que la aplicación se haya actualizado y ahora los botones o menús estén en otro lado (eso es absolutamente disculpable) o que en una reunión con personas de otras organizaciones te veas forzado a usar una aplicación nueva que no es la que se emplea como aplicación corporativa en tu organización habitual.
Lo que intento decir es que las personas de una organización no saben usar las aplicaciones que su organización lleva como mínimo desde marzo 2020 utilizando para su trabajo remoto. En el caso de mis estudiantes, esa aplicación se llama Office365. Pues bien, dos años después hay personas (y no una, ni dos), que no saben editar de manera compartida y síncrona un documento de texto, presentación u hoja de cálculo con Office365. Algunas personas, ni siquera saben que eso es posible y consideran que solo «google drive» ofrece esa funcionalidad.
Me he quedado pasmado viendo como mis estudiantes hacían una ronda para recoger todos los emails para poder editar un documento de texto en google drive, cuando tenían, al mismo tiempo abierto TEAMS y la posibilidad de crear un documento en TEAMS al que, automáticamente, todos tenían permisos de edición.
No me vale la excusa de «es que yo domino Google Drive» (porque no es cierto, no saben como exportar le documento creado en un formato «.docx») o que «en drive es más fácil o se pueden hacer cosas que Office365 no puede» (yo creo que es justo al revés)
Lección 5. Se presta muy poca atención a como se «etiquetan» los documentos generados por el grupo
En todos los grupos en los que participo, cada personas nombra los documento del modo que le apetece (muchas veces son un críptico: «documento1.docx», que es el nombre por defecto que sale al indicar que quieres guardar un archivo). Esto pasa incluso cuando das normas explícitas a un grupo indicando cómo quieres que se nombren los ficheros para poder luego archivarlo (y recuperarlos) con facilidad (sin tener que dedicar tiempo de un «archivero» a que renombre cada uno de los documentos).
En mi opinión los documentos que genera el grupo es la esencia que queda como resultado del tiempo invertido. Como mínimo debería haber un acta, pero también puede haber otros «productos» específicos liberados en forma de documento (texto o imágenes o fotos o lo que sea).
Si esos documentos no se van a tener que consultar nunca más, los puedes etiquetar como te apetezca, porque no va a afectar a nada. De hecho si no los vas a consultar nunca más, te puedes ahorrar el hacer el documento (y quizás también la reunión. Porque si de la reunión no se deriva nada que debas usar en futuro, aunque solo sea un acuerdo o una lista de tareas, quizás es que no era muy necesaria).
Sin embargo, si vas a reutilizar el resultado del grupo (o puedes necesitar consultarlo en el futuro), es imprescindible que ése documento sea localizable. La forma más efectiva que yo he encontrado es «etiquetar» el documento en el nombre del fichero (eso nunca falla). Yo, como mínimo pongo la fecha en la que se ha realizado el documento, el contexto del equipo o proyecto al que pertenece y algunas palabras que pueden servir de clave para localizar el documento por tipo (acta, acuerdo, propuesta, plantilla, lecciones-aprendidas) y otras para poder filtrar y evitar «falsos positivos»
