ひどい見積もりに対処する

私が取り組んだ最近のプロジェクトは、建築家によってひどく過小評価されていることが証明されました。推定値は少なくとも500％外れていました。

残念ながら、見積もりが顧客とサインオフされた後、私はプロジェクトに参加しました。シニア開発者として、私はすぐに機能および技術仕様に気付きました。いくつかの大きなギャップと不確実性が含まれていました。

その結果、私はビジネスおよび技術ディレクターと緊急事態会議を呼び出して彼らに現実を知らせることを強いられたと感じました。何よりもまず、開発者として、私はこれが非常にストレスの多い困難な状況であることに気付きました。「ビジネス」は、ITが無能であり、メッセンジャーであると非難し、私はいくつかの「弾丸」を受け取りました。

顧客はアカウントをキャンセルすると脅しましたが、現在までプロジェクトは未完成であり、私はそれとは直接関係していません。

建築家は社会的にはナイスガイでしたが、このエピソードに基づいて、単に無能であるか、彼の推定に影響を与える大きな販売/ビジネスのプレッシャーがありました。

それでは、プログラマーとして、この種の状況についてのあなたの経験はどのようなもので、どのように対処することを勧めますか？

長い返信ですが、最後に要約がありますので、すべてを読んでわからない場合は要約にスキップしてください！

開発者として、私は状況を文字通り他のすべてのプロジェクトに対処しなければなりませんでしたが、プロジェクト管理に移るまで、効果的に対処する方法を学びませんでした。私にとって効果的な対処とは、期待の管理と推定の仕組みの理解という2つのことです。

最初にデューデリジェンスを実施することなく、見積もりを提供する、見積もりにコミットする、または見積もりの​​正確性を示す他の指示を与えることは非倫理的であるという前提から始めます。他の人々はあなたの専門能力に依存して必要な仕事の量を予測し、誤った指示を与えると彼らと彼らのビジネスを傷つけます。

しかし、あなたは何かを与えなければなりません、実際の生活の中で、あなたは即席の会議または遅いプロジェクトに引きずり込まれ、上司はおそらく、彼らがすぐに数字を考え出すか、彼らが提供した推定値にコメントすることを期待していることを明確にします ここで、期待値管理が機能します。

問題を理解したり数字を自分で計算したりせずに数字や指示を与えるのは間違っていることを説明してください。彼らの数値が非常に正しいかもしれないと言ってください、あなたがあなた自身で推定運動を行った前にあなたは知らないだけです。そして、あなたはそこに何がいつ必要なのかをよく理解しているかもしれませんが、数字を計算するにはまだ時間が必要だと言います。彼らがあなたに与えることを期待するかもしれない1つだけの見積りがあります：あなたが見積りを提供できるようになるとき。必ずその数字を提供してください。

開発者は、最初にレビューすることなく、他の人々の見積もりに対して責任を負わない（または受け入れると解釈できる指示を与える）ことはありません。プロジェクトマネージャーとしては、まったく異なる問題です。なぜなら、実際には見積もりプロセスをある程度制御できるからです。見積もりを導き出し、レビューする方法と、実際の作業を行うために他の人に頼らなければならず、確実にコミットされます。

デューデリジェンスを行うことができずに、推定値についてコメントすることさえしないでください。これは倫理的です。弁護士または医師は、クライアント（または患者）が規則を順守し、最初に評価手順を実行しない限り、アドバイスを提供できないことを絶対に明確にします。同様に、あなたは専門的な意見を述べる前に質問に答える権利があります。

2番目の部分は、推定の仕組みについてです。ソフトウェア開発以外の業界（製造、金融市場、建設）を含む、見積もりを行うためのさまざまなアプローチと見積もりプロセスの仕組みを調査することをお勧めします。これにより、上司やクライアントがあなたに合理的に何を期待できるかを知ることができ、奇妙なことに、作業量についてより正確な予測をするのに役立ちます。それはあなたの見積もりを守る能力を向上させ、建築家や販売員によって提供されたものとは異なるたびに数字を守る必要があります。

通常、それが機能する方法は、奇妙な見た目または比較的大きなアイテムについて最初に推定値をスキャンすることです。したがって、「非標準」の名前を持つものを守る準備をしてください。また、すべてのタスクの規模が同じになるように、より大きなタスクを分割します。つまり、ほとんどのタスクが2日かかり、1つのタスクが10日である場合、ドリルの準備をします。

