你应该掌握的产品研发管理流程及常见问题处理

你会常常因为需求变更被开发测试吐槽，被抱怨研发管理流程规范太多，流程太复杂，被领导质问为什么延期需求那么多吗？对于产品经理或是项目经理来说，研发管理流程是极其繁琐且难以规范化的工作，本篇文章将介绍大厂的B端产品研发管理流程以及管理中出现问题的解决方案。

一、研发管理流程

整个研发管理过程分为5个阶段，需求阶段，开发阶段，测试阶段，上线阶段，验收阶段，每个阶段都有相应的负责人，对阶段内的所有任务和节点的交付情况负责，保证节点正常推进，而项目经理则统筹起推进全局的角色。

如果按照双周发版的频率，2次版本中间会有时间交叉，即上个版本的测试阶段与下个版本的需求阶段重合，这样可以保证各个角色在每个阶段都有工作任务，满足快速迭代的要求。

1. 需求阶段：产品经理主导

• 产品经理：评估并设计需求；提供需求清单；组织需求评审会，邀请开发测试参会
• 开发：评估本次版本需求可行性和工时，并输出开发方案设计书（如有必要，组织需求反讲会）
• 测试：评估本次版本需求工时
• 项目经理：根据开发测试工作量确定需求排版情况

说明：整个需求阶段会与上个版本的测试阶段重合，测试人员工作重点会放在上个版本的测试工作上。

2. 开发阶段：后端开发主导

• 产品经理：对开发出现的问题进行及时评估影响和重新设计方案
• 开发：进行产品开发及自测，如有前后端交互的需求，需同时提供接口文档，进行前后端联调
• 测试：根据需求说明文档和开发设计文档，输出测试案例，并组织测试案例评审会
• 项目经理：确保转测节点正常推进

3. 测试阶段：测试主导

• 产品：上线前一天在UAT环境进行测试，发送版本升级的客户影响通知
• 开发：针对测试同学提出的bug进行修复
• 测试：进行功能测试，提出bug并修复跟进，上线前一天进行回收测试并发送测试报告
• 项目经理：确保发版时间检查完毕

4. 上线阶段：运维主导

• 开发：汇总产品变更内容并提变更单
• 测试：发版上线后进行正式环境生产验证
• 运维：负责发版前置检查，发版上线，上线后问题处理
• 项目经理：跟进发版进度，对出现紧急问题及时处理

5. 验收阶段：项目经理主导

• 产品经理：生产验收（只验收功能性的需求），客户推广及客户培训
• 开发：如出现生产问题进行问题修复
• 测试：总结bug原因
• 项目经理：版本复盘，统计研发管理过程数据，如需紧急版本则负责版本的发起

该流程仅展示在整个版本流程中各交付节点及其对应角色的产出物，针对其他工作事项例，如产品经理进行竞品调研，客户调研等工作不一一列举。

二、发现问题：研发管理报告

建议在整个研发管理过程中，需要制定一些指标来发现研发管理过程中出现的最多的问题和影响面最大的问题，由此制定规范，对症下药解决问题。

指标1：不规范行为次数

统计在整个研发管理过程中各角色人员出现不遵守规范的次数与情况，进行积分排名，奖惩并行

指标2：bug数据

统计上线前的bug数，上线后bug数，包括但不局限于占比，趋势变化情况，并分析各类bug出现的根本原因和责任人

指标3：需求延期情况

统计每个版本的需求延期情况和延期原因，并跟进需求延期造成的影响，对影响大的需求进行根本问题处理

指标4：需求变更

统计每个版本的需求变更次数及原因，对占比对大的原因进行整改

其他指标：需求溢出率，自动化测试覆盖率，漏洞处理率，版本回退率，sonar扫描率等。

三、常见问题及处理

研发管理问题是任何公司任何部门都会出现，需要协作的部门就需要管理，其本质是能力问题，惰性问题和合作问题，能力问题会导致需求质量，开发质量，测试质量差，惰性问题会导致各种节点延期，信息不统一的问题，而合作问题则会出现沟通障碍，协调合作问题。

能力需要培训，而惰性需要通过规范和奖惩结合。面对研发管理过程各类的问题，并非所有的问题都需要立即处理，在解决问题的同时也会带来一些问题，重要的是要针对影响最大出现频率最大的问题进行针对性处理，同时要有奖励制度，在整个研发管理过程主要有如下几类问题：

