2008-09-12 9 views
21

Estoy planeando dar una presentación técnica para un producto que estamos construyendo. La audiencia prevista es desarrolladores técnicos. Por lo tanto, la mayor parte del tiempo, será la depuración A través del código en Visual Studio, análisis de rendimiento, alguna revisión de la arquitectura, etc.Buenos consejos para una presentación técnica

He leído par de blogs en tamaños de fuente a utilizar, plantillas para utilizar en Visual Studio, presentation tools , among other muy useful tips.

¿Qué estoy buscando específicamente es cómo mantener la sesión interesante sin hacerla un tutorial de código seco? ¿Cómo evitar que la gente se duerma? Sería genial escuchar algunas historias ...

Update1: Bonito clip de youtube en zoomit. Glue Audience To Your Presentation With Zoomit.

Update2: Nuevo puesto de Scott Hanselman después de que sus PDC talk - Tips for Preparing for a Technical Presentation

Respuesta

10

poner comentarios interesantes en el código.

// Esto mejor no falla durante mi próxima presentación, estúpido @ # $ @ #% $ code.

No hable de ellos, déjelos ser encontrados por el público.

-Adam

+0

impresionante. Ya puedo pensar en un par de ellos .. –

+0

imágenes chistosas (ni imágenes prediseñadas ni dilbert, use fotos o XKCD) son siempre un ganador! – metao

1

Esto es algo que se me explicó, y creo que es muy útil. Es posible que desee considerar no deslizarse demasiado al principio. Desea mostrarles a sus oyentes algo (obviamente, no el código) por adelantado que los mantendrá al margen de sus asientos con el deseo de aprender cómo hacer lo que les acaba de mostrar.

+0

de acuerdo. necesito comenzar con un bang. Me pregunto qué sería eso .. –

5

FYI, ese artículo de Hanselman tiene an update (su enlace es de 2003).

+0

Gracias. Actualizado con el nuevo enlace. –

4

Use historias. Incluso con ejemplos de código, tenga una historia de fondo: he aquí por qué alguien está haciendo esto. Para aumentar la participación de la audiencia, pida ejemplos de X donde X sea algo que usted sabe que puede hacer una demostración, luego formule el recorrido en esos términos.

O tal vez tenga historias de guerra sobre cómo era diferente o cómo normalmente lleva más tiempo o lo que sea. Encuentro que las personas se identifican con tales cosas, luego, al darles ejemplos, lo están rastreando mentalmente según su propia experiencia.

+0

Este es un consejo realmente excelente ... Gracias. –

1

Recientemente comencé a usar herramientas de mapas mentales para presentaciones y descubrí que funciona muy bien.

http://en.wikipedia.org/wiki/Mind_map

Básicamente, me encuentro con personas solo en zonas hacia fuera el segundo de empezar a entrar en detalles con una presentación. Transmitir la información con un mapa mental (al menos en mi experiencia) proporciona una manera mucho más fácil para que la información se transmita y se vincule.

La clave es presentar la información por etapas (es decir, sus ideas de alto nivel primero, luego con más detalle, de a una por vez).Las herramientas de mapas mentales básicamente te permiten expandir tu mapa, a medida que la audiencia mira y tu información más y más detallada presente. Hacerlo de esta manera permite a su audiencia absorber gradualmente los datos en etapas más pequeñas, lo que tiende a ayudar a la retención.

Consulte FreeMind para obtener una herramienta gratuita para jugar. Mind Manager es un producto pago, pero es mucho más pulido y fluido.

1

Mantenga su "representación visual" simple y estándar.

Si está en Vista, oculte los iconos de su escritorio y utilice uno de los fondos de pantalla predeterminados. Mantenga su configuración de Visual Studio (especialmente las barras de herramientas) como estándar y "fuera de la caja" como sea posible. Cuantas más personalizaciones muestre en su entorno, es más probable que la gente se concentre en ellas en lugar de en su contenido.

