Como posso fazer uma boa apresentação para partes interessadas não técnicas importantes?

No final do mês, tenho que fazer uma apresentação sobre um projeto de software no qual estou trabalhando sozinho, que basicamente decidirá se vou ou não conseguir um emprego em tempo integral na empresa que sou contratado temporariamente para agora. Darei minha apresentação ao presidente de nosso departamento e a dois vice-presidentes. O presidente tem menos conhecimento de programação do que os outros dois vice-presidentes e é, em última análise, a pessoa que preciso impressionar.

Quais são as coisas mais importantes que preciso transmitir na apresentação? Meu gerente já me disse para enfatizar as seguintes coisas:

1. Estou dirigindo este projeto na direção certa e estou no controle total de tudo.
2. Estou concluindo este projeto dentro do cronograma.

Em que outras coisas devo me concentrar durante minha apresentação para parecer o mais digno de contratar possível? Estou pensando em destacar os esforços que estou fazendo no nível de design para reduzir riscos e incertezas no software (duas coisas que imagino serem muito importantes para os superiores).

Uma coisa que me preocupa particularmente é encontrar o equilíbrio certo entre detalhes técnicos e não técnicos na apresentação. Se eu não incluir nenhum detalhe técnico, o presidente do nosso departamento não saberá sobre todos os recursos "secretos" do software, mas se eu for técnico demais, ele poderá se perder e não entender. pontos importantes na apresentação.

Qualquer dica seria apreciada.

Conheça o seu público.

Você já conquistou a regra número 1 de falar em público - avaliou a experiência técnica das pessoas com quem estará falando e sua apresentação deve ser adaptada de acordo. Não se preocupe em exibir sua apresentação com muito techno-garble e leet-speak.

A grande tentação ao enfrentar os grandes cabeleiras é realmente tentar e WOW -los com seu dicionário impressionante de conceitos técnicos, teorias e aplicações. A ideia é, é claro, que se você confundiu suficientemente o chefe , é claro que deve estar qualificado para este trabalho!

Isso até funcionará, provavelmente, no curto prazo para obter a posição de tempo integral que você procura. O presidente, no entanto, sem dúvida se afastará da reunião pensando: "Não faço ideia do que esse cara estava falando", e você pode apostar na sua vida que será a impressão que ele tem de você pelo resto da sua vida .

Por que isso é ruim? No mundo dos negócios, CEOs, presidentes etc. procuram pessoas com quem possam se comunicar. Sim, é importante ter nerds tecnicamente avançados e altamente capazes nas trincheiras que podem depurar o código C que faz interface com uma porta serial personalizada, mas adivinhem? Eles não se importam. Todos eles se preocupam é que você está no controle e que eles podem confiar em você. O caminho mais seguro para os círculos internos (promoção, dinheiro, glória, despojo) é a comunicação eficaz com os superiores.

Aqui está o conselho: concentre-se em suas realizações com a empresa até o momento. Não mexa nas porcas, parafusos e cabos - os olhos deles brilharão e você será apenas mais um programador para eles. Passe um tempo conversando sobre coisas que eles podem entender e que seus chefes se afastem de você com a confiança necessária para dizer: "Eu confio neste homem para fazer o trabalho".

Uma das coisas mais importantes que você deve ter em mente é não exagerar. A apresentação de muitas informações, especialmente quando se trata de um projeto técnico apresentado a pessoal não técnico, perderá rapidamente seu público. Faça o possível para garantir que todos os tópicos discutidos sejam significativos para o "quadro geral".

Quanto ao "quadro geral", o gerenciamento não técnico geralmente tenta traduzir a discussão técnica em termos de custo, tempo e qualidade.

Com isso em mente, você pode mencionar as principais decisões que tomou no projeto e destacar o benefício dessas decisões em termos de custo, tempo e / ou qualidade. Tente escolher de 3 a 4 decisões-chave e faça uma breve discussão sobre essas decisões. Se eles quiserem mais informações, perguntarão (apenas esteja preparado para responder!).

Eu também altamente recomendável que você execute a sua apresentação por um amigo não-técnico antes da mão, e obter a sua opinião. É muito fácil pensar que você está sendo não técnico quando, na verdade, você ainda está usando muito jargão. Quanto menos técnico for seu amigo, melhor. Tente encontrar alguém que mal consiga ligar um computador e muito menos programar. Se eles podem seguir a essência do que você está dizendo, você está em boa forma.

Descobri que a maioria das pessoas técnicas (inclusive eu) tem uma tendência a ser muito técnica. As probabilidades são de que você ficará surpreso com o pouco do material técnico que elas podem seguir. Por exemplo, se você vai explicar que está reduzindo riscos e incertezas, deixe bem claro que todos os projetos têm riscos e incertezas, não apenas os seus, porque não é um slam dunk que eles sabem disso.

