Come posso fare una buona presentazione a stakeholder importanti e non tecnici?

Alla fine del mese, devo tenere una presentazione di un progetto software sul quale ho lavorato da solo che deciderà sostanzialmente se farò un lavoro a tempo pieno presso l'azienda. Sono un assunto temporaneo per adesso. Darò la mia presentazione al presidente del nostro dipartimento e a due vicepresidenti. Il presidente ha meno conoscenze di programmazione rispetto agli altri due vicepresidenti ed è in definitiva la persona di cui ho bisogno per impressionare.

Quali sono le cose più importanti che devo comunicare nella presentazione? Il mio manager mi ha già detto di enfatizzare le seguenti cose:

1. Sto guidando questo progetto nella giusta direzione e ho il pieno controllo di tutto.
2. Sto completando questo progetto nei tempi previsti.

Su quali altre cose dovrei concentrarmi durante la mia presentazione per farmi apparire il più degno possibile? Sto pensando di evidenziare gli sforzi che sto compiendo a livello di progettazione per ridurre i rischi e le incertezze nel software (due cose che immagino siano molto importanti per i superiori).

Una cosa di cui sono particolarmente preoccupato è trovare il giusto equilibrio tra dettagli tecnici e non tecnici nella presentazione. Se non includo alcun dettaglio tecnico, il presidente del nostro dipartimento non saprà di tutte le funzionalità "nascoste" presenti nel software, ma se sono troppo tecnico, potrebbe perdersi e non capire punti importanti nella presentazione.

Eventuali suggerimenti sarebbero apprezzati.

Conosci il tuo pubblico.

Hai già conquistato la regola numero 1 di parlare in pubblico - hai valutato l'esperienza tecnica delle persone con cui parlerai e la tua presentazione dovrebbe essere adattata di conseguenza. Non preoccuparti di cancellare la tua presentazione con un sacco di tecno-garble e parolacce.

Una grande tentazione di fronte alle grandi parrucche è quella di provare davvero e WOW con il tuo impressionante dizionario di concetti tecnici, teorie e applicazioni. L'idea è, ovviamente, che se hai sufficientemente confuso il capo , allora ovviamente devi essere qualificato per questo lavoro!

Questo funzionerà anche, probabilmente, a breve termine per ottenere la posizione a tempo pieno che stai cercando. Il presidente, tuttavia, si allontanerà sicuramente dall'incontro pensando "Non ho idea di cosa stesse parlando di quel ragazzo" e puoi scommettere sulla tua vita che sarà l'impressione che ha di te per il resto della tua vita .

Perché è così male? Nel mondo degli affari, CEO, presidenti, ecc. Cercano persone con cui possano comunicare. Sì, è importante disporre di geek altamente qualificati e tecnicamente avanzati nelle trincee che possono eseguire il debug del codice C che si interfaccia con una porta seriale personalizzata ma indovinate un po '? A loro non importa. A loro importa solo che tu abbia il controllo e che possano fidarsi di te. Il modo più sicuro nei circoli interni (promozione, denaro, gloria, bottino) è una comunicazione efficace con i superiori.

Ecco il consiglio: concentrati sulle tue realizzazioni con l'azienda fino ad oggi. Non scavare in dadi e bulloni e cablaggi: i loro occhi si glasseranno e sarai solo un altro programmatore per loro. Trascorri del tempo a parlare di cose che possono capire e fai allontanare i tuoi capi da te con la sicurezza di dire: "Mi fido di quest'uomo per portare a termine il lavoro".

Una delle cose più importanti da tenere a mente è quella di non eccedere. Presentare troppe informazioni, specialmente quando si tratta di un progetto tecnico presentato a personale non tecnico, perderà rapidamente il pubblico. Fai del tuo meglio per assicurarti che ogni argomento che discuti sia significativo per il "quadro generale".

Per quanto riguarda il "quadro generale", la gestione non tecnica generalmente cerca di tradurre la discussione tecnica in termini di costi, tempi e qualità.