Mantenga el contenido en sus diapositivas lo más estable posible. Recuerde, usted está hablando (y en el mejor de los casos, con) su audiencia para que las diapositivas sirvan como puntos de debate. Si desea incluir más detalles, colóquelos en las notas de diapositivas. Esto es especialmente bueno si hace que las cubiertas de diapositivas estén disponibles después.

Si alguien te hace una pregunta y no sabes la respuesta, no temas decir que no sabes. Siempre es mejor que tratar de adivinar lo que crees que debería ser la respuesta.

Además, si está utilizando Vista, asegúrese de ponerlo en "modo de presentación". PowerPoint también tiene un modo similar, así que asegúrese de usarlo también: tiene la presentación de diapositivas en un monitor (el proyector) y una vista más pequeña de la diapositiva, además de notas y un temporizador en el monitor de su computadora portátil.

4

Recomiendo la publicación de Scott Hanselman (mencionada anteriormente). He escrito un post con algunos consejos, sobre todo por razones egoístas - reviso cada vez antes de dar una presentación técnica:

Tips for a Technical Presentation

Si estás utilizando un indicador de la consola, make sure the font is readable and that your paths are preset when possible.

Tómese 15 minutos para instalar y aprenda a usar ZoomIt, para que su audiencia pueda ver claramente lo que está presumiendo. Si tiene que preguntar si pueden ver algo, ya ha fallado.

Probablemente lo más importante es have separate Visual Studio settings pre-configured with big, readable fonts.

+0

Este es un gran honor ... Soy uno de sus lectores habituales. En realidad, tenía el enlace a la entrada de tu blog, pero lo eliminé para evitar demasiados enlaces a la pregunta. –

1

¿Ha oído hablar de Pecha-Kucha?

La idea detrás de pechakucha es mantener presentaciones concisa, el interés nivel y tener muchos presentadores compartiendo sus ideas dentro del curso de una noche. Por lo tanto, se creó el formato 20x20 Pecha Kucha: cada presentador tiene permitida una presentación de diapositivas de 20 imágenes, cada una mostrada durante 20 segundos. Esto se traduce en un total de tiempo de presentación de 6 minutos y 40 segundos en una etapa antes de la próxima presentadora es de hasta

Ahora, no estoy seguro si eso corta duración podría estar bien para una demostración del producto. Pero puede tratar de obtener algunas ideas agradables del concepto, como ser conciso y mantenerse al tanto, el tiempo efectivo, la gestión del espacio, etc.

0

Si utiliza diapositivas en absoluto, sigue Guy Kawasaki's 10/20/30 rule:

  • No más de 10 diapositivas
  • no más de 20 minutos empleados en portaobjetos
  • No menos de 30 tipo de punto en portaobjetos

-Adam

+0

"la mayoría de las veces, voy a depurar a través del código en Visual Studio" No se presta realmente a las diapositivas. – swilliams

3

Uno de los mejores consejos que he tenido para hacer demos es simplemente grabarlas con anticipación y reproducir el video, narrando en vivo. Luego, las cosas inesperadas ocurren en privado y obtienes tantas puñaladas como necesites.

Por lo general, necesita algún entorno para usar como referencia para preguntas, pero para el bit de presentación, grabarlo con anticipación (y ensayar su narración sobre el video) garantiza que puede estar en lo más alto de su juego.

También me gusta poner pequeñas bromas en las diapositivas y ese video grabado que hace parecer que la persona que hizo las diapositivas está comentando sobre los procedimientos en vivo o que alguien más está ejecutando las diapositivas. A menudo, no hago ninguna referencia a la broma en la diapositiva.

Por ejemplo, en mi most recent demo presentation, tenía una diapositiva con el texto "ASP.NET MVC" centrado del que hablaba sobre cómo estaba usando el marco. En una fuente más pequeña, tenía el texto "Catchy name, huh?". Cuando hice esa demostración en vivo, esa diapositiva me dio una sonrisa. No es digno de stand-up por cualquier tramo de la imaginación, pero a menudo presentamos algunas cosas bastante secas y cada poquito ayuda.