Se o risco e a incerteza derivam de problemas não técnicos e de gerenciamento, ou pelo menos cientes deles, então inclua de qualquer maneira o que você fez.

Além disso, enfatize o positivo, pois eles tiram pelo menos tanto do seu tom quanto qualquer coisa que você diz. Portanto, não gaste muito tempo com riscos e incertezas. Se você precisar trazer isso à tona mais tarde, para coisas fora do seu controle, convém cobrir o que você precisará de outras pessoas para concluir a tarefa dentro do prazo. Como para a maioria dos projetos, outras pessoas que não fazem o que precisam em tempo hábil são uma possibilidade real, isso reduz a chance de você ser responsabilizado por isso.

Embora o pessoal técnico perceba a importância fundamental dos recursos "ocultos", o pessoal não técnico não. Você provavelmente não pode fazer mais do que dizer que este projeto tem alguns problemas técnicos importantes para gastar tempo, como foozbars, whatsits e blá-blá, mas você está fazendo tudo isso e as coisas estão dentro do cronograma.

Bem, a descrição do seu projeto é muito vaga, mas vou tentar.

Eu imagino que o aplicativo que você criou seja um substituto para um aplicativo diferente ou uma ferramenta para automatizar um processo que foi ou ainda é realizado manualmente.
Faça uma análise de caso para diferentes cenários, comparando o fluxo de trabalho antes e depois da introdução do seu software. Coisas que eu gostaria de ver:

• mostre como você simplificou cenários muito comuns
• mostre versões com falhas na experiência do usuário e como você as aprimorou. mostre como você implementou o feedback fornecido a você.
• mostre alguns números ou tabelas comparando tempo, produtividade, recursos etc. antes e depois. Aqui está o que eu ouço "Com o uso de static noisee more static noisenós diminuiu o tempo necessário para fazer X em Y% "

Pessoalmente, eu não ligo para o que está acontecendo sob o capô e seus gerentes se importam ainda menos (na verdade, passo muito tempo nisso e aproveito isso, mas sei que não gero valor mexendo com coisas que ninguém nunca verá). Um produto de software (componente, biblioteca, estrutura ou aplicativo) precisa ser utilizável (robusto, rápido, flexível, previsível) e razoavelmente à prova de futuro.

Se eu te contratei, quero me convencer de que você valoriza essas qualidades. Gostaria que você me explicasse por que meios você tenta alcançá-los e por que escolheu esses meios. Eu quero ver que você usa boas ferramentas. Mostre-me as estatísticas do rastreador de projetos. Dê-me uma visão geral das metodologias de desenvolvimento que você usa, explique-as e suas vantagens brevemente (para quase tudo no mundo, existe um forro de dois clichês sofisticados que faz parecer convincente). Mostre-me como trabalhar com você será agradável, como será capaz de reagir às minhas necessidades em constante mudança e como a comunicação com você é muito agradável, porque você não apenas lança detalhes técnicos para mim, mas oferece soluções, é claro são implementados em um nível técnico, mas que você poderá representar em termos que eu entendo e que sejam relevantes para mim.

Considere estruturar o preso como uma matéria de jornal: coisas importantes primeiro (planeje começar tarde e ser cortado cedo) e cubra quem, o que, por que, quando, onde e como. Gosto dos modelos de página única do One Minute Manager, eles me forçam a simplificar as coisas.

Re estilo de apresentação:

• Faça um script e pratique com antecedência. Faça um vídeo de si mesmo, assista na manhã seguinte. Pratique novamente.
• Vá no seu próprio ritmo (algumas pessoas trabalham melhor se fizerem uma pausa e agitam o café, mas você pode imaginar um lento Robin Williams?), Mas incorpore algumas pausas e reformulações planejadas para pontos importantes. Momento ... é difícil, precisa de prática.
• Não faça, não faça PPT, você fica lá e lê. Não faça um PPT que você poderia estar lá e ler, porque então isso é exatamente o que você vai fazer. Use o PPT para exibir gráficos, para mostrar apenas a palavra-chave ou duas. Você os quer focados em você, não no preso. A recomendação de 10/20/30 para a Kawasaki é boa.
• Pratique com antecedência :) para que você tenha alguns ciclos de sobra para fazer contato visual, procurando pistas para se adaptar e para saber o que está perdendo se eles começarem a tirar você dos trilhos.

Re conteúdo:

• Após o resumo do jornal, cubra os requisitos - e inclua alguns requisitos diferidos (coisas que você aprendeu, mas não se enquadram no escopo do esforço atual) ... inclua algumas coisas que você considerou como requisitos no início, mas que foram capazes de se livrar de você investigado.
• Declare os principais riscos em termos de negócios - eles não se importam com o risco de que "os dados RDF não sejam muito bons", eles se preocupam com o risco considerado "o dimensionamento do modelo de dados exigirá retrabalho se obtivermos dados de clientes cada vez mais complexos" e que você tem uma resposta para todos os riscos: como eles saberão se o evento de risco está acontecendo (qual é a sua métrica) e o que você já fez sobre isso, o que a equipe poderá fazer se acontecer.
• Pode ser que um risco ainda não esteja bem definido, seja mal tratado ou seja catastrófico e não corrigível se ocorrer - diga-o. Até que ponto você entra na pilha de riscos depende do assunto (jogos médicos?), Portanto, essa é uma área em que seu julgamento será mostrado.

