项目报价为什么总靠拍脑袋？没有历史工时数据，人工成本很难估准

“这个项目大概需要多少钱？”

很多项目型企业真正困难的，并不是不知道服务器多少钱、采购多少钱或外包多少钱，而是：不知道内部人员到底需要投入多少时间。

于是报价会议很容易变成：

• 技术负责人凭经验估一遍，
• 项目经理再加一点，
• 销售根据客户预算调整一下，
• 最后得到一个大家“感觉差不多”的数字。

经验当然有价值。

问题是，如果每次项目报价都只能重新依赖某几个人的记忆，那么企业做过再多项目，也很难把过去的经验真正积累下来。

历史工时数据的价值之一，就是把：

“我觉得这个项目大概要这么多人”

逐步变成：

“类似项目过去实际投入了哪些角色、多少时间，这次有哪些地方不同。”

这并不能自动算出一个“正确报价”，但至少让人工成本估算多了一层可以检查的依据。

为什么项目报价最容易低估人工投入

项目刚开始报价时，大家看到的通常是需求和交付物。

例如：

• 做一个系统；
• 开发一个模块；
• 实施一套方案；
• 完成一个客户项目。

因此估算很容易集中在最显眼的生产工作上。

软件项目里可能首先想到：开发。

设计项目里可能首先想到：设计。

实施项目里可能首先想到：现场实施。

但一个真正完成的项目往往还包括：

• 需求沟通、
• 方案讨论、
• 项目管理、
• 评审、
• 测试、
• 返工、
• 客户支持、
• 上线准备、
• 问题处理。

如果历史上没有留下这些工作的实际投入，新项目估算就容易只估“主工作”，忽略周围大量必要工作。

最终出现一种很常见的情况：项目确实按合同金额交付了，但团队一直觉得：

“这个项目怎么做得这么累？”

问题不一定是员工效率低。

也可能是一开始就没有把真实的人力投入估进去。

合同金额知道得很清楚，不代表项目成本也知道得很清楚

假设一个项目报价已经确定。

企业通常很容易看到：

• 合同金额、
• 采购支出、
• 外包费用、
• 差旅等直接支出。

但内部人工往往没有这么直接。

例如一个项目同时需要：

• 项目经理、
• 开发人员、
• 测试人员、
• 实施人员。

如果没有项目工时数据，月底只能问：

“你这个月大概有多少时间在这个项目？”

不同人会使用不同方式回忆。

• 有人按整个月估；
• 有人只记得主要阶段；
• 有人会漏掉临时支持；
• 有人同时参与多个项目，很难再还原准确分配。

最后得到的人工成本本身就是估算出来的。

下一次报价再使用这个估算结果作为历史经验，误差就会继续传递。

真正有价值的历史数据，不只是“项目总共用了多少小时”

假设过去做过一个类似项目。

如果只知道：

项目总工时 600 小时。

这个数字仍然不够。

因为新项目真正需要判断的是：这 600 小时是怎么形成的？

例如可以把历史投入拆成：

有了这些信息，新项目才可以判断：

• 哪些历史投入仍然适用，
• 哪些是旧项目特有的问题，
• 哪些地方这一次会更复杂，
• 哪些地方反而更简单。

从“照抄历史项目”变成“用历史项目做基线”

历史数据也不能直接复制。

假设上一项目有：5 个主要模块。

这次项目有：7 个模块。

上一项目客户接口比较稳定。

这次需要对接多个外部系统。

上一项目后期发生了大量需求变更。

这次需求范围已经提前确认得比较清楚。

这时合理的做法不是：

“上次用了 600 小时，所以这次也报 600。”

而是把上一项目当作基线。

逐项比较：

• 项目范围有什么变化？
• 角色配置有什么变化？
• 技术复杂度有什么变化？
• 外部协作有什么变化？
• 哪些历史投入属于正常交付？
• 哪些属于特殊返工？

这样历史工时才是估算依据，而不是一个新的“拍脑袋数字”。

一个简单的人工投入估算示例

下面只是教学示例，不代表任何企业的标准工时。

假设历史项目记录显示：

现在准备报价的新项目与它相似，但团队判断：

• 需求沟通复杂度更高；
• 核心开发范围接近；
• 测试需要增加外部系统联调；
• 上线方式相对简单。

