核心判断标准只有一条:旧报告里的某个成果,是否在本次外包交付中被重新验证、重新适配或重新实现。如果只是把旧结论原样搬进新报告,它属于沿用;如果本次交付产生了新的证据、新的实现或新的适用条件,它属于新增。混淆两者,最直接的后果是验收时把旧成果算进本次工作量,或者把新增成果漏记,导致后续维护和追加需求都缺少依据。
第一种条件:旧报告描述的页面、组件或流程,在本次交付中没有任何结构、样式或逻辑改动,且本次交付没有对它做新的测试或验证。这种情况下,旧结论应标记为沿用,不进入本次成果清单。
第二种条件:旧报告中的对象虽然存在,但本次交付对它做了适配——例如同一套页面结构用到了新的内容类型、新的终端宽度,或者同一段交互逻辑接入了新的数据来源。只要产生了新的验证记录或新的实现细节,就应标记为新增,哪怕最终视觉结果看起来和旧报告一致。
区分这两种条件时,不要只看文件是否被打开或复制。打开旧文件做参照,不等于本次交付产生了新成果;反过来,一个旧模块被重新测试并记录了新的边界情况,即使代码没变,也属于新增验证成果。
实际操作中,可以按本次外包团队做过的动作来归类,而不是按文件的时间戳。以下动作通常指向新增:
以下动作通常指向沿用,不应单独计入本次新增成果:
这里有一个容易出错的边界:如果旧报告中的结论本身已经过期,本次交付只是把它标注为“待复核”,这不算新增成果,只能算风险记录。真正的新增,需要本次交付给出替代结论或替代实现。
假设旧报告覆盖了三个页面,本次外包只对其中一个页面做了移动端适配,另外两个页面原样保留。归类时可以这样处理:
这个例子的关键不是页面数量,而是每个页面背后有没有本次交付产生的证据。假设本次只适配了一个页面,却把三个页面都写成新增,验收方在核对时会发现两个页面缺少对应的实现记录,从而对整个成果清单产生怀疑。反过来,如果本次确实对两个旧页面做了抽样复核,并记录了新的异常样本,即使页面本身没改,也应当把复核结论列为新增验证成果,而不是继续标为沿用。
建议在复用旧报告之前,先做一张对照表,至少包含四列:旧报告中的对象、本次交付是否触碰、触碰后产生了什么可复现证据、归类为沿用还是新增。这张表不需要复杂工具,用普通文档即可。
完成对照表后,下一步动作是把它交给验收方确认归类口径。如果验收方认可“沿用不计入新增”,那么后续追加需求的工作量评估就有了基准;如果验收方要求沿用部分也要重新验证,那么本次交付范围需要相应扩大,成本和周期也要重新估算。这个动作的结果会直接影响下一步:是直接进入验收,还是先补充验证再验收。
需要留意的例外是:当旧报告中的某个成果本身就是本次交付的前置依赖,并且本次交付对它做了兼容性处理,那么它既不是纯粹的沿用,也不是完全的新增。这种情况下,建议单独列为“适配性新增”,并注明它依赖的旧结论版本。这样做的目的是避免后续维护时把适配性改动误认为原始设计的一部分。
个别样本上,沿用和新增的区分可能很清晰。但当旧报告被复用到几十个页面或组件时,例外会集中出现:有的页面只改了文案,有的页面只改了图片,有的页面虽然代码没变但被放进了新的布局容器。这些情况不能直接照搬“改了就新增、没改就沿用”的简单规则。
更稳妥的做法是先定义本次交付的“成果单位”。如果成果单位是页面,那么改文案和改图片都算新增;如果成果单位是组件,那么只有组件本身的逻辑或样式变化才算新增,页面级改动不计入。定义清楚之后,再按同一口径逐项归类,例外就会减少。定义成果单位这一步本身也是实际动作,它的结果决定了后续工作量统计的粒度,也决定了验收时双方能不能对得上账。
最后需要说明的是,请求量、抓取量或某项统计归零,不能单独证明沿用和新增的归类正确。这些现象可能来自缓存、重复访问或其他与本次交付无关的原因。归类是否成立,仍然要看本次交付有没有产生可复现的证据,以及这些证据是否对应到具体的交付对象。