Subtexto: você está trabalhando sozinho e isso é sempre um pouco assustador para o gerenciamento - portanto, inclua indicadores de como você manteve os outros informados sobre o progresso, como aprendeu os requisitos declarados e os reais. A gerência acredita que a parte tecnológica é tediosa e precisa de pessoas inteligentes, mas é sempre viável ... as empresas raramente conseguem ou fracassam com base nas habilidades tecnológicas, e sabem disso; portanto, não tente impressioná-las com isso, não tente ensinar-lhes tecnologias. Em vez disso, imprima-os com o quão bem você investiga e enquadra um problema, catalisa uma discussão, comunica seu progresso.

As duas principais preocupações não exigem nada de técnico para a direção e a pontualidade do seu progresso. Obtenha feedback de outras pessoas envolvidas. Você não deseja nenhuma pergunta ou preocupação surpresa durante a apresentação.

Concentre-se na direção do projeto. Eles podem precisar de uma revisão sobre o que é isso tudo ou podem não estar envolvidos em nenhum planejamento. Dá exemplos de como você está cumprindo isso.

Apresente marcos do projeto e seu desempenho. Mencione quaisquer alterações nas especificações que possam ter alterado a linha do tempo.

Não evite mencionar problemas no projeto. A chave é como você conseguiu superá-los. Isso deve fornecer informações sobre sua capacidade de lidar com desafios futuros.

Fale devagar. Fique calmo. Não esqueça de respirar.

Embora você possa destacar as decisões tomadas, as tecnologias usadas e os problemas superados, a alta gerência normalmente estará focada nos problemas financeiros:

• A implementação deste projeto, dessa maneira, nos ajuda a fazer negócios de forma mais rápida, melhor e com menor custo ...
• O custo estimado deste projeto é X, as economias de curto prazo são Y e as economias de longo prazo são Z. (Você pode se safar com X sendo maior que Y, mas é melhor que seja menor que Z)

Alguns dos melhores pontos serão se você estivesse trabalhando no projeto e encontrou maneiras de aumentar a economia ou o desempenho quando comparado ao design original do projeto. Podemos esperar / supor que o projeto não seria iniciado, a menos que a gerência pensasse que eles iriam ganhar / economizar dinheiro ... se você aumentasse ainda mais o resultado final.

Esses tipos de métricas são importantes porque uma coisa que eles procuram é o custo de mantê-lo por perto, e se perguntando se o benefício de fazê-lo irá adicionar ou subtrair da linha de fundo.

A regra do PowerPoint de 20/10/30 de Guy Kawasaki seria minha sugestão se você usar o PowerPoint em sua apresentação, pois os princípios que ele descreve são muito bons em ter apenas 10 slides, 20 minutos, etc.

Algumas coisas que você também pode considerar:

Divirta-os. Não seja um palhaço, mas um pouco de paixão ou humor os fará prestar mais atenção.

Diminua a velocidade do discurso e adicione pausas para enfatizar.

Faça contato visual com todos na sala, não apenas com o tomador de decisão ou o chefe, já que outros podem influenciar o chefe também ...

Tente ter algumas histórias . Conte-lhes coisas engraçadas que aconteceram com você durante o projeto, ou mesmo as ruins. Faça com que vivam o clima com você ...

Resuma , resuma, resuma ... Sempre mantenha-os com você ...

Uma boa dica: enfatize os problemas técnicos com os quais eles podem acompanhar. Faça com que sintam que também compreendem a parte técnica. Isso lhes dará uma boa sensação ...

Use declarações como Essa é uma boa pergunta , tanto quanto você pode ...

Você escreveu,

"Uma coisa que me preocupa particularmente é encontrar o equilíbrio certo entre detalhes técnicos e não técnicos na apresentação".

Garr Reynolds é um dos principais especialistas na arte da apresentação e, em um de seus posts de 2005 (ainda oportuno), ele compara os estilos de apresentação de Steve Jobs e Bill Gates. Mesmo que você não leia o artigo, você pode obter uma dica nas capturas de tela comparando a apresentação de slides de Bill e a apresentação de Steve sobre qual apresentação é mais atraente e qual é mais provável que faça o público dormir (dica: aquela com todos os marcadores e estilo exagerado).

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

Desde 2005, Bill melhorou seu estilo de apresentação e Garr aborda as melhorias de Bill em um post de 2010.

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