¿Cómo puedo dar una buena presentación a las partes interesadas importantes y no técnicas?

Al final del mes, tengo que hacer una presentación sobre un proyecto de software en el que he estado trabajando solo, que básicamente decidirá si obtendré un trabajo a tiempo completo en la empresa a la que soy contratado temporalmente. por ahora. Daré mi presentación al presidente de nuestro departamento y a dos vicepresidentes. El presidente tiene menos conocimiento de programación que los otros dos vicepresidentes y, en última instancia, es la persona que necesito impresionar.

¿Cuáles son las cosas más importantes que necesito transmitir en la presentación? Mi gerente ya me ha dicho que enfatice las siguientes cosas:

1. Estoy dirigiendo este proyecto en la dirección correcta y tengo el control total de todo.
2. Estoy completando este proyecto a tiempo.

¿En qué otras cosas debería centrarme durante mi presentación para hacerme parecer lo más rentable posible? Estoy pensando en destacar los esfuerzos que estoy haciendo a nivel de diseño para reducir el riesgo y la incertidumbre en el software (dos cosas que imagino son muy importantes para los superiores).

Una cosa que me preocupa particularmente es encontrar el equilibrio correcto entre los detalles técnicos y no técnicos en la presentación. Si no incluyo ningún detalle técnico, el presidente de nuestro departamento no sabrá sobre todas las características "ocultas" que están en el software, pero si soy demasiado técnico, podría perderse y no entender puntos importantes en la presentación.

Cualquier consejo sería apreciado.

Conoce a tu audiencia

Ya has conquistado la regla número 1 de hablar en público: has evaluado la experiencia técnica de las personas con las que hablarás y tu presentación debe adaptarse en consecuencia. No te preocupes por dar brillo a tu presentación con mucha tecnología y charla.

Una gran tentación cuando te enfrentas a las grandes pelucas es probarlas y EXPRESIONARLAS con tu impresionante diccionario de conceptos técnicos, teorías y aplicaciones. La idea es, por supuesto, que si has confundido lo suficiente al jefe , ¡ por supuesto , debes estar calificado para este trabajo!

Esto incluso funcionará, probablemente, a corto plazo para conseguir el puesto de tiempo completo que está buscando. Sin embargo, el presidente, sin duda, se alejará de la reunión pensando: "No tengo idea de qué estaba hablando ese tipo", y puedes apostar tu vida a que será la impresión que tendrá de ti por el resto de tu vida .

¿Por qué es eso malo? En el mundo de los negocios, los CEO, los presidentes, etc. buscan personas con las que puedan comunicarse. Sí, es importante tener geeks altamente capaces y técnicamente avanzados en las trincheras que puedan depurar el código C que interactúa con un puerto serie personalizado, pero ¿adivina qué? No les importa Lo único que les importa es que usted tenga el control y que puedan confiar en usted. La forma más segura de entrar en los círculos internos (promoción, dinero, gloria, botín) es la comunicación efectiva con los superiores.

Aquí está el consejo: concéntrese en sus logros con la compañía hasta la fecha. No profundice en las tuercas y tornillos y el cableado: sus ojos se verán vidriosos y usted será solo otro programador para ellos. Dedique tiempo a hablar sobre cosas que puedan entender y haga que sus jefes se alejen de usted con la confianza de decir: "Confío en este hombre para hacer el trabajo".

Una de las cosas más importantes que debe tener en cuenta es no vender en exceso. Presentar demasiada información, especialmente cuando se trata de un proyecto técnico que se presenta al personal no técnico, perderá rápidamente su audiencia. Haga su mejor esfuerzo para asegurarse de que cada tema que discuta sea significativo para el "panorama general".

En cuanto al "panorama general", la administración no técnica generalmente trata de traducir la discusión técnica en términos de costo, tiempo y calidad.

Con eso en mente, puede mencionar las principales decisiones que ha tomado en el proyecto y resaltar el beneficio de esas decisiones en términos de costo, tiempo y / o calidad. Trate de elegir 3-4 decisiones clave y mantenga breve su discusión sobre esas decisiones. Si quieren más información, preguntarán (¡solo prepárate para responder!).

También recomiendo encarecidamente que ejecute su presentación por un amigo no técnico de antemano y obtenga su opinión. Es muy fácil pensar que no eres técnico cuando en realidad todavía estás usando demasiada jerga. Cuanto menos técnico sea tu amigo, mejor. Intenta encontrar a alguien que apenas pueda encender una computadora, y mucho menos programar. Si pueden seguir la esencia de lo que estás diciendo, estás en buena forma.

Descubrí que la mayoría de las personas técnicas (incluyéndome a mí) tienden a ser demasiado técnicas. Lo más probable es que se sorprenda de lo poco que pueden seguir de las cosas técnicas. Por ejemplo, si va a explicar que está reduciendo el riesgo y la incertidumbre, deje muy en claro que todos los proyectos tienen riesgo e incertidumbre, no solo el suyo, porque no es una sorpresa que lo sepan.