各タスクに何が含まれているかを明確にしてください。単にdevを持ち、ドキュメントが含まれていると誰かに思わせるのではなく、devとユニットテストを分割するのが最善です。明らかにこの方法では、かなりきめの細かい見積もりを作成する必要があります。

次に、掘削が行われます。長い仕事の内訳を確認することは非常に難しいため、クライアントや上司は別の戦略を採用する可能性があります：何かについて知っている可能性のあるランダムなビットに集中し、見積もり全体を信用できなくなるか、満足するまでドリルダウンします答えます。推定全体の信頼性は、ランダムなサンプルに依存する可能性があります！したがって、もう一度準備する時間、関連するビットのみを含める、余分なものを除外する、または「必要な」セクションに移動して、数字を守る方法を検討する時間が必要です。

明らかに、アプローチ、つまり機能、画面の数などに基づいて推定する方法、または複数のアプローチを使用する方法のいずれかを一貫させることができますが、いずれにしても、特定の推定方法を選択した理由を守る準備をしてください。また、あなたの数字が、必要な作業量を予測する他の人の試みと異なる理由を説明する準備もしてください。

弱い推定値の明らかな兆候を学ぶ：

• テンプレートからコピーされた一般的な実行タスクで満たされています（適切な推定値は手元のタスクに固有です）。

• 粗い見積もり（つまり、数日より長いタスク）。

• プロジェクトの初期段階で行われた見積もり、または要件や関連作業に関する実際の知識を持っていない可能性のある人によって行われた見積もり。

• 実際の行動者以外の人々がまとめた見積もり

• あいまいな見積もり（何が含まれており、同様に重要であるが何が除外されているかは明確ではありません）。

• タスクの規模の実質的な違い。

実装の詳細についての実際の知識がなくても、他の人の見積もりを評価し、図をドリルする練習をします。これにより、確固たる証拠がない場合に他の人の見積りを確認する要求を押し付けられたときに、余分な時間にわたって主張を裏付けることができます。

要約すると：

• デューデリジェンスを行う機会が得られる前に、その件に関してひどい見積もりや見積もりを行わないでください。

• 最初にそれを明確にし、他の人がそれを他の方法だと思い込ませたり、沈黙を同意の印として解釈させたりしないでください。

• これらの外部ソフトウェア開発を含む、さまざまな推定方法がどのように機能するか、実際のアプリケーションとメリットを知ってください。

• 見積もりを守る準備をしてください。

• 他の人の見積もりを評価する方法を学習して、非常に不正確な数字に専念する必要がないようにしてください。

未来を予測することは不可能です。予測（「推定」）を要求することは、単にトラブルを要求することです。誰もがそれを行い、誰もが間違っています。

「500％アウト」というあなたの判断は、おそらく建築家の見積もりと同じくらい間違っています。結局のところ、「...現在まで、プロジェクトはまだ未完成です...」という事実はありません。

誰も「正しい」答えを知りません。そして、それが完了するまで、誰も知りません。

そして、それが行われた後でも、「元の」推定値（変更管理の有無にかかわらず）は、実際に達成されたものと相関しない場合があります。

推定はtrapです-それは不正なゲームです。あなたは勝つことができず、あなたは負けず、ゲームから抜け出すことさえできません。

編集

悪い見積もりに対処する; 間違っているように見える「レガシー」推定値。

そこにそれがある。他の人の見積もりに同意しません。必要だと思われるものを省略したか、彼らはあなたとは異なる仕事の範囲を持っていた、または彼らは異なる生産率を持っていた。また、見積もりが単なる努力以上のものである場合、それらは異なるコスト基準を持ちます。これらはすべて議論の余地があります。そのため、推定に至るまでの詳細に異議を唱えます。全体の数に異議を唱えないでください。要約には実際の情報はありません。見積もりの​​根拠となる個々の詳細に異議を唱えます。彼らが考えていたことを見つけてください。

あなたの仮定が彼らの仮定と同じくらい間違っている可能性があります。同程度に。

見積りを依頼された場合。

1. あなたは間違っているでしょう。

   1. 彼らは仕事の範囲についてうそをつく。

   2. チームの生産性はわかりません。

   3. どんな新しい技術が関係していても、それは虚偽表示されています。

2. これらのことをランダムにカバーするためにパディングを投げることはできません。あなたは実際に「推定」するための基礎を知らないし、知らない。推測だけです。それを乗り越えます。

ルール1：推測しているだけなので、少しずつ推測してください。

