关于前端:需求研发流程节点及关键产出总结

2次阅读

共计 2038 个字符，预计需要花费 6 分钟才能阅读完成。

产品经理（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 进行线上验收，验收通过后整个流程完结