Si el riesgo y la incertidumbre provienen de problemas no técnicos y la administración está preocupada, o al menos consciente de ellos, entonces, por supuesto, incluya lo que ha hecho.

Además, enfatice lo positivo, ya que le quitarán al menos tanto de su tono como cualquier cosa que diga. Por lo tanto, no pase mucho tiempo en riesgo e incertidumbre. Si necesita mencionar esto para cubrirse luego de cosas que están fuera de su control, es posible que desee cubrir lo que necesitará de otras personas para completar la tarea a tiempo. Dado que para la mayoría de los proyectos, otras personas que no hacen lo que necesitan de manera oportuna es una posibilidad real, esto reduce la posibilidad de que se les culpe.

Aunque las personas técnicas se darán cuenta de la importancia clave de las características "ocultas", las personas no técnicas no lo harán. Probablemente no pueda hacer más que decir que este proyecto tiene algunos problemas técnicos en los que fue importante dedicar tiempo, como foozbars, whatsits y blah blahs, pero está haciendo todo eso y las cosas están programadas.

Bueno, la descripción de tu proyecto es muy vaga, pero lo intentaré.

Me imagino que la aplicación que creó es un reemplazo de una aplicación diferente o una herramienta para automatizar un proceso que se realizó o aún se realiza manualmente.
Realice un análisis de caso para diferentes escenarios comparando el flujo de trabajo antes y después de la introducción de su software. Cosas que me gustaría ver:

• muestra cómo simplificaste escenarios muy comunes
• muestre versiones, que tenían fallas en la experiencia del usuario y cómo las mejoró. muestre cómo implementó los comentarios que se le dieron.
• muestra algunos números o tablas que comparan el tiempo, la productividad, las características, etc., antes y después. Esto es lo que escucho "Mediante el uso de static noisey more static noiseque disminuyó el tiempo necesario para hacer X por Y% "

Personalmente, no me importa lo que sucede debajo del capó y a sus gerentes les importa aún menos (de hecho, dedico mucho tiempo y disfruto eso, pero sé que no genero valor al meterme en cosas con nadie alguna vez veremos). Un producto de software (componente, biblioteca, marco o aplicación) debe ser utilizable (robusto, rápido, flexible, predecible) y razonablemente preparado para el futuro.

Si te contraté, quiero convencerme de que valoras estas cualidades. Me gustaría que me explique por qué medios intenta lograrlos y por qué eligió esos medios. Quiero ver que usas buenas herramientas. Muéstrame las estadísticas del rastreador de proyectos. Dame una visión general de las metodologías de desarrollo que utilizas, explícalas y sus ventajas brevemente (para cada cosa en la tierra, hay un revestimiento elegante y elegante que lo hace sonar convincente). Muéstrame cómo trabajar contigo será agradable, cómo podrás reaccionar ante mis necesidades siempre cambiantes y cómo la comunicación contigo es muy agradable, porque no solo me arrojas detalles técnicos, sino que también me ofreces soluciones, eso por supuesto se implementan a nivel técnico, pero que usted podrá representar en términos que entiendo y que sean relevantes para mí.

Considere estructurar el preso como una historia de periódico: primero cosas importantes (planee comenzar tarde y cortar temprano), y cubra quién, qué, por qué, cuándo, dónde y cómo. Me gustan las plantillas de una sola página de One Minute Manager, me obligan a simplificar las cosas.

Re estilo de presentación:

• Escríbelo y practica con anticipación. Haz un video tuyo, míralo a la mañana siguiente. Practica de nuevo.
• Vaya a su propio ritmo (algunas personas trabajan mejor si hacen una pausa y hacen girar su café, pero ¿se imaginan un Robin Williams lento?), Pero incorporen algunas pausas y reformulaciones planificadas para puntos importantes. El tiempo ... es difícil, necesita práctica.
• no, no, no hagas algo de PPT te quedas ahí y lees. No hacer un PPT que podría estar allí y leer, porque entonces eso es exactamente lo que va a hacer. Use el PPT para mostrar gráficos, para mostrar solo la palabra clave o dos. Quieres que se centren en ti, no en el preso. La recomendación del 10/10/30 de Kawasaki es buena.
• Practique con anticipación :) para tener algunos ciclos libres para hacer contacto visual, buscar pistas para adaptarse y saber a qué se está cayendo si comienzan a desviarlo.

Re contenido:

• Después del resumen del periódico, cubra los requisitos, e incluya algunos requisitos diferidos (cosas que aprendió pero que no encajan en el alcance del esfuerzo actual) ... incluya algunas cosas que consideró como requisitos al principio, pero que pudo arrojar a medida que usted investigado
• Indique los riesgos clave en términos comerciales: no les importará el riesgo de que "los datos RDF no se compartan bien", les importa que haya considerado el riesgo "el escalado del modelo de datos requerirá un nuevo trabajo si obtenemos datos de clientes cada vez más complejos" y que tiene una respuesta para cada riesgo: cómo sabrán si está ocurriendo el evento de riesgo (cuál es su métrica) y qué ha hecho al respecto, qué podrá hacer el equipo al respecto si sucede.
• Podría ser que un riesgo aún no esté bien definido, se maneje de manera insuficiente o sea catastrófico e inamovible si ocurre, dígalo. Lo lejos que llegues a la pila de riesgos depende del tema (¿juegos médicos?), Por lo que esta es un área donde tu juicio se mostrará.

