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

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 techno-garble e leet-speak.

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

Funzionerà anche, probabilmente, a breve termine per ottenere la posizione a tempo pieno che stai cercando. Il presidente, tuttavia, uscirà indubbiamente dall'incontro pensando: "Non ho idea di cosa stia parlando quel ragazzo", e puoi scommettere che la tua vita sarà l'impressione che ha di te per il Resto della tua vita .

Perché è così male? Nel mondo degli affari, amministratori delegati, presidenti, ecc. Cercano persone con le quali possono comunicare. Sì, è importante avere geek altamente capaci e tecnicamente avanzati nelle trincee che possono eseguire il debug del codice C che si interfaccia con una porta seriale personalizzata, ma indovina un po '? A loro non importa Tutto ciò a cui tengono è che hai il controllo e che possono fidarsi di te. La via più sicura nei circoli interni (promozione, denaro, gloria, rovina) è una comunicazione efficace con i superiori.

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

Una delle cose più importanti che dovresti tenere a mente è non sovvertire. 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 in genere cerca di tradurre la discussione tecnica in termini di costi, tempi e qualità.

Tenendo questo a mente, puoi citare le decisioni importanti che hai preso nel progetto e evidenziare i vantaggi di tali decisioni in termini di costi, tempi e / o qualità. Prova a scegliere 3-4 decisioni chiave e mantieni breve la tua discussione su queste decisioni. Se vogliono ulteriori informazioni, chiederanno (preparati solo a rispondere!).

Vorrei anche altamente consigliare di eseguire la presentazione da parte di un amico non tecnico prima della mano e di ottenere la sua opinione. È molto facile pensare di non essere tecnici, mentre in realtà usi ancora troppo gergo. Meno tecnico è il tuo amico, meglio è. Prova a trovare qualcuno che riesca a malapena a 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) tende ad essere troppo tecnica. Le probabilità sono che sarete sorpresi di quanto poco materiale tecnico possano seguire. Ad esempio, se stai per spiegare che stai riducendo il rischio e l'incertezza, chiarisci chiaramente che tutti i progetti hanno rischi e incertezza, non solo i tuoi, perché non è uno schifo che loro lo sanno.

Se il rischio e l'incertezza derivano da problemi non tecnici e la gestione è interessata, o almeno consapevole, di essi, allora in ogni caso includi ciò che hai fatto.

Inoltre, enfatizza il positivo, dal momento che toglieranno almeno tanto dal tuo tono quanto qualsiasi cosa tu dica. Quindi non passare molto tempo a rischio e incertezza. Se è necessario portare questo per coprirsi più tardi per cose al di fuori del proprio controllo, si potrebbe voler coprire ciò che sarà necessario da altre persone per completare l'attività nei tempi previsti. Dal momento che per la maggior parte dei progetti altre persone non stanno facendo ciò di cui hanno bisogno in modo tempestivo è una possibilità reale, questo riduce la possibilità che ne venga incolpata.

Sebbene le persone tecniche comprenderanno l'importanza fondamentale delle funzionalità "sotto il cofano", le persone non tecniche non lo faranno. Probabilmente non puoi fare altro che affermare che questo progetto ha alcune questioni tecniche che sono importanti per trascorrere del tempo, come gli foozbar, i whatsits e i blah blah, ma stai facendo tutto questo e le cose sono in programma.

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

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

• mostra come hai semplificato gli scenari molto comuni
• mostra le versioni, che presentavano difetti nell'esperienza utente e in che modo li hai migliorati. mostra come hai implementato il feedback che ti è stato dato.
• mostra alcuni numeri o tabelle che confrontano tempo, produttività, caratteristiche, ecc. prima e dopo. Ecco cosa sento "Con l'uso di static noise e more static noise abbiamo ridotto il tempo necessario per fare X di Y% "

