どこから始めますか？

1. アクティビティの目的は、このアクティビティの範囲外です。 つまり、サイトを開発する目的は、商品を販売することではなく、別の通信チャネルを提供することにより顧客へのサービスを向上させることです。 B2Bシステムを開発する目的は、ネットワークを介して顧客とやり取りするためのソフトウェアを作成することではなく、自動化によってコストを削減し、売上を増加させることです。
2. 目標は測定可能でなければなりません。 目標は、達成可能最終（「2016年の2倍の売上」）にすることも、単なる方向性（毎年2回以上の売上の増加）にすることもできます。 しかし、それが測定可能であることは常に重要です。 たとえば、「私たちのブランドに対する高い顧客ロイヤルティを確保する」という目標は奇妙です。「高い」が何を意味するのかは明確ではなく、おそらく今は何もありません。 そして、「ブランドロイヤルティを半分にする」という目標はより測定可能ですが、それを評価するには、実装前後にいくつかの調査を行う必要があります。

RFPの主な内容の重要なポイント

「何をすべきか」と「方法」

• 開発者は、問題の記述とともに文書を読みます 。 「何をすべきか」という質問に対する答えを得る。 この段階では、顧客の本当の期待に関する多くの情報がすでに失われているため、ここではスキップします。
• 開発者は、アーキテクチャと実装 、つまり 「自分のやり方」という質問に答えます。 通常、この段階はいかなる形でも正式化されないという事実に注意を促します。
• 開発者は、自分が発明したアーキテクチャと実装（「方法」）を通じて、結果（「何をする」）につながる作業 （「いくら」）を評価します。 この段階で、予算が生まれます。
• 開発者が見積もりと計画を送信します。 。 ドキュメントの残りの部分は、90％がコピーアンドペーストで標準の単語です。 最良の場合、彼は選択されたアプローチについて少し書いています。

個々の要件の評価

1つではなく2つのプロジェクト

プロジェクト番号1。 設計

1. 目標、目的、ビジネス要件
2. 機能要件
3. 非機能要件
4. システム使用シナリオ
5. 制限。

1. 特定の仕事
2. 作業パッケージの内訳、
3. 使用したソフトウェア
4. 推定サーバーインフラストラクチャ
5. テスト手法（負荷、統合）
6. データ移行アプローチ
7. ...その他、特定のプロジェクトに応じて

プロジェクト番号2。 実装

コスト管理

1. クライアントは設計段階のみにサインアップし、第2段階では競争する必要があります。
2. 彼の文書は第2段階で比較的公開される可能性が高く、

滝かアジャイルか？

• あなた自身と同僚の何人かは、あなたの時間の80％〜100％を完全に没入型のプロジェクトに充てる準備ができています
• 十分な能力があり、技術者とともに開発に没頭する準備ができている、
• 締め切りに間に合わない、または請負業者の仕事の質が低いというリスクを個人的に共有する準備ができています。
• あなたと請負業者の両方が、現時点では要件を収集することは普通ではないことを理解しています。要件はまだ発明されていないためです。そして、市場、ビジネス、
  
  

• すでに行った比較的標準的なプロジェクトに行く場合、
• あなたは今、あなたが望むものをかなりよく理解しています、
• 技術者とのコミュニケーションを管理し、緊密にするための時間のかなりの部分を与える準備ができていない
• 現時点で開発にかかる費用を知ることは重要です。これは請負業者にとって頭痛の種であり、限られた予算に品質を入れる方法です。
• 開発がいつ完了するかを知ることは重要であり、請負業者が締め切りに対して金銭的な責任を負うことが重要です。

機能要件

サービス

• 相互作用の順序（タスクの設定方法、反応の予想速度、通信チャネル）
• 支払い方法（月額料金、後払い、料金、前払い、月から月への振替）
• 測定可能な結果は何ですか（レポート、ドキュメント、コード、レイアウト、外部監査など）
• 保証するもの（彼らに経済的責任があるかどうか、「できる」と「すべき」を区別することが重要です）
• ペナルティとペナルティ（実際、それらが何であるか、合計されるかどうか、どのように決定されるか、どの時間枠か）

ドキュメント形式

• 著者 。 最初は、「顧客」はどこにでも書かれています。 開発者がいくつかの暗黙的な要件が指定されていると考える場合、開発者が新しい行を追加します。
• セクション フィルタリングに便利
• サブセクション 。 フィルタリングに便利
• 一意のクレーム番号 。 ACCOUNTやSUMMESLIMNなどのExcelの数式に便利
• 要件のテキスト 。 自由形式で。 写真はありません。 1段落。
• 要件を含む作業パッケージ 。 開発者によって完成される。

• ジョブパッケージ名
• h / hでの作業パッケージの評価 。 開発者には、評価を作業の種類に分類する権利があります（以下を参照）。 たとえば、マネージャー、アナリスト、開発者、テスターの時間を個別に強調表示します。
• パッケージに含まれる要件の数（管理のため、0になる場合があります） 。 リクエストにより。 これは、Excelの「アカウント」式を介して自動的に計算されます。

この記事に意図的に含まれていなかったものとその理由

• 要件のトレーサビリティ：理想的には、機能的および非機能的はビジネス要件、タスクへの要件、目標へのタスクに戻るべきです。 適切な経験なくしてすべてがとても美しいシステムを構築することは非常に困難です。 ただし、要望と可能性がある場合は、すぐに要件を階層化することをお勧めします。
• ビジネスプロセスとオブジェクト間の関係を視覚化 する方法 ： 多くの点で、スキームは多くの言葉より雄弁 です 。 UML / Aris / IDEFx、BPMN、ERD、シーケンス図などがあり、ビジネスプロセスとデータ間の関係を記述します。

おわりに

• RFP:
  
  
  • - ,
  • ,
  • (, , SEO)
  • ( , , )
  • :
    
    
    
    
    
  • ,
  
  
  
• 
  
  
  • , (1) (2)
  • , ( — )
  • ()
  • - ,
  
  
  
• : , .
• : , , , , , , . , .
• , : Waterfall Agile
  
  
  • Agile: , , , ,
  • Waterfall: , , , , , , , ,