1. 需求变更

• 问题：产品随意更改需求的内容/逻辑或开发修改开发方案；需求变更未通知到需求的全部相关人员（特别是测试和前端）；需求说明文档或开发设计文档无统一放置，沟通内容无正式记录
• 影响：需求变更导致开发或测试工作量增大或有重复工作量；需求通知不到位导致各角色获取信息有偏差，需求上线后发现前后端不一致，或必要的测试点未测试导致未发现bug
• 方案：严格规范需求变更规范，需由变更人提起申请，经由相关的产品，开发，测试，项目经理，领导知会及同意后才允许变更，并记录变更原因。变更内容要求正式记录，不允许口头通知或提供聊天记录

2. 节点延期

• 问题：由于工作量评估有误或个人能力问题或拖延心理导致产品提供需求方案延期，开发提供设计方案延期，开发转测延期，测试提供测试报告延期，
• 影响：研发过程节点延期导致后续流程都出现风险，最后导致功能/产品延期，客户满意度下降
• 解决：规范节点延期需说明必要原因，并要求在延期一天后进行撤版或执行临时方案，做好客户通知与安抚工作

3. 无统筹人

• 问题：各个阶段没有对应的统筹人，大家只负责自己部分的工作，缺少统筹
• 影响：零散无人管理，无法识别整体影响
• 解决：每个阶段确定主负责人统筹推进阶段任务与交付情况，对节点交付物做检验，针对出现问题主动发起解决讨论或会议

4. 测试质量差

• 问题：开发自测质量差，导致测试阶段bug多；测试的测试案例有缺漏，测试覆盖不全面，导致未发现bug
• 影响：开发修改bug占用开发时间，测试未发现bug导致上线有问题
• 解决：统计各类bug的数量及原因，针对主要原因进行规范整改，例如统计开发bug数并计入KPI；测试需组织测试案例评审会，推进使用自动化工具提升测试覆盖率

5. 研发管理规范遵守度低

• 问题：研发管理规范频繁变更，一是适应期会各角色还未养成习惯，二是存在侥幸心理和惰性心理，认为犯错没影响未遵守指定研发管理规范
• 影响：随意违反研发管理规范，导致需求
• 解决：一是减少研发管理犯规变更次数，只针对重要问题，定期统一宣导并执行管理规范；二是对于规范的遵守情况奖惩并行，积分制规范管理严格化，对违反人员公示和处理

6. 缺少统一管理平台

• 问题：一个需求的发起，开发，变更等步骤在多个平台跟进和处理；项目经理需手工在不同平台跟进版本进度或获取研发管理数据
• 影响：多平台操作导致工作效率降低，且容易遗漏部分环节导致需求风险
• 解决：尽量统一平台管理和跟进需求的各节点交付情况，并开发研发管理工具，自动根据需求推进情况获取当前交付情况

7. 人员冲突或工作安排不合理

• 问题：各板块需求不平均，需求多的板块的相关开发人员工作量多，其余工作量少，且出现紧急插单需求增加部分人员工作负担
• 影响：工作量多的人需求未能按时完成，工作量少的人当月无产出
• 解决：产品提出需求时尽量平衡安排各个板块内容；项目排版按照每个人员能在本次版本中能支持的工作量安排工作，包括紧急需求的工作量，不安排超过工作量的需求

8. 开发规范或文档缺失

• 问题：缺失开发规范文档，确实历史的开发设计方案/需求设计方案
• 影响：缺少开发文档导致开发方式不统一，后期系统架构混论；开发设计方案和需求设计方案确实导致工作交接无法追溯历史追溯，只能靠猜存在极大风险
• 解决：每次版本须输出相关方案文档，并规定在固定平台统一放置，不断沉淀历史资料

好的研发管理能够明显提高一个团队工作效率，但每个部分都需要根据实际情况进行适配性的管理，如果有兴趣，可以更多的关注项目管理的框架例如scurm框架，或许你会发现研发管理没那么难。

我是一个对世界充满好奇的B端产品经理，产品经理不仅要懂方法论，而且学会把方法论运用到实际中，大家有什么想了解也可以留言～

 

本文由 @🍀 素夏 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议