71

如果是，为什么？多少？

我倾向于夸大我的一点，因为我可能过于乐观。

4

51 回答 51

143

Hofstadter 定律：任何计算项目所花费的时间都是您认为的两倍——即使您考虑了 Hofstadter 定律。

于 2009-02-11T16:16:57.270 回答
58

如果您根据过去的经验夸大您的估计以试图弥补您固有的乐观情绪，那么您并没有夸大。您正在尝试提供准确的估计。但是，如果您充气以使您始终有绒毛时间，那可不太好。

于 2009-02-11T16:17:29.123 回答
52

哦，是的，我学会了总是将我的初始估计乘以 2。这就是为什么FogBUGZ 的基于证据的调度工具非常有用的原因。

于 2009-02-11T16:15:54.153 回答
42

任何要求其程序员为粗粒度特性估计时间的组织从根本上被破坏了。

破解步骤：

  1. 聘请技术项目经理。如果需要，开发人员可以兼任这些人。
  2. 任何功能请求、更改请求或错误进入数据库时​​立即将其放入数据库。（我的组织使用 Trac，它并不完全糟糕。）
  3. 让您的 PM 将这些请求分解为每个需要一周或更短时间的步骤。
  4. 在每周一次的会议上，您的 PM 决定他们希望在这周完成哪些工单（可能来自市场营销等的投入）。他们将这些票分配给开发人员。
  5. 开发人员尽可能多地完成分配的工单。和/或，他们与 PM 争论他们认为持续时间超过一周的任务。根据需要调整、拆分、重新分配票证等。
  6. 每周都会编写和检查代码。QA 总是有事可做。优先级最高的更改首先完成。营销人员确切地知道即将发生的事情以及时间。最终：
  7. 您的公司处于软件项目 20% 成功率的右侧。

这不是火箭科学。关键是第 3 步。如果营销想要一些看起来很复杂的东西，你的 PM（有开发人员的输入）会弄清楚第一步需要不到一周的时间。如果 PM 不是技术性的，那么一切都会丢失。

这种方法的缺点：

  1. 当营销人员询问“获得 [X] 需要多长时间？”时，他们没有得到估计。但我们都知道，他们也知道，他们之前得到的估计纯属虚构。至少现在他们每周都可以看到证据表明 [X] 正在开发中。
  2. 作为开发人员，我们每周工作的选择更少。这无疑是真的。不过有两点：首先，优秀的团队让开发人员参与决定分配哪些票证。其次，IMO，这实际上让我的生活变得更好。

没有什么比在 1 个月的时候意识到我给出的 2 个月的估计是完全不合适的，但不能改变，因为它已经在官方营销文献中更令人沮丧。要么我通过改变我的估计、冒着差评和/或错过奖金的风险来惹恼上级，要么我做了很多无薪加班。我已经意识到，大量的加班并不是一个糟糕的开发人员的标志，也不是一个“热情”的人的标志——它是一种有毒文化的产物。

是的，很多这些东西都包含在（各种）XP、“敏捷”、SCRUM 等之下，但实际上并没有那么复杂。你不需要一本书或顾问来做这件事。你只需要公司的意愿。

于 2009-02-17T04:37:48.227 回答
37

斯科蒂法则：

  • 做出最好的猜测
  • 四舍五入到最接近的整数
  • 两倍的四倍（感谢亚当！）
  • 增加到下一个更高的计量单位

例子：

  • 你认为这需要 3.5 小时
  • 四舍五入到 4 小时
  • 四倍至 16 小时
  • 将其延长至 16 天

达达！当你在不到 8 天的时间内完成它时，你就是一个奇迹创造者。

于 2009-02-11T19:30:34.387 回答
25

通常是的，但我有两种策略：

  1. 始终将估计值提供为一个范围（即 1d-2d）而不是单个数字。数字之间的差异告诉项目经理您的信心，并允许他们更好地计划。
  2. 使用FogBugz 的 Evidence Based-Scheduling或个人电子表格之类的东西，将您的历史估计与您实际花费的时间进行比较。这会给你一个比总是加倍更好的主意。尤其是因为加倍可能还不够！
