Bons conseils pour une présentation technique

Question

Je prévois faire une présentation technique pour un produit que nous sommes en train de construire. Public visé: développeurs techniques. Donc, la plupart du temps, je vais déboguer à travers le code dans Visual Studio, l'analyse des performances, une revue de l'architecture, etc

J'ai lu quelques uns de blogs sur les tailles de police à utiliser, les modèles à utiliser sur Visual Studio, presentation tools , among other très useful tips.

Ce que je cherche spécifiquement est comment garder la session intéressante sans faire une marche à suivre de code sec? Comment éviter que les gens ne s'endorment? Serait génial d'entendre quelques histoires ..

Mise à jour1: Nice youtube clip on zoomit. Glue Audience To Your Presentation With Zoomit.

Update2: Nouveau message de Scott Hanselman après ses PDC talk - dans le code Tips for Preparing for a Technical Presentation

Answer 1

mettre des commentaires intéressants.

// Pour mieux ne pas manquer lors de ma prochaine présentation, code stupide @ # $ @ #% $. Ne parlez pas d'eux, laissez-les être trouvés par l'auditoire.

-Adam

Answer 2

C'est quelque chose qui m'a été expliqué, et je pense qu'il est très utile. Vous pouvez envisager de ne pas glisser lourd au début. Vous voulez montrer à vos auditeurs quelque chose (évidemment, probablement pas le code) à l'avance qui les gardera sur le bord de leur siège et qui voudront apprendre comment faire ce que vous venez de leur montrer.

Answer 3

FYI, cet article de Hanselman a an update (votre lien date de 2003).

Answer 4

Vous devriez lire Mark Jason Dominus excellente presentaton sur la parole en public: Conference Presentation Judo

Answer 5

Utilisez des histoires. Même avec des exemples de code, avoir une trame de fond: voici pourquoi quelqu'un fait cela. Pour augmenter la participation de l'auditoire, demandez des exemples de X où X est quelque chose que vous savez que vous pouvez démo, puis exprimez la marche à suivre dans ces termes. Ou peut-être que vous avez des histoires de guerre à propos de comment c'était différent ou comment cela prend plus de temps ou quoi que ce soit d'autre. Je trouve que les gens s'identifient à de telles choses, et alors que vous donnez vos exemples, ils les repèrent mentalement à leur propre expérience.

Answer 6

J'ai récemment commencé à utiliser les outils de Mind Mapping pour les présentations et j'ai constaté que cela se passait très bien.

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

Fondamentalement, je trouve les gens zone juste la seconde vous commencez à entrer dans les détails avec une présentation. Transmettre l'information avec une carte mentale (au moins dans mon expérience), fournit un moyen beaucoup plus facile pour l'information d'être transmis et liés ensemble. La clé consiste à présenter l'information par étapes (c'est-à-dire d'abord vos idées de haut niveau, puis plus en détail, une à la fois).Les outils de mind-mapping vous permettent essentiellement d'élargir votre carte, au fur et à mesure que le public regarde et votre information de plus en plus détaillée. Le faire de cette façon permet à votre audience d'absorber progressivement les données en plus petites étapes, ce qui tend à favoriser la rétention.

Découvrez FreeMind pour un outil gratuit pour jouer avec. Mind Manager est un produit payant, mais est beaucoup plus poli et fluide.

Answer 7

Gardez votre "représentation visuelle" simple et standard.