「推定」状況における根本的な問題は、将来を予測することではありません。1〜2週間よりもはるかに長い期間にわたって正確に行うことはできません。予測は、直接および即時の詳細な知識がある期間に限定してください。たとえば、次のリリース。

基本的な質問は、通常、買い手または顧客の意思決定です。問題は「費用はいくらですか？」ではありません。-それは不完全です。問題は、「投資に見合うだけの価値があるか？」です。本当の問題は、「コスト/ベネフィット比とは」と「投資を増やせばリターンを増やせないので、いつ支出をやめるべきか」というラインに沿ったものです。これらは本当の質問です。

ルール2：意思決定者を事実情報でサポートします。

ほとんどの人は、アジャイルアプローチが最適です。最初のリリース（今から1か月）には5人×4週間かかり、1日100万ドルの損失を修正する機能Xと1週間20万ドルの損失機会を修正する機能Yが生成されます。あなたは何をしているのか詳細な知識があるので、この予測は理にかなっています。その後のリリースは少しかすんでいます。

今から1年後のリリースは非常に将来的であり、ランダムな数字で予測することはできません。将来の6か月以上の詳細を気にせず、単純な経験則を使用してください。

彼らがTCOが何であるかを尋ねるとき、あなたは正直でなければなりません。「開発費用の支払いを停止すると、総費用が発生します。支払いを停止するまで、常に費用が発生します。」

本当の質問は、「どのような問題を修正しようとしていますか？」です。または「どのような新しい機会を追求していますか？」そして「その価値は何ですか？」

ルール3：解決するはずの問題よりもソフトウェアのコストを低くします。

問題がよくわからない場合、推定は認識に合わせて調整されます。これを避けるようにしてください。

確率について。衰弱する病気や事故を除いて、ソフトウェア開発のどの部分も実際の確率に左右されません。「リスク」は、単に悪い管理です。通常、「ビジネスニーズAまたはテクノロジーBの複雑さを考慮していません」という形式です。「問題または技術についてより多くを学んだので、私たちはスケジュールを変更しました」という形で、「スコープクリープ」として処罰されます。

学習して範囲を変更する可能性はありません。それは確実です。

計画中。「計画」と「推定」があります。何を構築するかを計画することは、チェックリストまたは依存関係グラフとして最もよく表される1つの事柄です。必要な労力の「推定」は、知らない要因に基づいています。

「計画」は普通の良い管理です。

「推定」には、知らない知識が必要です。正確に「労力を見積もる」ためには、製品に対するソースコードレベルの洞察力が必要です。また、そのソースコードを入力する人と、その人が犯す間違いを知る必要があります。あなたはそれを知ることができないので、どんな見積もりも間違っていなければなりません。そして、しばしば誤解を招くので間違っているので、役に立たない。

見積もりが500％外れていて、プロジェクトがまだ進行している場合、見積もりにはどのような価値がありますか？

無し。それは人々を不幸にすることでした。しかし、プロジェクトはとにかく前進しました。

誰も未来を見ることができないので、見積もりを正しくしても何の意味もありません。それを有用にし、人々が決定を下せるようにします。

地平線を短くしてください。できるだけ早く価値を提供します。顧客がいつでもプロジェクトをキャンセルでき、しかも価値があるプランを作成します。

計画がプロジェクトの唯一の「神聖な真実」にならないようにしてください。提供可能な機能は神聖です。成果物が変わると、他のすべてが変わるはずです。

計画が作成している価値を超えないようにしてください。

十分な時間がなければ、十分な時間はありません。とにかくプロジェクトを完了するための魔法の解決策はありません。私の意見では、あなたはあなたがそれを述べることができることをしました。彼らは難しい方法を見つけなければならなかったことが判明しました。それが通常のやり方です。うまくいけば、建築家と経営陣は彼らの過ちから学び、二度としないでください。経営陣があなたの議論に耳を傾けて適切な行動を取るにはあまりにも無知であるときにこれが通常のビジネスである場合、他のプロジェクトまたは別の会社を探すことは良い考えかもしれません。

「開発者は職人であり、職人にできる最悪のことは、彼にくだらない製品を届けさせることです。」どこかからの有名な引用ですが、どこからか思い出せません。

誠実さは常に尊重されるべきです。私は「建築家のビジョン」の受信側にいましたが、開発者がソリューション全体が機能しないという悲惨なニュースで私に来たとき、私たちはビジネスユニットに行き、ひどい会話をしました。その後、開発者は、機能の80％で構成される新しい見積もりを思いつきましたが、期限内に予算内で納品しました。