于 2009-02-11T16:19:24.253 回答
25

我将能够在 3-6 周内回答这个问题。

于 2009-02-11T18:51:13.310 回答
23

它不被称为“膨胀”——它被称为“使它们遥不可及”。

于 2009-02-11T16:25:54.410 回答
18

采取任何你认为合适的估计。然后加倍。

于 2009-02-11T16:15:20.907 回答
17

不要忘记您（工程师）实际估计理想时间（scrum 术语）。

而管理层在实时工作。

不同之处在于理想的时间是没有中断的时间（每次中断后有 30 分钟的热身时间）。理想时间不包括开会时间、午餐时间或正常闲聊时间等。

考虑到所有这些，理想的时间将倾向于实际时间。

示例：预计时间 40 小时（理想） 管理层将假设这是 1 周的实时时间。

如果将 40 小时转换为实时时间：

  • 假设每天开一次会（时长 1 小时）
  • 每天午餐休息一次（1 小时）
  • 加上 20% 的闲聊浴室休息时间获得咖啡等的开销。

一天 8 小时现在是 5 小时工作时间（8 - 会议 - 午餐 - 热身）。
乘以 80% 的效率 = 每天 4 小时的理想时间。

您的 40 小时理想需要 80 小时才能完成。

于 2009-03-14T00:08:07.987 回答
16

柯克：斯科特先生，您是否总是将您的维修估算值乘以四倍？

斯科蒂：当然可以，先生。我还能如何保持我作为奇迹创造者的声誉？

于 2009-03-11T20:20:18.123 回答
12

一个好的经验法则是估计需要多长时间，然后再增加 1/2 的时间来解决以下问题：

  1. 要求会改变
  2. 您将被拉到另一个项目以进行快速修复
  3. 隔壁办公桌的新人需要帮助
  4. 重构部分项目所需的时间，因为您找到了更好的做事方式
于 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 回答
5

六个星期。

行业标准：每个请求都需要六周时间。有些会更长，有些会更短，最后一切都会平均化。

此外，如果您等待足够长的时间，它不再成为问题。我无法告诉你我经历了多少次火钻只是为了削减项目/功能。

于 2009-02-11T18:40:39.593 回答
4

我不会说我夸大了它们，而是我试图根据过去的经验设定更现实的期望。

于 2009-02-11T16:17:10.687 回答
4

您可以通过两种方式计算项目持续时间 - 一种是计算所有涉及的任务并计算出每项任务需要多长时间，将延迟、会议、问题等因素考虑在内。这个数字看起来总是很短，这就是人们总是说的原因比如“加倍”。在交付项目的一些经验之后，您将能够非常快速地判断出，只需简要查看规范需要多长时间，而且总是会是第一种方法得出的数字的两倍......

于 2009-02-11T16:58:29.620 回答
4

为诸如调试和测试之类的事情添加特定的缓冲时间比仅仅增加总时间更好。此外，通过花时间真正计划工作的各个部分，您将使估算本身变得更加容易（可能还有编码）。

如果有的话，请记录下您的所有估算并将它们与实际完成时间进行比较，以了解您倾向于低估多少以及在什么条件下。这样您就可以更准确地“充气”。

于 2009-02-11T17:24:55.623 回答
3

我不会说我夸大了它们，但我确实喜欢为项目中可能涉及的所有可能任务使用模板。

您会发现并非列表中的所有任务都适用于所有项目，但是拥有列表意味着我不会让任何任务漏掉，因为我忘记了为它们留出一些时间。

当您发现需要新任务时，请将它们添加到您的列表中。

这样，您将有一个现实的估计。

我倾向于对可实现的目标持乐观态度，因此我倾向于偏低估计。但我知道我自己的这一点，所以我倾向于额外增加 15-20%。

我还跟踪我的实际值与我的估计值。并确保所涉及的时间不包括其他中断，请参阅我的 SO question on how to get back in the flow的已接受答案。

高温高压

干杯

于 2009-02-11T16:29:02.763 回答
3

我不会将项目的额外估计时间称为“膨胀”，除非您确实在最初的估计之前完成了您的项目。如果你养成了总是在最初预计的时间之前完成项目的习惯，那么项目负责人就会变得明智并更早地期待它。