Tenendo presente ciò, puoi menzionare le principali decisioni che hai preso nel progetto ed evidenziare il vantaggio di tali decisioni in termini di costi, tempi e / o qualità. Prova a scegliere 3-4 decisioni chiave e mantieni breve la discussione di tali decisioni. Se vogliono maggiori informazioni, ti chiederanno (preparati a rispondere!).

Vorrei anche altamente consiglia di eseguire la presentazione da un amico non tecnico prima della mano, e ottenere il loro parere. È molto facile pensare di non essere tecnico quando in realtà stai ancora usando troppi gerghi. Meno tecnico è il tuo amico, meglio è. Prova a trovare qualcuno che riesce a malapena ad accendere un computer, per non parlare del programma. Se riescono a seguire l'essenza di ciò che stai dicendo, sei in buona forma.

Ho scoperto che la maggior parte delle persone tecniche (incluso me stesso) ha la tendenza ad essere troppo tecnica. Le probabilità sono che rimarrai sorpreso da quanto poco delle cose tecniche possono seguire. Ad esempio, se hai intenzione di spiegare che stai riducendo il rischio e l'incertezza, chiarisci che tutti i progetti hanno rischi e incertezze, non solo i tuoi, perché non sono schiacciati che sanno questo.

Se il rischio e l'incertezza derivano da problemi non tecnici e la gestione è preoccupata, o almeno consapevole, di questi, allora includi sicuramente ciò che hai fatto.

Inoltre, sottolinea il positivo, poiché toglieranno almeno tanto dal tuo tono quanto qualsiasi cosa tu dica. Quindi non perdere molto tempo a rischio e incertezza. Se hai bisogno di sollevarlo per coprirti in seguito per cose al di fuori del tuo controllo, potresti voler coprire ciò di cui avrai bisogno da altre persone per completare l'attività nei tempi previsti. Dal momento che per la maggior parte dei progetti altre persone che non fanno ciò di cui hanno bisogno in modo tempestivo è una possibilità reale, ciò riduce la possibilità che tu ne sia incolpato.

Anche se i tecnici capiranno l'importanza chiave delle funzionalità "under the hood", i non tecnici non lo faranno. Probabilmente non puoi fare altro che dire che questo progetto ha alcuni problemi tecnici su cui era importante trascorrere del tempo, come foozbar, whatsits e blah blahs, ma stai facendo tutto questo e le cose sono nei tempi previsti.

Bene, la descrizione del tuo progetto è molto vaga, ma ci proverò.

Immagino che l'applicazione che hai creato sia una sostituzione a un'altra applicazione o uno strumento per automatizzare un processo che è stato o è ancora eseguito manualmente.
Fai un'analisi del caso per diversi scenari confrontando il flusso di lavoro prima e dopo l'introduzione del tuo software. Le cose che vorrei vedere:

• mostra come hai semplificato scenari molto comuni
• mostra le versioni che presentavano difetti nell'esperienza utente e come le hai migliorate. mostra come hai implementato il feedback che ti è stato dato.
• mostra alcuni numeri o tabelle confrontando tempo, produttività, caratteristiche, ecc. prima e dopo. Ecco cosa sento "Usando static noisee more static noiseabbiamo ridotto il tempo necessario per fare X di Y% "

Personalmente, non mi importa di quello che sta succedendo e ai tuoi manager importa ancora di meno (in effetti ci trascorro molto tempo e mi diverto, ma so che non creo valore scherzando con nessuno vedrà mai). Un prodotto software (componente, libreria, framework o applicazione) deve essere utilizzabile (robusto, veloce, flessibile, prevedibile) e ragionevolmente a prova di futuro.