ビジネスユニットは、開発者が彼らに正直に話し、彼の会社の短所を認め、配達する犬のように働いたという事実によって勝ち取られました。彼は常に正直だったので、私たちはこの7年間、この男を私たちのために働かせてきました。

シナリオ全体は非常にまれです。ほとんどの場合、ビジネスユニットは、あなたが配達できないことを馬鹿だと思っています。長期的には、あなたをただのジャークのように扱いたいクレチンを喜ばせようとするよりも、長期的にはより多くの利益を得るため、この方法で操作しない顧客を探す必要があります。

自分の分野を知らない建築家に関しては、疫病のようにそれらを避けてください。かつて私と一緒に厳しい方法で強化していたメンターがいました-「これ、違います。練習しろ！」ミスを許容するのは、あなたがそれらを早く作成し、修正し、二度と作成しなかった場合だけです。顧客の役職に非技術的で経験の浅い人々を許可する企業は、廃業に値する「コミュニケーション」をとることができます。

私はかつてこのような状況に直面していました。プロジェクトがスケジュールを使い果たしたのは、ビジネスが要件を変更し、コミュニケーションのギャップがあり、上級管理職がプロジェクトを予定どおりにしたかったためです。さらに悪いことに、このプロジェクトに取り組んでいた1人の男が、より優先度の高い別のギャップを埋めるために引き抜かれました。

私のチームはプロジェクトを終わらせるために夜を過ごしていました。ある夜遅くの午前3時頃（私は19時間連続で働いていました）マネージャーにそれについて何かをするようメールを送りました。

翌日、会議が開かれました（開発者のみ）。週末にチーム全員が参加し、プロジェクトが完了する前にプロジェクトをテストしました。迅速な修正を行うためにチームに参加した人はほとんどいませんでした。最後に、チーム全体（プロジェクトチームだけでなく）の努力でプロジェクトを提供することができました。他のプロジェクトでも同じプロセスに従いました。

チーム全体が（プロジェクトに関与していなくても）アプリケーションをテストし、迅速なバグ修正を支援しました。

注：私のチームは約25人で構成されており、このチームにもさまざまなプロジェクトに取り組んでいるサブチームがあります。

私の唯一のアドバイスは、「マネージャーに話してください。プロジェクトが時間通りに配達できないことをしっかり伝えてください。また、代替手段を与えてください。

企業は、物事が予想よりもはるかに長くかかるという真実を好まないことが多い一方で、彼らはさらに少ないことを好む。どれだけ時間がかかるかを誰かに早く知らせれば知らせるほど、誰もが状況に応じてより迅速に計画を立てることができます。これは最初は大変な時期ですが、長期的には簡単になります。2度目に正しく取得し、不測の事態に対処します。

経営者に対処する際の重要なポイントを1つ強調します。管理者はソリューションを高く評価しています。

問題を抱えて経営陣に出向かなければならない場合（見積もりが非常に非現実的である場合など）、事前に一生懸命作業して、状況に対処する方法の代替案を含めてください。たとえば、システムの価値を理解するためにパレート分析（80/20ルール）を実行したり、（少なくとも最初のリリースから）機能をカットするための優先順位を付けて、最大のビジネス価値を持つ機能に集中したり、システムのカスタムパーツなどの適切な代替品である代替品（オープンソースプロジェクトなど）を探すことができます。

5ポンドの袋に25ポンドの砂がかからないことは間違いありませんが、管理者が不快なメッセージを吸収するのを支援することの一部は、あなたが熱心な仲間であることの証拠を提供することです。

あなたは、このに興味があるかもしれないIEEE記事私がしているブログの前について。ハイライトは次のとおりです。

• プロジェクトの失敗の最大の要因の1つは、過度に楽観的な見積もりです。
• 見積もりが低すぎる大きな理由の1つは、トップからのプレッシャーが早すぎるためです。
• もう1つは、実装中のスコープクリープであり、推定値を再検討する必要はありません。

最初に、問題のアーキテクトと非公式に話し、彼の推定値であなたの問題のリストを調べ、問題がどこにあるのか、彼らが解決するのにかかる時間の差を彼に納得させようとします。

それから私はあなたのラインマネージャー/プロジェクトマネージャーに行って、彼/彼らとそれについて議論したいと思います。

一日の終わりに、建築家は見積もりを与えたので、彼らはそれを認識している限り、変更される場合があり、時には大量に変更される可能性があり、製品を展開するなどの代替計画を立てることができます機能やその他の手段を減らします。

