language agnostic - Presentación sobre proyecto de software a no programadores

language-agnostic (14)

Pronto tendré que dar una presentación sobre mi proyecto de honores para la facultad de ingeniería y un gran grupo de estudiantes de ingeniería y tecnología en mi universidad. Si bien todas las personas que asistan serán de mentalidad técnica, no todos serán programadores y la mayoría serán de otras disciplinas de ingeniería.

He hecho presentaciones antes, y estoy seguro de que hablo con una multitud, pero ahora me doy cuenta de que todas las presentaciones que he dado anteriormente han sido para otros estudiantes de CS / SE y personal docente. Me pregunto si mi estilo de presentación asume que estoy presentando a otros geeks de software, para que sepan de lo que estoy hablando y pueda poner una demostración más interactiva que involucre a la audiencia.

Mi proyecto de honores no es terriblemente complejo ni teórico, tengo un prototipo de la aplicación Winforms de C #, pero está diseñado para ser extensible y operar con diferentes fuentes de datos (ODBC o WS) en el futuro, y algunas investigaciones sobre cómo podría extenderse con un motor de reglas y DSL y se convirtió en un producto comercializable. La organización que está probando mi prototipo ahorra decenas de miles de dólares al año al automatizar una función empresarial crítica.

Había planeado mostrar cuán extensible era con algunos códigos de codificación en vivo y de estilo UML. Realmente disfruto haciendo demostraciones y codificación en vivo, pero no sé si ese tipo de presentación será tan accesible para los no programadores, y me preocupa que si me vuelvo demasiado geek y técnica pueda alejar a la audiencia y los jueces.

¿Cuáles son las técnicas efectivas que ha encontrado para presentar proyectos de software de una manera que también es interesante para los no programadores?

Algunos consejos

Use un lenguaje técnico común. solo use términos que la audiencia reconocerá.
Vincula lo que expone usted mismo, con ejemplos reconocibles por el público.

también puedes leer estos excelentes artículos.

Adiós.

Aquí está mi consejo:

Tenga claro quién es su audiencia y cuál es su mensaje . ¿Está tratando de impresionar a seis miembros de la facultad que marcan su proyecto o que demuestra que puede entretener a toda la audiencia?
Tenga una página de Contenido desde el principio: de esa manera, la audiencia sabrá qué esperar.
Pon las cosas geek en un apéndice de tu presentación principal. De esa manera puedes echarle un vistazo, para hacer preguntas, pero no perderás el punto principal de tu charla.
Asegúrese de que su presentación fluya y cuente una historia : limite los números de diapositivas y no los ate: objetivos del proyecto, posibles usos, desafíos de diseño, elección de software, lo que hizo (límite técnico), resultados (demostración), resultados y limitaciones, siguiente pasos, preguntas.
Tenga una página de conclusiones al final: asegúrese de hacer un círculo hacia atrás y cruzar para referirse a la página de contenido original.
Deje un 15-20% de su tiempo para preguntas . Esto revelará lo que le interesa a la audiencia y le permitirá mostrar una comprensión más profunda del tema, es decir, solo podrá codificar en vivo si lo solicita.
Ensaye en voz alta incluso si se siente estúpido al hacerlo.

Buena suerte.

Concéntrese en la interfaz de usuario (también conocido como cómo les hace la vida más fácil) y en qué se diferencia de los productos similares (por qué deberían escuchar).

Creo que Simon Peyton Jones da excelentes charlas. Vea la sección Cómo dar una buena charla de investigación en esta página . En particular, mira el video de su charla sobre el tema vinculado en esa sección. Puede encontrar otros videos de sus charlas sobre Haskell, programación funcional, etc. para ver cómo practica lo que predica.

Cuando estaba trabajando en mi doctorado, la facultad nos dio esta regla para seminarios, y ha demostrado ser muy útil ya que:

