重要な非技術関係者に適切なプレゼンテーションを行うにはどうすればよいですか？

月末に、私が自分で取り組んでいるソフトウェアプロジェクトについてプレゼンテーションをしなければなりません。これは基本的に、私が一時的に雇っている会社でフルタイムの仕事を得るかどうかを決定します。今のところ。私の部門の社長と2人のVPにプレゼンテーションを行います。社長は他の2人のVPよりもプログラミングの知識が少なく、最終的に私が感心する必要がある人物です。

プレゼンテーションで伝える必要がある最も重要なことは何ですか？マネージャーから次のことを強調するように言われました。

1. 私はこのプロジェクトを正しい方向に進めており、すべてを完全にコントロールしています。
2. 私はこのプロジェクトを予定通り完了しています。

プレゼンテーション中に、他のどの点に焦点を当てて、自分を可能な限り雇用価値があるように見せるべきですか？ソフトウェアのリスクと不確実性を減らすために、設計レベルで行っている努力を強調することを考えています（私が想像する2つのことは、上級者にとって非常に重要です）。

私が特に心配していることの1つは、プレゼンテーションで技術的詳細と非技術的詳細の適切なバランスを見つけることです。技術的な詳細を含めない場合、部門の社長はソフトウェアに含まれる「内部」機能のすべてを知ることはできませんが、私が技術的すぎると、彼は迷子になり、理解できなくなる可能性がありますプレゼンテーションの重要なポイント。

任意のヒントをいただければ幸いです。

あなたの聴衆を知っています。

あなたはすでに人前で話すことの一番のルールを征服しました-あなたはあなたが話す人の技術的専門知識を評価しました、そしてあなたのプレゼンテーションはそれに応じて調整されるべきです。たくさんのテクノ・ガーブルとリート・スピークでプレゼンテーションを見せることを心配しないでください。

大きなかつらが直面する大きな誘惑は本当にしようとするとしているWOW技術的な概念、理論、およびアプリケーションのあなたの印象的な辞書でそれらを。あなたは十分に混乱してしまった場合という当然のアイデアビーイング、ボスを、そしてもちろん、あなたがこの仕事のために修飾する必要があります！

これは、おそらく、あなたが探しているフルタイムのポジションを取得するという短期間で機能します。しかし、大統領は間違いなく「あの男が何について話しているのかわからない」と考えて会議から離れることになり、残りの人生で彼があなたに抱いている印象であるあなたの人生を賭けることができます。

なぜそれが悪いのですか？ビジネスの世界では、CEO、社長などは、彼らがコミュニケーションできる人を探します。はい、カスタムシリアルポートとのインターフェイスであるCコードをデバッグできるが、何を推測できるのか、非常に有能で技術的に高度なオタクがいることが重要です。彼らは気にしません。彼らが気にするのは、あなたがコントロールしていることと、彼らがあなたを信頼できることです。内輪への最も確実な方法（昇進、金銭、栄光、略奪）は、上位者との効果的なコミュニケーションです。

ここにアドバイスがあります：これまでの会社でのあなたの成果に焦点を合わせてください。ナットとボルトと配線を掘り下げないでください-彼らの目はかすかに見えるので、あなたは彼らの単なるもう一人のプログラマーになるでしょう。彼らが理解できることについて話し、あなたの上司に「仕事を成し遂げるためにこの男を信頼します」と自信を持ってあなたから離れてもらいましょう。

あなたが心に留めておくべき最も重要なことの一つは、過剰販売しないことです。特に技術プロジェクト以外の人に提示される技術プロジェクトに関しては、あまりにも多くの情報を提示すると、すぐに視聴者を失います。議論するすべてのトピックが「全体像」にとって重要であることを確認するために最善を尽くしてください。

「全体像」に関して、非技術的な管理は一般に、技術的な議論をコスト、時間、および品質の観点から解釈しようとします。

それを念頭に置いて、プロジェクトで行った主要な決定に言及し、コスト、時間、および/または品質の面でそれらの決定の利点を強調することができます。3つから4つの重要な決定を選択し、それらの決定についての議論を簡潔にしてください。さらに情報が必要な場合は、質問します（答える準備をしてください！）。

また、技術的な知識のない友人によるプレゼンテーションを事前に実行し、意見を聞くことを強くお勧めします。実際にまだあまりにも多くの専門用語を使用しているのに、技術的でないと考えるのは非常に簡単です。あなたの友人が技術的でなければ、より良いです。プログラムはもちろんのこと、ほとんどコンピューターの電源を入れることができない人を見つけてください。彼らがあなたの言っていることの要点をたどることができれば、あなたは元気です。

