需求研发流程节点及关键产出总结

全流程图示

需求研发流程节点及关键产出总结

参与人员及职能说明

产品经理（PM）：需求的规划和设计者。收集用户诉求和反馈，确定需求收益，设计系统的功能和交互细节。一线业务诉求都会经过PM的消化确认后才会输出给开发人员。针对每个需求都要产出精准详尽的需求文档。（需求文档需要涵盖交互图）
开发人员（RD/FE）：根据需求文档，产出技术方案设计文档，并开发具体功能。开发细节全部参考需求文档，如果PM没写可以要求其补全。每个需求都会有一个对应的开发负责人，也叫主要开发RD，用来协调和反馈整体开发周期进度，通常由本次后端主要内容改动人担任。
交互和视觉设计（UI/UE）：负责产出交互图和设计图，交互最终会体现在需求文档中，要求研发人员严格实现，而UI的设计图则单独提供前端，具体实现程度会和前端开发协调。大多数时候项目并没有UE，都是PM自己设计的交互图。
测试人员（QA）：根据需求文档产出测试用例，并依赖测试用例测试和反馈发现的问题。

主要流程节点

需求圈定
决定本次迭代可以开发哪些具体的需求，每个部门的圈定方式不太一样，但结果都是确定了本次迭代的需求池和优先级，并打回业务价值相对很低或明显不符合规范要求的需求。圈定的意义在于，每次迭代根据产能确定合理的需求量，并确保整体业务价值最大化。执行详情可参考需求圈定执行概要
需求评审（以下都是针对单个需求）
1. 发起人员：产品经理（PM）
2. 参会人员：产品经理（PM）、开发人员（RD/FE）、设计人员（UI/UE）、测试人员（QA）
3. 需要准备：需求文档草案（PM）、交互图草案（PM/UE）
4. 主要产出：需求文档定稿（含交互）、各方排期情况及预期上线时间、技术评审时间节点
5. 讨论内容：各方人员需在需求文档草案的基础上，确认每个功能点是否可以/应该实现，在这个环节需要表达所有有异议的地方，并和PM讨论后确认最终实行的方案，定稿需求文档。另外还需要讨论各方参与人员的排期情况，确认各环节及上线的大体时间节点。针对设计和前端协作，还需要给出交付前端设计图的时间节点。最后还需要本次需求的主要开发人员给出技术方案评审，也就是下一个环节会议的具体时间。需要注意的是，需求文档定稿后如果还有（非细节补充类）改动，则需要发起需求变更流程，重新排期和估时，一般来说不会轻易发起需求变更
技术方案评审
1. 发起人员：本次需求的开发负责人（主要RD）
2. 参会人员：开发人员（RD/FE）（包含其他技术骨干，一般是组长等）、测试人员（QA）
3. 需要准备：技术方案设计草案（RD）、接口设计草案
4. 主要产出：技术方案设计定稿、接口设计定稿、前后端联调时间节点、提测时间节点
5. 讨论内容：本次需求的主要开发人员，需要邀请其他技术骨干来评审，确保本次实现的方案是科学合理的，并最终产出技术方案定稿。同时还需要和前端确认接口设计方案，并定稿接口文档。QA也需要参与则是为了加深对实现的了解，方便写出更有针对性的测试用例文档。方案都确认后即可明确排期计划，所以还需要确定前后端联调时间和提测时间（精确到半日）
开发/联调/测试用例编写
测试用例评审
1. 发起人员：测试人员（QA）
2. 参会人员：测试人员（QA）、开发人员（RD/FE）、产品经理（PM）
3. 需要准备：测试用例草案（QA）
4. 主要产出：测试用例定稿
5. 讨论内容：QA凭借自身对需求文档和技术方案的理解，产出系统性的测试用例文档。在本次会议上需要针对逐个case和PM、RD确认是否符合预期，会后需要定稿测试用例，定稿后可要求RD严格实现用例中的每一个case
项目自测
RD根据测试用例，完成自测工作，可参考关于提升开发质量，降低提测Bug率的探讨
项目提测
提测是有提测动作要求的，不同部门不太一样，可能是状态管理系统的任务状态修改，也可能是提测邮件确认。提测后QA如果还发现问题，则需要提出Bug并指派给对应RD。QA是有权打回提测的，通常都是因为问题太多、主流程跑不通等
问题修复
四方验收（可选）
1. 发起人员：本次需求的开发负责人（主要RD）
2. 参会人员：产品经理（PM）、开发人员（RD/FE）、设计人员（UI/UE）、测试人员（QA）（可选）
3. 需要准备：测试通过后待上线的功能
4. 主要产出：确认上线可行性
5. 讨论内容：本次会议是为了上线前的功能确认，以及设计图实现效果确认（设计确认也可以提前就开始做）。一般都是直接运行并展示功能，都确认通过后则可以开始筹备上线
上线及回归测试
上线前需要RD整理CheckList文档，用来确保上线后功能都符合预期，也不会影响其他相关功能。等顺利完成上线后，需要和PM一起，依赖CheckList进行线上验收，验收通过后整个流程结束