于 2009-02-11T16:34:43.543 回答
3

你的估计是基于什么的？

如果它们只是基于对需要多少代码以及编写该代码需要多长时间的模糊直觉，那么您最好将它们填充很多以考虑您没有想到的子任务，通信和同步开销和意想不到的问题。当然，无论如何，这种估计几乎毫无价值。

OTOH，如果您的估计是基于上一次使用给定的技术和开发人员数量完成该范围内的任务需要多长时间的具体知识，那么通货膨胀应该是不必要的，因为上述通货膨胀因素应该已经包含在过去的经历。当然，可能会有一些新因素对当前项目的影响是你无法预见的——这些风险证明一定数量的额外填充是合理的。

于 2009-02-11T17:37:53.987 回答
3

这就是为什么敏捷团队以故事点（任意和相对的度量单位）来估计任务，然后随着项目的进展跟踪团队的速度（每天完成的故事点）的部分原因。有了这些数据，您理论上就可以准确地计算完成日期。

于 2009-02-11T17:41:26.613 回答
3

我采取最坏的情况，加倍，但仍然不够。

于 2009-02-11T21:36:07.233 回答
3

承诺不足，交付过多。

于 2009-09-10T02:50:39.603 回答
2

哦，是的，长期艰苦经验的一般规则是给项目你最好的时间估计，加倍，这就是实际需要多长时间！

于 2009-02-11T16:16:01.937 回答
2

我们必须这样做，因为我们的白痴经理总是在没有任何理由的情况下减少它们。当然，一旦他意识到我们这样做了，我们就陷入了军备竞赛……

我完全希望成为第一个提交两年估计以更改对话措辞的人。

叹息。

于 2009-02-11T18:06:55.057 回答
2

正如很多人所说，这是经验和风险之间的微妙平衡。

  1. 始终从将项目分解为可管理的部分开始，事实上，您可以轻松地想象自己在同一天开始和完成的部分

  2. 当您不知道如何做某事时（例如第一次），风险就会增加

  3. 当您的风险上升时，您会从最佳猜测开始，然后将其加倍以覆盖一些意外情况，但请记住，您是在项目的一小部分而不是整个项目本身上这样做

  4. 当存在您无法控制的因素时，风险也会增加，例如输入的质量或似乎可以完成您想要的任何事情但您从未测试过的库

  5. 当然，当您获得特定任务（例如将模型连接到数据库）的经验时，风险就会降低

  6. 总结一切以获得小计......

  7. 然后，在整个项目中，总是为您将等待的所有答案/文件/好的，我们总是忘记的会议，在项目等等……这就是我们所说的人/政治因素

  8. 再次添加另外 30-40% 的测试和修正，这些测试和修正超出了您通常自己进行的测试......例如当您第一次将其展示给您的老板或客户时

当然，如果你看这一切，最终你可以用神奇的“双倍”公式来简化它，但不同的是，你将能够知道在紧迫的期限内你能挤出什么，你能承诺，什么是危险的任务，如何根据重要的里程碑制定你的日程安排等等。

我很确定，如果您注意到每个纯“编码”任务所花费的时间，并将其与您对风险的估计进行比较，您就不会差太多。问题是，要考虑前面的所有小问题并在没有任何障碍的情况下对你能做的事情保持现实（而不是乐观）并不容易。

于 2009-02-11T20:09:50.000 回答
2

我说什么时候能搞定。我确保对变更请求进行后续评估，而不是“是的，我可以做到”。不用说，这将需要更多时间。请求更改的人不会认为需要更长时间。

于 2009-02-11T22:24:36.603 回答
2

当然，如果你不加 25-50%，那你就是个白痴

问题是当你旁边的白痴不断提出比你的低 25-50% 的估计值时，PM 认为你是愚蠢的/慢的/摇摆不定的。

（有没有其他人注意到项目经理似乎从不将估计值与实际值进行比较？）

于 2009-02-17T13:15:57.267 回答
2

我的一般估计是guess * 2.5 + 1 week。

于 2009-03-11T20:28:34.047 回答
2