Si vous êtes sur Vista, cachez les icônes de votre bureau et utilisez l'un des fonds d'écran par défaut. Gardez vos paramètres Visual Studio (en particulier les barres d'outils) en standard et "out of the box" autant que possible. Plus vous personnalisez dans votre environnement, plus les gens vont se concentrer sur ceux-ci plutôt que sur votre contenu. Gardez le contenu de vos diapositives aussi consisque que possible. Rappelez-vous, vous parlez (et dans le meilleur des cas, avec) votre auditoire afin que les diapositives servent de points de discussion. Si vous souhaitez inclure plus de détails, placez-les dans les notes de diapositives. Cela est particulièrement utile si vous rendez les diapositives disponibles par la suite.

Si quelqu'un vous pose une question et que vous ne connaissez pas la réponse, n'ayez pas peur de dire que vous ne savez pas. C'est toujours mieux que d'essayer de deviner ce que vous pensez que la réponse devrait être.

De même, si vous utilisez Vista, veillez à le mettre en "mode présentation". PowerPoint a également un mode similaire, alors assurez-vous de l'utiliser aussi - vous avez le diaporama sur un moniteur (le projecteur) et une plus petite vue de la diapositive, plus des notes et une minuterie sur votre écran d'ordinateur portable.

Answer 8

Je recommande le post de Scott Hanselman (mentionné précédemment). J'ai écrit un post avec quelques conseils, principalement pour des raisons égoïstes - je passe en revue chaque fois avant de faire une présentation technique:

Tips for a Technical Presentation

Si vous utilisez une invite de la console, make sure the font is readable and that your paths are preset when possible.

Prenez 15 minutes pour installer et apprendre à utiliser ZoomIt, afin que votre public puisse voir clairement ce que vous montrez. Si vous devez demander s'ils peuvent voir quelque chose, vous avez déjà échoué.

Probablement le plus important est à have separate Visual Studio settings pre-configured with big, readable fonts.

Answer 9

Avez-vous entendu parler de Pecha-Kucha?

L'idée derrière Pecha Kucha est de garder présentations concises, le niveau d'intérêt et d'avoir de nombreux présentateurs partager leurs idées dans le cours d'une nuit. Par conséquent, le format 20x20 Pecha Kucha a été créé: chaque présentateur a droit à un diaporama de 20 images , chacune étant affichée pendant 20 secondes. Il en résulte une présentation totale temps de 6 minutes 40 secondes sur une scène avant le prochain présentateur est en

Maintenant, je ne suis pas sûr que courte durée pourrait être ok pour une démonstration du produit. Mais vous pouvez essayer d'obtenir quelques bonnes idées du concept, comme être concis et garder le point, le temps efficace, la gestion de l'espace, etc.

Answer 10

Si vous utilisez des diapositives du tout, suivez Guy Kawasaki's 10/20/30 rule:

• Pas plus de 10 diapositives
• Pas plus de 20 minutes passées sur des lames
• Pas moins de 30 type de point sur des lames

-Adam

Answer 11

Un des meilleurs conseils que j'ai jamais eu pour faire Les démos, c'est simplement les enregistrer à l'avance et lire la vidéo, en racontant en direct. Ensuite, les choses inattendues se passe en privé et vous obtenez autant de coups que vous avez besoin.

Vous avez toujours besoin d'un environnement à utiliser comme référence pour les questions, mais pour le bit de présentation, l'enregistrer à l'avance (et répéter votre commentaire sur la vidéo) vous garantit une place de choix. J'aime aussi mettre de petites blagues dans les diapositives et la vidéo enregistrée qui donne l'impression que la personne qui a fait les diapositives commente les délibérations en direct ou que quelqu'un d'autre exécute les diapositives. Souvent, je ne fais absolument aucune référence à la blague dans la diapositive.

Par exemple, dans mon most recent demo presentation, j'avais une diapositive avec le texte "ASP.NET MVC" centré dont je parlais sur la façon dont j'utilisais le framework. Dans une plus petite police, j'ai eu le texte "Nom Catchy, hein?". Quand j'ai fait cette démo en direct, cette diapositive a eu un petit rire. Ce n'est pas digne d'être vu par n'importe quel effort d'imagination, mais nous présentons souvent des choses plutôt sèches et chaque petit geste aide.

De même, j'ai inclus des diapositives qui sont simplement des commentaires sarcastiques du gars hors écran sur ce que je prévois de dire. Donc, je dirai, "Le code de base pour ce projet a besoin d'un peu d'aide", tandis que la diapositive derrière moi dit "C'était un tas de spaghettis avec 3 boulettes de viande, en fait" et une assiette de spaghetti. Encore une fois, sans commentaire de ma part et en passant à la diapositive suivante, comme si je ne l'avais même pas vu, cela rendait la situation encore plus drôle.

Cela peut aussi être utile si vous n'avez pas le meilleur timing comédique en supprimant la pression tout en ajoutant de la légèreté. Quoi qu'il en soit, ce que je veux vraiment dire, c'est que j'ai fait la plupart de mes démos/présentations comme si c'était un screencast et que je remplaçais la version live de moi (en mettant la vidéo en pause si nécessaire) les choses déraillent) pour l'audio quand je le donne devant un public.

Bien sûr, vous pouvez ensuite facilement rendre la présentation réelle disponible par la suite pour ceux qui le souhaitent. Pour les diapositives, je fais généralement de mon mieux pour ne pas dire les mots exacts sur l'écran plus souvent qu'autrement.

Answer 12

Si vous montrez le code qui a été préparé pour vous, alors assurez-vous que vous pouvez le faire fonctionner. Je sais que c'est une évidence mais j'étais juste à une conférence où 4 orateurs sur 5 ont eu des problèmes de code. Me dire que c'est «cool» ou même «vraiment cool» quand ça ne marche pas est une vente difficile.

Answer 13

La règle n ° 1 pour moi est: N'essayez pas de montrer trop.

Il est facile de vivre avec un morceau de code pendant quelques semaines et de penser: «Bon sang, quand je leur montrerai ça ils vont paniquer! Même pendant vos répétitions privées, vous vous sentez bien dans les choses. Mais une fois devant un public, la complexité de votre code est multipliée par le carré du nombre de spectateurs. (Il devient exponentiellement plus difficile d'expliquer le code pour chaque membre du public ajouté!)

Ce qui semblait si simple et direct se transforme rapidement en un bol géant de spaghetti que même sous pression vous ne comprenez pas. N'essayez pas de montrer le code de production (bien factorisé et bien partitionné), faites des exemples en ligne simples qui véhiculent votre message principal.

Ma règle n ° 1 pourrait être interprétée, par le cynique, comme ne surestimez pas votre public. En tant qu'optimiste, je le vois comme ne surestimez pas votre capacité à expliquer votre code!

rp

Answer 14

Comme il semble que vous faites une présentation en direct, où vous allez travailler avec des systèmes réels et non pas seulement les cartes (PPT, Impress, peu importe) assurez-vous qu'il est tout de travail juste avant de commencer. Ça ne raté jamais, si je ne l'essaye pas juste avant de commencer à parler, ça ne marche pas comme je m'y attendais. Surtout avec des démos. (J'en fais une le mardi, donc je peux raconter.)

L'autre chose qui aide est simplement de pratiquer, pratiquer, pratiquer. Surtout si vous pouvez le faire dans l'environnement exact dans lequel vous allez présenter. De cette façon, vous aurez une idée de l'endroit où vous devez être pour ne pas bloquer la vue de vos auditeurs, ainsi que d'autres pièges techniques en ce qui concerne à la configuration de la pièce ou aux systèmes.

Answer 15

En plus de certains logiciels comme Mind Manager pour montrer votre architecture, vous faites de trouver un enregistreur d'écran comme outil de présentation pour illustrer votre tâche technique. DemoCreator serait quelque chose de bien faire de la vidéo de votre activité à l'écran. Et vous pouvez ajouter plus de légende pour rendre le processus plus facile à comprendre.