联合概念验证与测试准备协调

这个场景能帮你做什么

客户想先验证方案，渠道说可以测试，原厂技术团队却还不知道测什么、用哪个版本、谁准备环境。WorkBuddy 可以把需求、技术资料与各方安排整理成概念验证准备包，让测试启动前的缺口和责任清楚可见。

概念验证通常简称 POC，用一段受控测试验证关键问题。本任务准备测试，不代替工程师部署、测试或出具通过结论。

开始前需要准备什么

提供客户要验证的问题、使用场景、技术方案、硬件与软件版本、数据范围、样机或测试环境、人员、时间、资源和访问授权。最低测试项应有目标、输入环境、动作、预期证据、通过条件和确认人。

没有通过标准时先确认，不能把“演示能运行”当客户问题已解决。客户真实数据、生产环境和设备操作由有权限人员决定；文件整理阶段不要求直接上传敏感数据。

具体怎么做

第一步：明确验证问题和边界

交客户需求及方案，要求区分业务目标、需要验证的技术假设和暂不验证内容。输出范围表，技术与客户负责人确认。客户问性能、兼容和操作流程时分别列项，不能用单次演示概括全部。

第二步：建立测试项草稿

按每个问题列环境、测试输入、操作负责人、待执行动作、预期记录和判断标准。动作只能依据技术方案起草，参数不明标待技术确认。输出测试项对照，区分已有标准和建议待确认标准。

第三步：核资源和前置条件

交原厂、伙伴和客户资源说明，整理设备、环境版本、网络、账号权限、样例数据、工具及接口资料的提供方和就绪状态。样机有申请未到货写未就绪；现成演示环境不默认与客户环境相同。

第四步：安排多方依赖

让 WorkBuddy 排需要先完成的事项、责任人、交接物、约定时间和阻塞影响。例如客户确认版本后才能配置环境，数据授权后才能导入样本。没有确认的时间列待协调，不自行承诺人员可用或测试周期。

第五步：交付启动核对与记录表

输出范围、测试项、环境资源、责任依赖、待解决问题及结果记录模板。记录区分未测、已执行、异常待复核和技术确认结果，初稿不填通过。负责人确认启动条件后按原有技术流程执行。

可以直接交给 WorkBuddy 的完整要求

请根据提供的客户需求、技术方案和多方资源记录，整理联合概念验证准备包。
先列验证问题、业务目标、技术假设和不在本次范围的事项，需客户与技术确认。
逐项列环境版本、输入、负责人、待执行动作、预期证据、通过标准与确认人。参数和标准缺失先列待核，不自行编造。
整理设备样机、网络、账号、数据授权、工具和接口资料的提供方、状态及依赖。演示环境与客户环境分开，申请不当就绪。
输出范围表、测试项草稿、资源清单、责任与前置依赖、启动缺项及结果记录模板，所有未执行项保持未测试。
不部署、不连接生产环境、不运行测试、不替客户授权、不宣称通过或作正式验收，不承诺样机和人员到位。

完成后会得到什么

教学示例：客户需要验证与现有数据库兼容，原厂只有新版本演示环境，伙伴尚未取得客户版本信息。准备包应把“确认客户版本”和“提供对应测试环境”列为前置条件，不能用演示成功写“兼容验证通过”。

结果应该怎么检查

核每项测试是否对应客户问题；环境版本与数据来源是否明确；标准是否已确认；设备和权限是否真实就绪；责任是否有人承接；结果表是否空留未测状态。重点查模拟与真实环境有无混用。

遇到这些情况怎么处理

标准只写效果好： 列可观察问题，请客户和技术负责人明确。

数据授权未取得： 先准备方案和合成测试需求，不导入真实数据。

版本变更或设备延期： 更新受影响测试及依赖，交负责人调整安排。

哪些必须人工决定

验证目标、技术动作、环境权限、数据使用、测试执行及结论由客户、原厂与伙伴技术负责人确认。WorkBuddy 提供准备协调，不代替技术验证。