顧客に示す見積もりはどの程度詳細ですか？
カスタムソフトウェアの場合、顧客に見積もりを出すとき、どの程度の詳細を含める傾向がありますか？
あなたは：
- それを数時間で実行できる小さなタスクに分割し、それらに完全なリストを提供しますか？
- 彼らに一つの大きな数を与えて、それに向かって努力しますか？もしそうなら、それはあなたがそれらを示す必要がないというより詳細な見積もりから来ていますか？
- それを大きな「フェーズ」に分割し、各フェーズに何時間も与えますか？
これは固定入札契約などではなく、「1時間あたり$ YでX時間かかると思います」というような状況です。
詳細すぎたり曖昧すぎたりしたくない場合は、どちらも問題を引き起こします。
曖昧すぎると、自分自身が何に関係しているのか明確に理解できなくなり、予期しない事態が発生したときに問題が発生します。
詳細すぎると、情報過多の非常に現実的なリスクが発生します。また、あなたがするすべてのことについて誰かが質問するかもしれません。
「ちょうどいい」とはクライアントによって異なりますが、クライアントが自分のしていることを理解していることを確信し、それらをはぎ取ろうとしないように、十分な詳細を用意する必要があります。作業をフェーズに分割することは、これを達成するための良い方法です。各フェーズは、配信可能な自己完結型の作業のセットである必要があります。 （開発プロセスのためにフェーズを小さなチャンクに分割できます）。
これにより、クライアントは進捗状況を確認し、必要に応じて残りの作業の優先順位を変更することができます。
あなたのシナリオでは、ユースケースまたは機能ごとに見積もりを提供するのがよいと思います。具体的なユースケースの見積もりについてお客様から苦情があった場合は、ユースケースのどの部分が最も困難で、最も多くの時間と費用を費やすかをさらに説明できます。お客様は、ユースケースを少し変更して、複雑さを軽減しながら機能を最大限に活用することを決定できます。
これはすでに実行中のプロジェクトで機能します-一部のリリースは完了していて、製品を知っています。新しいプロジェクトを開始する場合、非常に大きな不確実性があり、そのため、より大きなブロック-機能/ユースケース、マイルストーンなどでそれを行う必要があります。
推定時間の最小単位は、プロジェクトのサイズに基づく必要があります。数週間以内に実行されるいくつかのクイックWebアプリを作成している場合は、おそらく数時間で見積もりを使用できますが、多くの機能を備えたより大きなアプリの場合は、人日、人週、または人月で見積もりを使用する必要があります。芸術は、十分に正確であることです。最初の見積もりが正確すぎると、それを満たさない場合に問題が発生します。
私は読むことをお勧めします ソフトウェア推定：ブラックアートの謎を解く（スティーブマコネルによる） 。
もう1つの方法は、最も重要な機能を最初に追加し、フィードバックをできるだけ早く受け取ることによってソフトウェアを段階的に構築するアジャイルアプローチを使用することです。アジャイルでの見積もりは通常、より抽象的に行われます。
アジャイル見積もりについて読むために私はお勧めします アジャイル見積もりと計画（Mike Cohnによる） 。
あなたはそれに自信を持つのに十分な見積もりが必要であり、それは投資のリスクと一致する必要があります。ええ、それは曖昧です。私が言いたいのは、私は牛乳のために店への旅行を箇条書きにしないということです。フロントポーチを修理するのにかかった$ 10,000の明細化が欲しいです！
まず、読者がドリルダウンできる組織を用意します。 5つ以下の全体像の領域を与えてから、詳細のクラスターを与えます。同じように見える情報が7つ以上あふれていると、誰も何もうまく読むことができません。
また、人件費と部品（購入したソフトウェア、購入したハードウェア）のコストを分割することを計画します。また、パーツには、上記のパーツのリストを含める必要があります。顧客は、コストを劇的に削減するサイトライセンスのようなものを提供することによって、そこで請求額を減らすことができるかもしれないので、それは有用な交渉ポイントです。
特定の質問に答えるには：
- 数時間で実行できる小さなタスクに分解して、完全なリストを提供しますか？
時間は短すぎるでしょう、IMO。最小日/週。あなたが本当に8-20時間の長さの仕事をしているなら、これは店に行って牛乳の仕事をすることです。それはそれがかかるものを要します。
- 彼らに一つの大きな数を与えて、それに向かって努力しますか？もしそうなら、それはあなたがそれらを示す必要がないというより詳細な見積もりから来ていますか？
機能にかかる費用について少し説明します。顧客は、値札が表示されたときにスコープを変更することを希望する場合があり、使用する内訳がない場合は、より少ないものをより少ないお金で選択することはできません。この分割は議論のツールであるため、タスクよりも重要だと思います。顧客はたくさんの機能を望んでおり、あなたはお金を求めています。彼らがあなたが必要とするすべてのお金を持っていない場合、いくらかのお金は何もないよりはましですが、さまざまな機能のコストの内訳なしにどれだけ少ないことをするかを定義することはできません。
私は、ほとんど何でもするため、または少なくともサブ機能の大規模なコレクションを実行するために、何らかのベースラインが必要な状況にありました。その場合、私はベースラインの作業を定義し、次に各機能の記述で言及しました-「ベースラインも必要です」、ベースを構築する作業とそれぞれの固有の機能を示します。
- それを大きな「フェーズ」に分割し、各フェーズに何時間も与えますか？
私はそれがこのように行われるのを見てきましたが、個人的には、それが有用であるとは思いません。ウォーターフォールタイプのプロジェクトで作業している場合は、この内訳が必要になる可能性があるため、作業を適切にスケジュールしたことがわかります。しかし、私の好みは常に機能を見ることです。機能をいくつかのフェーズにグループ化して、効率のよいベストショットでスケジュールの感覚を与えることができますが、それができる場合は、フェーズごとの時間に縛られないようにします。
注：あなたが言ったように、これは契約入札ではなく、顧客が定義した形式を持っていることがよくあります。これは、私が顧客と一緒に座って、実際に顧客が何に支払いたいかについて議論する場合に最適なスケジュール形式での私のショットです。その精神では、優れた機能の説明は、数値と同じくらい簡単に重要です。なぜなら、それらが何を取得しているのかを非常に明確にしたいからです。
通常は2つのセクションに分けます。
- 概要概要
- 詳細な
私は通常、概要が一種のエグゼクティブサマリーであることを確認します（簡潔で誰もが理解できる）。詳細なセクションでは、アトミックタスクを見積もりで分類します。
車両についてはあまり知らないのに、ただFixed Car: $900私の費用の内訳;）
ルール1：見積もりはゲームです。
結果：何に使用されているかがわかるまで見積もりを出さないでください。
見積もりにはほとんど本当の意味はありません。それでも、誰もが自分たちが非常に重要だと考えています。それらは毎日変化しますが、どういうわけか、まったくナンセンスに基づいた数やスケジュールを持つことには管理上の魔法があります。
見積もりは、続行/中止の決定に使用される場合があります。単一の大きな数の方がおそらくより役立ちます。
見積もりは、進行中の進捗状況を追跡するために使用される場合があります。各リリースの予算を含む一連のリリースの方がおそらくより役立ちます。
見積もりは、より低い請求可能レートを要求するように強制するために使用される場合があります。提供する見積もりに関係なく、請求可能なレートについて話し合うことになります。
見積もりは、将来マネージャーを困らせるために使用される可能性があります。ここで何を提供してもかまいません。プロジェクトは数か月で崩壊し、人々は移動します。何が起こったのか疑問に思われることでしょう。
見積もりの目的を知る必要があります。
面白いのは、低入札の見積もりでプロジェクトが開始される可能性があることです。ローリングしたら、見積もりを上げることができ、誰も気にしません。
プロジェクトを大きく重要に見せるために、見積もりを非常に高くする必要がある場合があります。ローリングすると、最初のいくつかのリリースでビジネス上の問題が解決し、後のリリースでは悪い考えがあるため、プロジェクトの残りの部分がキャンセルされることがわかります。
数時間で実行できる小さなタスクに分解して、完全なリストを提供しますか？
通常は悪い考えです。お客様のニーズによって異なります。
小さなタスクでの最初の推測には、誤り、脱落、誤推定が含まれている必要があります。あなたは未来を予測することはできません。
すべてのエラーを追跡することはほとんどの顧客を悩ますので、このレベルの詳細を明らかにすることはめったに役に立ちません。
彼らに一つの大きな数を与えて、それに向かって努力しますか？
通常は悪い考えです。お客様のニーズによって異なります。時には彼らはあなたが解決しようとしている問題の予算対コストを正当化するために多数を必要とするだけです。
プロジェクトの進行に合わせてこの見積もりを変更すると、一部の顧客に迷惑がかかります。いくつかは変化に満足しています。
ただし、元の見積もりと修正の不一致に悩まされることもあります。大きな数の変化を追跡するために、変更管理の事務処理であなたを埋めることができる人もいます。
もしそうなら、それはあなたがそれらを示す必要がないというより詳細な見積もりから来ていますか？
悪くないアイデア。一般的には役に立ちませんが、悪い考えではありません。
覚えておいてください。ゲームです。未来を予測することはできません。詳細から仕上げるのは、プロセスの最後に乱数を「正当化」する唯一の方法です。
それを大きな「フェーズ」に分割し、各フェーズに何時間も与えますか？
これはあなたができる最高のことです。
このゲームに勝つことはできません。あなたも壊すことはできません。出ることすらできません。
見積もりに誤りがあり、それらの誤りを修正して見積もりを修正すると、一部の顧客は動揺します。
「フェーズ」は重要な順序である必要があります。ユーザーストーリーと一致する必要があります。それらは、機能の増分部分として（原則として）リリース可能である必要があります。
最も重要なのは、見積もりが何に使用されるかを見つけ、ユースケースに適合するものを提供することです。
私の愚見で -
[a]詳細な内訳は、男に他の場所で買い物をして、それぞれまたはすべてのポイントで交渉しようとすることです。家を建てるために100,000を取得した場合、基礎を築くために本当に50,000が必要ですか？
[b]彼は、成果物で終わるすべてのステップの価格見積もりを取得できます。成果物がない場合は、それが完了したと言っても、完了したと言っても、彼の仕事には関係ありません。成果物は現実です。他のすべては熱気です。
[c]価格とスケジュールの違いに注意してください。たとえば、1か月の労務費を請求しますが、2か月のスケジュールを許可します。あなたはいくつかの部分で過小に支払われ、他の部分で過大に支払われるかもしれませんが、それでもあなたはあなたを含むすべての人を幸せにするスケジュールを保つことができます。
通常、私は顧客が注文できるかどうかにかかわらず、すべてのアイテムの見積もりを提供します。たとえば、彼がプログラムに3つの変更を加えたい場合、私のオファーには「Aの変更はxxx、Bの変更はxxx、Cの変更はxxx」と表示されます。このようにして、彼はBがお金の価値がないと判断し、AとCを注文するだけで済みます。各部分の「分析xxx時間、設計xxx時間、実装xxx時間、テストxxx時間、文書化xxx時間」など、さらに詳しく説明します。率直に言って、クライアントがビジネス上の意思決定を行うためにそのレベルの詳細を必要とするとは思わない。