Se ti ho assunto, voglio essere convinto che apprezzi queste qualità. Vorrei che mi spiegassi con quali mezzi cerchi di raggiungerli e perché hai scelto quei mezzi. Voglio vedere che usi buoni strumenti. Mostrami le statistiche del tracker dei progetti. Dammi una panoramica delle metodologie di sviluppo che usi, spiegale brevemente e i loro vantaggi (per ogni cosa sulla terra, c'è una fodera fantasiosa che fa sembrare convincente). Mostrami come lavorare con te sarà piacevole, come sarai in grado di reagire alle mie esigenze in continua evoluzione e come la comunicazione con te è molto piacevole, perché non mi dai solo dettagli tecnici, ma offri soluzioni, ovviamente sono implementati a livello tecnico, ma che sarai in grado di rappresentare in termini che comprendo e che sono rilevanti per me.

Considera di strutturare il preso come una storia di un giornale: cose importanti prima (pianifica di iniziare tardi e tagliare presto), e coprire chi, cosa, perché, quando, dove e come. Mi piacciono i modelli a pagina singola di One Minute Manager, mi costringono a far bollire bene le cose.

Ri stile di presentazione:

• Scrivilo e fai pratica in anticipo. Fai un video di te stesso, guardalo la mattina dopo. Esercitati di nuovo.
• Segui i tuoi ritmi (alcune persone lavorano meglio se si fermano e fanno roteare il caffè, ma riesci a immaginare un Robin Williams lento?), Ma incorporano alcune pause e riaffermazioni pianificate per punti importanti. Il tempismo ... è difficile, ha bisogno di pratica.
• no, no, non fare un po 'di PPT che stai lì e leggi. Non fare un PPT che potresti stare lì e leggere, perché è esattamente quello che farai. Utilizzare il PPT per visualizzare la grafica, per mostrare solo la parola chiave o due. Li vuoi concentrati su di te, non sul preso. La raccomandazione Kawasaki del 20/10/30 è buona.
• Esercitati in anticipo :) in modo da avere alcuni cicli di riserva per stabilire un contatto visivo, cercare gli indizi a cui adattarti e quindi sai a cosa stai perdendo se iniziano a trascinarti fuori pista.

Ri contenuto:

• Dopo il riepilogo del giornale, copri i requisiti e includi alcuni requisiti differiti (cose che hai imparato ma che non rientrano nello scopo dello sforzo attuale) ... includi alcune cose che inizialmente hai considerato come requisiti ma che sei riuscito a perdere mentre indagato.
• Dichiarare i rischi chiave in termini commerciali - non si preoccuperanno del rischio che "i dati RDF non si frammentino bene", si preoccupano che tu abbia considerato il rischio "il ridimensionamento del modello di dati richiederà una rilavorazione se otteniamo dati dei clienti sempre più complessi" e che hai una risposta per ogni rischio: come faranno a sapere se si sta verificando l'evento a rischio (qual è la tua metrica) e cosa hai già fatto al riguardo, cosa sarà in grado di fare il team al riguardo se dovesse accadere.
• È possibile che un rischio non sia ancora ben definito, sia gestito in modo inadeguato o sia catastrofico e non risolvibile se si verifica - ditelo. Quanto lontano vai nella pila del rischio dipende dall'argomento (giochi medici?), Quindi questa è un'area in cui il tuo giudizio verrà mostrato.

Sottotesto: hai lavorato da solo e questo è sempre un po 'spaventoso per la gestione, quindi assicurati di includere indicatori su come hai tenuto gli altri informati sui progressi, su come hai appreso i requisiti dichiarati e reali. Il management ritiene che la parte tecnologica sia noiosa e abbia bisogno di persone intelligenti, ma alla fine è sempre fattibile ... le aziende raramente hanno successo o falliscono in base alle competenze tecnologiche, e lo sanno, quindi non sforzarti troppo per impressionarli, non farlo cerca di insegnare loro le tecnologie. Piuttosto, impressionali per quanto riesci a indagare e inquadrare un problema, catalizzare una discussione, comunicare i tuoi progressi.

