POC拖过了原定周期，结论又停留在“感觉还行”“再试试看”，采购评审就无法据此做判断。这类问题通常同时涉及验证范围、通过标准和执行机制：范围不断追加会让周期顺延，标准写得模糊会让证据无法进入评审。下面按症状分类、原因排查、纠偏处置、有条件决策与复发预防的顺序展开，适用于采购前POC的执行异常处置。
要点总览（TL;DR）
- 先做症状分类：验证范围持续追加、周期反复顺延、结论停留在主观印象，三类症状常叠加出现，叠加时优先处理范围问题。
- 原因排查按范围、标准、资源、决策机制的顺序推进，每类假设都要找到清单对比、排期记录、评审表对照等具体证据，避免凭印象下结论。
- 纠偏按四步执行：冻结验证范围、把验证项改写为含指标阈值判定人证据形式的通过标准、设定带停止点的收口周期、补齐关键证据缺口。
- 收口时证据不完整可做有条件决策：逐项标明已覆盖与未覆盖的采购风险，用补充验证或合同条款兜底，并把不确定性写入决策记录。
- 复发预防靠启动时固定验证清单与通过标准、周度检查证据产出、明确结论责任人，并把POC材料归档为可复用的评审依据。
先分清是周期拖延、结论失效，还是两者叠加
处理POC异常的第一步是判断当前处于哪种形态。周期拖延和结论失效经常同时出现，但处置的起点不同：前者要先控制范围和时间，后者要先补齐判定口径。把症状归错类，容易出现“加班赶进度”却仍然拿不出采购依据的情况。
可以先对照下表做初步分类。判断依据来自最近两周的实际记录，包括新增验证需求的数量、排期变更次数、评审会上被质疑的问题类型。
| 症状表现 | 可能形态 | 下一步动作 |
|---|---|---|
| 需求方持续追加场景，验证清单越来越长，原定完成时间一再推后 | 范围蔓延引发的周期拖延 | 进入S2核对范围类假设，准备冻结清单 |
| 周期反复顺延，但每次延期理由不同，缺少明确的到期节点 | 执行机制缺失引发的周期失控 | 进入S2核对资源与决策机制假设，设定停止点 |
| 验证做完了，结论仍是“整体体验不错”“基本满足”，采购评审无法引用 | 标准缺失引发的结论失效 | 进入S2核对标准类假设，重写通过标准 |
| 既延期又说不清验证了什么，关键风险项没有证据 | 范围蔓延与标准缺失叠加 | 先冻结范围，再重设标准，按S3四步处置 |
两类异常存在因果关联：范围蔓延往往同时造成周期拖延和证据不足。追加的场景分散了验证资源，每个场景都只做了浅层演示，既拖长周期，又无法形成可判定的结论。因此当两类症状同时出现时，优先处理范围问题。
本文讨论的范围是采购决策前POC的执行异常，包括范围、标准、资源和决策机制四类问题。部署方式选择、旧工具替换与迁移方案属于其他决策事项，不在本文展开。
逐项排查：范围、标准、资源、决策机制四类原因
症状分类之后，需要用证据确认原因，避免把猜测当成结论。建议按范围、标准、资源、决策机制的顺序排查：范围问题影响面最大，先排除它，后面的排查才不会被不断变化的需求干扰。每一类假设都要找到对应的记录或事实，而不是靠参会人的印象。
范围类假设
典型表现是需求方在POC过程中持续追加场景，或把定制开发、接口改造纳入验证内容，验证清单没有冻结时点。验证证据包括：对比启动时的验证清单与当前清单，统计新增项数量及提出人；检查是否存在为POC单独开发的代码或配置；查看排期变更记录中延期理由是否集中在“新增需求”。如果新增项超过原清单的三成，范围蔓延基本可以确认。
标准类假设
通过标准写成“操作便捷”“响应较快”“满足业务需要”这类主观描述，缺少量化阈值、判定人和证据形式。验证证据是逐条检查验证项：能否指出具体的指标、合格线、由谁判定、以什么材料作为证据。若超过一半的验证项无法回答这四个问题，结论失效的原因就在标准侧。这类问题在周期正常的POC中同样存在，容易被进度压力掩盖。
资源类假设
环境准备延迟、测试数据不到位、厂商实施人员与业务方关键用户投入不足，都会让排期空转。验证证据包括：环境交付时间与原计划对比、数据准备任务的完成记录、双方投入人天与约定投入的差距、等待响应的时间占比。如果延期主要发生在等待环节而非验证执行环节，应优先处理资源问题。
决策类假设
采购评审的评分口径与POC验证项不对应，或者没有人对POC结论负责。验证证据是：把采购评审表与验证清单逐项对照，看关键评分项是否有对应的验证证据；确认POC是否有明确的结论责任人和评审召集人。若评审表上的权重项在POC中没有验证记录，说明POC设计与采购决策脱节，这类问题无法通过延长周期解决。
排查顺序建议为：先范围、再标准、后资源、最后决策机制。每完成一类排查，记录“假设是否成立、依据是什么”，形成书面排查记录。四类原因可能同时存在，处置时按影响程度排序，不必等全部查清才开始动作。
纠偏处置：冻结范围、重设标准、设定收口周期
原因确认后，按四步推进纠偏。四步有先后依赖：范围不冻结，重设标准就没有稳定对象；标准不明确，收口评审就没有判定依据。
第一步：冻结验证范围
组织需求方、业务负责人和厂商共同确认三件事：已完成的验证项及其证据、与采购风险直接相关需要保留的验证项、其余移出POC的项。移出的项不是丢弃，而是记录为后续补充验证或合同约定事项。冻结结果形成书面清单，注明冻结日期和变更审批人。此后新增需求一律走变更审批，不再默认纳入本期POC。
第二步：把验证项改写为可判定的通过标准
每个保留的验证项补齐四个要素：指标、阈值、判定人、证据形式。例如把“审批流程要顺畅”改写为“覆盖三类审批场景，单笔审批平均耗时不超过约定值，由业务负责人依据操作录屏和系统日志判定通过”。标准改写完成后，由采购评审的关键干系人确认，确保验证项与评审口径对齐。
第三步：设定带停止点的收口周期
根据剩余验证项的工作量和资源情况，设定一个明确的收口日期，并约定到期无论完成度如何都进入结论评审。收口周期内按周检查证据产出，而不是只检查进度百分比。停止点的作用是终止无限延期，让采购决策有确定的时间输入。
第四步：补齐证据缺口
对影响采购判断的关键项，安排补充验证；无法在收口周期内完成的，改用其他证据来源，例如厂商提供的同类客户案例说明、产品演示录像、试用环境中的定向测试记录。补充证据同样要注明来源、时间和适用范围，避免在评审中被当作全面结论使用。
风险边界需要提前交代：调整验证范围和重排验证项必须与需求方书面确认，邮件或会议纪要均可，避免后续对“验证过什么”产生争议；已投入搭建的定制环境保留备份和配置记录，防止范围调整后无法复现此前的验证结果；移出POC的验证项要登记去向，不能无声消失。
在验证项和证据的管理上，可以把每个验证项建成工作项，关联负责人、通过标准、证据附件和状态，用看板跟踪每周产出；验证结论和评审材料放在文档中并与工作项关联，便于评审时逐项追溯。ONES Project 支持需求与任务规划至迭代并分配负责人，提供看板、燃尽图和自定义报表；ONES Wiki 支持文档关联任务并插入工作项列表，可用于承载验证清单与评审材料。具体承载方式可在试用中按团队习惯配置。
用现有证据做有条件决策并防止复发
纠偏是否生效，要看三个观察点：验证范围是否稳定，冻结后新增项是否都走了变更审批；验证项是否按周产出符合标准的证据，而不是临近收口才集中补材料；结论评审是否按约定日期召开，参会人是否包含采购评审的关键干系人。三个观察点连续两周正常，说明纠偏机制在运转；任一观察点反复异常，需要回到S2重新核对对应原因。
收口时证据仍不完整是常见情况，此时可以推进有条件决策。做法是把采购风险逐项列出，标明哪些已被POC证据覆盖、哪些未覆盖，未覆盖项约定处理方式：在合同签订前安排补充验证，或在合同中写入性能指标、验收标准、退出条款等兜底约定。有条件决策的关键是把不确定性写进决策记录，让评审者知道自己在什么信息基础上做出的判断，而不是用“基本没问题”掩盖缺口。
复发预防要在下一次POC启动时落地，主要包括四项机制：
- 启动时固定验证清单与通过标准，清单与采购评审表逐项对应，双方签字确认；
- 设置周度进度检查，检查内容是证据产出而非任务完成比例，延期超过约定天数触发升级；
- 明确POC结论责任人和评审召集人，结论必须形成书面材料；
- POC结束后把验证清单、证据、结论和未覆盖风险整理为评审材料归档，作为后续验收和复盘的基础。
把POC结论沉淀为可复用的评审材料，还能减少重复验证：同类采购再次启动POC时，可以直接引用已归档的证据，只针对新增风险项设计验证内容。这样POC的投入会随次数累积，而不是每次从零开始。
常见问题
POC已经延期很久，是先压缩周期还是先砍验证范围？
先处理范围。周期拖延多数由验证项持续追加引起，范围不冻结，压缩出来的时间很快会被新增需求重新占满。做法是先把当前清单与启动清单对比，保留与采购风险直接相关的验证项，其余移出本期POC并登记去向，再据此设定收口日期。范围冻结和周期设定要一起与需求方书面确认，单独压缩周期容易变成赶工演示，证据质量反而下降。
验证项做到什么程度才算有证据，可以进入采购评审？
每个验证项要能回答四个问题：看什么指标、合格线是多少、由谁判定、以什么材料作为证据。四项齐全，证据才能被评审引用。操作录屏、系统日志、测试记录、厂商书面说明都可以作为证据形式，但要注明来源、时间和适用范围。只有演示和口头评价的验证项，建议在收口前补做定向测试或改用其他证据来源，并在评审材料中标注证据强度。
收口日期到了，关键验证项还没做完，采购还能继续推进吗？
可以推进有条件决策。把采购风险逐项列出，标明哪些已被POC证据覆盖、哪些未覆盖，未覆盖项约定处理方式：签订前安排补充验证，或在合同中写入性能指标、验收标准和退出条款。关键是让评审者看到决策建立在什么信息基础上，并把未覆盖风险写入决策记录。若未覆盖项涉及核心业务场景且无法用合同兜底，应单独升级决策，而不是默认放行。
范围调整后，之前做过的验证结果还有效吗？
已完成且证据完整的验证项继续有效，前提是环境、配置和版本没有变化。因此调整范围时要保留定制环境的备份和配置记录，防止后续无法复现此前的验证结果。被移出的验证项要登记去向，后续补充验证时可以直接引用已有证据，只针对新增风险设计内容。若环境发生变更，受影响的验证项需要重新确认，并在评审材料中说明变更范围。
怎样避免下一次POC再出现同样的拖延和结论失效？
把机制固定在启动环节：验证清单与采购评审表逐项对应并双方签字确认，每个验证项写明通过标准；执行期间按周检查证据产出而非任务完成比例，延期超过约定天数触发升级；明确结论责任人和评审召集人，结论必须形成书面材料。POC结束后把清单、证据、结论和未覆盖风险归档，同类采购再次启动时可直接引用，减少重复验证。