ほとんどの技術者（私を含む）は技術的になりすぎる傾向があることがわかりました。オッズは、彼らが従うことができる技術的なものがどれだけ少ないかに驚かれることでしょう。たとえば、リスクと不確実性を低減していることを説明する場合、すべてのプロジェクトがあなただけのものではなく、リスクと不確実性を持っていることを非常に明確にしてください。

リスクと不確実性が非技術的な問題に起因しており、管理者がそれらを懸念している、または少なくとも認識している場合、必ずあなたがしたことを含めてください。

また、ポジティブな点を強調してください。少なくとも、あなたの言うことと同じくらいあなたの口調から引き離されるからです。したがって、リスクと不確実性に多くの時間を費やさないでください。後で自分の手に負えないことを自分でカバーするためにこれを起動する必要がある場合、スケジュールどおりにタスクを完了するために他の人から必要なものをカバーすることができます。ほとんどのプロジェクトでは、他の人が必要なことをタイムリーに行わないことが現実的な可能性があるため、これが原因であなたが非難される可能性が低くなります。

技術者は「内部」機能の重要性を認識しますが、非技術者は認識しません。このプロジェクトには、foozbars、whatsits、blah blahsなど、時間を費やすことが重要な技術的な問題があると言う以上のことはできないでしょうが、あなたはそれをすべて行っており、予定どおりです。

まあ、あなたのプロジェクトの説明は非常にあいまいですが、試してみます。

作成したアプリケーションは、別のアプリケーションの代替品であるか、手動で実行された、またはまだ実行されているプロセスを自動化するツールのいずれかです。
ソフトウェアの導入前後のワークフローを比較するさまざまなシナリオのケース分析を行います。私が見たいもの：

• 非常に一般的なシナリオを合理化した方法を示します
• ユーザーエクスペリエンスに欠陥があったバージョンと、それらをどのように強化したかを表示します。与えられたフィードバックをどのように実装したかを示します。
• 前後の時間、生産性、機能などを比較する数値または表を表示します。ここで私は聞いている「の使用により、static noiseおよびmore static noise、我々はY％でXを行うために必要な時間を減少させました」

個人的に、私はボンネットの下で何が起こっているかは気にしませんし、あなたのマネージャーはもっと気にしません（実際、それに多くの時間を費やして楽しんでいますが、誰もいじらないことで価値を生み出さないことを知っています表示されます）。ソフトウェア製品（コンポーネント、ライブラリ、フレームワーク、またはアプリケーション）は、使用可能（堅牢、高速、柔軟、予測可能）であり、合理的な将来性を備えている必要があります。

私があなたを雇ったなら、あなたはこれらの資質を大切にしていると確信したいです。私はあなたがそれらを達成しようとすることを意味し、なぜあなたがそれらの手段を選んだのかを説明してほしい。私はあなたが良いツールを使用しているのを見たいです。プロジェクトトラッカーの統計情報を表示します。使用している開発方法論の概要を説明し、それらとその利点を簡単に説明します（地球上のあらゆるものについて、説得力のある派手な2つのライナーがあります）。技術的な詳細を投げるだけでなく、もちろんソリューションを提供するため、あなたとの仕事がいかに楽しいか、私の絶えず変化するニーズにどのように対応できるか、どのようにあなたとのコミュニケーションがとても楽しいかを教えてください技術レベルで実装されますが、あなたは私が理解し、私に関連する用語で表現できるようになります。

新聞記事のように新聞記事を構造化することを検討してください：重要なものを最初に（遅れて開始し、早期に切断する計画を立てて）、誰、何、なぜ、いつ、どこで、どのようにカバーします。私はOne Minute Managerの単一ページテンプレートが好きで、それらは物事をうまく整理することを強制します。

再プレゼンテーションスタイル：

• スクリプトを作成し、事前に練習してください。自分の動画を作成し、翌朝視聴します。もう一度練習してください。
• 自分のペースで進みます（コーヒーを一時停止して旋回させるとうまくいく人もいますが、ロビン・ウィリアムズが遅いと想像できますか？）タイミング...それは難しいです、それは練習が必要です。
• あなたがそこに立ち読みするPPTを作らないでください。そこに立って読むことができる PPTを作成しないでください。PPTを使用してグラフィックを表示し、キーワードを1つまたは2つだけ表示します。プレソではなく、あなたに焦点を合わせたいのです。10/20/30 Kawasakiの推奨事項は適切です。
• 事前に練習してください:)アイコンタクトを行うためのいくつかの予備サイクルがあり、適応する手がかりを監視します。

再コンテンツ：

