建站预算：内部工时怎样计入自建方案的真实成本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e4da01a93298.html
📄
建站预算：内部工时怎样计入自建方案的真实成本
自建方案的真实成本，等于外部现金支出加上内部工时折算值。内部工时不是零成本，它挤占的是你本可以用于获客、内容或产品的时间。要算清这笔账，先别急着套小时工资，而是从你手上已有的旧站资料或旧系统清单出发，逐项标注“谁来做、做多久、做完之后是否还要持续投入”。下面用一个假设例子说明可执行的处理顺序。
先把手上的旧资料变成工时清单
假设你准备退出旧的建站合作关系，手上留有一份旧站页面清单和一份后台账号交接记录。不要直接评估“重建要多少钱”，而是把每一条资料转成动作：
- 旧页面清单 → 逐页判断保留、改写还是删除，标注每页需要谁审、大约几轮。
- 后台账号交接记录 → 核对哪些配置能导出、哪些只能人工重建，标出重建动作的执行人。
- 旧合作关系中的定制功能 → 判断是否仍有价值，保留则要安排后续维护人，退出则要安排替代方案。
这一步的产出不是预算数字，而是一张带执行人的动作表。动作表越具体，后面折算工时越不容易拍脑袋。
内部工时折算要选对参照，而不是套一个固定时薪
内部工时折算常见两种做法，适用条件不同：
- 按机会成本折算：适合团队时间已经排满、每多一件事就要推迟另一件事的情况。参照可以是这类人对外报价的时薪，或他们本可产出的业务价值。结果是自建方案看起来更贵，但更接近真实取舍。
- 按边际成本折算：适合团队有空闲时段、额外投入不挤占其他任务的情况。参照可以只是加班补贴或外包补位费用。结果是自建方案显得便宜，但前提是空闲时间真实存在。
两种算法都成立，区别在于你的团队当下是否有可挪用的时间。如果选错参照，预算会系统性偏高或偏低。
一个假设例子：退出旧合作时保留哪些部分
假设旧站有 40 个页面，其中 25 个内容仍有效，10 个已过期，5 个是旧合作方定制的活动页。内部处理动作和工时估算可以这样拆：
- 25 个有效页面：每页审校并迁移，假设每页 0.5 小时，共 12.5 小时，由内容岗承担。
- 10 个过期页面：判断合并或删除，假设每页 0.2 小时，共 2 小时，由内容岗承担。
- 5 个定制活动页：确认是否继续使用。若保留，需安排后续维护人；若退出，需重建替代页，假设每页 1 小时，共 5 小时，由技术岗承担。
把这 19.5 小时按你选定的参照折算，再加外部现金支出，才是这一轮退出的自建真实成本。做完这一步，你会得到两个可比较的数字：继续维护旧方案的持续工时，和一次性迁移加后续维护的工时。哪个更低，取决于旧系统还能不能低成本维持。
哪些信号说明该停手，哪些只说明要调整
执行过程中会出现一些容易被误读的信号。比如旧后台访问量下降、抓取量归零，这可能说明旧系统已无价值，也可能只是入口变更、统计口径变化或临时故障，不能单独作为退出依据。更可靠的判断来自动作表本身：
- 如果保留项只剩少量静态页面，且维护动作可以合并到现有流程，继续保留通常比迁移省事。
- 如果保留项需要专人持续处理配置或对接，而这个人已经不在团队，迁移或替换往往更划算。
- 如果定制功能仍被业务依赖，先确认替代方案是否可行，再决定退出节奏，避免中途停摆。
这些判断不需要额外工具，只需要把动作表上的执行人和时长填实。
把结果写回预算，并决定下一步
完成折算后，把内部工时和外部支出分成两栏：一次性迁移成本和每月持续成本。然后做一个实际动作：选一个低风险页面先按动作表执行一遍，记录实际耗时。如果实际耗时明显高于估算，说明你的参照或拆分粒度需要调整，后续预算应同步修正；如果接近估算，就可以按同一方法处理剩余页面。这个动作的结果直接决定你是继续自建、缩小保留范围，还是重新评估外部方案。