我总是把我的估计加倍，原因如下：

1) 墨菲定律的缓冲。有些事情总是会在你无法解释的地方出错。

2）低估。程序员总是认为事情很容易做到。“哦，对了，几天就好了。”

3) 议价空间。高层管理人员总是认为可以缩短日程。“只要让开发者更加努力！” 这使您可以给他们想要的东西。当然，过度使用这个（不止一次）会训练他们假设你总是高估。

注意：最好将缓冲区放在项目计划的末尾，而不是针对每个任务。并且永远不要告诉开发人员缓冲区存在，否则帕金森定律（工作扩展以填补其完成的可用时间）将生效。有时我会告诉高层管理人员缓冲区存在，但显然我没有给他们理由#3 作为理由。当然，这取决于你的老板对你诚实的信任程度。

于 2009-03-20T10:34:57.113 回答
1

这里的许多人都在说进行估算并将其翻倍（有时再翻倍）。其他人说使用基于证据的调度（al la Joel）。

当我估算一个项目时，每个任务有四个组成部分：

  1. 我最好的猜测是需要多长时间。
  2. 不确定性（风险）——比如规范中没有的东西（已知/未知的未知）会使时间加倍。
  3. Bug修复
  4. 应急时间

对于#1，我使用了最现实的估计。
对于#2，我决定风险的可能性，然后将#1 乘以得到调整后的估计值，
对于#3 和#4，我将调整后的估计值乘以 20%，然后成为每个值的值。

所以对于任何任务，最终的总数是原始估计的 140% 或更多。

对于整个项目，意外事件和错误修复被收集到两个单独的任务中，并随着项目的进展而被消化。

当然，这不包括我通常使每个任务的总价值相等的测试。

于 2009-02-11T17:35:53.243 回答
1

我的一个朋友曾经告诉我他使用这个算法：

  1. 做个估计
  2. 用最大的时间单位表示，不要低于 0.5
  3. 我们称它为 x（单位）
  4. 结果是2*x+2（单位）
于 2009-02-11T17:42:48.157 回答
1

我不会夸大我的估计，我会填充它们！

于 2009-02-11T17:54:02.683 回答
1

两周。

行业标准：每个请求都需要两周时间。有些会更长，有些会更短，最后一切都会平均化。

于 2009-02-11T17:58:37.197 回答
1

我不会“膨胀”，而是想出最可能的最坏情况。根据项目的复杂性，我可能会填充更多内容以应对不可预见的情况。

由于我的项目通常不会达到“最坏情况”状态，因此我通常在估计时间之前完成，但足够接近估计目的。考虑到做得太早或太晚之间的选择，我每次都会早点去。

于 2009-02-12T02:09:02.007 回答
1

死亡行军对此有一些很棒的文章。

我最喜欢的是当他说我们在公司玩的游戏之一是工程师将估算值翻倍，然后管理和市场营销将其减半——不幸的是工程师没有被告知他应该加倍他的估算值。<咧嘴/>

他提到的另一种游戏是当经理让你不断修改你的估计，直到你到达他们一直想要的日期。我实际上对这个没有问题，只要允许工程师摆弄范围，实施细节，他们使用哪些 3rd 方包，甚至可能是预算......只要营销 / 管理 /工程最终都在同一页上，并且工程师没有被迫人为地引入估算值。

[编辑] 哦，我差点忘了——还有另一种经典方法：*2,+1。首先，将您的估计值乘以 2，然后将您的度量单位增加 1。如果您的诚实估计是 3 周，则改为 6 个月。<邪恶的笑容/>

于 2009-03-13T15:12:05.107 回答
1

在评估项目的前十分钟内，我通常会占用我想到的初始时间跨度的 250%。前 100% 是我知道可以快速完成的事情，接下来的 100% 是由于不可预见的事件而额外增加的，最后额外的 50% 是“与他人交流”。

似乎对我来说工作得很好。

于 2009-03-15T21:47:53.103 回答
1
  1. 计算您认为尽可能准确的估计值。
  2. 加倍。
  3. 引用结果，但要加上“正负 25%”。

例如，如果您认为需要 6 个工作日，请预测“12 个工作日，正负 3 个工作日”。