• 新聞の要約の後、要件をカバーし、いくつかの延期された要件（学習したものの、現在の取り組みの範囲に収まらないもの）を含めます...最初は要件と考えていたものの、流したことがあるものを含めます調査した。
• 主要なリスクをビジネス用語で述べる-彼らは「RDFデータがうまく断片化しない」というリスクを気にかけず、「複雑化する顧客データを取得する場合、データモデルのスケーリングには手直しが必要」というリスクを考慮しているすべてのリスクに対して応答があります：リスクイベントが発生しているかどうか（どのようなメトリックスか）、およびそれについて既に何をしたか、それが発生した場合にチームはそれに対して何ができるかをどのように知るか。
• リスクはまだ明確に定義されていないか、十分に対処されていないか、発生した場合は壊滅的で修正不可能です。あなたがリスクパイルにどの程度侵入するかは、対象（医療？ゲーム？）に依存するため、これはあなたの判断が示される領域です。

サブテキスト：あなたは自分で仕事をしてきましたが、それは常に管理にとって少し怖いです-だから、あなたが他の人にどのように進歩を知らせ続けたか、あなたが述べられた方法と実際の要件を学んだ方法の指標を含めるようにしてください。経営陣は、技術の部分は退屈で賢い人を必要としていると信じていますが、最終的には常に実行可能です...それらに技術を教えてみてください。むしろ、問題をどれだけうまく調査して組み立て、議論を触媒し、進捗を伝えるかを彼らに印象づけてください。

2つの大きな懸念事項は、進行の方向性と適時性に関して技術的なものを必要としません。関与した他の人々からフィードバックを得る。プレゼンテーション中にサプライズな質問や懸念をしたくない。

プロジェクトの方向に焦点を当てます。彼らはこれが何であるかについて再考を必要とするかもしれませんし、彼らはどの計画にも関与していないかもしれません。これを実現する方法の例を示します。

プロジェクトのマイルストーンとパフォーマンスを提示します。タイムラインを変更した可能性のある仕様変更について言及します。

プロジェクトの問題に言及することは避けないでください。重要なのは、どのようにそれらを克服できたかです。これにより、将来の課題に対処する能力に関する洞察が得られます。

ゆっくり話してください。冷静である。呼吸することを忘れないでください。

行われた決定、使用されたテクノロジー、および克服された問題を強調することができますが、通常、上級管理職は最終的な問題に焦点を当てます。

• この方法でこのプロジェクトを実装すると、ビジネスをより速く、より良く、より低コストで行うことができます...
• このプロジェクトの推定コストはX、短期的な節約はY、長期的な節約はZです。

プロジェクトで作業しているときに、元のプロジェクト設計と比較して節約またはパフォーマンスを向上させる方法を見つけた場合、いくつかの最良のポイントがあります。経営陣がお金を稼ぐ/節約しようと考えない限り、プロジェクトが開始されないことを期待/想定することができます。

これらの種類の指標は重要です。なぜなら、彼らが注目していることの1つは、あなたの周りを維持するコストであり、そうすることの利益が最終的な利益に加減するのか疑問に思うからです。

パワーポイントの10/20/30規則からのガイ・カワサキは、あなたは彼が輪郭がちょうど10スライド、20分を持っていることについてかなり良い、などです原則として、プレゼンテーションで使用するパワーポイントをすれば私の提案になります

考慮すべき事項もいくつかあります。

それらを楽しませる。ピエロにならないでください。少しの情熱やユーモアがあれば、彼らはもっと注意を払うようになります。

スピーチを遅くし、強調のために一時停止を追加します。

作るアイコンタクトと誰も他の人がうまくとして上司に影響を与える可能性があるので、部屋で、意思決定者や上司だけでなく、...

いくつかの話をしてみてください..プロジェクト中にあなたに起こった面白いこと、あるいは悪いことについて話してください。

要約し、要約し、要約します...常にあなたに追いついてください...

良いヒント：フォローアップできる技術的な問題に重点を置いてください。技術的な部分も理解していると感じさせてください。

できる限りそれが良い質問であるような文を使用してください...

あなたが書いた、

「私が特に心配しているのは、プレゼンテーションで技術的詳細と非技術的詳細の適切なバランスを見つけることです。」

Garr Reynoldsは、プレゼンテーションアートの第一人者であり、彼のブログ投稿の 1つでもあります。 2005年の（まだタイムリー）で、Steve JobsとBill Gatesのプレゼンテーションスタイルを比較しています。洞察力に富んだ記事を読んでいない場合でも、BillのスライドショーとSteveのスライドショーを比較するスクリーンショットからヒントを得ることができます。すべての箇条書きと過剰なスタイリング）。

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

2005年以降、ビルはプレゼンテーションのスタイルを改善し、Garrは2010年からのブログ投稿でビルの改善について説明しています。

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