Application Developer Days 2010カンファレンスでレポートの承認が発表された後、聴衆にとって興味深いレポートを作成するためにどのようなレポートを作成すべきかを尋ねられ始めました。 実際、ここには1つのトリックがあります。会議は特定のプラットフォームに結び付けられておらず、ホールのほとんどの人は必ずしも一目であなたの主題を理解しているわけではありません。 したがって、著者に短いメモを書くことにしました。
もちろん、何らかのテンプレートに従ってレポートを作成することはできません。 誰もが優れた報告書を作成する方法について独自の理解を持っています。 準備中に留意する必要がある原則のみを説明します。
- レポートは聴衆の興味を引くものでなければなりません。 キャプテンのレパートリーからのアイテムは明らかですが、これはその重要性を否定しません。
- 私たちの会議はプログラマ向けです 。 プログラマーとして個人的に興味のある短いリスト：プログラミング言語、アーキテクチャー手法、ライブラリー、開発環境、その他のツール。 最後に、完成したプロジェクトに関する興味深いレポート。
- 仕事の組織、スクラムおよびその他のアジャイル、時間管理、およびマネージャーによると、開発者はプログラミングに加えて仕事で行うべきものはそれほど興味深いものではありません。 スタートアップの問題もプログラマー起業家にのみ関心があります。 それらは存在しますが、少数です。
- 「テスト」という言葉は、「テストによる開発」というフレーズで使用されている場合にのみ、プログラマにとって興味深いものです。 プログラムで検証できないのは、テスターの手作業と個人的な問題だけです。 そして、他の人々の問題は、誰にも特に興味がありません。 あなたがテスターであり、テストに関するレポートを作成したい場合は、プログラマーが会場に座ることを忘れないでください。 どういうわけか彼らは喜ばなければなりません。
- 視聴者が究極の目標を理解していれば、どんなレポートも興味深いものになります。 言語が馴染みがなく、プラットフォームが異質であっても。 アクションの意味を理解している場合、人生で同様のタスクに遭遇する可能性が常にあるため、プロセスを掘り下げてみます。
- 意味が視聴者に明らかであることを期待しないでください。 彼らのほとんどは、あなたのタスクの本質とプラットフォームの問題を知りません。 最初に明示的に解釈することをお勧めします。
- レポートは、特定の技術の特定の問題に深く入り込むべきではありません。 多くの場合、そのような深さは、視聴者にとって明らかな実際的な意味の欠如に関連しています。 テクノロジーの同僚でも。 （目的は明確ではありません。）
- PowerPointからの死を思い出してください。
そのため、レポートの計画は、特定の実用的なタスクから始まります。 視聴者がこのタスクを自分の現実に投影できるなら、彼は興味を持ちます。
会議のウェブサイトで著者向けの詳細情報をお読みください 。 要約のテンプレートと、 レポートを確認するシステムへのリンクがあり、これらの要約をアップロードする必要があります。