客户验收测试流程

1、强调bug提交规范2、经办人初始为协作人3、调整不规范字段；例：bug归属团队、测试阶段、4、描述不规范和附件提交不规范，需要产品经理自行调整（操作类，要上传视频；计算类上传工程、识别类上传图纸工程）5、调整后由协作人转给各团队接口人6、过程中需耐心解释，产品经理认知，bug会在每个工程和图纸都复现，因此不愿意上传附件图纸和工程7、疑难及偶现问题；了解情况后，在本地机器尝试复现上传

是/否BUG

晨夕会检视

开始

迭代需求池

活动结束

目标检视与数据分析总结

模拟用户对量行为

bug提交

管理里程碑版本需要发布的问题

任务评估

启动会需要介绍提交规范及测试工具的使用；本次做的不好的地方，启动会时没有进行讲解，导致提问题时，大量的解释和修改工作量

产品经理估时

构件类型级别直径汇总表

问卷回收

工程技术经济指标

执行方案

6、工程量-工程图元反查

目标、目的等讲解

3、自行估时，容易接受；出现延迟时，容易沟通；同时为下次活动估时提供比较数据

需求池管理

每日问题整理

确定本次活动需要达到的目标；交付物、及过程目标；例：总结文档、工程文件、提交问题的有效率、问卷

是

总结会

策略依据目的和目标确定；绘制工程、量差分析、结对绘制工程、结对分析量差、对量

策略说明

否

制定方案

从粗到细，先易后难，控大量调小量，求同存异，相互沟通

制定策略

3、汇总计算出量

需求答复确认

1、按照模块进行分类、去重2、发送邮件给个团队需求

1、解决安装卸载、非功能性问题2、解决需求变更后，功能位置及操作发生的变化3、解决图纸类及选用工程的问题

1、每日需求同产品经理，当面沟通确认描述不清晰的问题、需求变更而反馈问题、2、需求答疑确认回复，整理后发送产品经理，对处理结果达成一致3、本次活动做得不好的地方，①、活动前未和需求沟通好，导致产品需求较为被动，答复不及时 ②、3月31号因在结束最后一天建议问题，整理和沟通不及时 ③、产品经理判断模块的方式同产品不同，存在大量的整理工作量4、后续建议，用有道协同进行管理（协作人、同需求具有读写权限、产品经理有只读权限）

明确活动目的，活动主要展开的模块，例：模型/计算

1、统一对量版本

建议类、需求类问题管理

5、工程量表对比

1、按照每日详细计划检视完成情况2、简述当天问题发现情况3、确定是否启动加班策略

1、关键支撑策略-拟定专人跟踪，及时调整 ；确定每日目标及晨夕会 2、延迟应对策略-加班、适当缩减范围 3、其他风险应对策略-测试版本切换、地区规则 4、制定关键检视点-时间1周左右，2天为单位对标整体进度

1、花费1~2小时，给产品经理熟悉任务，输入每日详细计划

颁发活动纪念品

研发

根据产品经理估时，完善每日计划

详细计划

对量策略

需求与产品经理交流会

每日计划

bug提交规范及测试工具使用

过程答疑

版本需求池

活动内容介绍、时间安排

问卷

楼层构件类型级别直径汇总表

执行方案说明

需求采集池

1、稳定性问题2、易用性问题3、17产品与13产品4、模块级问题细化5、产品核心价值点是否得到体现6、活动类问题收集

4、导出报表工程量

工程绘制阶段

管理快速发布时，下个迭代版本即可修改问题

2、计算设置/计算规则统一

实际工程演示

明确目的

管理需要研究、收集、暂时不处理的等需求

流程概要设计

2、产品经理估时与任务执行人估时进行校核，存在较大出入时，及时分析沟通

启动会

确定目标

问卷设计