Diles lo que vas a decirles. (Por ejemplo, breve descripción introductoria del problema y resumen de resultados)
Diles. (Por ejemplo, detalles técnicos que comprenden la mayor parte del tiempo)
Diles lo que les dijiste. (Ej. Breve resumen y conclusiones)
Abre el piso para preguntas.

En su posición, tomaría alrededor del 10-20% de su tiempo asignado para hacer el # 1 de una manera en gran medida no técnica. Entonces, podrías describir la función comercial que tu código automatiza, por qué es importante, cómo eran las cosas antes y después de aplicar tu solución, cómo se está ahorrando dinero, ese tipo de cosas.

Luego me lanzaría a una discusión altamente técnica dirigida a la multitud de CS / SE. Incluso si el resto de la gente no lo entiende y se le nublan los ojos, al menos su presentación les habrá dado una idea de qué se trata, y quizás reconozcan algo aquí o allá.

Para la tercera parte, resumiré brevemente el problema y describiré cómo lo resolvió en un lenguaje no técnico, y luego haré su demo de whiz-bang de extensibilidad de codificación en vivo. Incluso si la gente que no pertenece a CS / SE no comprende la demostración, verán pasar dulces ojos y sus colegas profesionales y docentes asentirán y sonreirán, por lo que pensarán que es genial.

Una vez asistí a un seminario de un tipo que ganó el Premio Nobel por aplicar la teoría del caos a los sistemas químicos. Aplicó este enfoque, así que aunque todos los no teóricos como mis colegas químicos orgánicos y yo estábamos completamente fuera de nuestra profundidad, el hecho de que todos los teóricos estaban entusiasmados nos dejó con la sensación de que era un gran seminario aunque no lo hicimos. Tengo una pista sobre lo que él dijo.

En primer lugar, sugiero hablar con los asesores de su facultad sobre lo que esperan de su presentación. Si hay alguna pregunta acerca de cómo debe equilibrar los detalles técnicos comprensibles solo para las personas de CS versus conceptos más generales comprensibles para una audiencia más amplia, creo que realmente ayudaría obtener opiniones de aquellos que lo evaluarán.

Una cosa que realmente me gusta ver en una presentación es un "mensaje para llevar a casa". ¿Qué es lo que quiere que todos en la audiencia recuerden mucho después de que hayan salido de la sala? Cuéntales el mensaje final desde el comienzo. Dígales que pasará el resto de la presentación explicando por qué deberían preocuparse y por qué deberían creerle. Incluso si la gente se pierde en algunos de los aspectos técnicos, si por lo menos conduce a casa ese único mensaje, habrá entregado una cosa a mucha gente.

Otra sugerencia: no te olvides del formato. Las diapositivas de presentación deben ser legibles desde cualquier lugar del auditorio / sala de conferencias. No abrume a las personas con demasiado texto en una diapositiva. Mantenga las viñetas cortas y fáciles de escanear. ¿Desea que las personas pasen su tiempo leyendo sus diapositivas o desea que escuchen lo que tiene que decir? No use acrónimos, pero si debe, explíqueles lo que significan y coloque las definiciones en sus diapositivas, a menos que esté seguro de que son de dominio público. Si la gente está sentada allí preguntándose qué diablos significa ese acrónimo, no están escuchando.

En cuanto a si debes mostrar el código real o la codificación en vivo, mi instinto es que no deberías hacerlo a menos que sea absolutamente crítico para el punto que estás haciendo. Si su proyecto fue en realidad sobre una construcción de codificación (por ejemplo, si usted había inventado el concepto de un "método de extensión"), está bien, tendría sentido entrar en algún código real. Pero parece que el significado de lo que has hecho definitivamente está en un nivel de eso. Es posible que desee mostrar qué tan poco código se necesita para, por ejemplo, conectar una fuente de datos diferente, pero en realidad no accedería a recorrer el código a menos que sienta que no puede expresar su punto de otro modo. Una cosa que probablemente me gustaría ver si estuviera en la audiencia es una demostración de tu código en acción. Muéstrame lo que hace, y dime por qué es genial.

