El pasado 23-24 de noviembre del 2018 tuve la suerte de disfrutar de un evento tecnológico llamado Commit Conf. Una nueva conferencia por y para desarrolladores con nuevo front, pero con el mismo backend que sus orígenes, Codemotion. La organización decidió no seguir con el contrato de marca de Codemotion y ahora han hecho su propia conferencia.
9 tracks, 2 tracks de talleres, escaparates, networking. ¡Todo excepcional!
Desde hace varios años, la herramienta que utilizan para gestionar las entradas, charlas, panel, permite dar feedback. Algo muy importante para aprender, mejorar, perfeccionar o darse cuenta si se ha entendido bien lo que uno quería decir. ¿Genial no? ¡Es todo un lujo!
Comentario en una charla begginer
Charla mal estructurada, muy básica y que no deja conceptos claros
Detrás de cada charla hay una preparación, que puede ser mejor o peor, pero la hay. Hay insomnio el día de antes, nervios el mismo día y nervios después.
Una vez dada la charla, te das cuenta que hay cosas que al final no has dicho, cosas que has metido la pata por decir mucho, te has quedado con esa persona que no paraba de mirar el móvil o esa otra que se ha quedado dormida. Es decir, dispones de un pack de autofeedback para rayarse suficientemente un buen rato.
No estuvo bien explicada. Muy lioso todo
¿Y quien es el ponente? ¿Quién es el ponente medio de la commit?
Lo que hace que sea una conferencia excepcional es que son charlas reales de gente real que se ha pegado con las cosas que enseña. ¡Tiene un valor incalculable! Esa persona te va a contar lo bueno y lo malo de una herramienta. Esa persona no te va a vender.
Creo que ha faltado trabajo a nivel general tanto en el tema a presentar como en la elocución. No obstante, os animo a trabajarla por el titulo es atratictivo, un tema de moda y que lo presenteis dos perfiles tan diferentes son un gran base.
El ponente medio tiene perfil genérico de desarrollador o desarrolladora de software. Esa persona será un crack en hacer su trabajo. No obstante, eso no implica que disponga las mejores dotes comunicadoras del mundo o ser mega experto en lo que habla o ser dioses: son personas. El ponente (medio) invierte más de 5 días enteros en hacer, preparar y ensayar su charla. Si además implica crear un nuevo proyecto en github o hacer un piloto, puede ser el doble de tiempo.
Normalmente no conocemos a la persona que vamos a dar feedback. No sabemos cuánta experiencia tiene, cómo están sus nervios, cómo se lo va a tomar, cómo le va a afectar o cómo le va a ayudar lo que diga. No sabemos si ha tenido un buen o mal día o si tiene algún problema personal que le atormenta.
¿Cómo se comporta la organización con la persona? Esta persona no cobra y no gana dinero por dar la charla de 45 min. Con suerte, le pagan el viaje y alojamiento.
Para dar un buen feedback es importante:
- Primero: agradecer el esfuerzo por la charla.
- Segundo: resaltar algo positivo de ella. Seguro que algo cumple.
- Cómo se mueve en el escenario
- Las manos
- Las anécdotas que cuenta
- El contexto inicial
- El resumen final que dan ganas de dejarlo todo y hacer lo que dice
- El diseño de las slides
- El contenido que mete para argumentar a lo que quiere llegar.
- La amenidad.
- La historia de la charla.
- La habilidad de empatizar y conectar con el público
- Aquella feature o historia que no sabías
- Comentar algo que vayas a hacer después de la charla.
- Tercero: decir cómo mejorarías un aspecto
- Último: volver a dar las gracias o decir una frase buena que motive.
Dar un mal feedback es muy fácil:
- Primero: asistir a la charla
- Segundo: cabrearse porque no es lo esperado y dudabas entre esa y otra charla
- Tercero: decir lo que no te ha gustado sin rodeos. A poder ser, con cuenta anónima.
- Cuarto: asumir cosas que no ha hecho al preparar la charla. «no ha hecho guión», «se nota que no ha ensayado», «es obvio que no ha preparado nada». Sobretodo poner un no.
- Quinto: si además dices algo faltoso o hiriente gana puntos.
- Sexto: Utilizas esa tónica destructiva en todos.
Aquí me pregunto:
- ¿Te leíste la descripción y el nivel de la charla?
- ¿Pensaste en cómo podría afectarle a la persona tus palabras?
- ¿Pensaste en lo que había preparado para dar su charla?
Me quedé con mal sabor de boca. Los ponentes se pisaban al hablar, los chistes no engancharon. Para mi gusto demasiado cliché. Se salvaron los últimos minutos cuando se habló de la evolución de la arquitectura. Os ánimo a que le deis una vuelta. Suerte!
Lo que parece que la gente no es consciente es de las consecuencias de un mal feedback:
- No volver a dar una charla nunca más
- No volver a compartir nada en ningún medio.
- Síndrome del impostor nivel 5 de 5.
Y vamos a más:
- Ansiedad
- Depresión.
- Frustración
Va más allá de charla “beginner”, un soporífero conjunto de obviedades
No creo que haya que decir que todo es magnífico porque entonces no aprendes. Creo que hay formas y formas de dar feedback. Si un feedback es bien dado el efecto es muy bueno. De hecho un buen feedback es un regalo de un experto para mejorar.
Otra forma de dar feedback es acercándote después de la charla al ponente y si tras preguntarle si quiere recibir feedback, comentarle tus opiniones. La cara y reacciones de la persona te ayudarán a redirigir mejor tu discurso. Tienes que entender que hay muchas veces que el ponente no quiere recibir feedback, ya sea porque ya lo ha recibido por su círculo de confianza o porque tus sensaciones (malas) post-charla le han generado una gran inseguridad.
Otra forma de dar feedback es hacer una pregunta de algo que no te hayas enterado. Ahí el ponente te está resolviendo una duda y además está percibiendo que su discurso no se ha enterado bien.
En caso que la forma de dar feedback sea escrito, voy a dar unos ejemplos de transformación de feedback sacados de ejemplos reales.
Ejemplo 1:
Charla mal estructurada, muy básica y que no deja conceptos claros
Gracias por compartir, has hecho un repaso por los conceptos básicos que viene muy bien para un begginer como está catalogada esta charla. Estaría genial que antes de explicar los contextos pusieras un contexto o un ejemplo real para seguir un hilo de historia. ¡Muchas gracias!
Ejemplo 2:
No estuvo bien explicada. Muy lioso todo
Gracias por compartir. Está genial el formado live coding. Me quedé con estas dudas, ¿cómo puedo hacer un evento? ¿cómo bla blabla? Desde mi punto de vista, como remate para el 5 sería hacer un resumen final para revisar los conceptos que dijiste durante la charla. ¡Me pondré a trastear con tus consejos!
Ejemplo 3:
Charla muy básica y bastante desafortunada. Me ha dado la sensación de que estaba sin preparar.
Gracias por compartir. La charla ha tenido toques de humor que la ha hecho amena. En mis charlas suelo hacer un ensayo con mi propio equipo para que me ayude a mejorar. ¡Os lo recomiendo! Gracias
Ejemplo 4:
La presentación no estaba trabajada. Ni siquiera se veía bien el ppt. Debería estar mejor preparada
Gracias por compartir. Normalmente el tipo de aula de ese escenario es proyector, por lo tanto de normal hace difícil leer las slides. En estos casos lo que hago es o poner dos slides en vez de una o en vez de código hago un esquema para que al menos se entiendan los conceptos. ¡La siguiente lo petáis!
Ejemplo 5:
Muy densa y con un tono muy lineal. Contenido interesante
Gracias! El contenido muy interesante. Se nota que el ponente domina la materia porque ha metido mucho contenido. Para la próxima charla recomiendo algo menos de contenido con algún ejemplo, seguro que estarás más cómodo! Por último está genial hacer cambios de voz para engancharnos más aún! Muy bien!!
Ojalá entre todos creemos una cultura social que evitemos el sufrimiento con nuestros comentarios ofensivos y destructivos. Lamentablemente, ahora la solución la veo lejos de una sociedad educada. Por lo tanto, desde mi punto de vista, la solución recaería en la organización del evento y cómo quiere hacer llegar el feedback al ponente.
Cuando algo tan importante y de tanto valor como es el feedback, es un privilegio para todo el mundo, tenemos un problema.
En Stack Overflow no puedes puntuar un comentario si no tienes x puntos. Se llama Gamificación. El una herramienta de feedback podría ser similar . No todo el mundo sabe dar feedback por lo tanto no debería todo el mundo dar feedback.
Alguien que ya haya dado charla en una conferencia sería un buen punto de partida. Creo que vivir el duro proceso te aporta de unos conocimientos para poder compartir con el resto de ponentes.
Sí, este año también he tenido muy malas críticas. Cosa que no les voy a quitar la razón, se podría haber hecho mucho mejor. Gracias a las veces que se podría haber hecho mejor, he ido aprendiendo y mejorando, hasta llegar a una charla que por fin estoy orgullosa.
Por suerte todos estos años he contado con mis amigos/amigas que han estado a mi lado para no darme más mal del necesario. He aprendido a saber leer lo que esté bien comunicado e ignorar el resto. También he aprendido a no leer ningún comentario (como me ha pasado en Xataka). Todo ello hace que mantenga las ganas de seguir haciendo lo que me gusta.
Me pregunto cuánta gente se habrá quedado por el camino porque no tenía a esos amiguis. Cuánta gente habrá tirado la toalla. Cuanta gente ya pasa de dar charlas por la frustración innecesaria que genera.
Quería dar mi opinión personal y seguro que es diferente a la tuya. Al menos, todos deberíamos darle una vuelta a esto: cuando damos nuestra opinión a un ponente, youtuber, tuitero, instagramer, detrás hay una persona que piensa, siente y sufre.
Si te gusta comparte, si quieres dar tu opinión, espero tus comentarios. Gracias
** Los comentarios han sido tomados de la web pública de commit conf.
** Se ha omitido el nombre de la fuente por respeto y evitar bulling hacia ellos.
** Si alguien considera una falta que no aparezca su nombre en su comentario, me lo comunique por comentario para cambiarlo.
Software y otras desvirtudes 
Muy bien explicado, lo único que agregaria es pedir permiso antes de dar feedback. Hay veces que no tienes ganas porque sabes que no lo has hecho bien, o porque no tienes ganas de que alguien te venga a decir cosas. Asi que es educado preguntar antes, oye te puedo dar feedback. O si te lo piden.
Totalmente, para el WTM Zaragoza no quisimos perdir feedback. Nosotras ya teníamos apuntadas bastantes cosas para mejorar. Preferimos perder opiniones pero ganar en salud. Gracias Don Jorge Juan Barroso Carmona
Yo no he dado nunca ninguna charla, aunque el feedback es algo que en nuestra profesión está a la orden del día. Estoy de acuerdo con @yondemon sobre que el feedback tiene que ser directo. No es una cuestión de no conocer a la persona, es una cuestión de que si el receptor del feedback y el emisor del feedback entran en la conversación, es preferible que sea directo para que las dos partes se entiendan sin perjuicios. Igual que hay técnicas para dar charlas que se enseñan todas las cosas que has comentado que se pueden mejorar, también hay técnicas para dar y recibir feedback. Pero parece que a muy poca gente se molesta en trabajar ese aspecto. Para mí el feedback no es un opción, ni mucho menos una obligación, para mí es un privilegio. Tiene que ser solicitado o al menos acordado, objetivo y directo. Tiene que ser específico (cuantos más ejemplos se den mejor) y aplicable. Yo no soy fan de las técnicas de feedback que se intentan dar ¨algo bueno¨, ¨algo malo¨, etc. El feedback tiene que ser neutro, sin connotaciones y objetivo sobre algo que los involucrados saben del tema. El ponente en el fondo esta ahí porque quiere, muchas personas no necesitan que se les agradezca lo que hacen, porque ya se sienten agradecidos al hacerlo. Creo que las charlas técnicas se están convirtiendo en audiciones tipo Operación Triunfo. Todos queremos mejorar, pero masacrar a feedback no siempre ayuda a la mejora. El análisis de mejora para mí es a veces algo más personal, algo que el ponente puede adquirir por él mismo sin necesidad de ser masacrado con comentarios. Las charlas o eventos técnicos son para exponer temas, adquirir o no conocimientos de los temas que se exponen y no para evaluar a quien los expone. En mi opinión hay una presión innecesaria sobre el ponente, cuando lo que importa al fin y al cabo es lo que cuenta, no como lo cuenta. Estoy de acuerdo con tu reflexión y post, al final tenemos que pensarlo una o dos veces antes de dar feedback y tres o cuatro veces en como lo damos.
Muchas gracias por compartir!
Normalmente, exponerse de forma pública en un evento en el que los asistentes pagan por la entrada y donde la propia organización del evento categoriza a los speakers en función de la opinión que tienen los asistentes a base de estrellas suele tener malos resultados. La propia organización fomenta este comportamiento desde hace unos años y es por esto que algunos speakers se han negado a participar en este evento
En estos casos lo que se puede hacer es solicitar a la organización que borre tus datos de la plataforma por lo que estos comentarios tendrán que borrarse también para cumplir con GDPR.
Por otro lado, me parece bastante soberbio el titular este post como «Not todo el mundo sabe o debe dar feedback». No creo que seamos nosotros los que debamos censurar el contenido de lo que se puede o no se puede publicar, más bien deberíamos ser capaces de aprender a gestionar el feedback que se nos da siendo capaces de descartar el que creamos que no es válido.
De nuevo muchas gracias por compartir. ¡Seguro que en los siguientes eventos lo petáis!
Estoy en gran parte de acuerdo con Cesar.
El feedback está a la orden del día en nuestra profesión (aunque por desgracia, casi siempre para puntualizar lo malo). Yo también soy ponente y he recibido mucho feedback.
Personalmente pienso que no habría que evitar el feedback como ponente, si no más bien educar a la gente a dar feedback. El feedback negativo (pero constructivo) es el que nos hace crecer.
A mi me daría una patada en el alma el acercarme a un ponente y que antes de decir nada me diga «no acepto feedback», lo tacharía de egocéntrico como mínimo (aunque la realidad sea que tiene miedo a ser «valorado»)
Yo me considero un muy buen ponente, pero muy posiblemente sea porque no me dan criticas negativas y eso es malo. ¿Soy buen ponente de verdad o simplemente me han filtrado lo malo? Me levanta la moral cuando alguien me ha dicho «Ostias, das una charla? No lo sabía, pues entonces paso del otro track y voy a verte a ti» Eso levanta el ánimo a un muerto.
Hace 1 año di una charla en Londres en conjunto con mi jefe y salí muy contento «Anda, puedes hablar frente 500+ personas y un directo de miles y encima en inglés, que crack estás hecho». Para que luego te den un buen feedback negativo (de mi jefe): Te has pasado toda la ponencia leyendo de las pantallas y eso queda muy mal. Como que ya no puedo ver mi charla, solo me veo a mi mismo mirando las pantallas. ¿Jode? Mucho, pero lo que pasa 1 vez, no pasan 2.
Luego hay feedback «curioso» que ni es bueno ni es malo. «Oye, en la vida real hablas muy bruto, con acento andaluz a tope sin pronunciar bien según que cosas y en las charlas cambias radicalmente y pronuncias todo perfectamente». Y no es mentira, aunque es cierto que no me había dado cuenta.
Pero si estoy de acuerdo que es un tema muy delicado y a un ponente primerizo le puede sentar muy mal todos esos comentarios (a mi me sentaría mal incluso ahora). Habría que intentar dar feedback constructivo aunque sea para puntualizar las cosas malas y los ponentes deberían intentar no evitar el feedback. Es tanto la fuente de frustración como la fuente de aprendizaje.
Así que mi consejo es: Leed el feedback, estad abierto a el y simplemente coge de el lo que te interesa, del resto pasa de el. Esas transformaciones de feedback que has hecho, lo hacemos nosotros mentalmente y ya. «Charla mal estructurada, muy básica». Pues pensamos… ¿Había algo aquí que quizás fuese demasiado básico? Era una introducción no sé a «Patron MVC» y he enseñado el qué es una variable en C#? Quizá he metido algún que otro slide donde explicaba algo que ya debería de ser obvio si entras a esta charla. ¿Mal estructurada? Voy a ver si la idea progresa bien o he dicho muchos «Esto lo explico luego, esto lo explico luego»
Así que nada, os animo a todos a seguir dando ponencias y por supuesto a ponerse en los zapatos de los demás a la hora de dar feedback.
Hola, te agradecería que menciones los autores de las citas de la plataforma de comentarios de la
Commit que has plagido en tu post o las elimines (lo que cumpla la GDPR o la LOPG, que no lo sé) si no quieres tener problemas legales.
Un saludo.
Pingback: Meetup con Sean Larking (Microsoft Edge), ofertas empleo Java, Python y más noticias tecnología de Mallorca
Pingback: Mi paso por la CommitConf Estrategias branching: trabajando con git y personas – Jesús L.C. – Apuntes de un aprendiz
Pingback: Commit conf 2018: ha venido para quedarse – Software y otras desvirtudes
Pingback: Commit-Conf ¡Vamos! ¿Y qué esperar del evento?