Le due principali preoccupazioni non richiedono nulla di tecnico per la direzione e la tempestività dei tuoi progressi. Ricevi feedback da altre persone che sono state coinvolte. Non vuoi domande o dubbi a sorpresa durante la presentazione.

Concentrati sulla direzione del progetto. Potrebbero aver bisogno di un ripasso di cosa si tratta o potrebbero non essere stati coinvolti in nessuna delle pianificazioni. Fornisce esempi di come lo stai soddisfando.

Presenta le pietre miliari del progetto e la tua performance. Indica eventuali modifiche alle specifiche che potrebbero aver modificato la sequenza temporale.

Non evitare di menzionare eventuali problemi nel progetto. La chiave è come sei riuscito a superarli. Ciò dovrebbe fornire loro informazioni sulla capacità di gestire le sfide future.

Parla lentamente. Stai calmo. Non dimenticare di respirare.

Sebbene sia possibile evidenziare le decisioni prese, le tecnologie utilizzate e i problemi superati, i vertici aziendali si concentreranno in genere su questioni di fondo:

• L'implementazione di questo progetto, in questo modo, ci aiuta a fare affari più velocemente, meglio e ad un costo inferiore ...
• Il costo stimato di questo progetto è X, i risparmi a breve termine sono Y e i risparmi a lungo termine sono Z. (È possibile cavarsela con X maggiore di Y, ma è meglio inferiore a Z)

Alcuni dei punti migliori saranno se mentre stavi lavorando al progetto hai trovato modi per aumentare i risparmi o le prestazioni rispetto al progetto originale. Possiamo sperare / presumere che il progetto non sarebbe stato avviato se la direzione non avesse pensato che avrebbero fatto / risparmiato denaro ... se si aumentasse la linea di fondo, sarebbe ancora meglio.

Questi tipi di metriche sono importanti perché una cosa che stanno osservando è il costo di tenerti in giro, e chiedersi se il vantaggio di farlo aumenterà o sottrarrà dalla linea di fondo.

La regola del 10/10/30 di PowerPoint di Guy Kawasaki sarebbe il mio suggerimento se usi PowerPoint nella tua presentazione poiché i principi che delinea sono abbastanza buoni per avere solo 10 diapositive, 20 minuti, ecc.

Alcune cose che potresti anche considerare:

Intrattenili. Non essere un clown, ma un po 'di passione o umorismo li farà prestare più attenzione.

Rallenta il tuo discorso e aggiungi pause per dare enfasi.

Stabilisci un contatto visivo con tutti nella stanza, non solo con il decisore o il capo, poiché anche altri possono influenzare il capo ...

Prova ad avere delle storie ... Raccontagli di cose divertenti che ti sono successe durante il progetto, o anche di quelle cattive ... Falli vivere l'umore con te ...

Riassumi , riassumi, riassumi ... Tienili sempre con te ...

Un buon suggerimento: sottolinea i problemi tecnici a cui possono dare seguito .. Fagli sentire che capiscono anche la parte tecnica .. Darà loro una buona sensazione ...

Usa dichiarazioni come questa è una buona domanda il più possibile ...

Hai scritto,

"Una cosa di cui sono particolarmente preoccupato è trovare il giusto equilibrio tra dettagli tecnici e non tecnici nella presentazione."

Garr Reynolds è uno dei massimi esperti nell'arte della presentazione e, in uno dei suoi post sul blog del 2005 (ancora attuale), confronta gli stili di presentazione di Steve Jobs e Bill Gates. Anche se non leggi l'articolo approfondito, puoi ottenere un suggerimento dagli screenshot confrontando la presentazione di Bill e la presentazione di Steve su quale presentazione è più avvincente e quale è più probabile che metta a dormire il pubblico (suggerimento: quello con tutti i punti elenco e lo stile eccessivo).

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

Dal 2005, Bill ha migliorato il suo stile di presentazione e Garr illustra i miglioramenti di Bill in un post sul blog del 2010.

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