Del mismo modo, he incluido diapositivas que son simplemente comentarios snarky del tipo fuera de pantalla sobre lo que planeo decir. Por lo tanto, diré: "La base de código para este proyecto necesitaba un poco de ayuda", mientras que la diapositiva detrás de mí decía "Era una pila de espagueti con 3 albóndigas, en realidad" y un plato de espagueti como fondo deslizante. De nuevo, sin ningún comentario mío y pasando a la siguiente diapositiva, como si ni siquiera lo hubiera visto realmente lo hizo más divertido.

Eso también puede ser una ayuda si no tienes la mejor sincronización cómica al quitar la presión mientras aún agregas ligereza.

De todos modos, lo que realmente se reduce a esto es que he estado haciendo la mayor parte de mi presentación/presentación de trabajo como lo haría si fuera un screencast y luego sustituyo la versión en vivo de mí (pausando el video como apropiado si las cosas se descarrilan) para el audio cuando lo doy frente a una audiencia.

Por supuesto, puede hacer fácilmente la real presentación disponible después para aquellos que lo deseen.

Para las diapositivas, generalmente hago todo lo posible para no decir las palabras exactas en la pantalla la mayoría de las veces.

3

Si está mostrando el código que estaba preparado para usted, asegúrese de que pueda hacerlo funcionar. Sé que es obvio, pero estaba en una conferencia en la que 4 de cada 5 oradores tenían problemas con el código. Decirme que es 'genial' o incluso 'realmente genial' cuando no funciona es una venta difícil.

+0

De acuerdo. Debe funcionar la primera vez, todo el tiempo. – TonyOssa

2

La regla # 1 para mí es: no intente mostrar demasiado.

Es fácil vivir con un pedazo de código durante un par de semanas y pensar: "¡Maldición, cuando les muestre esto se van a asustar!" Incluso durante tus ensayos privados te sientes bien con las cosas. Pero una vez en frente de una audiencia, la complejidad de su código se multiplica por el cuadrado del número de miembros de la audiencia. (¡Se vuelve exponencialmente más difícil de explicar el código para cada miembro de la audiencia agregado!)

Lo que parecía tan simple y directo en privado se convierte rápidamente en un cuenco gigante de espaguetis que bajo presión incluso usted no comprende. No intente mostrar el código de producción (bien factorizado y bien particionado), haga simples ejemplos en línea que transmitan su mensaje central.

Mi regla n. ° 1 podría ser interpretada, por los cínicos, ya que no sobreestimará su audiencia. ¡Como optimista, lo veo así como no sobreestimo tu habilidad para explicar tu código!

rp

2

Dado que parece que usted está haciendo una presentación en vivo, donde se va a trabajar con los sistemas reales y no sólo los gráficos (PPT, Impress, lo que sea) asegúrese de que es todo el funcionamiento justo antes de empezar. Nunca falla, si no lo intento justo antes de comenzar a hablar, no funciona como esperaba. Especialmente con demos. (Estoy haciendo uno el martes para poder relacionarme).

Otra cosa que ayuda es simplemente practicar, practicar y practicar. Especialmente si puede hacerlo en el entorno exacto en el que se presentará. De esa forma tendrá una idea de dónde debe estar para no bloquear la vista de sus oyentes, así como cualquier otra técnica que pueda haber con respecto a a la configuración de la sala o sistemas.

1

Además de algún software como Mind Manager para mostrar su arquitectura, puede hacer que encuentre un grabador de pantalla como herramienta de presentación para ilustrar su tarea técnica. DemoCreator sería algo bueno para hacer un video de su actividad en pantalla. Y puede agregar más textos destacados para que el proceso sea más fácil de entender.

Cuestiones relacionadas