¡Espero que vaya bien!

He estado en la misma situación
(presentando un proyecto de ingeniería de software / procesamiento / reconocimiento de imágenes en una competencia de profesores de EE).

Comience con el problema (el problema)
Luego el fondo (un BIT de fondo técnico)
La solución:
- Comience con diagramas de bloques (todos los ingenieros los leen)
- Luego explique las tecnologías y cuán brevemente: qué tan complicada fue la implementación
  (No subestime la parte complicada; de lo contrario, puede hacer que su trabajo parezca simple para los ingenieros de otros campos; no apreciarán su esfuerzo)
Resultados:
- Muestre ejemplos visuales breves (intente hacerlos intrigantes)
  (ejemplos de código corto pueden ir aquí)
- Demostración de interfaz de usuario corta
- Mostrar gráficos impresionantes
Bibliografía, gracias, posibles mejoras futuras / investigación
Preguntas (si el foro es grande, dígales de antemano que el tiempo de las preguntas será al final)
Consejo general:
- Práctica de presentación (una y otra vez)
- Deje 45-60 segundos por diapositiva
- No más de 5 puntos por diapositiva
- 1 línea por punto
- Añadir chistes
- Sin animaciones excepto para demostrar problemas complicados más rápido
- Utilice fuentes claras (Ariel o Calibri para texto normal, 1 fuente diferente para títulos)
- Use colores de alto contraste (claro sobre negro u oscuro sobre blanco si debe: sin oscuridad sobre oscuro o brillante o brillante)

Me inclinaría a no usar código (a menos que sea necesario), y usar algún tipo de pseudocódigo genérico (y directo).

Además, si está hablando con tarjetas rápidas, coloque ''¡Respire!'' en la parte superior de las cartas. Me ayudó...

Mezcle y combine un tema que todos conozcan. Me ha ayudado a diapositivas temáticas con imágenes que van desde la Divina Comedia hasta Los Simpson. No sé cuán formal es tu presentación, pero es una técnica constructivist común engancharte a algo que tu audiencia ya sabe para mostrar tu punto.

Una vez asistí a una presentación de Larry Wall donde explicó las características de Perl 6 usando ejemplos del golf mezclado con el Señor del Anillo.

Para atraer a ambas audiencias, a veces doy la explicación técnica y luego la sigo con mi explicación "en inglés, por favor". CSI y otros dramas con ciencia en ellos hacen esto todo el tiempo, con buenos resultados.

En otras palabras, [inserte la explicación en inglés sencillo aquí].

Por favor, escucha el siguiente podcast: Manager Tools - Presentation basic

Cubrirá todos los aspectos básicos que necesita para hacer presentaciones efectivas.

Ahora, al hacer presentaciones de proyectos, haga lo siguiente:

Cree un modelo de arquitectura de alto nivel ... vea este model , probablemente pueda hacerlo mejor (nota: la imagen del modelo es de mi blog).
Crear una lista de requisitos de alto nivel
Cree un diagrama de proceso del flujo de trabajo de la aplicación (una vez más bonitos colores, flechas y bloques). Este modelo mostrará cómo se espera que un usuario trabaje con la aplicación para resolver su tarea principal.

Para que el presente la aplicación primero les muestre la lista de requisitos y hable sobre ellos, luego la arquitectura de alto nivel y finalmente el diagrama del proceso de flujo de trabajo de la aplicación que puede ser seguido por una demostración en vivo.

La regla más importante es presentar a un nivel bastante alto con muchos diagramas y modelos para mostrar de qué estás hablando.

Vamos a atacar esto como un problema de refactorización.

es decir, en lugar de agregar más a su presentación, ¿hay alguna manera de sacar cosas?

Por ejemplo, no creo que presumir que su aplicación de demostración puede usar múltiples fuentes de datos es esencial, y mucho menos concederle la posibilidad de programar allí mismo durante la presentación. Sé que se ocupó del diseño de su aplicación para llegar a ese punto, pero la mayoría de la gente está más interesada en las SALIDAS que en las ENTRADAS de una aplicación. Y aún más en los BENEFICIOS de dicha aplicación.

