もしそうなら、なぜですか？いくら？
楽観的すぎるので、少し膨らませる傾向があります。
7487 次
51 に答える
143
ホフスタッターの法則: どんなコンピューティング プロジェクトでも、ホフスタッターの法則を考慮したとしても、予想の 2 倍の時間がかかります。
于 2009-02-11T16:16:57.270 に答える
58
過去の経験に基づいて見積もりを膨らませて、生来の楽観主義を補おうとしても、膨らませることにはなりません。正確な見積もりを提供しようとしています。ただし、常に綿毛の時間があるように膨らませる場合、それはあまり良くありません。
于 2009-02-11T16:17:29.123 に答える
52
そうそう、私は常に最初の見積もりを 2 倍にすることを学びました。だからこそ、FogBUGZ のエビデンスベースのスケジューリングツールは非常に便利です。
于 2009-02-11T16:15:54.153 に答える
42
プログラマーに大まかな機能の時間を見積もるよう求める組織は、根本的に壊れています。
解除する手順:
- テクニカル プログラム マネージャーを雇う。開発者は、必要に応じてこれらの人々を兼ねることができます。
- 機能要求、変更要求、またはバグが発生したら、すぐにデータベースに入れます (私の組織では Trac を使用していますが、完全にうまくいかないわけではありません)。
- PM に、これらの要求を 1 週間以内のステップに分割してもらいます。
- 毎週のミーティングで、PM はその週にどのチケットを処理するかを決定します (おそらく、マーケティングなどからの情報に基づいて)。それらのチケットを開発者に割り当てます。
- 開発者は、割り当てられたチケットをできるだけ多く終わらせます。または、1 週間以上かかると思われるタスクについて PM と議論します。チケットは、必要に応じて調整、分割、再割り当てなどを行います。
- コードは毎週作成され、チェックインされます。QA には常にやるべきことがあります。最も優先度の高い変更が最初に実行されます。マーケティング担当者は、いつ、何がパイプから流れてくるかを正確に把握しています。そして最終的に：
- あなたの会社は、ソフトウェア プロジェクトの成功率 20% の右側にあります。
それはロケット科学ではありません。重要なのはステップ 3 です。マーケティング担当者が複雑に見えるものを求めている場合、PM は (開発者の意見を聞きながら) 1 週間もかからない最初のステップを見つけ出します。PM が技術者でない場合、すべてが失われます。
このアプローチの欠点:
- マーケティング担当者が「[X] を取得するのにどのくらいかかりますか?」と尋ねても、見積もりは得られません。しかし、彼らが以前に得た見積もりが純粋なフィクションであることは、私たち全員が知っています。少なくとも今では、[X] が取り組んでいる証拠を毎週見ることができます。
- 私たちは開発者として、毎週取り組んでいることの選択肢が少なくなっています。これは間違いなく真実です。ただし、2 つのポイントがあります。まず、優れたチームは、どのチケットを割り当てるかの決定に開発者を関与させます。第二に、IMO、これは実際に私の人生をより良くします。
1 か月の時点で、私が示した 2 か月の見積もりが絶望的に不十分であり、変更できないことに気付くことほどがっかりすることはありません。見積もりを変更したり、悪い評価を付けたり、ボーナスを逃したりして、上層部を怒らせたり、無給の残業をたくさんしたりします。多くの残業は、悪い開発者や「情熱的な」開発者のしるしではなく、有毒な文化の産物であることに気づきました。
ええ、このようなことの多くは (さまざまに) XP、「アジャイル」、SCRUM などでカバーされていますが、実際にはそれほど複雑ではありません。それを行うために本やコンサルタントは必要ありません。必要なのは企業の意志だけです。
于 2009-02-17T04:37:48.227 に答える
37
スコッティ ルール:
- あなたの最善の推測をしてください
- 最も近い整数に切り上げる
その4倍の2倍（Adamに感謝！）- 次に高い測定単位に増加
例：
- 3.5時間かかると思いますか
- それを4時間に丸める
- その4倍の16時間
- 16日までシフト
たーだぁ！8 日以内にそれを成し遂げたとき、あなたは奇跡の労働者です。
于 2009-02-11T19:30:34.387 に答える
25
通常はそうですが、私には2つの戦略があります。
- 推定値は、単一の数値ではなく、常に範囲（つまり、1d〜2d）として提供してください。数字の違いは、プロジェクトマネージャーにあなたの自信について何かを伝え、彼らがより良い計画を立てることを可能にします。
- FogBugzのEvidenceBased-Schedulingや個人用スプレッドシートなどを使用して、過去の見積もりと実際にかかった時間とを比較します。これにより、常に2倍にするよりも優れたアイデアが得られます。特に、倍増では不十分な場合があるためです。
于 2009-02-11T16:19:24.253 に答える
25
3～6週間でお答えできます。
于 2009-02-11T18:51:13.310 に答える
23
それは「膨らませる」とは呼ばず、「リモートでリアルにする」と呼ばれます。
于 2009-02-11T16:25:54.410 に答える
18
適切と思われる見積もりを取ります。次にそれを2倍にします。
于 2009-02-11T16:15:20.907 に答える
17
あなた (エンジニア) が実際に理想的な時間 (スクラム期間) を見積もることを忘れないでください。
管理は実際の時間で作業します。
違いは、理想的な時間は中断のない時間です (各中断の後に 30 分間のウォームアップを行います)。理想的な時間には、会議の時間、昼食の時間、または通常のおしゃべりの時間などは含まれません。
これらすべてを考慮に入れると、理想的な時間は実際の時間に近づく傾向があります。
例: 推定時間 40 時間 (理想) 経営陣は、それがリアルタイムで 1 週間であると想定します。
その 40 時間をリアルタイムに換算すると、次のようになります。
- 1 日 1 回の会議を想定 (所要時間 1 時間)
- 1日1回の昼食休憩（1時間）
- おしゃべりのバスルームでコーヒーを飲んだりするための 20% のオーバーヘッドが追加されます。
8 時間の 1 日が 5 時間の作業時間 (8 - 会議 - 昼食 - ウォームアップ) になりました。
80% の効率を掛ける = 1 日あたりの理想的な時間は 4 時間です。
この 40 時間の理想は、実際には 80 時間かかります。
于 2009-03-14T00:08:07.987 に答える
12
経験則として、次の問題をカバーするためにかかる時間を見積もり、さらに1/2の時間を追加します。
- 要件が変更されます
- あなたは迅速な修正のために別のプロジェクトに引っ張られます
- 次の机の新しい人は何かを手伝う必要があります
- あなたが物事を行うためのより良い方法を見つけたので、プロジェクトの一部をリファクタリングするのに必要な時間
于 2009-02-11T16:25:46.890 に答える
10
<sneaky>
プロジェクトの見積もりを膨らませる代わりに、各タスクを個別に膨らませます。誰があなたと何分も議論することになるので、上司がこの方法であなたの見積もりに異議を唱えるのは難しい.
</こっそり>
しかし、真剣に、EBS を使用することで、人々は通常、大きなタスクよりも小さなタスクを見積もる方がはるかに優れていることがわかりました。プロジェクトを 4 か月と見積もった場合、完了するまでに 7 か月かかる可能性があります。そうでないかもしれません。一方、タスクの見積もりが 35 分である場合、通常はほぼ適切です。
FogBugz の EBS システムは、見積もり履歴のグラフを表示します。私の経験から (他の人のグラフも見てみると)、人々は短いタスクを見積もるのにはるかに優れています。したがって、私の提案は、プロジェクトのブードゥー乗算を合計として行うのではなく、前もってプロジェクトを非常に小さなタスクに分割して、見積もりがはるかに優れているようにすることです。
次に、全体に 3.14 を掛けます。
于 2009-02-11T18:38:38.990 に答える
6
取得したい詳細度に大きく依存しますが、追加の「バッファ」時間は、タスク レベルでのリスク評価に基づいている必要があります。ここでは、さまざまなバッファ時間を設定します。 高リスク: 50% から 100% 中リスク: 25% から 50% 低リスク: 10% から 25% (すべて以前のプロジェクト経験に依存)。
リスク領域は次のとおりです。
- 要件カバレッジの推定 (#1 のリスク領域は、設計および要件レベルでコンポーネントが欠落している)
- 使われている技術の知識
- リソースに対する知識/自信
- あなたのプロジェクトに影響を与える他のプロジェクト、リソースの変更などの外的要因。
したがって、コンポーネント A をカバーする特定のタスク (またはタスクのグループ) の場合、最初の見積もりは 5 日であり、要件範囲に基づいてリスクが高いと見なされます - 50% から 100% の間で追加できます。
于 2009-02-11T17:47:35.257 に答える
4
プロジェクトの期間は2つの方法で計算できます。1つは、関連するすべてのタスクを計算し、それぞれにかかる時間を計算し、遅延、会議、問題などを考慮に入れることです。この数字は常にひどく短く見えるため、人々は常に物事を言います'doubleit'のように。プロジェクトの提供をある程度経験した後は、スペックを簡単に見るだけで、どれくらいの時間がかかるかをすばやく知ることができます。常に、最初の方法で到達した数値の2倍になります...
于 2009-02-11T16:58:29.620 に答える
4
過去の経験に基づいて、より現実的な期待を設定しようとする限り、私はそれらを膨らませるとは言いません.
于 2009-02-11T16:17:10.687 に答える
4
合計時間を単純に膨らませるよりも、デバッグやテストなどのために特定のバッファ時間を追加することをお勧めします。また、事前に時間を取って作業の断片を実際に計画することで、見積もり自体がはるかに簡単になります (おそらくコーディングも)。
どちらかといえば、すべての見積もりを記録し、実際の完了時間と比較して、どれだけ過小評価する傾向があり、どのような条件下であるかを把握してください。このようにして、より正確に「膨らませる」ことができます。
于 2009-02-11T17:24:55.623 に答える
3
約束不足、配信超過。
于 2009-09-10T02:50:39.603 に答える
3
私はそれらを膨らませるとは言いませんが、プロジェクトに関与する可能性のあるすべてのタスクにテンプレートを使用したいと思っています.
リスト内のすべてのタスクがすべてのプロジェクトに適用できるわけではないことがわかりますが、リストがあるということは、タスクに時間を割くのを忘れて、タスクをすり抜けてしまうことがないことを意味します。
新しいタスクが必要であることがわかったら、それらをリストに追加します。
このようにして、現実的な見積もりを得ることができます。
私は何が達成可能かについて楽観的である傾向があるため、低い方で見積もる傾向があります。しかし、私は自分自身についてそれを知っているので、15〜20％余分に追加する傾向があります.
また、実績と見積もりを追跡します。また、関連する時間に他の中断が含まれていないことを確認してください。フローに戻る方法に関する SO の質問に対する受け入れられた回答を参照してください。
HTH
乾杯
于 2009-02-11T16:29:02.763 に答える
3
最初の見積もりよりかなり前にプロジェクトを実際に完了しない限り、プロジェクトの追加の見積もり時間を「膨らませた」とは呼びません。当初の見積もり時間よりもかなり前にプロジェクトを完了する習慣を常につけておけば、プロジェクト リーダーは賢明になり、より早く完了することを期待します。
于 2009-02-11T16:34:43.543 に答える
3
あなたの見積もりは何に基づいていますか？
必要なコードの量とそのコードを記述するのにどれくらいの時間がかかるかについての漠然とした直感に基づいている場合は、考えもしなかったサブタスク、通信、同期を説明するために LOT をパディングすることをお勧めします。オーバーヘッド、および予期しない問題。もちろん、そのような見積もりはとにかくほとんど価値がありません。
OTOH、あなたの見積もりが、特定のテクノロジーと開発者の数でその範囲のタスクを実行するのに最後にかかった時間の具体的な知識に基づいている場合、上記のインフレ要因はすでに含まれているはずなので、インフレは必要ありません過去の経験。もちろん、現在のプロジェクトに影響を与える予測できない新しい要因がおそらくあるでしょう。そのようなリスクは、ある程度の追加パディングを正当化します。
于 2009-02-11T17:37:53.987 に答える
3
これが、アジャイル チームがストーリー ポイント(恣意的で相対的な測定単位) でタスクを見積もる理由の1 つです。次に、プロジェクトの進行に伴い、チームの速度 (1 日あたりに完了するストーリー ポイント) を追跡します。このデータを使用すると、完了日を理論的に正確に計算できます。
于 2009-02-11T17:41:26.613 に答える
3
最悪のシナリオを考えて、それを 2 倍にしますが、それでも十分ではありません。
于 2009-02-11T21:36:07.233 に答える
2
私の一般的な見積もりはguess * 2.5 + 1 weekです。
于 2009-03-11T20:28:34.047 に答える
2
そうそう、長い経験から得た一般的なルールは、プロジェクトにかかる時間の最善の見積もりを与えることです。それを 2 倍にしてください。
于 2009-02-11T16:16:01.937 に答える
2
多くの人が言うように、経験とリスクの微妙なバランスです。
常にプロジェクトを扱いやすい部分に分解することから始めます。実際、同じ日に開始して終了することを簡単に想像できるようにします。
やり方がわからないとき（初めてのときなど）はリスクが高くなる
リスクが高くなった場合は、最善の推測から始めて、それを 2 倍にして予期しない部分をカバーしますが、プロジェクト全体ではなく、プロジェクトの小さな部分でそれを行っていることを忘れないでください。
入力の品質や、必要なすべてを実行できるように見えるがテストしたことのないライブラリなど、制御できない要因がある場合にも、リスクが高まります。
もちろん、特定のタスク (モデルをデータベースに接続するなど) で経験を積むと、リスクは低下します。
すべてを合計して小計を取得します...
次に、プロジェクト全体で、あなたが待っているすべての回答/ドキュメント/OK、私たちが常に忘れている会議、その間のアイデアの変更のために、常に約20〜30％を追加します（その数は会社によって異なります）。プロジェクトなど...それは私たちが人的/政治的要因と呼んでいるものです
また、上司や顧客に最初に見せるときなど、通常自分で行うテスト以外のテストと修正を説明するために、さらに 30 ～ 40% を追加します。
もちろん、これらすべてを見ると、魔法の「ダブルイット」式で単純化できることになりますが、違いは、タイトな締め切りの中で何を絞ることができるか、何ができるかを知ることができるということです。コミットする、危険なタスクとは何か、重要なマイルストーンでスケジュールを立てる方法など。
それぞれの純粋な「コーディング」タスクに費やされた時間を書き留めて、そのリスクに関する見積もりと比較すれば、そう遠くないことは間違いありません。問題は、先のすべての小さな断片を考えて、ハードルなしで何ができるかについて (楽観的ではなく) 現実的になることは容易ではないということです。
于 2009-02-11T20:09:50.000 に答える
2
次の理由から、私は常に見積もりを 2 倍にします。
1) マーフィーの法則のバッファ。あなたが説明できない何かが常にどこかでうまくいかないでしょう。
2) 過小評価。プログラマーは常に、物事は簡単にできると考えています。「ええ、数日かかります。」
3) 交渉スペース。上層部は常にスケジュールを短縮できると考えています。「開発者をもっと働かせてください！」これにより、彼らが望むものを与えることができます。もちろん、これを (複数回) 使いすぎると、常に過大評価していると想定するように訓練されます。
注: 各タスクではなく、プロジェクト スケジュールの最後にバッファを配置することをお勧めします。また、バッファーが存在することを開発者に決して伝えないでください。そうしないと、パーキンソンの法則 (作業は完了までに利用可能な時間を埋めるように拡大する) が代わりに有効になります。時々、私は上層部にバッファーが存在することを伝えますが、明らかに正当化する理由 3 を彼らに伝えません。これはもちろん、上司があなたの誠実さをどれだけ信頼しているかにかかっています。
于 2009-03-20T10:34:57.113 に答える
2
私たちの愚かなマネージャーは常に何の正当化もなくそれらを減らすので、私たちはしなければなりません。もちろん、彼が私たちがこれを行っていることに気付くとすぐに、私たちは軍拡競争に巻き込まれます...
私は、ダイアログの文言を変更するために 2 年間の見積もりを提出する最初の人になることを完全に期待しています。
ため息。
于 2009-02-11T18:06:55.057 に答える
2
私はいつそれを成し遂げることができるかを言います。変更要求があった場合は、「はい、できます」ではなく、新しい見積もりでフォローアップするようにしています。言うまでもなく、もっと時間がかかります。変更を要求する人は、それ以上かかるとは思いません。
于 2009-02-11T22:24:36.603 に答える
1
私は、最も可能性の高い最悪のシナリオを解決するほど「膨らませる」ことはしません。プロジェクトの複雑さによっては、予期せぬ状況を説明するために、さらに多くのパディングを行う場合があります。
私のプロジェクトが「最悪のシナリオ」の状態に達することはめったにないので、通常は見積もり時間より前に完了しますが、見積もり目的には十分近いです。早すぎるか遅すぎるかの選択肢が与えられた場合、私は毎回早くします。
于 2009-02-12T02:09:02.007 に答える
1
ここにいる多くの人は、見積もってそれを 2 倍にする (そして時にはさらに 2 倍にする) と言っています。他の人は、エビデンスベースのスケジューリングを使用すると言っています (al la Joel)。
プロジェクトを見積もるとき、各タスクには次の 4 つのコンポーネントがあります。
- どれくらいの時間がかかるかについての私の最善の推測。
- 不確実性 (リスク) - おそらく仕様に含まれていない何か (既知/未知の未知) があり、時間が 2 倍になります。
- バグの修正
- コンティンジェンシー・タイム
#1 については、可能な限り最も現実的な見積もりを使用します。
#2 については、リスクの可能性を決定し、それを #1
に掛けて調整済み推定値を取得します。#3 と #4 については、調整済み推定値に 20% を掛けて、それがそれぞれの値になります。
したがって、どのタスクでも、最終的な合計は元の見積もりの 140% 以上になります。
プロジェクト全体では、不測の事態とバグ修正が 2 つの別々のタスクにまとめられ、プロジェクトの進行に伴って食い込まれます。
もちろん、これには通常、各タスクの合計値に等しくするテストは含まれていません。
于 2009-02-11T17:35:53.243 に答える
1
はい、膨らませます。しかし、十分ではありません。
于 2009-07-08T19:09:16.503 に答える
1
私は通常、プロジェクトを評価してから最初の 10 分以内に、最初に考えた時間の約 250% を費やします。最初の 100% は、すぐに実行できるとわかっていること、次の 100% は不測の事態のための追加、最後の 50% は「他の人とのコミュニケーション」です。
私にとってはうまくいくようです。
于 2009-03-15T21:47:53.103 に答える
1
私の見積もりは通常非常に正確です (20 年の経験から得られたものです) が、それでも通常は私の見積もりを少し膨らませます。ボーナスタイムに関しては、約束を怠り、過剰に提供する方が常に良いです:-)
それでも、あなたのプロジェクト マネージャーが何らかの価値がある場合、見積もりをどうするかはほとんど変わらないはずです (中には、消費する酸素に見合わない人もいますが、少数派だと思います)。
彼らは、実際の見積もりに対して見積もりを追跡し、その情報を使用して次の見積もりを調整してから、プロジェクト計画に入力します。これにより、特定のタスクをどの程度正確に見積もっているかを正確に把握できます (私は常に、UI、DBMS、ミドルウェアなどのタイプとサイズ/複雑さに基づいています)。
次に、UI タスクを継続的に過小評価していることがわかった場合、次の反復でそれらを増やす必要があることがわかります。彼らは、あなたがいくつかの仕事をこなしていることがわかれば、あなたの見積もりを引き下げる必要があることを知っているでしょう。これには、時間の経過とともに自動的に調整されるという利点があります。
真剣に、PM は 1 日中何もせずに座っていると考える人もいますが、その仕事の背後には少なくともわずかな工学と科学があります。コードカットへの情熱に戻る前は、私もその一人でした。
于 2009-03-17T01:38:01.093 に答える
1
- できるだけ正確であると思われる見積もりを計算します。
- 2倍にします。
- 結果を引用しますが、「プラスまたはマイナス 25%」を追加します。
たとえば、6 営業日かかると思われる場合は、「12 営業日プラスマイナス 3 営業日」と予測します。
于 2009-03-15T21:56:33.240 に答える
1
私の友人は、彼がこのアルゴリズムを使用していると私に言ったことがあります:
- 見積もりをする
- 値0.5を下回らないように、できる限り最大の時間単位で表現してください
- x（単位）としましょう
- 結果は2*x+2 (単位)
于 2009-02-11T17:42:48.157 に答える
1
私は見積もりを膨らませません。
于 2009-02-11T17:54:02.683 に答える
1
この現在のプロジェクトの開始時に、当時のプロジェクト マネージャーが 6 週間後にすぐに見積もりを出したことを覚えています。
私の目は彼らのソケットから膨らんでいます！私たちが取り組む方法さえ知らなかった分野がまだ山のようにあることを知っています。彼はより多くの「経験」を持っていたので、この男は上級でした
言うまでもなく、6 週間後も仕様はまだ作成中で、実質的にコードは検討されていませんでした。
最終的にはチームを縮小し（私だけに！）、実際の進歩がついに実現しました。私は昔、契約書の製図工として正確に見積もる方法を学びました。
関連する主なスキルは 2 つあります。
まず、見積もり を練習します。さまざまなプロジェクトを実際に見積もってみることに勝るものはありません - あなたがプロジェクトマネージャーでなくても、間違っているかどうかは問題ではありません - しかし、あなたが行うすべてのプロジェクトの内部見積もりを保管してください (まあ、あなたがプロジェクトマネージャーです）
第二に、ほとんどのプロジェクトの爆発はプロジェクトの依存関係によるものです。これらを事前に特定することは、失敗した場合にプロジェクトを脱線させる可能性のある要因を知るために重要です。
于 2009-03-15T21:59:22.343 に答える
1
二週間。
業界標準: すべてのリクエストには 2 週間かかります。長くなるものもあれば、短くなるものもあり、最終的にはすべてが平均化されます。
于 2009-02-11T17:58:37.197 に答える
1
私は50％を追加します。ただし、クライアントと以前に仕事をしたことがあり、クライアントが最後に変更を加えるのが好きだとわかっている場合は、2 倍以上になる可能性があります。私はできる限り未知のものを予測しようとします... 成功することもあれば、失敗することもあります。
于 2009-03-16T23:10:42.443 に答える
0
ほとんどの開発者は、多くのテスト時間、多くのバグ修正時間、または管理オーバーヘッド（電子メール、コーヒー、会議など）を考慮に入れていないことを念頭に置いて、一部のグループは週に20時間しかスケジュールしないか、少なくとも2.5を掛けます。
于 2009-05-10T04:13:05.423 に答える
0
見積もりを現実に近づけるために見積もりを 2 倍にしたり膨らませたりしなければならない場合、最初の見積もりは明らかに間違っているか不完全でした。見積もりには、タスクで発生する可能性のあるすべての要因を含める必要があります。正当な理由なしに余分な時間を追加することは、a ** をカバーするだけです。安全のために X を追加するだけでなく、全額の背後に理由があるはずです。再設計と微調整があることがわかっている場合は、会議、テスト、バグ修正などと同じように、それらを考慮に入れます。
適切な見積もりは atcuals と一致するか、近いはずです。そうでない場合、見積もりは正しくありません。
目標は、実際の値をできるだけ見積もりに近づけることです。見積もりゲームの IMHO で、大幅に下回ることは、上回ることと同じくらい悪いことです。
于 2009-02-11T19:21:09.760 に答える
0
コンサルティング会社の場合は、見積もりのパディングが多すぎることについて十分に注意する必要があります。あなたは利益を上げる必要がありますよね？リソースが次の割り当てをすぐに受けられないように保護している場合、それはできません。また、どのようなプロジェクトに着手するかを検討してください。お客様と T&M を行うことはできますか? そうでない場合、固定入札を提供せざるを得ない場合は、固定期間も含めて、リスクをクライアントと共有します。この議論のさまざまな話題を台無しにした同僚が何人いるかはわかりません。PM として、あなたはステップアップしなければなりません。a) 納期を確実に守るために、小さくて妥当なパディングを提供し、b) 固定入札プロジェクトに伴うリスクについて交渉し、共有するために、SOW に適切な文言を盛り込む必要があります。あなたを保護し、c) あなた' 仕事を勝ち取ろうとしていますよね？競争力を維持するために、計画段階でAチームが見積もりを確実に入手できるように行動してください。
WPF と Silverlight はかなり新しいものですが、競合他社からの入札が急速に増えています。
トピックから少し外れますが、セールスとプロジェクトについて交渉する際に、お客様があなたのチームの熱意を理解できるようにします。優れた PM は、新しい顧客から尊敬と信頼を得るのに役立ちます。
内部資金によるプロジェクトについて話すとき、ほとんど違いはありません。野獣の性質と非難のライフサイクル、およびこれらのタイプのプロジェクトの多くからの要件により、リスクが高く短期間の外部プロジェクトよりも強力なプロジェクト管理が必要です。
最後に、作業を実行するリソースから同意を得る必要があります。チーム リーダーは見積もりを評価し、見積もりが高いか低いかを判断できる必要があります。すべてのプロジェクトで ROI を達成できなければならないため、必要以上に見積もりをパディングしなければならない場合があります。しかし、本当に仕事が小さく、B または C のリソース チームをプロジェクトに投入しなければならない場合は、入札額が高すぎる場合はその機会を検討してください。それが重要なビジネス上の意味を持たない限り、それをやってのけるリソースが本当にない場合は、ギグをすることは避けてください. この経済では、それが常に選択肢になるわけではありません。
于 2009-03-20T10:24:25.670 に答える
0
私はプロジェクトの時間見積もりを絶対に避けます。代わりに、最初のマイルストーンまでの時間を予測し、完了に向けてマイルストーンを計画し、進行中の保留中のマイルストーンを定期的に確認することを好みます。
例外: コードが本質的に完成しており、マイルストーンのために変更する必要がある場合。プロジェクトが些細なものであるか、以前のプロジェクトとほとんど同じである場合。完全かつ正確な仕様がある場合 (アプリケーション プラットフォームの変換の場合など)。
顧客またはマネージャーが確固たる目標期日を主張する場合、私は完全な仕様を確定することを主張します。または、別のマネージャーまたは顧客を見つけます。それが選択肢にない場合は、日付を空中から取り出して、非常に不正確であり、見逃される可能性が高いことを知らせますが、マイルストーンが完了すると洗練されます.
時間見積もりのトリックとアプローチの種類はすべて、プロジェクトの種類によって異なります。そのため、見積もりはあいまいな技術のままです。
于 2009-03-14T00:56:48.743 に答える
0
私は「ダブルイット」ポリシーが好きです。ただし、少なくとも 30% は増やしてください。これは、私の最後の IBank のシニア マネージャーから言われたことがあります。
于 2009-02-11T17:55:05.490 に答える
0
私は、最も一般的な考え方とは逆のアプローチを取り、見積もりをできる限り正確にしようとします。そして、プロジェクト マネージャーに、私が見積もりを過大評価しないことを知らせます。次に、ランダム係数 2 を適用するか、快適に感じるものを適用するかは、ユーザー次第です。
見積もりを出すときは、見積もりがどのように進んでいるかを示すのも好きです。「私はその数をお尻から飛び出しました」から「先週、すべてのタスクの詳細とリストを作成し、複雑または未知の統合のプロトタイプを作成しました。見積もりは事実のステートメントです」までの範囲のソート値。 （一般的なものではありません:)
これは主に、最初のプロジェクト計画が本来よりも約 3 倍長くなるように、管理チェーンの全員が見積もりにわずかな要因を追加したように見えるいくつかのプロジェクトから来ています。そのようなことに続くように思われるのは、オフィスの政治以外に実際に言及することなく、プロジェクトの時間を切り刻むランダムな馬の取引のラウンドです.
見積もりを出した人をどれだけ信頼しているかのケースだと思います.プロジェクト/プロダクトマネージャーを信頼し、100％正直であり、彼らにあなたの見積もりを与えることができる必要があると心から信じています.正直に信じていることは真実です。これとは反対に、それらは合理的でなければならず、見積もりを上回った場合は、それについて話し、新しい見積もりを噛むだけでなく、見積もりを改善しようとします。
于 2009-03-14T13:49:13.357 に答える
0
私はそれを2倍にすることは決してありません。通常、デザイン/アイデア/変更はポストイットノートに提示されます。通常、約1年の見積もりから始めます。ノートが洗練されるほど、見積もりが良くなります。
これでも、実装が終わったときにはまだ半分しか終わっていないことを私は知っています。これは通常、元の年の推定値の範囲内にあるため、ポスト イット ライターが設計上の問題を洗い流す十分な時間があります。
于 2009-03-17T04:24:17.807 に答える