于 2009-03-15T21:56:33.240 回答
1

我记得在这个当前项目开始时，当时的项目经理直接给出了 6 周的估计！

我的眼睛刚从眼眶里凸出来！知道仍然有很多我们甚至不知道如何解决的领域。这家伙是资深的，因为他有更多的“经验”

不用说，6 周后，规范仍在编写中，几乎没有考虑任何代码。

最终，我们缩小了团队规模（仅限于我！），最终取得了实际进展。我很早以前在做合同制图员的时候就学会了如何准确估算。

涉及两个主要技能。

首先 练习估算。没有什么比实际估计各种项目更好的了——即使你不是项目经理，你是否做错也没关系——但对你所做的每个项目进行内部估计（如果你这样做应该很重要）是项目经理）

其次，大多数项目井喷是由于项目依赖性造成的，提前识别这些对于了解哪些因素能够在滑倒时使项目脱轨至关重要。

于 2009-03-15T21:59:22.343 回答
1

我加了50%。但是，如果我以前曾与客户合作过，并且我知道他们喜欢在最后做出改变，那么这可能会增加一倍或更多。我试图尽可能地预测未知……有时我成功，有时失败。

于 2009-03-16T23:10:42.443 回答
1

我的估计通常非常准确（来自 20 年的经验），但我通常还是会夸大一点；在奖金时间方面，承诺不足和过度交付总是更好:-)

尽管如此，如果您的项目经理值得任何东西（有些人不值得他们消耗的氧气，但我相信他们是少数），那么您对估算所做的工作应该不会有什么不同。

他们将根据您的实际情况跟踪您的估算，并使用该信息来调整您的下一组估算，然后再将其输入项目计划。这将使他们能够准确地了解您对某些任务的估计程度（我总是根据 UI、DBMS、中间件等类型和大小/复杂性来确定它们）。

然后，如果他们看到您不断低估 UI 任务，他们就会知道在下一次迭代中提高它们。如果他们能看到你在做一些任务，他们就会知道减少你的估计。这具有随时间自动调整的优点。

说真的，有些人认为 PM 整天无所事事地坐在他们的 ars 上（或者在美国联邦航空局的屁股上），但这项工作背后至少有一点工程和科学知识。我知道，在我重拾对代码切割的热情之前，我曾经是其中的一员。

于 2009-03-17T01:38:01.093 回答
1

是的，我给它们充气。但还不够。

于 2009-07-08T19:09:16.503 回答
1

我从不认为估计是不准确的，因为程序员无法估计编写代码需要多长时间，而是因为他们只估计编写代码需要多长时间。根本无法估计会议、客户响应时间、测试、客户变更、业务规则修订等。

当这些项目一开始就被考虑在内，并且项目是在任务级别估计的，而不是“哦，我认为这需要...... 7 周！” 那么估计通常是准确的。

所以如果我填充，那是因为我碰巧知道这些项目没有被计算在内，或者这些项目没有被适当地计算。

于 2009-07-08T19:48:11.027 回答
0

我喜欢“双倍”的政策。但是，至少将其提高 30%。我在上一个 IBank 的一位高级经理曾经告诉过我们这一点。

于 2009-02-11T17:55:05.490 回答
0

如果你必须加倍或夸大你的估计以使它们接近现实，那么你最初的估计显然是错误的或不完整的。估计需要包括任务可能遇到的所有因素。无故加额外的时间只是覆盖了你的a**，全额的背后应该有原因，而不是为了安全才加X。如果您知道会有重新设计和调整，那么将这些因素考虑在内，同样适用于会议、测试、错误修复等。

正确的估计应该与实际值匹配或接近，否则估计是不正确的。

我们的目标是让实际值尽可能接近估计值，在恕我直言的估计游戏中，低于预期与超过预期一样糟糕。

于 2009-02-11T19:21:09.760 回答
0

我不惜一切代价避免对项目进行时间估算。相反，我更喜欢预测第一个里程碑的时间并绘制完成的里程碑，并定期回顾未决的里程碑。