Algunos puntos de orientación:

Haga la presentación sobre ellos . Si la audiencia ha sentido el dolor que su programa resuelve, recuérdeles ese dolor. Si se trata de otras investigaciones como usted, pídales que se pongan en el lugar de la organización a la que ayudó.
Compare la forma antigua con la nueva forma de hacer las cosas. ¿Por qué la nueva forma es más eficiente? ¿Llevará a más ventas? ¿reducirá el inventario? o ahorrar dinero? ¿Alguien perderá su trabajo porque su solución hace que su tarea sea irrelevante? Nota: Al hacer presentaciones tecnológicas que he observado es importante abordar lo que le sucede a las personas que hacían la tarea anteriormente. Afortunadamente, la mayoría de las veces las personas no pierden sus trabajos, en la mayoría de los casos, las mismas personas pueden gestionar un volumen mucho mayor de trabajo gracias a la tecnología.
Mostrar resultados ¿Cuáles son los resultados reales que su compañía de demostración ha observado?
Use efectos visuales significativos . Si pudieras hacer algunas animaciones que expliquen tu algoritmo aún mejor.
Dile tu punto al principio y al final . La mayoría de las personas olvidarán lo que sucedió en el medio, así que asegúrese de decir lo más importante al principio y al hablar.
Practica, practica . Sí, suena ridículo, pero haz toda tu presentación delante de un espejo o video grabado al menos dos veces. Mientras más, mejor. No dé una de las presentaciones más importantes de su vida sin un ensayo.

Respira y sé positivo que lo harás bien :-D

PD: Mis sugerencias se derivan de esta página web. Me ha guiado varias veces: 6 Estímulos para alcanzar el viejo cerebro

Ya estás trabajando en conocer a tu audiencia, lo que creo que es increíble, solo tienes que dar un paso más y preguntarte a ti mismo, si yo fuera x persona en la audiencia, qué obtendría de esta presentación.

Yo cuestionaría la validez y cuánto esfuerzo debería incluirse en la demostración técnica / de codificación, si es probable que el grupo al que presenta nunca use su implementación específica. Puede ser más importante describir cómo se acercó a la extensibilidad, de modo que pueda reunir ideas entre los pares sobre cómo pueden abordarla en el futuro, así como también sobre puntos que son importantes para todos los miembros de su audiencia, y tal vez atajo la demostración un poco para mostrar que sí, de hecho funciona.

No sé ustedes, pero personalmente siempre obtuve más valor de este tipo de presentaciones basadas en cómo el proyecto atrae a todos, cómo se las está arreglando para ahorrar decenas de miles de dólares al año para esta empresa, teóricamente por qué otras compañías podrían querer usarlo también, cuál es el mercado y otros factores, cuáles fueron los obstáculos tecnológicos que tuvo que superar, incluso si se trata de un proyecto simple, hubo cosas que debe haber pensado antes de tiempo para evitar y evitar que te arrinconen en una esquina.

Creo que si eres un presentador realmente bueno, y el propósito de la presentación es ser amplio y atractivo para todo el grupo, y no una charla sobre la teoría del caos y la aplicación a los sistemas químicos, que tiene ese propósito declarado, deberías apelar al mínimo común denominador de la audiencia, y toda la audiencia puede entretenerse y apreciar lo que ha logrado en cada paso del camino, y para hacer esto, no necesariamente tienen que entender cada paso dado.

Lo que hago es hablar de analogías, tratar de convertir al mundo real los términos que estás explicando.

Por cierto, ¿por qué estás hablando de aspectos de tecnología de software para personas no tecnológicas? Primero debe orientar el contenido a su audiencia. ¿Quién es tu audiencia principal? Los expertos en tecnología o no, elige uno.

Saludos,