技術的でない重要な利害関係者に優れたプレゼンテーションを行うにはどうすればよいですか？
今月の終わりに、私が自分で取り組んでいるソフトウェアプロジェクトについてプレゼンテーションを行う必要があります。このプロジェクトでは、基本的に、会社でフルタイムの仕事に就くかどうかを決定します。今のところ。私の部門の社長と2人の副社長にプレゼンテーションを行います。大統領は他の2人の副社長よりプログラミング知識が少なく、結局私が印象づける必要のある人物です。
プレゼンテーションで伝える必要がある最も重要なことは何ですか？私はマネージャーから次のことを強調するように言われています：
- 私はこのプロジェクトを正しい方向に進めており、すべてを完全に管理しています。
- このプロジェクトは予定どおりに完了しています。
プレゼンテーションの中で、自分ができる限り雇用価値のあるものに見えるようにするには、他にどのようなことに注意する必要がありますか？ソフトウェアのリスクと不確実性を減らすために、設計レベルで行っている努力を強調することを考えています（私が想像する2つのことは、上級者にとって非常に重要です）。
私が特に心配していることの1つは、プレゼンテーションで技術的な詳細と非技術的な詳細の適切なバランスを見つけることです。技術的な詳細を何も含めないと、部門の社長はソフトウェアの「内部」機能のすべてを知ることができませんが、私が技術的すぎると、道に迷って理解できなくなる可能性がありますプレゼンテーションの重要なポイント。
任意のヒントをいただければ幸いです。
聴衆を知る。
あなたはすでに一番大事なスピーチのルールを征服しました-あなたは話す相手の技術的専門知識を評価しました、そしてあなたのプレゼンテーションはそれに応じて調整されるべきです。たくさんのテクノガーブルやリートスピーチでプレゼンテーションを無効にすることを心配しないでください。
大きなかつらに直面するときの大きな誘惑は、技術的な概念、理論、およびアプリケーションの印象的な辞書で実際に試して[〜＃〜] wow [〜＃〜]しようとすることです。もちろん、もしあなたが上司を十分に混乱させたなら、もちろんこの仕事！
これはおそらく、あなたが探しているフルタイムのポジションを得るための短期的にはうまくいくでしょう。しかし、大統領は間違いなく「私はその男が何について話しているのか分からない」と考えて会議から離れ、間違いなくあなたの人生を賭けることができます感想彼はあなたのために持っていますRest of Your Life。
なぜそれが悪いのですか？ビジネスの世界では、CEOや社長などがコミュニケーションをとれる人を探しています。はい、カスタムシリアルポートとインターフェイスするCコードをデバッグできるが、何を推測しているのかを、非常に有能で技術的に高度なオタクが抱えていることが重要です。彼らは気にしません。彼らが気にしているのは、あなたが管理下にあるであること、そして彼らが信頼できることです。内側のサークル（昇進、お金、栄光、台無し）への最も確実な方法は、上層部との効果的なコミュニケーションです。
これがアドバイスです。これまでの会社での成果に焦点を当ててください。ナットやボルト、配線を掘り下げないでください。彼らの目はうっすらと見え、あなたはJust Another Programmerになります。彼らが理解できることについて話し、時間をかけて上司にあなたから離れさせ、「私はこの人が仕事を成し遂げると信じています」と自信をもって話しかけます。
心に留めておくべき最も重要なことの1つは、売り過ぎないことです。あまり多くの情報を提示すると、特に非技術担当者に提示される技術プロジェクトに関しては、すぐに聴衆を失います。話し合うすべてのトピックが「全体像」にとって重要であることを確認するために最善を尽くしてください。
「全体像」に関しては、非技術的管理は一般的に技術的議論をコスト、時間、および品質の観点に変換しようとします。
これを念頭に置いて、プロジェクトで行ったmajorの決定に言及し、コスト、時間、品質の面でそれらの決定の利点を強調できます。 3〜4つの主要な決定を選び出し、それらの決定についての議論を簡潔にしてください。詳細情報が必要な場合は、質問します（回答する準備をしてください！）。
私も強く技術的な知識のない友人がプレゼンテーションを事前に行い、彼らの意見を聞くことをお勧めします。実際にはまだ専門用語を使いすぎているのに、技術的ではないと考えるのは非常に簡単です。友人の技術が少なければ少ないほど良いです。プログラムは言うまでもなく、コンピュータの電源をほとんど入れられない人を探すようにしてください。彼らがあなたが言っていることの要点をたどることができれば、あなたは良い状態です。
ほとんどの技術者（自分自身を含む）は技術的すぎる傾向があることがわかりました。おそらく、彼らがフォローできる技術的なものがほとんどないことに驚かれるでしょう。たとえば、リスクと不確実性を低減していることを説明する場合は、すべてのプロジェクトにリスクと不確実性があることを明確にしてください。これは、これを知っているのがスラムダンクではないためです。
リスクと不確実性が非技術的な問題に起因し、経営陣が懸念している場合、または少なくともそれらを認識している場合は、必ず、行ったことを含めてください。
また、あなたが言うこと以上に少なくともあなたの口調から多くを取り除くので、ポジティブを強調します。したがって、リスクと不確実性に多くの時間を費やさないでください。後で自分の手に負えない事柄をカバーするためにこれを取り上げる必要がある場合は、スケジュールどおりにタスクを完了するために他の人が必要とするものをカバーすることができます。ほとんどのプロジェクトでは、他の人が必要なことをタイムリーに実行していないことが現実的な可能性であるため、非難される可能性が低くなります。
技術者は「内部」機能の重要性を認識しますが、非技術者は認識しません。このプロジェクトにはfoozbars、whatsits、blah blahなど、時間を費やすことが重要であったいくつかの技術的な問題があると言う以上のことはできないでしょう。
まあ、あなたのプロジェクトの説明は非常に曖昧ですが、私は試してみます。
作成したアプリケーションは、別のアプリケーションに代わるものか、手動で実行されていたプロセスを自動化するツールのいずれかだと思います。
ソフトウェアの導入前後のワークフローを比較するさまざまなシナリオのケース分析を作成します。私が見たいもの：
- 非常に一般的なシナリオをどのように合理化したかを示す
- ユーザーエクスペリエンスに欠陥があったバージョンと、それらをどのように拡張したかを表示します。与えられたフィードバックをどのように実装したかを示します。
- 前後の時間、生産性、機能などを比較するいくつかの数値または表を表示します。 「
static noiseとmore static noiseを使用することでXを実行するのに必要な時間がY％短縮されました "
個人的に、私は内部で何が起こっているのか気にしません、そしてあなたのマネージャーはもっと気にしません（実際、私はそれに多くの時間を費やして楽しんでいますが、誰もいじらないことによって価値を生み出さないことは知っていますこれまでに表示されます）。ソフトウェア製品（コンポーネント、ライブラリ、フレームワーク、またはアプリケーション）は、使用可能（堅牢、高速、柔軟、予測可能）であり、妥当な将来性を備えている必要があります。
私があなたを雇ったなら、私はあなたがこれらの資質を大切にしていると確信したいと思います。どのような手段でそれらを達成しようとしたのか、なぜそれらの手段を選んだのかを説明してください。あなたが良いツールを使っているのを見たいです。プロジェクトトラッカーの統計情報を表示します。あなたが使用している開発方法論の概要を説明し、それらとその利点を簡単に説明してください（地球上のあらゆるものについて、説得力のあるサウンドを作るための派手な2つのライナーがあります）。あなたとの仕事がどれほど楽しいか、私の変化し続けるニーズにどのように対応できるか、そしてあなたとのコミュニケーションがどれほど楽しいかを見せてください。私に技術的な詳細を投げかけるだけでなく、もちろん解決策を提供するからです。技術レベルで実装されていますが、私が理解し、私に関連する用語で表現できるようになります。
新聞の記事のようにプレソを構成することを検討してください。最初に重要なもの（遅れて開始し、早めに切り取ることを計画します）を作成し、誰が、何を、なぜ、いつ、どこで、どのように行うかをカバーします。私はOne Minute Managerのシングルページテンプレートが好きです。それらは私に物事をうまく煮詰めさせることを強制します。
プレゼンテーションスタイルについて：
- それを台本にして、前もって練習しましょう。自分のビデオを作り、翌朝それを見てください。もう一度練習してください。
- 自分のペースで進んでください（一時停止してコーヒーをかき回した方がうまくいく人もいますが、ゆっくりとしたロビンウィリアムズを想像できますか）。しかし、重要なポイントについて、計画された一時停止と言い直しを組み込んでください。タイミング...それは難しいです、それは練習が必要です。
- しない、しない、しないPPTそこに立って読んでください。PPTあなた立って読んでください。それがまさにあなたがすることです。PPTを使用してグラフィックを表示し、キーとなるWordや2つだけを表示します。 10/20/30川崎のおすすめは良いです。
- 事前に練習してください:)アイコンタクトを取り、適応する手がかりを監視するための予備のサイクルがいくつかあります。そして、彼らがあなたを軌道から外し始めたら、あなたが何を落としているかを知っています。
再コンテンツ：
- 新聞の要約の後に、要件をカバーし、延期された要件をいくつか含めます（学んだが、現在の取り組みの範囲に収まらないもの）...最初は要件として検討したが、次第に流すことができたいくつかの事項を含めます。調査した。
- ビジネス用語で主要なリスクを述べる-彼らは、「RDFデータが適切に分割されない」というリスクを気にせず、「データモデルのスケーリングはますます複雑な顧客データを取得する場合、やり直しが必要になる」というリスクを考慮し、すべてのリスクに対する対応があります。リスクイベントが発生しているかどうか（メトリックは何か）をどのようにして知ることができますか。また、それに対してすでに何を行っているか、発生した場合にチームは何ができるでしょうか。
- リスクはまだ十分に定義されていないか、十分に処理されていないか、または発生した場合に壊滅的で修正不可能である可能性があります。リスクの山にどれだけ進むかは主題（医療？ゲーム？）に依存するので、これはあなたの判断が示される領域です。
サブテキスト：あなたは自分で作業してきましたが、それは常に管理上少し怖いです。そのため、他の人に進捗状況を知らせ続けた方法、明示された要件と実際の要件をどのように学んだかを示す指標を含めてください。経営陣は、技術の部分は退屈で利口な人材が必要であると信じていますが、最終的には常に実行可能です...企業は技術スキルに基づいて成功したり失敗したりすることはめったになく、彼らはそれを知っています。それらに技術を教えることを試みなさい。むしろ、問題をどのように調査して組み立て、議論を促進し、進捗状況を伝えるかを彼らに印象づけてください。
2つの主要な懸念事項は、進行の方向性と適時性について技術的なものを必要としません。関与している他の人々からフィードバックを得る。プレゼンテーション中に驚きの質問や心配事をしたくない。
プロジェクトの方向性に焦点を当てます。彼らはこれが何であるかについての再考を必要とするかもしれません、または彼らはどんな計画にも関与しなかったかもしれません。これを実現する方法の例を示します。
プロジェクトのマイルストーンとパフォーマンスを提示します。タイムラインを変更した可能性のある仕様変更について言及します。
プロジェクトの問題について言及することを避けないでください。重要なのは、どのようにしてそれらを克服できたかです。これにより、将来の課題に対処する能力についての洞察が得られます。
ゆっくり話してください。冷静である。呼吸することを忘れないでください。
決定、使用されたテクノロジー、および克服された問題を強調することができますが、上級管理職は通常、最終的な問題に焦点を当てます。
- この方法でこのプロジェクトを実装すると、ビジネスをより速く、より良く、より低コストで行うことができます...
- このプロジェクトの推定コストはXで、短期の節約はYで、長期の節約はZです（XはYより大きくても、Zより小さいほうがいいでしょう）。
最良のポイントのいくつかは、プロジェクトで作業しているときに、元のプロジェクトの設計と比較して節約またはパフォーマンスを向上させる方法を見つけた場合です。経営陣が彼らがお金を稼ぐ/節約するつもりであると考えない限り、プロジェクトが開始されないことを期待/仮定することができます。
これらの種類のメトリックは重要です。なぜなら、彼らが注目していることの1つは、ユーザーを維持するコストであり、そうすることのメリットが収益に追加されるのかマイナスになるのか疑問に思うからです。
あなたが書いた、
「私が特に心配していることの1つは、プレゼンテーションで技術的な詳細と非技術的な詳細の適切なバランスを見つけることです。」
Garr Reynoldsはプレゼンテーション技術の第一人者の1人であり、彼の ブログ投稿 の2005年（まだタイムリー）の1つで、Steve JobsとBill Gatesのプレゼンテーションスタイルを比較しています。洞察に満ちた記事を読まなくても、BillのスライドショーとSteveのスライドショーを比較するスクリーンショットから、どのプレゼンテーションがより説得力があり、どのプレゼンテーションが聴衆を眠らせる可能性が高いかについてヒントを得ることができます（ヒント：すべての箇条書きとやりすぎのスタイリング）。
http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html
2005年以降、Billはプレゼンテーションスタイルを改善しており、Garrは2010年のブログ投稿でBillの改善をカバーしています。
PowerPointの10/20/30ルール から Guy Kawasaki プレゼンテーションでPowerPointを使用する場合、彼が概説する原則は10だけであることについてかなり優れているため、私の提案です。スライド、20分など.
考慮すべきいくつかの点：
それらを楽しませます。ピエロではなく、少しpassionまたはhumorは、彼らにもっと注意を向けさせます。
スピーチを遅くします強調のために一時停止を追加します。
他の人が上司に影響を与える可能性があるため、意思決定者や上司だけでなく、部屋でアイコンタクトを全員と行う同じように...
ストーリー ..をいくつか持つようにしてください。プロジェクト中にあなたに起こった面白いこと、または悪いことさえも伝えてください。
要約、要約、要約...常にあなたと一緒にそれらを維持してください...
良いヒント：フォローアップできる技術的な問題に重点を置いてください..彼らが技術的な部分も理解していると感じさせる..それは彼らに良い気持ちを与えるでしょう...
それは良い質問ですのようなステートメントをできるだけ多く使用してください...