Personalmente, non mi interessa per quello che sta succedendo sotto i cofani ei tuoi manager si preoccupano ancora di meno (in effetti passo molto tempo su questo e mi diverto, ma so che non creo valore facendo scherzi con cose che 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 tu mi spiegassi in che modo cerchi di raggiungerli e perché hai scelto quei mezzi. Voglio vedere che usi buoni strumenti. Fammi vedere le statistiche del tracker dei progetti. Fammi una panoramica delle metodologie di sviluppo che utilizzi, spiegali brevemente e i loro vantaggi (per ogni cosa sulla terra, c'è una fodera di fantasia e fantasia che lo rende convincente). Mostrami come lavorare con te sarà piacevole, come sarai in grado di reagire alle mie esigenze in continua evoluzione e in che modo la comunicazione con te è molto piacevole, perché non mi metti solo i dettagli tecnici, ma offri soluzioni, naturalmente sono implementate a livello tecnico, ma tu sarai in grado di rappresentare in termini che comprendo e che sono rilevanti per me.

Considera la strutturazione del preso come una storia di un giornale: cose importanti prima (piano per iniziare in ritardo, e venire tagliati 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 sì che le cose si riducano molto bene.

Stile presentazione:

• Scriptalo e fai pratica in anticipo. Fai un video di te stesso, guardalo il mattino dopo. Esercitati di nuovo.
• Vai al tuo ritmo (alcune persone lavorano meglio se mettono in pausa e fanno girare il caffè, ma riesci a immaginare un lento Robin Williams?), ma incorporano alcune pause e riforme pianificate per punti importanti. Tempismo ... è difficile, richiede pratica.
• non farlo, non farlo, non creare un PPT che stai lì e leggi. Non fare un PPT potresti stare lì e leggere, perché è esattamente quello che farai. Usa 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 10/20/30 è buona.
• Fai pratica prima del tempo :) quindi hai un paio di cicli di ricambio per stabilire un contatto visivo, cercando gli indizi per adattarti, e così sai cosa stai perdendo se iniziano a trascinarti fuori pista.

Nuovo contenuto:

• Dopo il riepilogo del giornale, includi i requisiti e includi alcuni requisiti posticipati (cose che hai appreso ma non rientrano nello scopo dello sforzo attuale) ... includi alcune cose che hai considerato come requisiti all'inizio, ma che sono stati in grado di versare come hai studiato.
• Rischi principali dello stato in termini aziendali - non si preoccupano del rischio che "i dati RDF non si scheggino bene", si preoccupano che tu abbia considerato il rischio "il ridimensionamento del modello di dati richiederà una rielaborazione se i dati dei clienti diventano sempre più complessi "e che tu hai una risposta per ogni rischio: come faranno a sapere se l'evento di rischio sta accadendo (qual è la tua metrica) e cosa hai già fatto al riguardo, cosa potrà fare il team in caso affermativo.
• Potrebbe essere che un rischio non sia ancora ben definito, che sia sottodimensionato, o che sia catastrofico e non verificabile se si verifica - dillo. Quanto lontano vai nella pila del rischio dipende dall'argomento (giochi medici?) Quindi questa è un'area in cui il tuo giudizio mostrerà.

Sottotesto: hai lavorato da solo e questo è sempre un po 'inquietante 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 quelli reali. Il management crede che la parte tecnologica sia noiosa e abbia bisogno di persone intelligenti, ma alla fine è sempre fattibile ... le aziende raramente riescono o falliscono in base alle competenze tecnologiche, e lo sanno, quindi non tentare troppo di impressionarle con questo, non farlo prova ad insegnare loro le tecnologie. Piuttosto, impressionali con la tua capacità di investigare e inquadrare un problema, catalizzare una discussione, comunicare i tuoi progressi.

Le due maggiori 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 nessuna domanda o preoccupazione a sorpresa durante la presentazione.

Concentrati sulla direzione del progetto. Potrebbero aver bisogno di un ripasso su cosa sia tutto questo o potrebbero non essere stati coinvolti in alcuna pianificazione. Fornisce esempi di come si sta realizzando questo.

Presenti pietre miliari del progetto e della tua performance. Indica eventuali modifiche alle specifiche che potrebbero aver alterato la sequenza temporale.

Non evitare di menzionare alcun problema nel progetto. La chiave è come sei riuscito a superarli. Questo dovrebbe dare loro un'idea della tua 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, la gestione superiore si concentrerà in genere sui problemi di linea 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. (Puoi farcela con X essere maggiore di Y, ma è meglio che sia inferiore a Z)

Alcuni dei punti migliori saranno se, mentre stavi lavorando al progetto, hai trovato dei modi per aumentare i risparmi o le prestazioni rispetto al progetto originale. Possiamo sperare / presumere che il progetto non verrà avviato a meno che la direzione non pensi che stiano per fare / risparmiare denaro ... se aumenti la linea di fondo è ancora meglio.

Questi tipi di metriche sono importanti perché una cosa che guardano è il costo di tenerti in giro, e chiedersi se il vantaggio di farlo sta andando a sommare o sottrarre dalla linea di fondo.

La regola di PowerPoint 10/20/30 da Guy Kawasaki sarebbe il mio suggerimento se utilizzi PowerPoint nella tua presentazione in quanto i principi che delinea sono piuttosto buoni con solo 10 diapositive, 20 minuti, ecc.

Alcune cose che potresti anche considerare:

Intrattenerli. Non essere un pagliaccio, ma un po 'di passione o umorismo farà sì che prestino più attenzione.

Rallenta il discorso e aggiungi pause per l'enfasi.

Fai contatto visivo con tutti nella stanza, non solo il decisore o il capo, poiché altri potrebbero avere influenza anche sul capo ...

Cerca di avere alcune storie .. di loro delle cose divertenti che ti sono accadute durante il progetto, o anche di quelle cattive .. Falli vivere l'atmosfera con te ...

Riepiloga , riepiloga, riepiloga ... Tienili sempre con te ...

Un buon suggerimento: sottolinea i problemi tecnici che possono seguire .. Falli sentire che capiscono anche la parte tecnica .. Darà loro il buon feeling ...

Utilizza affermazioni come Questa è una buona domanda il più possibile ...

Hai scritto,

"One thing I'm particularly worried about is finding the right balance between technical and non-technical details in the presentation."

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

link

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

link