ひどい見積もりに対処する
私が取り組んだ最近のプロジェクトは、建築家によってひどく過小評価されていることが証明されました。推定値は少なくとも500％アウトでした。
残念ながら、見積もりが顧客と承認された後、私はプロジェクトに連れて行かれました。シニア開発者として、私はすぐに機能と技術の仕様に気づきました。いくつかの大きなギャップと非認証が含まれています。
その結果、私はビジネスディレクターやテクニカルディレクターと緊急会議を開き、彼らに現実を知らせざるを得なくなりました。私は何よりもまず開発者として、これは非常にストレスの多い困難な状況だと感じました。 「ビジネス」はITが無能でメッセンジャーであると非難し、いくつかの「弾丸」を受け取りました。
顧客はアカウントをキャンセルすると脅迫しましたが、現在のところプロジェクトはまだ完了しておらず、私はもはや直接関与していません。
建築家は社会的にはナイスガイでしたが、このエピソードに基づくと、単に無能であるか、彼の見積もりに影響を与える大きなセールス/ビジネスプレッシャーがありました。
それで、プログラマーとして、この種の状況のあなたの経験は何ですか、そしてあなたはそれに対処することをどのようにアドバイスしますか？
長い返答ですが、最後に要約を取得しました。全体を読んでわざわざわざわざない場合は、要約にスキップしてください。
開発者として、私は文字通り他のすべてのプロジェクトで状況に対処する必要がありましたが、プロジェクト管理に移るまでは、効果的に対処する方法を学びませんでした。私にとって効果的に対処することは、期待の管理と見積もりの仕組みの理解の2つについてです。
最初にある程度の注意を払うことができずに、見積もりを提供したり、見積もりを約束したり、見積もりの正確さを示す他の指標を与えることは非倫理的であるという前提から始めます。他の人々は必要な仕事量を予測するあなたの専門的な能力に依存しており、誤った表示を与えることは彼らと彼らのビジネスを傷つけます。
しかし、あなたは何かを与える必要があります。実際の生活では、即席の会議や後期のプロジェクトに引きずり込まれ、上司はおそらく、すぐに何かを考え出すか、彼らが提供した見積もりについてコメントすることを期待していることを明らかにします。ここで期待管理が行われます。
問題を理解し、自分で数値を計算することなく、図や表示を与えるのは間違っていることを説明してください。彼らの数字はかなり正しいかもしれないと言いますが、自分で推定演習を行う前に分からないだけです。そして、あなたはそこに何がいつ必要かについての良い絵を持っているかもしれませんが、数値を計算するのにまだ時間が必要だと言ってください。彼らがあなたに与えると予想するかもしれない見積もりは1つだけあります：見積もりを提供できるようになるとき。必ずその図を提供してください。
開発者は、他の人の見積もりを最初に確認することなく責任を負わない（または、受け入れと解釈できる指示を与える）ことはありません。プロジェクトマネージャーとしては、まったく異なる問題です。なぜなら、実際に見積もりプロセスをある程度制御できるからです。見積もりを導き出し、確認する方法と、実際の作業を他の人に任せて実行する必要があるため、彼らがコミットされていることを確認してください。
デューデリジェンスを行うことができずに見積もりにコメントすることはありません。これは倫理的です。弁護士または医師は、クライアント（または患者）が自分のルールを順守し、最初に評価手順を実行しない限り、アドバイスを提供できないことを明確にします。同様に、専門家の意見を述べる前に質問に答える権利があります。
2番目の部分は、推定がどのように機能するかについてです。ソフトウェア開発以外の業界（製造、金融市場、建設）を含む、見積もりを行うためのさまざまなアプローチと見積もりプロセスのしくみを調査することをお勧めします。これにより、上司やクライアントが合理的に何を期待できるかがわかり、不思議なことに、作業量についてより正確な予測を行うことができます。それはあなたの見積もりを守るあなたの能力を向上させます、そしてあなたがそれらが建築家または販売員によって提供されたものと異なるときはいつでもそれらの数字を守る必要があります。
通常、それが機能する方法は、推定値が最初にスキャンされて、奇妙に見えるアイテムまたは比較的大きなアイテムがないかどうかです。したがって、「非標準」の名前で何かを守る準備をしてください。また、より大きなタスクを分割して、すべてのタスクの大きさが同じになるようにします。つまり、ほとんどのタスクが2日かかり、1つのタスクが10日である場合は、ドリルする準備をします。
各タスクに何が含まれているのかを明確にしてください。開発者と単体テストを分割して、誰かにドキュメントも含まれていると想定させるのではなく、開発者と単体テストを分けるのが最善です。明らかにこの方法では、かなりきめの細かい見積もりを作成する必要があります。
次に掘削が始まります。長い作業の内訳を確認することは非常に難しいため、クライアントまたは上司は別の戦略を採用する可能性があります。彼らが何かについて知っているかもしれないランダムなビットに集中し、彼らが見積もり全体を信用できないか、あなたに満足するまでドリルダウンします。答えます。推定全体の信頼性は、ランダムなサンプルに依存する可能性があります。したがって、もう一度、注意深く準備し、関連するビットのみを含め、余分なものを除外するか、それらを「Nice to have」セクションに移動して、図をどのように防御するかを検討する時間が必要です。
明らかに、アプローチ、つまり機能、画面数などに基づいて推定する方法に一貫性を持たせることも、複数の方法を組み合わせることもできますが、いずれにせよ、特定の推定方法を選択した理由を弁護する準備をしてください。また、あなたの数値が、必要な作業量を予測しようとする他の人と異なる理由を説明する準備もしてください。
弱い見積もりの明らかな兆候を学ぶ：
テンプレートからコピーされた一般的なありふれたタスクで満たされます（適切な見積もりは、現在のタスクに固有です）。
粗い見積もり（つまり、数日より長いタスク）。
プロジェクトの初期段階で行われた見積もり、または要件や作業に関する実際の知識を持っていない可能性がある人によって行われた見積もり。
実際の実行者以外の人々によって編集された推定値
曖昧な推定（何が含まれているのか、そして同様に重要なのは除外されているのかは明らかではない）。
タスクの大きさのオーダーの実質的な違い。
実装の詳細についての実際の知識がなくても、他の人の見積もりを評価し、数値を掘り下げる練習をします。これにより、明確な証拠がない場合に他の誰かの推定を確認するよう要求されたときに、余計な時間の間あなたの主張を裏付けるのに役立ちます。
要約するには：
あなたがデューデリジェンスをする機会がある前に、その問題についてひどいまたはどんな見積もりにもコミットしないでください。
最初はそれを明確にし、他の方法だと誰にも思い込ませず、沈黙を合意のしるしとして解釈させないでください。
これらの外部ソフトウェア開発を含め、さまざまな推定方法がどのように機能するか、それらの実用的なアプリケーションとメリットを知っています。
あなたの見積もりを守る準備をしてください。
他の人の見積もりを評価する方法を学びます。そうすれば、非常に不正確な数値に自分をコミットする必要がなくなります。
未来を予測することは不可能です。予測（「推定」）を要求することは、単に問題を求めることです。誰もがそれを行い、誰もがそれを間違っています。
「500％減」というあなたの判断は、おそらく建築家の推定と同じくらい間違っています。結局のところ、「...これまでのところ、プロジェクトはまだ完成していません...」ここで入手できる事実はありません。
「正しい」答えは誰にもわかりません。そしてそれが完了するまで、誰も知らないでしょう。
そして、それが完了した後でも、「変更管理の有無にかかわらず」「元の」見積もりは、実際に達成されたものと相関しない場合があります。
見積もりは罠です-それは不正なゲームです。あなたは勝つことができず、あなたは破ることができず、ゲームから抜け出すことさえできません。
編集
間違った見積もりに対処する。 誤って表示される「レガシー」推定。
そこにそれがある。あなたは誰か他の人の見積もりに同意しません。彼らはあなたが必要だと思うものを省いたのでしょう。彼らはあなたとは異なる作業範囲を持っているか、彼らは異なる生産性を持っていました。また、見積もりが単なる努力以上のものである場合は、コスト基準が異なります。それらすべてに異議がある。したがって、見積もりに至るまでの詳細に異議を唱えます。全体の数に異議を唱えないでください-要約には実際の情報はありません。見積もりを支える個々の詳細に異議を唱えます。彼らが何を考えていたかを調べてください。
それはあなたの仮定が彼らの仮定と同じくらい間違っている可能性が高いです。同程度に。
見積もりを求められた場合。
あなたは間違っているでしょう。
彼らは仕事の範囲について嘘をついています。
あなたはチームの生産性を知りません。
どんな新しい技術が関与していても、それは誤って伝えられています。
これらのものをランダムにカバーするためにパディングを単に投入することはできません。あなたは実際には知りませんし、「推定する」ための根拠もありません。それはただの推測です。それを乗り越えなさい。
ルール1：推測しているだけなので、少しずつ推測してください。
「推定する」状況での基本的な問題は、将来を予測するnotです。 1週間か2週間よりずっと長い期間、正確にそれを行うことはできません。予測を、直接的かつ直接的な詳細な知識がある期間に限定します。たとえば、次のリリース。
基本的な質問は、通常、購入者または顧客の意思決定です。問題は「コストはどうなるのか」ではありません。 -それは不完全です。問題は、「投資に価値があるか」ということです。本当の問題は、「費用対効果の比率はどうなっているのか」と「投資を増やしても収益が増加しないので、いつ支出をやめるべきか」ということです。それらは本当の質問です。
ルール2：事実に基づく情報で意思決定者をサポートする。
ほとんどの人は、アジャイルのアプローチが最適です。最初のリリース（今から1か月後）は5人×4週間かかり、1日100万ドルの損失を修正する機能Xと、1週間あたり20万ドルの不足している機会を修正する機能Yを生み出します。あなたは自分が何をしているかについて詳細な知識を持っているので、この予測は理にかなっています。その後のリリースは少しかすんでいます。
今から1年後のリリースは遠い将来であり、乱数の予測はありません。 6か月以上先の詳細については気にせず、単純な経験則を使用してください。
彼らがTCOとは何かを尋ねるとき、あなたは正直でなければなりません。 「開発費の支払いを停止すると、総費用が発生します。支払いを停止するまで、常に費用が発生します。」
本当の質問は、「修正しようとしている問題は何ですか？」または「あなたはどんな新しい機会を追求していますか？」そして、「その価値は何ですか？」
ルール3：ソフトウェアが解決するはずの問題よりもコストを抑えます。
問題をよく知らない場合、推定値は知覚に合うようにゲームされます。これは避けてください。
確率について。衰弱させる病気や事故を除いて、ソフトウェア開発のどの部分も実際の確率に左右されません。 「リスク」は単に悪い管理です。一般的には、「ビジネスニーズAまたはテクノロジーBの複雑さを考慮していません」という形式です。 「スコープクリープ」として罰せられる「問題や技術について詳しく知ると、スケジュールを変更する」という形をとることがよくあります。
物事を学び、範囲を変更する可能性はありません。それは確実です。
計画中。 「計画」と「見積もり」があります。何を構築するかを計画することは1つのことであり、チェックリストまたは依存関係グラフとして最もよく表されます。必要な労力の「見積もり」は、不明な要素に基づいています。
「計画」は普通の良い管理です。
「見積もる」には未知の知識が必要です。正確に「労力を見積もる」には、製品に対するソースコードレベルの洞察が必要であり、そのソースコードを入力する人とその個人が犯す間違いを知っている必要があります。あなたはそれを知ることができないので、どんな見積もりも間違っているに違いありません。そして多くの場合、誤解を招くために役に立たないという点を間違っています。
見積もりが500％アウトでプロジェクトがまだ進んでいる場合、見積もりにはどのような価値がありますか？
なし。それがしたすべては人々を不幸にすることでした。しかし、プロジェクトはとにかく進んだ。
誰も未来を見ることができないので、見積もりrightを取得しても何の意味もありません。それを有用にし、人々が意思決定をするのを助けます。
地平線を短くしてください。できるだけ早く価値を提供します。お客様がいつでもプロジェクトをキャンセルでき、それでも価値があるプランを作成します。
計画がプロジェクトの唯一の「神聖な真実」にならないようにしてください。提供可能な機能は神聖です。成果物が変わると、他のすべても変わるはずです。
計画が生み出す価値を超えないようにしてください。
時間がないと時間が足りません。とにかくプロジェクトを完了するための魔法の解決策はありません。私の意見では、あなたはそれを述べることができるであろうことをしました。彼らは難しい方法でそれを見つけなければならないことがわかりました。それが通常のやり方です。うまくいけば、建築家と経営者は彼らの過ちから学び、二度とそれをしないでください。経営陣があなたの議論に耳を傾け、適切な行動を取ることができないほど平常なビジネスである場合は、他のプロジェクトまたは別の会社を探すことをお勧めします。
「開発者は職人であり、職人に対してあなたができる最悪のことは彼がくだらない製品を届けるようにすることです。」どこかからの有名な引用ですが、どこからか思い出せません。
誠実さは常に尊重されるべきです。私は「建築家のビジョン」の終焉を迎えていました。開発者がソリューション全体が機能しないという悲惨なニュースを聞いてきたとき、私たちはビジネスユニットに行き、ひどい会話をしました。その後、開発者は、機能の80％で構成される新しい見積もりを出しましたが、時間通りに予算通りに納品しました。
ビジネスユニットは、開発者が彼らに誠実に話し、彼の会社の短所を認め、犬のように働いて納品するという事実に勝利しました。彼はいつも正直だったので、この男は過去7年間私たちのために働いていました。
シナリオ全体が非常にまれである-ほとんどの場合、ビジネスユニットは、あなたが配信できなかった馬鹿だと思っています。このように操作しない顧客を探す必要があります。長期的に見ると、あなたをただのように扱いたいだけのクレチンを喜ばせようとするよりも多くの利益を得ることができるからです。
自分の分野を知らない建築家に関しては、ペストのように避けてください。私は厳しい方法で私と一緒に補強するために使用したメンターがいました-「これはそうではありません。間違いを容認するのは、あなたがそれらを早期に作り、修正し、二度とそれを行わない場合だけです。彼らが「コミュニケーション」をとることができるので、技術的でなく、経験の浅い人々を顧客との立場に置くことを許可する企業は、廃業に値する。
私はかつてこの状況に直面していました。これは、ビジネスが要件を変更し、コミュニケーションのギャップがあり、上級管理職がプロジェクトを時間どおりに計画したかったためです。さらに悪いことに、このプロジェクトに取り組んでいた1人の男が、優先順位の高い別のギャップを埋めるために引き抜かれました。
私のチームはプロジェクトを完了するために夜を費やしていました。ある夜遅くの午前3時頃（私は19時間ずっと働いていました）私はそれについて何かをするようにマネージャーにメールを送りました。
翌日、ミーティングがありました（開発者のみ）。 週末にチーム全体がやって来て、プロジェクトが完成する前にテストを行いました。迅速な修正を行うためにチームに加わった人はほとんどいませんでした。ついに、チーム全体の努力でプロジェクトを提供することができました（そうではありません）プロジェクトチームのみです。他のプロジェクトについても同じプロセスに従いました。
チーム全体（プロジェクトに関与していない場合でも）がアプリケーションをテストし、バグの迅速な修正を支援しました。
注：私のチームは約25人で構成されており、サブプロジェクトもさまざまなプロジェクトに取り組んでいます。
私の唯一のアドバイスは、「マネージャーに話してください。プロジェクトが時間どおりに配達されないことをしっかりと伝えてください。また、代替案を与えてください。マネージャーは、赤ちゃんが時間どおりに配達されることを常に期待しています:)」
企業は、物事が予想よりもはるかに長くかかるという真実を好まないことがよくありますが、彼らはさらに少ないことを望んでいます。実際にどれだけ時間がかかるかを誰かに早く知らせれば、誰もが状況を迅速に計画できます。これは最初は困難な時期になる可能性がありますが、長期的には容易になります。ちょうどそれを2回目に正しくして、不測の事態に備えてください。
あなたの経営に対処する際の重要なポイントの1つを強調しておきます。マネージャーはソリューションを高く評価しています。
問題を抱えて経営陣に行く必要がある場合（たとえば、見積もりが非常に非現実的である場合）は、状況に対処する方法の代替案を含めるように事前に懸命に作業してください。たとえば、システムの価値を理解するためにパレート分析（80/20ルール）を行うことができ、（少なくとも最初のリリースから）フィーチャーをカットするための優先順位付けされたケースを作成して、最大のビジネス価値を持つフィーチャーに集中することができます。システムのカスタムパーツなどの適切な代替品である代替案（オープンソースプロジェクトなど）を探すことができます。
5ポンドのバッグには25ポンドの砂が入らないことは間違いありませんが、経営者が不愉快なメッセージを吸収するのを助けるための一部は、あなたが熱心な同盟者であることの証拠を提供しています。
最初に、問題のある建築家に非公式に話し、問題のリストを彼の見積もりで確認し、問題がどこにあるか、そして解決するのにかかる時間の違いを彼に納得させます。
それから私はあなたのラインマネージャー/プロジェクトマネージャーに行き、彼/彼らとそれについて話し合うつもりです。
結局、アーキテクトはESTIMATESを提供しました。そのため、変更が加えられる場合があり、場合によっては大幅に変更される可能性があります。これは、それを認識している限り、製品のロールアウトなどの代替計画を立てることができます。フェーズ、機能やその他の手段を減らします。
結局のところ、あなたが上記を行ったら、それはもはやあなたの責任ではありません。
あなたは間違いなく直接クライアントや建築家の上司に行くべきではありません、これは悪感情を助長するだけであり、ほとんど常にあなたはいくつかの非難を受けるでしょう。
あなたができる最善のことは、あなた（この場合、あなた個人ではなく）の悪い見積もりから学ぶことです。学ぶべきことの1つは、アイデアを実装する人以外の誰かに、それがかかる時間を決して見積もらせないことです。プログラマの速度は桁違いに変化する可能性があるため、他の誰かのために推定することはほぼ不可能です。
私はあなたの痛みを感じます...私はこのすべての欲求不満を処理する方法がわかりません:(
https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target
過去には、営業部が顧客に支払うと考えている数字を満たすために見積もりを大幅に削減したプロジェクトマネージャーに対処する必要がありました。マネージャーは許可を求めるより許しを請う方が良いとの意見でした。
開発者がマネージャによってカットされることを知っているので、これが開発者が彼らの見積もりを埋めることを学んだ理由です。したがって、見積もりを2倍にして30％を追加すると、妥当なスケジュールを取得できる可能性が高くなります。
顧客は常にそれをもっと安くしたいと思っており、妥当な見積もりで彼らに来た場合、彼らはそれを躊躇し、あなたにコスト削減または彼らが歩くことを要求します。しかし、あなたが高すぎると、彼らは議論せずに歩いて行きます（「私たちはそれを考慮してあなたに戻ります」）。
それは、管理された期待のゲームです。
問題は、当初の見積もりが出ていないことではなく、経営陣があなたを信じていなかったということです。
経営陣に意思決定をさせる最良の方法は、次のとおりです。
- 問題を証拠で説明し、それをバックアップします。そして
- 彼らが選択できる複数のソリューションを提供します（最も好ましいものから最も好ましいものへの順序で）。
（1）については、スクラムを実装し、危険な見積もりに対して実績を追跡することは、主張を裏付けるためにうまく機能します。
（2）の場合、私の選択肢の1つは、「クライアントを使用して優先機能リストを開発する（別名、スクラム用語での製品バックログ）」です。これは、固定価格または非常に官僚的な組織ではトリッキーですが、 それは可能です です。
お役に立てば幸いです。
私は（コードを書いているすべての人について確信しているように）共感します。私の最後の会社はこれについてかなりひどいものでした-営業担当者がプロジェクトを売り込んでから、あなたは入って見積もりを見て、ただ笑います。
トムが述べたように-一日の時間はそんなにありません。寝なくても。
３つあると思います。
ほとんどの場合、クライアントの期待を管理するおよび透過的にする必要があります。何ができるかを率直に示し、何を成し遂げたかを示します-それがすべてです。 （Totophilが述べたように）非常に粗くチャンクアップされた要件を渡された場合、これは特に当てはまります。彼らがあなたがしなければならなかった仕事の量を見ることができれば、彼らは見積もりがいかに悪いかを知ることができます。彼らが生産性と進歩を見るならば、それは私の経験の何よりも重要です。
期待を管理し、ワークロードで透過的であることに加えて、他の大きなことはスコープ管理だと思います。スコープナチであることであなたの肛門/攻撃的であることとあなた自身の尻尾をカバーすることの間には大きな領域があります。誰かがこの追加の機能を望んでいるとき-それに同意してください！そして、プロジェクト（または次のリリース）に追加される時間について、比較的正確な見積もりを与えます。これの利点は、だけではありません別の80時間の週に身を詰め込む-あなたはその見積もりにもいくつかのパッドを手に入れ、他の人に追いつく可能性があります。
幸運を！
それを見たり理解したりせずに、何もしないでください。顧客またはあなた自身の管理者があなたにそんなにお金を払う気がないなら、彼らはあなたが成功するように設定していません。
これは、詳細、データ、および構築中のアプリケーション全体でそれらがどのように相互作用するかを理解するのに失敗した（そして多くの場合はそうです）。質問をし、答えを見つけ、それをすべて明らかにする代わりに、仮定が行われます。
クライアントによく言うことの1つは、あなたが私を首つりにするつもりなら、少なくとも私は自分のロープで首を吊るすか、誰か他の人ではなく自分の銃と弾丸で撃たせてください。 =
それを解決しようとする人々の回転ドアを持っていることは、最終的に彼らにとってはるかに悪いでしょう。
非現実的で不十分な計画と見通しの欠如は、組織全体の問題の兆候である可能性があり、その場合はそれに慣れるか、先に進みます。
まず、プロジェクトの範囲を過大評価している可能性を検討します。営業担当者やアーキテクトは、ソリューションを誇張する傾向があります。それらを額面どおりに受け取らないでください。彼らはおそらくあなたが顧客と約束したよりも少ないものを思いつくことを期待しています。
私がここでやろうとしていることは、私が持っている時間をかけて、できる限り賢く使うことです。顧客の優先順位を把握し、それを実現します。 10回のうち9回は、顧客は自分の最優先事項が満たされたことに満足し、行われていない作業の80％を見落とします。
あなたがしたい最後のことは、緊急会議に電話をかけ、人々が邪悪であると非難することです。あなたは言う：
「彼らに現実を知らせなさい」
しかし、現実は単なる意見です！リラックスして仕事をして、重要なことにあなたに政治的資本を費やしてください。プロモーション、お金、休日など。
あなたのためにプロモーションを取引する上司が顧客に本当に一生懸命取り組んでいるのは理にかなっています。顧客に代わって問題を解決することはありません。
覚えておくべきことの1つは、見積もりにはスコープのクリープまたは不可避の遅延（またはクライアントが特定の形式の情報のファイルなど、彼らがそうするだろうと言ったことを与えていないことに基づく問題）が含まれないことです。
これらのいずれかが発生するたびに、見積もりと期日の両方またはいずれかをプッシュバックすることを学びました。新しい機能を追加し、新しい見積もりと新しい期日を取得します。合意された日に必要な情報を提供できなかった場合は、新しい期日を取得してください。情報を提供しますが、それを不完全または不正確にするか、約束された以外の方法で、新しい見積もりと納期を送信し、合意された機能の要件を変更し、新しい見積もりと納期を取得します。クライアントがより高い優先度で作業することを望んでいたため、プロジェクトでの作業を停止し、新しい納期を送信します（プロジェクトが長期間保留されている場合は追いつき時間が発生する可能性があるため、場合によっては新しい見積もりになります）。
元の推定値が開発グループの外から来たもので、それについて検討されなかった場合、それを入手したら、自分の推定値を準備します（予想されるすべてのタスクの詳細レベルで-はるかに高いレベルで）与えられた見積もりよりも詳細な情報を提供します）、すぐにそれをチェーンに提供し、与えられた見積もりを満たすために何を切り取るべきかを尋ねます。
答えが何もない場合は、問題をより詳細に検討したので、クライアントに新しい見積もりを通知するように要求します。クライアントがX時間のみを支払うことを経営者が主張する場合、説明された仕事はあなたの見積もり未満では実行できないので、残りの開発時間を誰が支払うかを彼らに尋ねます。それは会社がヒットを取り、彼ら自身のために時間を支払う用意があると判明するかもしれません。
彼らが利益からそれを取りたくない場合、彼らはクライアントにもっと時間を必要とすることを知らせず、会社は販売に関する開発スタッフの詳細な見積もりを返さないでしょう。 「プロジェクトを勝つために」という見積もりの場合、あなたは死の行進プロジェクトに参加しています。最善の策は、できるだけ早く出ることです。あなたが支払うことに同意した50時間を費やすときよりもプロジェクトができるだけ早くかかることをクライアントが知っている方がクライアントが幸せになることを指摘することができ、あなたが本当に必要とする500で完了しさえしていません。過度に楽観的な見積もりは、プロジェクトの失敗を予測する最大の要因の1つであることを伝えます。これらのタイプの企業では機能しませんが、十分な回数繰り返すと、最終的には沈み込むでしょう。
見積もりの改善も考慮に入れます。 「今見ているように、このプロジェクトはX工数かかる」という意味です。 20〜30％後、私は再見積もりします。
結局のところ、ファイルダウンローダーはどのようにしてその推定を行うのでしょうか。それは常にそれを洗練させます。
十分な見積り担当者は、「見積りは、数学を実行するように求め、推測を使用して将来を予測するのに役立つ方法である」および「私たちが行うコミットメントは、見積もりを作成します。私たちは、ばかげた量の作業を行うことに同意でき、完了できないと思われることに同意できますが、これらのどれも実際にソリューションのmathを変更しません機能の巨大なバッチAではない開発方法論Aは日付Bまでに行われるため、失敗する可能性ははるかに低くなります。」
多くの見積もりには、交渉の言葉が使われています。彼らはmathの言語でしゃべられ、mathの不確実性について話す必要があります。
見積もり担当者は、ビジネスマンが交渉する意思に現実を曲げることはできません。彼の唯一の仕事は、彼らにやめさせることです。