目标 ​

为更好的管理产品研发、运营过程中测试、评审、用户、运营等的反馈意见，特指定此规范。

名词 ​

项目经理 项目整体负责人。

产品 产品设计工程师。

开发 前、后端开发工程师，移动端开发工程师。

测试 测试工程师，功能测试一般有产品助理兼任。

评审 评审委员会，包括但不限于产品、开发、测试、运营等负责人和用户代表。

用户 分为关键用户和最终用户，项目建设过程中参与的用户为关键用户，项目运营过程中参与的运维为最终用。

运营 运营工程师。

管理措施 ​

产品研发过程中测试、评审、用户等反馈的意见，通过《问题清单》进行管理，主要分为：问题登记、问题分析、指定负责人、问题解决、问题反馈、“回头看”等几个部分。

问题登记 ​

问题登记主要有测试、运营、产品来负责。其中，测试主要负责登记单元测试、集成测试、用户测试过程中的问题及意见； 产品主要负责登记（受理）内部评审、用户评审等项目外部人员反馈意见；运营主要负责登记（受理）产品运营过程中最终使用用户的意见。

问题清单登记的内容主要包括“序号”、“功能域”、“功能项”、“问题描述”、“提出人”、“提出时间”、“受理人（登记）人”。 其中问题描述务必清楚，以阅读人可以“望文生义”为基准。

问题分析 ​

产品为问题分析的第一负责人，必要时可组织项目经理、开发、测试、运营等人员共同商定。问题分析完成后，需在问题清单中维护"问题类别"、"问题分析"、“解决方案”、“优先级”、“计划（期望）完成时间”等。

问题类别主要包括缺陷、优化、需求、咨询、数据等。

• 缺陷是指系统计算逻辑存在差错，主要表现在产出结果与期望结果不一致。比如：期望输出2条记录，实际是3条。缺陷原则上由原开发负责人负责，“T+0”完成解决。

• 优化是指系统计算逻辑本身无误，但边界处理上存在不足或无关业务逻辑的表现层调整。比如：在不影响计算逻辑的情况下显示字段增加、字段长度调整、前端字段名称调整等。优化原则上由原开发负责人负责，“计划（期望）完成时间”需经过负责人认可，高优先级优化类问题一般在"T+1"版本迭代中逐步完善。

• 需求是指涉及系统计算逻辑调整或实现方式调整，前者称之为“需求变更”，比如：增加判断标准、增加取数字段、增加下载功能等；后者称之为“设计变更”，比如：原来为前端下载，需改为后端下载。需求需经过需求评审后指定责任人、安排迭代计划, 重大调整需按需求变更流程进行管理。

• 咨询是指系统运营过程中，最终用户使用过程提出的疑问，原则上“T+0”完成解决。

• 数据是指系统测试、运营过程中，因数据原因造成的系统异常。由测试、运营负责处理，原则上“T+0”完成解决。

⚠️ B端产品运营过程中可能存在管理方面的问题，这里暂不考虑。

优先级主要分为高、中、低三个等级。

• 高优先级是指问题不处理影响其它工作（测试、用户业务）正常开展；

• 中优先级是指问题不处理影响范围仅限于问题本身，不响应其它工作正常开展；

• 低优先级是指问题不处理不影响系统正常使用，仅影响使用体现；

问题解决 ​

问题处理完成后，由问题处理负责人维护“实际完成日期”，由问题受理人（登记人）——测试、运营、产品——负责验证并维护“验证完成日期”。 原则上，以“实际完成日期”为基准，“T+1”完成验证。

对于验证不通过的问题，需在“备注”列填写说明，格式：“YYYYDDMM-不通过说明；\n”

问题反馈 ​

问题处理完成后，受理人需做好反馈，并更新“问题状态”。运营受理的问题需当天完成向用户反馈，产品受理的问题需当周周报内体现，完成向项目经理、审查委员会、用户反馈。

问题状态主要分为已受理（登记）、处理中、挂起、已关闭、已完成。

• 已受理（登记） 问题登记后默认状态为已受理（登记）。

• 处理中 对于优化、需求等处理耗时比较长的问题，在指定负责人后可将问题状态更新为“进行中”。缺陷、咨询、数据因耗时较短，一般不维护此状态。

• 挂起 对于需等待其它条件、且暂时不予处理的问题，可将问题状态更新为“挂起”，挂起”的问题不做日常跟进，仅作阶段性回顾即可。

• 已关闭 对于不合理需求、优化、咨询，经需求评审后，可由产品经理将问题状态更新为“已关闭”，已关闭的问题反复被提起时需引起注意，可能是用户痛点。

• 已关闭 问题处理完成并反馈后，受理人需将问题状态问题状态更新为“已完成”。

“回头看” ​

“回头看”是问题管理执行效果及不断提升问题管理水平的重要举措，包括但不限于回顾各环节执行情况、各环节改进成效，提出各环节进一步改进意见等。