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、产品经理估时与任务执行人估时进行校核，存在较大出入时，及时分析沟通
启动会
确定目标
问卷设计
