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

全流程图示

参与人员及职能说明

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

主要流程节点

1. 需求圈定
   决定本次迭代可以开发哪些具体的需求，每个部门的圈定方式不太一样，但结果都是确定了本次迭代的需求池和优先级，并打回业务价值相对很低或明显不符合规范要求的需求。圈定的意义在于，每次迭代根据产能确定合理的需求量，并确保整体业务价值最大化。执行详情可参考需求圈定执行概要

2. 需求评审（以下都是针对单个需求）

   1. 发起人员：产品经理（PM）
   2. 参会人员：产品经理（PM）、开发人员（RD/FE）、设计人员（UI/UE）、测试人员（QA）
   3. 需要准备：需求文档草案（PM）、交互图草案（PM/UE）
   4. 主要产出：需求文档定稿（含交互）、各方排期情况及预期上线时间、技术评审时间节点
   5. 讨论内容：各方人员需在需求文档草案的基础上，确认每个功能点是否可以/应该实现，在这个环节需要表达所有有异议的地方，并和PM讨论后确认最终实行的方案，定稿需求文档。另外还需要讨论各方参与人员的排期情况，确认各环节及上线的大体时间节点。针对设计和前端协作，还需要给出交付前端设计图的时间节点。最后还需要本次需求的主要开发人员给出技术方案评审，也就是下一个环节会议的具体时间。需要注意的是，需求文档定稿后如果还有（非细节补充类）改动，则需要发起需求变更流程，重新排期和估时，一般来说不会轻易发起需求变更

3. 技术方案评审

   1. 发起人员：本次需求的开发负责人（主要RD）
   2. 参会人员：开发人员（RD/FE）（包含其他技术骨干，一般是组长等）、测试人员（QA）
   3. 需要准备：技术方案设计草案（RD）、接口设计草案
   4. 主要产出：技术方案设计定稿、接口设计定稿、前后端联调时间节点、提测时间节点
   5. 讨论内容：本次需求的主要开发人员，需要邀请其他技术骨干来评审，确保本次实现的方案是科学合理的，并最终产出技术方案定稿。同时还需要和前端确认接口设计方案，并定稿接口文档。QA也需要参与则是为了加深对实现的了解，方便写出更有针对性的测试用例文档。方案都确认后即可明确排期计划，所以还需要确定前后端联调时间和提测时间（精确到半日）
4. 开发/联调/测试用例编写

5. 测试用例评审

   1. 发起人员：测试人员（QA）
   2. 参会人员：测试人员（QA）、开发人员（RD/FE）、产品经理（PM）
   3. 需要准备：测试用例草案（QA）
   4. 主要产出：测试用例定稿
   5. 讨论内容：QA凭借自身对需求文档和技术方案的理解，产出系统性的测试用例文档。在本次会议上需要针对逐个case和PM、RD确认是否符合预期，会后需要定稿测试用例，定稿后可要求RD严格实现用例中的每一个case
6. 项目自测
   RD根据测试用例，完成自测工作，可参考关于提升开发质量，降低提测Bug率的探讨
7. 项目提测
   提测是有提测动作要求的，不同部门不太一样，可能是状态管理系统的任务状态修改，也可能是提测邮件确认。提测后QA如果还发现问题，则需要提出Bug并指派给对应RD。QA是有权打回提测的，通常都是因为问题太多、主流程跑不通等
8. 问题修复

9. 四方验收（可选）

   1. 发起人员：本次需求的开发负责人（主要RD）
   2. 参会人员：产品经理（PM）、开发人员（RD/FE）、设计人员（UI/UE）、测试人员（QA）（可选）
   3. 需要准备：测试通过后待上线的功能
   4. 主要产出：确认上线可行性
   5. 讨论内容：本次会议是为了上线前的功能确认，以及设计图实现效果确认（设计确认也可以提前就开始做）。一般都是直接运行并展示功能，都确认通过后则可以开始筹备上线
10. 上线及回归测试
    上线前需要RD整理CheckList文档，用来确保上线后功能都符合预期，也不会影响其他相关功能。等顺利完成上线后，需要和PM一起，依赖CheckList进行线上验收，验收通过后整个流程结束

关键文档

1. 需求文档（含交互图）：整个研发流程的核心，定稿后不能轻易修改是整个研发流程的基石
2. 技术方案设计文档：多为后端技术方案，用来确保本次实现科学合理，也方便未来查阅
3. 测试用例文档：在需求评审后便可以开始编写，提测前一定需要完成评审，是系统性测试的保障，也是开发人员自测的依赖
4. 线上CheckList文档：线上回归需要涵盖的范围，用这种形式是为了避免遗漏