Subtexto: Has estado trabajando solo y eso siempre da un poco de miedo a la administración, así que asegúrate de incluir indicadores de cómo mantuviste informado a los demás sobre el progreso, cómo aprendiste los requisitos establecidos y los requisitos reales. La gerencia cree que la parte tecnológica es tediosa y necesita personas inteligentes, pero en última instancia siempre es factible ... las empresas rara vez tienen éxito o fracasan en función de las habilidades tecnológicas, y lo saben, así que no intenten impresionarlos con eso, no lo hagan. intenta enseñarles tecnologías. Por el contrario, impresionarles con lo bien que investigan y enmarcan un problema, catalizan una discusión, comunican su progreso.

Las dos preocupaciones principales no requieren nada técnico para la dirección y la puntualidad de su progreso. Obtenga comentarios de otras personas que han estado involucradas. No desea preguntas o inquietudes sorpresa durante la presentación.

Centrarse en la dirección del proyecto. Es posible que necesiten una actualización de lo que se trata todo esto o pueden no haber estado involucrados en ninguna de las planificaciones. Da ejemplos de cómo estás cumpliendo esto.

Presente los hitos del proyecto y su desempeño. Mencione cualquier cambio de especificación que pueda haber alterado la línea de tiempo.

No evite mencionar ningún problema en el proyecto. La clave es cómo has podido superarlos. Esto debería darles una idea de su capacidad para manejar desafíos futuros.

Habla despacio. Estate calmado. No te olvides de respirar.

Si bien puede resaltar las decisiones tomadas, las tecnologías utilizadas y los problemas superados, la alta dirección generalmente se centrará en los problemas finales:

• La implementación de este proyecto, de esta manera, nos ayuda a hacer negocios más rápido, mejor y a un costo menor ...
• El costo estimado de este proyecto es X, los ahorros a corto plazo son Y y los ahorros a largo plazo son Z. (Puede salirse con X siendo mayor que Y, pero es mejor que sea menor que Z)

Algunos de los mejores puntos serán si, mientras trabajaba en el proyecto, encontró formas de aumentar los ahorros o el rendimiento en comparación con el diseño original del proyecto. Podemos esperar / asumir que el proyecto no se iniciaría a menos que la gerencia pensara que iban a ganar / ahorrar dinero ... si aumentara el resultado, eso es aún mejor.

Este tipo de métricas son importantes porque una cosa que están observando es el costo de mantenerlo cerca y preguntarse si el beneficio de hacerlo va a sumar o restar del resultado final.

La regla del 20/10/30 de PowerPoint de Guy Kawasaki sería mi sugerencia si usa PowerPoint en su presentación, ya que los principios que describe son bastante buenos sobre tener solo 10 diapositivas, 20 minutos, etc.

Algunas cosas que también puede considerar:

Entretenerlos No seas payaso, pero un poco de pasión o humor hará que presten más atención.

Disminuye la velocidad de tu discurso y agrega pausas para enfatizar

Haga contacto visual con todos en la sala, no solo con el que toma las decisiones o el jefe, ya que otros también pueden influir en el jefe ...

Trate de contar algunas historias ... Cuénteles sobre cosas divertidas que le sucedieron durante el proyecto, o incluso las malas ... Haga que vivan el estado de ánimo con usted ...

Resumir , resumir, resumir ... Mantenlos siempre contigo ...

Una buena pista: enfatice los problemas técnicos con los que pueden hacer un seguimiento. Hágales sentir que también comprenden la parte técnica. Les dará una buena sensación ...

Use declaraciones como Esa es una buena pregunta tanto como pueda ...

Tu escribiste,

"Una cosa que me preocupa particularmente es encontrar el equilibrio correcto entre los detalles técnicos y no técnicos en la presentación".

Garr Reynolds es uno de los principales expertos en el arte de la presentación, y en una de sus publicaciones de blog de 2005 (aún oportuno), compara los estilos de presentación de Steve Jobs y Bill Gates. Incluso si no lee el artículo perspicaz, puede obtener una pista de las capturas de pantalla que comparan la presentación de diapositivas de Bill y la presentación de diapositivas de Steve sobre qué presentación es más convincente y cuál es más probable que haga que la audiencia se duerma (pista: la que tiene todos los puntos de la viñeta y el estilo exagerado).

http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html

Desde 2005, Bill ha mejorado su estilo de presentación, y Garr cubre las mejoras de Bill en una publicación de blog de 2010.

http://www.presentationzen.com/presentationzen/2010/08/the-naked-transformation-of-bill-gates-the-presenter.html