建站成本预算：内部工时怎样计入自建方案的真实成本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c188f3d734ff.html
📄
建站成本预算：内部工时怎样计入自建方案的真实成本
自建方案的真实成本，应当把内部工时按“可替代外包价”或“机会成本价”折算后计入，而不是按零计算。前提是这些工时确实占用了本可用于交付客户或推进产品的时间；如果团队处于闲置期、且没有可替代的产出用途，那么按零计入反而更接近真实增量成本。判断的关键不是“有没有花时间”，而是“这些时间原本能换成什么”。
先分清增量成本与沉没成本
把工时计入预算时，最容易出错的是把全部投入时间都当成新增成本。正确的做法是只计增量成本：如果不做这个自建方案，这部分时间是否会被用于其他有产出的事。
- 若团队本来就有排满的交付任务，自建占用的每小时都意味着推迟其他工作，应按替代产出计价。
- 若团队处于明确闲置期，且没有可承接的订单或迭代任务，这时的工时增量成本可能接近零。
- 若工时来自创始人或核心成员，机会成本往往高于普通执行岗，折算系数应单独标注。
一个可核对的证据是排期表：把自建任务插入前后，其他任务的完成日期是否被推后。如果日期没变，说明工时被吸收；如果被推后，推迟造成的损失就是应计入的成本。
用可替代外包价折算，而不是用薪资
薪资只反映雇佣成本，不反映市场替代价。更稳的折算是问：这项工作如果外包，报价大概落在什么量级。这个量级不需要精确，但必须来自可核对的报价或历史采购记录，而不是凭感觉。
假设一个自建方案需要前端搭建、内容迁移和上线调试，内部投入约若干人天。若同类工作外包报价按人天计，把人天数乘以这个单价，就得到工时的替代成本。这个数字通常会让“自建更省”的直觉反转——因为自建省下的是显性付款，付出的是隐性排期。
需要注意，这里不给出具体价格区间，因为不同地区、不同复杂度差异过大；你应使用自己手头能核对的报价单作为基准。
什么情况下“工时按零计”才成立
前面结论有一个明确的反例：当团队时间无法变现、且自建不会推迟任何有收入的任务时，工时按零计入是合理的。
典型条件是：项目处于等待期、没有并行交付、成员技能与自建任务匹配、且这段时间不存在其他被放弃的选项。此时把工时标为零，能避免虚增预算导致误判。但只要其中任何一条不成立——比如有并行客户项目、或成员本可投入获客——按零计入就会低估真实成本，让自建方案看起来比实际更划算。
区分两种解释的证据：查同一时间段内其他任务的交付记录。若其他任务照常按期完成，支持“时间被吸收”；若出现延期或取消，支持“存在机会成本”。
把工时写进预算表的具体动作
不要只在备注里写“内部投入若干天”，而要在预算表中单列一行：工时折算成本。动作如下：
- 列出自建所需的全部内部角色与预计人天。
- 为每个角色选择一个可核对的折算单价，来源可以是外包报价或历史采购记录。
- 相乘后得到工时折算成本，与采购、服务器、域名等显性支出并列。
- 在表旁标注假设：这些工时是否占用了可交付时间。
这个动作的结果会直接影响下一步：如果折算后自建总成本高于外包，你应重新评估是否自建，或缩小自建范围；如果折算后仍低于外包，且团队时间确实可被吸收，自建才具备预算上的合理性。下一步动作应基于这张表做取舍，而不是基于“省了钱”的直觉。
常见的三个计入错误
- 按全额薪资计入：把固定薪资全部摊到项目上，会高估增量成本，因为薪资在闲置时也要支付。
- 完全不折算工时：把内部投入当免费，会低估自建的真实代价，尤其在团队满负荷时。
- 混淆沉没与增量：已经投入的时间不应再影响后续决策，只有未来会发生的工时才应进入预算比较。
把这三类错误排除后，你得到的工时折算数字才可用于自建与外包的对比。下一步应固定这张预算表的假设，并在项目结束后用实际人天回填，检验当初的折算是否偏离实际。