例外情况：当代码基本完成并且只需要针对里程碑进行修改时。当项目与之前的项目无关紧要或基本相同时。当有完整准确的规范时（例如在应用平台转换的情况下）。

如果客户或经理坚持一个确定的目标日期，那么我会坚持一个完整的规范。或者我找到另一个经理或客户。如果这些都不是一个选项，我会从空气中提取一个日期，让他们知道它非常不准确，可能会被错过，但会随着里程碑的完成而改进。

时间估计技巧和方法的类型因项目类型而异，这就是为什么估计仍然是一门模糊的艺术。

于 2009-03-14T00:56:48.743 回答
0

我对似乎最常见的态度采取了相反的方法，我尽量使我的估计尽可能准确，然后确保项目经理知道我没有虚报我的估计。然后由他们决定应用任何 2 的随机因子或任何他们觉得舒服的值。

当我给出估计时，我也想给出某种指示，表明估计是如何通过的。某种价值，从“我刚刚从我的屁股中取出这个数字”到“我在上周详细列出并列出了所有任务，对任何复杂或未知的集成进行原型设计，并且估计是事实陈述” （不是一个常见的:)

这主要来自几个项目，似乎管理链中的每个人都在估算中添加了自己的小因素，因此初始项目计划比应有的时间长约 3 倍。随之而来的似乎是一轮随机的马交易，它缩短了项目时间，除了办公室政治之外没有任何真正的参考。

我想这是一个你有多信任你给出估计的人的例子，我真诚地相信你必须能够信任并且对你的项目/产品经理 100% 诚实，并且能够给他们估计你诚实地相信是真实的。与此相反的是，它们必须是合理的，当您超出估算值时，请谈论它并尝试改进您的估算值，而不仅仅是咀嚼新的估算值。

于 2009-03-14T13:49:13.357 回答
0

我从不把它翻倍。通常，设计/想法/更改会出现在便笺上，我通常从大约一年的估计开始，并且便笺得到的越精致，我的估计就越好。

即使这样，我也知道当我完成实施时，我只完成了一半。这通常在最初的年度估计范围内，因此帖子作者有足够的时间来解决任何设计问题。

于 2009-03-17T04:24:17.807 回答
0

如果你是一家咨询公司，你真的需要考虑过多地填充你的估计。你需要赚钱，对吧？如果您不让您的资源尽快承担下一个任务，您就无法做到这一点。另外，考虑一下你将要进行什么样的项目。你能和客户一起做 T&M 吗？如果没有，并且您被迫提供固定出价，还包括固定期限并与客户分担风险。我无法告诉你我看到有多少同事在这次讨论中搞砸了这些话题。作为 PM，您必须站出来，a) 提供一个小的、合理的填充以确保可以满足交付日期，b) 通过在 SOW 中获得良好的语言来协商和分担固定投标项目所涉及的风险保护你，和 c) 你' 重新努力赢得工作，对吗？？？表现得像，并确保您的 A 团队在规划阶段获得估算，以保持竞争力。

WPF 和 Silverlight 是相当新的，但我们很快就会让竞争对手低于我们的出价。

稍微偏离主题，但帮助客户在与销售人员谈判项目时意识到您团队的强度。一个好的产品经理可以帮助赢得新客户的尊重和信任。

谈论内部资助的项目时，差别真的很小。由于野兽的性质以及许多此类项目的生命周期和需求，它们需要比一些高风险、短期外部项目更强大的项目管理。

最后，您必须从将要执行工作的资源中获得支持。团队负责人应该祝福估算，并能够判断它们是高还是低。您必须能够在每个项目上获得投资回报，因此有时您可能需要超出预期的估算值。但确实，如果工作量很小，并且您在项目中投入了 B 或 C 资源团队，如果出价太高，则将机会留在桌面上。除非它具有重要的商业意义，否则如果您确实没有资源来完成它，请避免参加演出。在这个经济体中，这并不总是一种选择。

于 2009-03-20T10:24:25.670 回答
0

请记住，大多数开发人员不会考虑太多的测试时间、错误修复时间和管理开销（电子邮件、咖啡、会议等），一些小组每周只安排 20 小时和/或乘以至少 2.5

于 2009-05-10T04:13:05.423 回答