結局のところ、上記のことを行ったら、それはもはやあなたの責任ではありません。

クライアントや建築家の上司に直接行くべきではありません。これは悪い感情を促進するだけであり、ほとんど常にあなたのせいになります。

あなたができる最善のことは、（この場合は個人的にではなく）あなたの悪い見積もりから学ぶことです。学ぶべきことの1つは、アイデアを実装する人以外の誰かがそれがどれくらいかかるかを推定させないことです。プログラマーの速度は桁違いに変化する可能性があるため、他の誰かの推定はほとんど不可能です。

私はあなたの痛みを感じます...私はこのフラストレーションをすべて処理する方法がわかりません:(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

過去には、営業部門が顧客が支払うと考えていた数字を満たすために見積もりを削減したプロジェクトマネージャーに対処する必要がありました。マネージャーは、許可を求めるよりも許しを請う方が良いと考えていました。

開発者が彼らの見積もりを埋めることを学んだ理由は、彼らが彼らのマネージャーによって削減されることを知っているからです。したがって、見積もりを2倍にして30％を追加すると、妥当なスケジュールを取得できる可能性が高くなります。

顧客は常により安くそれを望みます。合理的な見積もりで顧客が来た場合、顧客はそれをalkして、コストを削減するか、歩くことを要求します。しかし、高すぎると、彼らは議論せずに歩くだけです（「私たちはそれを検討し、あなたに戻ります」）。

管理された期待のゲームです。

問題は、元の推定値が出ていたということではなく、経営陣があなたを信じていなかったことです。

経営陣が決定を下せるようにする最良の方法は次のとおりです。

1. 問題を裏付ける証拠で問題を概説します。そして
2. それらから選択する複数のソリューションを提供します（最も優先度の低いものから最も優先度の高いものの順に）。

（1）スクラムを実装し、危険な推定値に対して実績を追跡することは、主張を裏付けるのにうまく機能します。

（2）の場合、私の選択肢の1つは、「クライアントとの優先機能リストの開発（別名スクラム用語で製品バックログ）」です。これは固定価格または非常に官僚的な組織では扱いにくいが、それは可能だ。

お役に立てば幸いです！

私は（コーディングをしている人なら誰でも確信しているように）共感します。私の最後の会社はこれについてかなりひどいものでした-営業担当者がプロジェクトに参加して売り込み、それからあなたが入って、見積もりを見て、そしてただ笑います。

Tomhが述べたように、1日の時間はそれほど多くありません。寝なくても

三つのこと、私は思う。

ほとんどの場合、クライアントの期待を管理し、透明にする必要があります。あなたができることを率直に行い、あなたがやったことを示す-それのすべて。これは、（トトフィルが述べたように）あまりにも粗くまとめられた要件を渡された場合に特に当てはまります。彼らが生産性と進歩を見たなら、それは私の経験で何よりも重要です。

期待を管理し、ワークロードを透明にすることに加えて、もう1つの大きなことはスコープ管理です。スコープナチであることと、あなた自身の最後尾をカバーすることで、アナル/攻撃的であることの間には大きな領域があります。誰かがこの追加の機能を必要とするとき-同意してください！そして、それらをプロジェクトに追加することをどのくらいの時間に比較的正確に推定与えるこれの逆が唯一ではありません（または次のリリースを。）ではない、別の80時間の週に自分自身を詰め込む-あなたもにその見積りのいくつかのパッドを取得する可能性他に追いつく。

幸運を！

それを見たり、理解したりせずに、何もしないでください。顧客またはあなた自身の管理者があなたにそんなにお金を払う気がないなら、彼らはあなたを成功させる準備をしていません。

これは、多くの場合、詳細、データ、および構築中のアプリケーション全体でそれらがどのように相互作用するかを理解できないことでした。質問をし、答えを見つけ、それをすべて書き留める代わりに、仮定が行われます。

私がクライアントによく言うことの1つは、もしあなたが私を絞首刑にしようとするなら、少なくとも私は自分のロープで自分を絞首刑にするか、他人ではなく自分の銃と弾丸で私を撃つことです。

それを解決しようとする人々の回転ドアを持つことは、彼らにとって最終的にははるかに悪いでしょう。

非現実的で計画が不十分で先見の明がないことは、組織全体の問題のシグナルである可能性があります。

まず、プロジェクトの範囲を過大評価している可能性を考慮します。営業担当者とアーキテクトは、ソリューションを誇張する傾向があります。それらを額面どおりに受け取らないでください。彼らはおそらくあなたが顧客に約束したよりも少ないものを思い付くと期待しています。

私がここでやることは、私が持っている時間をとり、できるだけ賢く過ごすことです。顧客の優先順位を把握し、それらを実現します。10回中9回、顧客は自分の最優先事項が満たされたことに満足し、未完了の作業の80％を見落とします。

最後にしたいことは、緊急会議を招集し、人々を悪であると非難することです。あなたは言う：

「彼らに現実を知らせる」

しかし、現実は単なる意見です！あなたの仕事をし、リラックス、そしてにとって重要なもので、あなたのpolitcal資金を費やします。昇進、もっとお金、もっと多くの休日が好きです。

あなたの上司が顧客のために本当に一生懸命働いているあなたのためにプロモーションを取引しているのは理にかなっています。顧客に代わってヘイワイヤに行くことはしません。

覚えておくべきことの1つは、推定値にはスコープクリープや避けられない遅延（または、特定の形式の情報ファイルなど、クライアントが要求したと言わないことに基づく問題）が含まれないことです。

これらのいずれかが発生するたびに、見積りおよび/または期日を遅らせることを学びました。新しい機能を追加し、新しい見積もりと新しい期日を取得します。合意した日に必要な情報を提供しなかった場合、新しい期日を取得します。情報を提供しますが、不完全または不正確、または約束されたもの以外のいずれかの方法で、新しい見積もりと期限を送信し、合意された機能の要件を変更し、新しい見積もりと期限を取得します。クライアントがより高い優先度で作業することを望んでいたため、プロジェクトでの作業を停止し、新しい期日を送信します（プロジェクトが長時間保留されている場合、キャッチアップ時間があるため、新しい推定値を送信する可能性があります）。

元の見積もりが開発グループの外部から来ており、彼らがそれについてcom辱されていない場合、それを入手したら、自分の見積もりを準備します（あなたが持っていると思うすべてのタスクの詳細なレベルで-はるかに高いレベルで）あなたが与えられた推定値よりも詳細な情報）、チェーンのすぐ上でそれを提供し、あなたが与えられた推定値を満たすために何を切り取るべきかを尋ねます。

答えが何もなければ、クライアントに新しい推定値を通知するように要求します。これで、問題をさらに詳しく調べました。経営者がクライアントにX時間しか支払わないと主張する場合、あなたに説明された仕事はあなたの見積もりよりも短い時間ではできないので、残りの開発時間に誰が支払うか尋ねてください。会社がヒットを取って、時間を自分で支払うことをいとわないことが判明するかもしれません。

彼らが利益からそれを持ち出そうとせず、彼らがもっと時間を必要とすることをクライアントに告げず、会社が開発スタッフの販売に関する詳細な見積もりを支持しないなら、プロジェクトに勝つために」の見積もりでは、あなたは死の行進プロジェクトにあり、あなたの最善の策はできるだけ早く出ることです。あなたは、プロジェクトが支払いに同意した50時間を費やし、あなたが本当に必要な500でさえ終わっていないときよりも、プロジェクトができるだけ早く長くなることを知っていることをクライアントがより幸せに感じることができます。過度に楽観的な見積もりは、プロジェクトの失敗の最大の予測因子の1つであることを思い出してください。これらのタイプの企業では動作しませんが、十分な回数繰り返した場合、最終的には沈んでしまいます。

見積もりの​​精緻化も考慮します。「今見ているように、このプロジェクトにはX工数かかります」という意味です。20〜30％後、再見積もりなどを行います。

結局のところ、ファイルダウンローダーはどのように推定を行いますか？絶えず洗練されています。

推定者が十分ではないので、「推定は、あなたが数学と推測を行い、有用な方法で未来を予測することを求めている」と「私たちが行うコミットメントは、私たちが行う数学とは完全に分離しています」見積もりを行います;愚かな量の作業を行うことに同意することができ、完了できないと思われることに同意しますが、これらのいずれもソリューションの数学を実際に変更しません」と「巨大ではない開発方法論を行うことができます機能Aのバッチは、障害が発生する可能性がはるかに低くなるように日付Bまでに行われます」

多くの見積書には、交渉の言葉が使われています。彼らは言語で表現する必要が数学との不確実性について話数学。

見積もり担当者は、ビジネスマンの意思に応じて現実を曲げることはできません。彼の唯一の仕事は、彼らに挑戦をやめることです。