プロジェクト分析またはプロジェクト概要の書き方は？
私たちは小さな（15 ppl）Web開発/設計会社であり、約8人のフルタイムのLAMP開発者がいます。エラーの量を減らし、予算が見積もりを上回らないようにするために、開発を開始する前に、プロジェクトのある種のテクニカル分析を導入しました。これはアプリケーション開発者にとっては簡単なことではありませんが、私たちのセクター（webdev）では一般的な方法よりも少ないようです。これまで、プロジェクトマネージャーが集めた簡単な説明（多くの場合1ページ未満）を受け取り、最初に開発に取り掛かり、結果として壊滅的な予算編成の失敗が発生しました。
この問題に取り組むために、私はこの主題について読み始めました。CodeComplete2、Pragmatic Programmer、The MythicalMan-monthを読みました。新しいプロジェクトの準備と分析の背後にある概念を理解したと思いますが、実際的な例が不足しています。私が読んだものをよりよく実践するために私が見ることができるテクニカル分析の例や広範なプロジェクトの概要を知っている人はいますか？私は例による学習の大ファンです、それを言う必要はありません:)
残念ながら、ほとんどのプロジェクトスコープのドキュメントは商業的に保護されているため公開できませんが、良いものを作るための経験を積み重ねることができてうれしいです。私が見たいと思うようなものを含めました。
覚えておくべき主なことは、あなたが達成しようとしていることです-あなたは何が起こっているかについてあなたとクライアントの間で共通の理解を得ようとしています。悪い見積もりは、あなたがそれが取ると思ったものとそれがとったものとの違いだけでなく、あなたがあなたが提供しようとしていると思ったものとあなたが提供しようとしているとクライアントが思ったものについてもです。
これらすべてを文書化する方法の1つは、カバーされていることです。クライアントが戻ってきて「レポートモジュールはどこにありますか」に移動した場合は、「レポートモジュールはありません」という文を指すだけですが、実際にはそうではありません。それ。それは本当に、最後（対立する可能性が高い）ではなく、最初（建設的である可能性がある）でその会話をすることについてです。プロジェクトまたはアカウントマネージャーがあまりにも多くの詳細が否定的に聞こえるままになり始めた場合は、これを覚えておいてください。
だから、あなたは何を含めるべきですか：
何が行われているのかについての高レベルの説明-ほんの数段落。それは実際には詳細を提供するつもりはありませんが、それはシーンを設定します。したがって、このセクションでは、ウィジェットを販売するためのeコマースサイトを構築している、それはB2BサイトではなくB2Cである、プロジェクトはサイトの完全な設計と構築をカバーしている、などと言います。せいぜい2、3段落。
高レベルの機能要件-構築/設計される主要な機能の概要を示す箇条書き。データエンティティごとに、作成、読み取り、更新、削除のいずれであるかが含まれます。これにより、タスクをよりよく理解できるようになります。したがって、ユーザーを作成/読み取り/更新/削除する機能、注文を作成、読み取り、更新する機能、製品カテゴリを作成/読み取り/更新/削除する機能、テキストを含む製品を作成/読み取り/更新/削除する機能が含まれます、画像とビデオ。
非機能要件-大量のデータが失われる別の領域。非機能要件には、パフォーマンス、ユーザー負荷、監査、アーカイブ、セキュリティなどが含まれます。レポートはここに収まるかもしれません-それは本当に機能的ですが、それはシステムのコア部分ではなく、システムの使用をサポートするものであることが多いため、忘れられがちなものです。特定の領域で何かを行っていない場合（たとえば、監査証跡がない場合）、おそらく別のセクションでそれを明確に述べてください...
範囲外-何か（少しの機能、別のシステムへのインターフェース）が含まれているかどうかについての議論中に物事が浮かび上がります。これらを書き留めてください！私の経験でスコープが失敗する重要な領域の1つは、これらの会話のさまざまな記憶であり、それを前もって紙に書くことは、それを取り除くか、その多くを取り除きます。これは、レポートが入り込む可能性のあるもう1つの領域です（レポートが必要なことはわかりますが、何が必要かはわかりません。そのため、配信してどこにあるかを尋ねます）。また、ユーザー管理（パスワードのリセット？）とセキュリティもあります。
前提条件-プロジェクト中のこの時点では、本当に正確な見積もりを出すには情報が不十分になります。それは大丈夫です、これがあなたがしたことであることが明確である限り、あなたはあなた自身のギャップを埋めることができます。したがって、彼らが物事をレイアウトするための企業テンプレートを提供していると仮定している場合は、それを書き留めてください。彼らがすべてのコピーと画像を提供していると思われる場合は、もう一度書き留めてください。
私が検討したい他のセクション：
技術プラットフォーム-重要だと思われる場合は、技術プラットフォームを高レベルで説明してください（この場合はLAMPとその他のビット）。私の経験では、これはスコープクリープが実際に発生する領域ではありませんが、2分かかる傾向があるため、問題はありません。
他のシステムへのインターフェース-私の経験では、プロジェクトを複雑にするものの1つは、完全に制御できないものです。これが発生する重要な領域の1つは、他のシステムへのインターフェースです。これらを扱っている場合は、システム、インターフェースのタイプ、および行われる相互作用をリストすることが常に最善です。したがって、彼らの在庫システムを更新している場合は、それがWebサービスであると言い、在庫クエリを実行し、在庫レベルを更新するとします。
依存関係-繰り返しますが、これはあなたのコントロールの外側の一部です。プロジェクトに貢献している他の関係者（クライアントを含む）がいる場合は、彼らに期待していることをリストするのが最善の場合があります。誰がどのような形式でコピーを提供していますか（簡単にインポートできる適切に構造化されたExcelファイルですか、それとも100万のWordドキュメントですか）。インターフェースすることが期待されるサードパーティアプリケーションのテストシステムはどうですか？これらのものはいつ必要ですか？
お役に立てれば。
編集：前回の仕事で使用したいくつかのテンプレートを掘り下げて少し匿名化しました。それらは内部にあります（つまり、他の組織で作業を行うチームではなく、社内で作業を行う内部チームでした）が、構造とプリンシパルは同じです。
私はあなたが望む種類の文書にかなり近いプロジェクト委任テンプレートを含めました：
http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template
そして、あなたが役に立つと思ういくつかのビットを持っているかもしれない仕様テンプレート：
http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template
プロジェクトの義務1には、そこにあるプロジェクトの1つからの実際のサンプル（非常に面倒な金融システム調整パッケージ）が含まれ、奇妙な例で何がどこに行くのかについての構造とポインターが含まれています。
それらはすべて素晴らしい本です。 「ソフトウェア要件2」と「ピープルウェア：生産的なプロジェクトとチーム」も追加することをお勧めします（ピープルウェアはまだ読んでいません。しばらくの間、やることリストに載っています。恐れ入ります）。
しかし、私は経験に代わるものはないのではないかと心配しています。チームが過去に引用したこと、実際に配信するのにかかったものに注意を払い、自分が正しいか間違っているかについて自分が正しいか間違っている理由を見つけようとすると、その方法を学ぶことができます。より良い。
私の経験では、大きな問題を小さな問題に分解しようとしても問題はありません。繰り返します。最終的に0.5〜1プログラマー日かかる作品ができたと思うと、時間を見積もるときに私が最高の成功を収めたところに到達しています。
もちろん、プログラマーがあなたのために働いていることを覚えておく必要があります。アリスは出荷可能なソリューションを半日でコーディングし、ボブは1日かかり、チャーリーはそこに着くまでに2日かかり、コードレビューのためにボブから1時間かかる場合があります。 。プログラマーの長所と短所を知ることも経験が必要です。