- Las charlas técnicas necesitan explicación de contexto, pero es fácil perder a la audiencia al inicio, así que resulta más efectivo mostrar primero la situación del problema y luego completar el contexto
- Esta técnica, como el consejo de escritura de Lawrence Block, consiste en intercambiar la primera y la segunda parte escritas de forma natural para poner al frente una escena con tensión
- Una presentación que explica primero el contexto puede sentirse repetitiva para quienes ya lo conocen, y para quienes no lo conocen todavía no hay suficiente motivo para escuchar, así que su atención puede bajar
- En el ejemplo de optimización de una máquina virtual basada en JIT, primero se muestran el perfil de rendimiento, un cambio de código que parece una mejora y los datos de que en realidad se volvió más lento, y después se explican el JIT, la optimización y la arquitectura
- Si al principio planteas un problema que dan ganas de resolver, los programadores naturalmente intentan encontrar la solución y luego tienen motivación para seguir la explicación
Estructura de una presentación que muestra primero el problema
- Una charla técnica normalmente necesita tanto establecer el contexto como presentar el problema a resolver
- Pero si empieza con la explicación del trasfondo, el gancho de la primera parte de la charla se debilita
- Para la audiencia que ya conoce el contexto, se vuelve información repetida
- Para la audiencia que no lo conoce, todavía no surge la motivación para intentar entenderlo
- El método de Kent Beck consiste en crear el material de la presentación en el orden deseado y luego intercambiar entre sí las primeras dos diapositivas, párrafos o capítulos
- Es una técnica tomada de Telling Lies for Fun and Profit de Lawrence Block
- Si escribes una historia de manera natural, el primer capítulo presenta al protagonista y el segundo desarrolla el incidente
- Si intercambias los dos capítulos, comienzas con una escena en la que el protagonista está en peligro
- Una vez creada la tensión, la presentación del personaje viene después, así que el lector tiene una razón para querer conocerlo
Ejemplo de una charla sobre optimización JIT y reacción de la audiencia
- Si fuera una charla sobre optimización de una máquina virtual basada en compilación JIT, normalmente primero se presentarían el JITing, el principio de Pareto como base del ajuste de rendimiento y la arquitectura actual de la máquina
- Pero una optimización común para reducir hotspots puede terminar haciendo más lento el rendimiento total, y un cambio que no parece problemático puede producir una gran mejora
- Una estructura que empieza en la segunda diapositiva coloca desde la primera diapositiva el material para juzgar el caso
- Un perfil de rendimiento donde se ven hotspots
- Un cambio de código que parece que va a mejorar las cosas
- Datos que muestran que la optimización no solo falló, sino que hizo más lento al sistema
- Si después añades la explicación de JIT, optimización y arquitectura, tanto la audiencia que ya conoce el trasfondo como la que no lo conoce seguirán atentas: la primera esperando la solución del misterio y la segunda porque ya tiene una razón para concentrarse
- Cuando a un programador se le presenta un problema, suele reaccionar con el impulso ingenieril de resolverlo, por lo que es efectiva una estructura que desde el inicio plantee un problema para resolver junto con la audiencia
1 comentarios
Opiniones de Hacker News
Hace unas semanas, cuando di una charla en PyCon, me costó meter todo el contenido en el tiempo disponible y al final recorté los primeros minutos de introducción.
Eliminé la parte en la que iba entrando poco a poco al tema y explicaba el contexto de por qué yo estaba calificado para hablar de eso, y pasé directo al primer punto; ahí había un buen chiste y funcionó muy bien.
Aprendí que, si el tema es lo suficientemente interesante, se puede saltar la introducción e ir directo al grano, y que mezclar un chiste puede captar bastante bien la atención del público.
Detesto los pitches de venta que empiezan contando la historia de la empresa y, curiosamente, muchas grandes empresas japonesas suelen ser especialmente malas en esto.
En cada diapositiva hay que pensar: “si no doy una razón para leer la siguiente diapositiva, el público se levanta y se va”.
Si todavía no sé qué estás ofreciendo, no hace falta justificar la existencia del presentador; al final, lo central no es quien presenta, sino quien escucha.
Es difícil trabarse mucho en esas partes, y mientras tanto uno entra en calor para pasar a la presentación en sí.
Claro, cuanto más breve mejor, por eso suelo memorizar las primeras frases palabra por palabra.
Incluso cuando estoy más ansioso, puedo asegurarme de sacar bien la primera parte, y después hablar con más libertad.
Unos 30 segundos están bien, pero varios minutos es demasiado, ya sea una presentación o un video de YouTube.
Entiendo por qué la gente lo hace.
Supongo que intentan reducir riesgos como “¿esta persona está calificada?” o “no entiendo el contexto”, pero me gustaría que se animaran un poco y fueran directo a lo importante.
Como ya elegí escuchar esa charla, explicar por qué es interesante es predicarle al coro.
En la cultura hacker, normalmente se juzga a la gente por su capacidad más que por sus credenciales, así que se puede colar algo como “por cierto, esto lo hice yo”, pero no leas tu currículum; convénceme con ideas.
No es así en todos los contextos, y algunos públicos valoran mucho las credenciales.
Si la gente no eligió por sí misma esa charla, también hace falta suficiente contexto.
Aun así, en general es mejor captar primero el interés y volver a la introducción después de haberlo conseguido.
En la escuela de posgrado recibí bastante entrenamiento para presentar, y mi asesor solía practicar conmigo durante los ensayos casi como si me hiciera preguntas sorpresa.
La primera diapositiva debe verse como algo que se deja en pantalla un momento mientras no se habla, como la portada de un libro.
Por ejemplo, si el moderador presenta diciendo “el siguiente ponente hablará sobre BlahBlah”, yo respondo: “Gracias, SoAndSo. Soy Godelski y siguiente diapositiva voy a hablar sobre BlahBlah”.
En cambio, si presenta diciendo “el siguiente ponente es Godelski y presentará su trabajo sobre BlahBlah”, respondo: “Gracias, SoAndSo. Siguiente diapositiva” y avanzo.
Hay variantes, incluso cuando no hay presentación, pero lo importante es no repetir información que quien presenta ya dijo y salir rápido de la diapositiva de título.
Esa diapositiva solo sirve para mostrar quién habla y de qué hablará; si tienes más información que transmitir al público, no deberías quedarte en esa diapositiva.
Hay muchos más elementos en la composición y organización de las diapositivas, pero es difícil generalizar; aun así, creo que una diapositiva de agenda es bastante útil, aunque se muestre menos de un segundo.
También cobra más importancia cuando las diapositivas se suben en línea.
Las diapositivas para presentar se hacen como apoyo al habla, así que no encajan bien cuando se suben en línea, y sería bueno poder incluir fácilmente las notas del presentador.
En Google Slides funciona bastante bien, pero en PDF es difícil, y con beamer ya es posible o parece que podría serlo, así que quizá alguien pueda impulsar una nueva práctica.
Mis presentaciones técnicas son bastante populares, y dentro de la empresa incluso personas no técnicas que no están interesadas en el tema se pasan las diapositivas.
La estructura narrativa es clave, y sin historia una presentación no puede ser interesante.
Mientras preparo una presentación, reviso continuamente las diapositivas para comprobar que el flujo de la historia sea natural.
Durante la presentación evito que aparezca demasiada información de golpe en pantalla, y uso la línea de tiempo de PowerPoint para que la diapositiva se vaya formando lentamente mientras hablo.
Intento que se vea casi como si estuviera usando un pizarrón; a nadie le gusta que, al cambiar de diapositiva, aparezca de pronto un muro de texto.
No es que evite por completo las diapositivas solo con texto, pero rara vez las uso porque pocas veces son la mejor forma de transmitir mi historia o un concepto.
Mientras preparo la presentación, también la releo constantemente para asegurarme de que no se vuelva aburrida por ser demasiado técnica ni aburrida por ser demasiado poco técnica.
El equilibrio es importante: si de pronto tengo que entrar demasiado profundo en lo técnico, en las siguientes diapositivas debo volver a subir el nivel, y lo mismo a la inversa.
Aunque uso poco texto, empleo muchas visualizaciones dibujadas a mano para explicar los conceptos con precisión, así que incluso impresas siguen siendo comprensibles y transmiten lo que hay que saber.
Por último, no importa qué app uses.
Un mal artista culpa a sus herramientas, y yo uso PowerPoint porque tiene soporte para iPad Pencil y una línea de tiempo de animación completa que, si se usa bien, permite casi hacer una película.
Aunque en la práctica lo uso sobre todo para dividir las diapositivas en piezas más pequeñas.
Las presentaciones técnicas siempre empiezan con un spoiler
Quienes tienen prisa, o simplemente confían en lo que digo, pueden quedarse con la información más importante e irse casi de inmediato
Quienes no estén de acuerdo o quieran ver pruebas de la afirmación pueden seguir participando
Es una expresión que se usa más en notas o correos, pero el concepto es el mismo
Si primero dices qué hay al final, la gente entiende hacia dónde va la explicación de contexto
Puedes escribir la columna vertebral de la historia, pero si quieres convencer al público de que al final del arcoíris hay una escena de explosión, primero tienes que mostrarles el tráiler
Vas directo a la parte buena, sin hacer que el público “se gane” la recompensa, y luego explicas el resto para quienes estén interesados
Algo de esto también aparece en varias reseñas de demos: https://web.archive.org/web/20220126051034/https://www.secon...
Empiezo con un resumen y, cuando corresponde, incluso pongo primero código completo y reutilizable que se puede copiar y pegar
Como eso es lo que quiero de los demás, yo también lo hago así
Hay que dejar el ego de lado y priorizar la utilidad
Te obliga a decir primero por qué a la gente debería importarle, y como lo menos interesante queda para después, si te pasas de tiempo o alguien pierde la concentración, no se pierde gran cosa
[1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
Puede verse como la versión para presentaciones de “I’m okay, the bull is dead”
https://www.computerworld.com/article/1702433/i-m-ok-the-bul...
Entiendo que en una situación así una persona pueda no estar tranquila y no explicarse con claridad, pero no parece que ese haya sido el caso aquí
Si estás en calma, es mejor darle primero a la otra persona una explicación de 10 a 15 segundos de lo que pasó
Primero dices la conclusión y el impacto, y después completas el contexto que llevó a ese hecho
Las presentaciones técnicas todavía necesitan una historia
Como en las técnicas estándar de storytelling, deberían empezar con un incidente que capte el interés, es decir, un incidente inicial
The Matrix empieza con Trinity a punto de ser capturada, Bambi con la madre recibiendo un disparo, y Star Wars con una nave pequeña perseguida por una nave enorme que dispara láseres
Una buena presentación técnica sigue una buena estructura narrativa
Incidente inicial, acumulación hacia un pequeño clímax, breve retroceso, clímax, conclusión
Si quieres ser un gran presentador técnico, conviene leer libros sobre cómo contar buenas historias
Por ejemplo, esos artículos larguísimos que empiezan con “David vive con sus perros boopy y bloppy en una casa de 3 habitaciones en algún lugar del campo...” hacen que los cierre de inmediato
Hace tiempo tomé una excelente clase de presentaciones dictada por un comediante, y el consejo que más recuerdo fue estructurar la presentación como una épica heroica
Es una estructura que todos conocen: todo está bien, ocurre una tragedia, se supera el problema, se celebra
Puedes pensar que no encaja con una presentación técnica, y no todas las presentaciones tienen que ser así, pero se puede aplicar con mucha más frecuencia de lo que parece
Básicamente, todo lo que resuelve un problema puede contarse de esta manera
Sin embargo, demasiadas presentaciones empiezan con “Voy a hablar del proyecto X. Este es el esquema de las diapositivas. Bueno, ¿qué es X?”
En cambio, se puede decir algo como: “Teníamos muchas cosas que hacían Y. Funcionaba bien hasta que llegó Z. Luego vino el desastre. La solución existente A no servía en absoluto para este caso. Entonces creamos X. Pero no funcionó por ... así que tuvimos que ... y finalmente todo funcionó”
Recomiendo empezar la primera diapositiva con una imagen sin texto
Esa imagen no debería tener, en apariencia, ninguna relación con el tema de la presentación que estaba en la diapositiva de título sin número
Así la gente se preguntará qué explicación vas a dar y prestará atención
Después de resolver el acertijo, pasas a la segunda diapositiva para presentar la definición del problema o la pregunta de investigación, y luego sigues con la estructura habitual: panorama general, método, datos, experimentos, resultados de evaluación, discusión y limitaciones, resumen, conclusión y trabajo futuro
Pero esto solo funciona para presentaciones orales
Otro tipo importante de slide deck, muy común en grandes empresas globales, se parece más a una mezcla entre una presentación de PowerPoint y un documento de Word
Las diapositivas están llenas de texto para que el deck se entienda por sí solo, y se escriben no solo para presentarlas, sino principalmente para que circulen por correo y se lean
Como los ejecutivos pueden hojear solo las diapositivas sin escuchar la presentación, rompen deliberadamente algunas reglas de las buenas diapositivas que apoyan una buena presentación
Al menos en mi campo, visión por computadora y aprendizaje automático, se coloca en la primera página una figura grande, atractiva y, de ser posible, autoexplicativa
Sirve para captar la atención de quien hojea el PDF y atraerlo
En visión por computadora normalmente se puede encontrar algo visualmente llamativo, como una imagen que destaque una reconstrucción 3D o detección de objetos
O se puede usar una gráfica que muestre cuánto mejor es mi método que la línea base, pero puede resultar menos interesante para alguien que no entiende bien qué significan los números
En las demos aprendí hace mucho que hay que empezar por lo bueno.
Si tienes un excelente software de monitoreo, no deberías empezar por el proceso de instalación, la configuración de la recolección de métricas y cómo conectaste el frontend a la base de datos de series temporales, para luego mostrar esos gráficos geniales que antes no existían.
En cambio, deberías mostrar primero esos gráficos geniales que antes no existían y explicar por qué son útiles.
Después, cuando todos ya estén interesados, puedes tomarte el tiempo para mostrar cómo llegaste a ese estado.
He visto demasiadas demos que empiezan con un proceso largo y aburrido hasta llegar a lo interesante, y habrían sido mucho mejores si hubieran mostrado primero lo interesante.
Es una forma genial para las presentaciones técnicas.
Pero cuando se hace así en medios de entretenimiento como novelas o series de TV, siempre pierde interés.
Si no hace falta información de contexto para entender una escena de acción, creo que se puede saltar todo ese contexto.
Ojalá no subieran tanto el ritmo para luego bajarlo demasiado rápido a un estado en el que no pasa nada.
Aun así, tiene sentido, porque pone primero la parte más importante de la historia.
Es como cuando una novela avanza demasiado lento, los lectores de prueba la abandonan antes de que pase algo interesante, y el editor sugiere: “pongamos al principio la gran escena de batalla del capítulo 10 para mostrar de qué va este libro”.
Ese método rara vez funciona bien.
Leí todas las oraciones y párrafos, pero todavía no estoy seguro de qué quiere transmitir el texto original.
¿Quiere decir “sáltate la introducción”?
Cuando empiezo una presentación, primero doy un breve resumen de en qué consistirá.
No siempre se puede ajustar el contenido al público, pero al menos si al principio das un índice o un resumen, la gente sabe cuándo concentrarse y cuándo puede distraerse un momento.
Los puntos clave que se refuercen por repetición deberían ser 2 o 3, no más.
Y mi consejo número uno es que, mientras más quieras que tu presentación suene natural, más tienes que practicarla de antemano.
Si eres un presentador con experiencia, también aprendes cuándo y cómo romper estas reglas.
Claro, la reinventó.