判断返工归属,先看触发返工的原因是需求变更、原交付缺陷,还是旧系统或旧内容本身无法按原假设继续使用;再看合同里对“完成”的定义和工时记录能否对应到具体动作。若报价按工时计费,返工不当然由甲方承担,也不当然由乙方承担,关键是把返工拆成可核对的动作,再按责任来源决定是否计入下一阶段工时。
按工时计费的报价,最容易在返工上产生分歧,因为双方讨论的是“又花了多少小时”,而不是“这个小时该不该花”。更可执行的做法是先把返工拆成三类:第一类,原约定范围内的交付有缺陷,例如页面模板在约定浏览器或设备上无法正常显示,需要重做;第二类,甲方在交付后新增或改变了需求,例如原本只要求调整旧栏目结构,后来要求把旧内容整体迁移到新路径;第三类,旧系统、旧内容或旧合作关系退出时暴露出的历史问题,例如旧页面没有统一模板、旧数据没有字段说明,导致原计划无法直接执行。
这三类的工时归属不同。第一类通常应由交付方承担修复成本,除非合同明确把某些兼容范围排除在外;第二类通常由提出变更的一方承担新增工时;第三类需要看合同是否把“旧资产可继续使用的程度”写进前提,如果没写,双方应就清理历史问题另做范围确认,而不是直接把它算进原报价。判断时不要只看谁提出返工,而要看返工动作是否属于原约定、是否由新要求触发、是否因旧资产状态超出原假设。
假设你手里有一份旧内容页面清单,准备退出旧系统,只保留仍然有价值的部分。你可以按下面步骤处理,每一步都会影响下一步的工时归属判断。
这个顺序的意义在于:返工归属不是靠争论“谁更负责”,而是靠页面清单、缺失项记录和范围对照来落地。你每完成一步,下一步的谈判对象都会更具体。
按工时计费时,合同或报价单里如果只写“完成页面优化”,返工边界会非常模糊。更有判断力的写法是同时出现三个要素:交付物、验收条件、变更处理方式。交付物说明做什么,例如“完成 20 个旧页面的标题层级和正文结构整理”;验收条件说明怎样算完成,例如“在约定设备上可正常阅读,且旧链接可访问或按约定跳转”;变更处理方式说明超出范围后怎么计工时,例如“新增页面或改变迁移路径,按实际工时另行确认”。
如果合同里没有变更处理方式,你可以要求把当前返工动作拆成“原范围”和“新增范围”两栏,再分别确认。这个动作不会自动让某一方少付钱,但会让下一步有依据:原范围缺陷先修复,新增范围先确认工时,旧资产历史问题先决定是否缩小范围。缺少这一步,按工时计费的报价很容易变成边做边加,最后无法判断哪些工时本来就不该发生。
旧合作关系需要退出时,常见误区是把“换人接手”直接等同于“全部重做”。按工时计费的情况下,这会迅速放大成本,也会让返工归属更难判断。更稳妥的做法是先区分三类资产:仍然有效的页面内容、仍然可用的模板或组件、已经失效的旧功能或旧数据。第一类可以保留并只做必要整理;第二类可以继续使用,但要先确认接手方是否能在不破坏现有结构的前提下修改;第三类应明确退出,不进入返工范围。
如果旧合作方留下的交付物缺少说明,接手方需要额外时间理解,这部分工时是否由你承担,取决于原合同是否要求交付说明。若原合同没有要求,你可以在新报价里把“理解旧资产”列为单独动作,并限定只处理仍然有价值的部分。这样做的结果是:你不需要为全部旧内容支付返工工时,只需要为保留部分支付可核对的整理成本。
假设某次优化报价按工时计费,原约定处理 30 个旧页面,前提是“旧页面结构基本一致”。执行中发现其中 8 个页面没有统一模板,需要单独调整。若合同把“结构基本一致”写成前提,那么这 8 个页面的额外工时更接近旧资产历史问题,应先确认是否缩小到只处理仍有价值的页面;若合同没有写这个前提,交付方在报价前也未核对旧页面状态,那么这部分返工更接近原报价范围判断不足,双方应先核对报价前的页面清单,再决定工时归属。这个例子只说明比较方法,不代表任何真实项目结果。
无论采用哪种判断,最后都要落到一个动作:把返工记录、原报价范围和旧资产状态放在同一张确认单上,逐条决定“修复、新增、缩小范围或退出”。只有完成这一步,按工时计费的网站优化价格才不只是总小时数,而是能解释每一段工时为什么发生、由谁承担、是否值得继续。