按效果付费，内部工时怎样计入自建方案的真实成本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6735f288b371.html
📄
按效果付费，内部工时怎样计入自建方案的真实成本
把内部工时计入自建方案，关键不是给每个小时标一个价，而是先确定哪些工时属于新增投入、哪些只是原有岗位的重新分配。只有新增投入才应进入方案的真实增量成本；原有人员被占用而挤掉的产出，则要用机会成本的方式单独说明。
矛盾现象：账面更省，实际更贵
常见的矛盾是：自建方案的外部支出明显低于继续采购服务，但团队季度复盘时发现交付节奏变慢、其他事项被推迟。两种解释都成立。
- 解释一：工时口径漏项。只统计了开发或配置时间，没算需求梳理、数据清洗、测试、上线后维护和答疑。自建方案的真实成本往往藏在这些零散环节里。
- 解释二：工时口径重复。把原本就在岗、工作内容本就包含这些事项的人员时间，按全额工资再计一遍，导致自建方案被高估。旧合作关系退出后，部分工作只是从外部转回内部，并未新增人头。
两种解释会得出相反的结论，所以不能只凭“感觉更忙”就断定自建更贵，也不能因为外部账单下降就认定更省。
区分两种解释的证据
能区分它们的是工时去向，而不是工时总量。建议连续记录两到四周，按以下维度归类：
- 新增还是转移。这项工作是退出旧方案后才出现的，还是原本就由内部完成、只是换了形式。
- 是否挤占其他产出。记录被推迟的事项名称和推迟时长，而不是只记录加班时长。
- 是否一次性。迁移、初始化配置属于一次性投入；数据核对、日常维护属于持续性投入，两者应分开摊销。
- 是否可替代。如果这些工时可以由更低成本的流程或自动化替代，就按替代后的工时计入，而不是按当前实际耗时。
如果记录显示大部分工时属于转移且没有挤占其他产出，第二种解释更可能成立；如果出现明确被推迟的事项和新增环节，第一种解释更可能成立。需要说明的是，加班增多或某项统计归零都不能单独证明判断正确，还要看被挤占事项是否真实存在。
一个注明假设的短例子
假设某团队退出旧合作关系后自建一套内容发布流程，外部支出下降。用两种口径估算：
- 口径A：把参与人员全部工时乘以内部小时成本，得到较高的自建成本。
- 口径B：只计入新增环节（迁移、测试、上线后维护）的工时，转移环节不计入。
若口径A的结果远高于继续采购，先检查是否重复计算了转移工时；若口径B的结果很低，但团队其他事项明显推迟，则说明机会成本没有体现。两个口径的差额，正是需要进一步核实的部分。此例仅用于说明比较方法，不构成对任何具体方案的成本结论。
把工时折算成可比较的数字
确定口径后，按以下步骤折算，使自建方案能与外部报价放在同一张表上比较：
- 把工时分为一次性投入和持续性投入，持续性投入按预计使用周期分摊。
- 新增投入按内部小时成本计入；转移投入只记录被挤占事项的影响，不重复计价。
- 把机会成本单独列一行，注明假设：被挤占事项若延后，是否影响后续排期或对外承诺。
- 将自建方案的折算总额与外部方案在同一周期内对比，而不是只比首月支出。
完成折算后，如果自建方案在包含新增工时和机会成本后仍低于外部方案，且团队能承受持续性投入，就可以进入下一步；如果差额主要来自被挤占事项，则应先调整排期或缩小自建范围，再决定是否退出旧合作关系。免费或低价的外部方案同样要按这个口径核对时间、额度与迁移成本，不能因为标价低就直接计入节省。
退出旧方案时保留仍然有价值的部分
旧内容、旧系统或旧合作关系退出时，并非所有投入都要清零。可迁移的数据结构、已沉淀的流程文档、仍可复用的素材，都能减少自建方案的新增工时。操作上，先列出旧方案中仍然有效的部分，逐项标注迁移所需工时；迁移工时计入一次性投入，而不是计入日常维护。这样处理的好处是，下一步比较时能看清哪些成本来自迁移本身，哪些来自长期运行，避免把一次性投入误当成持续负担而放弃仍然合理的自建选择。