这时估算讨论可以围绕每个阶段分别调整，而不是直接争论：

“到底报 500 还是 800 小时？”

重点不是得出一个数学上精确的答案。

而是让所有调整都有原因。

例如：

• 为什么需求阶段增加？
• 为什么上线阶段减少？
• 依据是历史数据还是新的项目条件？

只要这些依据能被记录和复查，企业的估算能力就会逐渐从个人经验变成组织经验。

工时数据怎样进入人工成本估算

有了角色或人员的投入时间以后，企业可以再结合自己的人工成本口径进行管理估算。

一个最简单的思路是：

人工投入时间 × 企业确认的成本基础

但这里需要特别注意：工资不等于完整人工成本。

企业是否加入：

• 社保、
• 福利、
• 管理分摊、
• 奖金、
• 其他成本

属于企业自己的财务和管理口径。

工时系统不应该擅自替企业定义这些规则。

工时负责提供的是：投入数量和归属。

成本口径由企业根据自己的财务制度确定。

因此，历史工时数据不是一张自动报价表，而是报价和预算的基础数据之一。

为什么只看“人天”也可能不够

一些企业习惯按：3 个人 × 20 天，估算项目。

这种方法简单，也很直观。

但它默认：这些人在这 20 天里都能够持续、完整地投入当前项目。

现实中可能出现：

• 同时支持其他项目；
• 中途等待客户反馈；
• 某阶段并不需要所有角色全程投入；
• 某些关键人员只在评审阶段参与。

因此，比“几个人做几天”更有解释力的是：不同角色在不同阶段实际需要多少投入。

人天仍然可以作为报价表达方式，但内部估算最好能够解释它是如何形成的。

没有历史工时数据，现在还能不能报价

当然可以。

项目报价在人类有工时系统之前就已经存在。

经验丰富的项目经理和技术负责人，本身就是非常重要的估算来源。

真正的问题不是：“没有工时数据就不能报价。”

而是：企业有没有办法让这一次的真实投入成为下一次报价的经验。

如果现在没有历史数据，可以先从新项目开始积累。

不需要一开始记录几十个字段。

至少能够记录：

• 项目、
• 人员或角色、
• 日期、
• 投入时间、
• 必要的工作说明。

如果企业确实需要按阶段估算，再增加阶段。

如果要区分返工、支持或需求变更，再增加相应分类。

字段应该跟着实际决策需要增加，而不是一次把所有可能信息都要求员工填写。

项目结束以后，要把“为什么超出估算”留下来

只知道：预算 500 小时，实际 650 小时。

意义仍然有限。

真正应该复盘的是：多出来的投入在哪里？

• 是需求变化？
• 是技术难度判断错误？
• 是客户响应等待？
• 是返工？
• 是测试范围扩大？
• 还是临时支援其他事项导致原计划被打乱？

这些解释会直接影响下一次估算。

例如：如果历史超支来自一次特殊客户变更，就不能机械地把这部分全部加到以后所有项目里。

如果多个类似项目都在同一阶段反复超出估算，则说明原来的报价模型可能一直遗漏了某种工作。

项目报价不应该只由工时决定

工时数据很重要，但也不能反过来走到另一个极端：

算出人工成本，就等于算出了报价。

商业报价还可能受到：

• 客户价值、
• 市场竞争、
• 交付风险、
• 付款条件、
• 战略关系、
• 采购方式

等因素影响。

因此历史工时更适合回答：这个项目大概要消耗多少内部人力。

至于最终卖多少钱，是另一个商业决策。

把两者分开，反而更容易知道一个低价项目究竟是主动的商业选择，还是一开始就没有算清成本。

从“项目做完了”变成“项目经验留下来了”

一个企业真正有价值的历史项目，不只是：合同还在，文档还在，代码还在。

还应该能够回答：

• 当时哪些角色参与了？
• 不同阶段投入多少？
• 哪些工作超出了原来的估算？
• 为什么发生变化？
• 最终实际人工投入是多少？

这些数据一旦能够持续积累，下一次项目报价就不再完全从零开始。

经验仍然重要。

区别只是：过去经验只存在于几个人脑子里。

现在开始有一部分经验能够被记录、比较和复用。

这才是历史工时数据对项目报价真正的价值。