コンサルティングにおける過去5年間で、このプロセスは頻繁に変更されましたが、過去2年間で以下に説明するプロセスを使用しています。
最初の会議
潜在的なクライアント（リード）との最初の連絡後、通常、Skypeで会議または電話を開催します。 このミーティングの前に、リードについての詳細情報を見つけようとします。彼/彼女がどのように私たちを見つけたのか、彼が誰で、何に取り組んでいるのか、どこにいるのかなど
会議中、私たちについて、私たちの歴史とリモートワークと管理へのアプローチについて少しお話します。 その後、将来のプロジェクトの詳細を掘り下げ、次の質問に対する答えを見つけようとします。
- プロジェクトの目的は何ですか？
- 市場の競合他社は何ですか？
- 競合他社がある場合、プロジェクトの違いは何ですか？
- 彼はこのプロジェクトでどのようにお金を稼ぐつもりですか？
- なぜ彼はRubyで開発することにしたのですか？
- 彼には他の開発者やデザイナーがいますか？
クライアントがゼロからスタートアップを開発したい場合：
- 開発はフルタイムで行われますか？
- 他に創設者はいますか？
- 彼はどのようにプロジェクトに資金を供給するつもりですか？
- 彼はスタートアッププロジェクトの立ち上げの経験がありますか？
クライアントが開発チームを持つ組織の場合：
- どのような開発チームがいますか？
- 彼らはどの技術スタックを使用していますか？
- 彼らはどのようにプロジェクトを管理していますか？ 彼らはスクラムを使用していますか？
- 彼らはテストを書いていますか？
- なぜ彼らは外部の助けに頼ることにしたのですか？
次に、支払い、外部APIなどの複雑なプロジェクトコンポーネントの詳細に進みます。 ここでの私の目標は、どの技術機能にもっと時間がかかるかを判断することです。
最後に、クライアントに、プロジェクトで既に持っている有用な情報、たとえばmocapas、デザイン、プレゼンテーションなどを送ってほしいと頼みます。 一部のお客様は、投稿する前にNDAに署名するよう求めています。
内部議論
最初の会議の後、私は通常、CTOであるビクターと話し、収集したプロジェクト情報を彼に伝えます。 ビクターは通常、クライアントとの最初の会議では考えなかったプロジェクトについて質問するため、これは重要なポイントです。 クライアントに新しい質問のリストを作成し、メールに書き込むか、電話で回答を受け取ります。
現時点では、Victorと私は他のこと、たとえば、このプロジェクトがカレンダーにどのように適合するか、このプロジェクトで使用するのが理にかなっているフレームワーク、ライブラリ、またはテクノロジー、これらの事柄がすでに実装しているものとどのように似ているかについて議論しています（今後の評価を改善するため）。
タスクを作成し、評価を行います
クライアントに対する主な質問を理解した後、ユーザーの使用シナリオ（ユーザーストーリー）を描き始めます。 通常、すべてのユーザーストーリーを含むPivotalTrackerで一時プロジェクトを作成します。 これらをエピックに追加して、ユーザー、支払い、注文、管理パネルなどの機能別にグループ化します。
次に、 見積りパーティを使用して評価を行います。 通常、最も明確な評価を得るために、チームの誰かにこのプロセスに参加するよう依頼します。
各ユーザーストーリーの複雑さを0、1、2、または3ポイントのスケールで評価します。 非常に失礼：1ポイントは1日の半日、2ポイントは1日、3ポイントは2日の作業になります。 一部のユーザーストーリーが3ポイント以上のように見える場合、それを複数のユーザーストーリーに分割します。
すべてのユーザーストーリーを評価したらすぐに、基本的なアプリケーションの作成、リポジトリの作成、ステージング環境の作成、モックアップの作成などの日常的なタスクを追加します。
価格プラグを決定する
推定されたユーザーストーリーのすべてのポイントを要約し、内部速度-1人の開発者が1週間に実装できるポイント数（以前のプロジェクトに基づいて）に分割します。 そのため、プロジェクトに何週間かかるかがわかります。 例：
合計ポイント：120
1週間の速度：12ポイント
120/12 = 10週間
その時点で、数週間でプロジェクトの見積もりがあります。 しかし、私たちの経験から、プロジェクトの詳細の半分以下しかわかっていないことがわかります。残りはクライアントから配信されないか、クライアントがまだ詳細を知らないかのどちらかです。 顧客は、開発中にプロジェクトの詳細を常に学習します。 これを考慮して、次のような評価を増やします。
推定時間：10〜14週間
次に、結果の時間に1日あたりの開発者の平均支払時間（約7時間）を掛けます（8時間作業しますが、実稼働時間のみ請求書を発行します）。最後に時間数に時間給を掛けます：
10週間* 5日* 7時間* 100ドル= 35,000ドル
14週間* 5日* 7時間* 100ドル= 49.000ドル
価格：35,000ドルから49,000ドル
ここでは、並行して実行できるユーザーストーリーの数を考慮して、このプロジェクトに関与する開発者の数も決定します。 2人で並行して作業できると判断した場合、時間の見積もりを半分に分割しますが、コストの見積もりは変わりません。
評価を提出する
最後に、クライアントに単純なPDFドキュメント（複数ページ）またはすべてのユーザーストーリー（およびその評価）、時間とコストの見積もりを記載したメールを送信します。 ファッショナブルなドキュメントのコンパイルに多くの時間を費やさないようにしていますが、この点についてはわかりません。
このメッセージの中で、私たちはこの評価が現時点で持っている情報に基づいてなされたとすぐに言います。 また、プロジェクトの最初にこれを含めなかった理由について話し合うことなく、プロジェクト開発のコースを変更する完全な自由があることをクライアントに説明します。 作業範囲を変更するための1つのルールは、スプリント中ではなく、週の初めに（スプリント計画中に）変更することです。
各スプリントの前にスコアを確認してください
プロジェクトが承認され、開発が開始された後、各週の初めに（通常は週ごとのスプリントで作業します）、スプリント計画を実行し、今週にどのユーザーストーリーを処理するか、クライアントから必要な情報を決定しますそれらを実装します。 現時点では、一部のユーザーストーリーで新しい詳細を見つけ、その評価を変更することがよくあります。
毎週の繰り返しと毎日のスタンドアップラリーにより、クライアントに開発プロセス、何が行われたか、何が残っているか、そして最初の評価にどれだけ近いかについて透明性を提供します。 したがって、驚きはありません。
スタンドアップラリーおよびスプリントの計画ごとに出席する必要がある製品の所有者をチームから任命する必要があることに注意してください。 私たちにとって必要です。
おわりに
プロジェクトの評価はプロジェクトの重要な部分ですが、これは私たちがお金を請求せず、常にこのプロジェクトを得ることができるものではありません。 したがって、プロセス全体の目標は、コストを回避するためにできるだけシンプルな状態を維持し、見積りをできる限り正確にすることです。