研发管理流程
2023-06-26 14:33:52 3 举报研发管理阶段 问题发现处理
作者其他创作
大纲/内容
上线阶段
04
开发修改bug占用开发时间，测试未发现bug导致上线有问题
周四
统计每个版本的需求延期情况和延期原因，并跟进需求延期造成的影响，对影响大的需求进行根本问题处理
缺少开发文档导致开发方式不统一，后期系统架构混论开发设计方案和需求设计方案确实导致工作交接无法追溯历史追溯，只能靠猜存在极大风险
无统筹人
生产验收（策划）复盘会（项目）客户推广（策划）问题修复发版
周六
上双周发版日
开发自测质量差，导致测试阶段bug多测试的测试案例有缺漏，测试覆盖不全面，导致未发现bug
阶段：
周日
人员冲突或工作安排不合理
工时统计（开发/测试）需求反讲会（开发）排版（项目）
开发规范或文档缺失
常见问题-影响内容-对应方案
周五
需求溢出率
问题
研发管理规范遵守度低
需求评审会（策划）
开发阶段
双周第二周
01
周一
一个需求的发起，开发，变更等步骤在多个平台跟进和处理；项目经理需手工在不同平台跟进版本进度或获取研发管理数据
验收阶段
零散无人管理，无法识别整体影响
规范节点延期需说明必要原因，并要求在延期一天后进行撤版或执行临时方案，做好客户通知与安抚工作
缺少统一管理平台
统计版本回退与发布占比
研发管理流程阶段
测试报告（测试）发版检查（运维）发版（运维）线上测试（QA）翻版（运维）
由于工作量评估有误或个人能力问题或拖延心理导致产品提供需求方案延期，开发提供设计方案延期，开发转测延期，测试提供测试报告延期，
测试阶段
上双周第二周
需求阶段 开发阶段 测试阶段 上线阶段 验收阶段
周二
报告指标
产品经理：对开发出现的问题进行及时评估影响和重新设计方案开发（后端主导）：进行产品开发及自测，如有前后端交互的需求，需同时提供接口文档，进行前后端联调测试：根据需求说明文档和开发设计文档，输出测试案例，并组织测试案例评审会项目经理：确保转测节点正常推进
影响内容
03
产品经理：生产验收（只验收功能性的需求），客户推广及客户培训开发：如出现生产问题进行问题修复测试：总结bug原因项目经理（主导）：版本复盘，统计研发管理过程数据，如需紧急版本则负责版本的发起
统计各类bug的数量及原因，针对主要原因进行规范整改，例如统计开发bug数并计入KPI测试需组织测试案例评审会，推进使用自动化工具提升测试覆盖率
周三
每次版本须输出相关方案文档，并规定在固定平台统一放置，不断沉淀历史资料
统计溢出需求占比
sonar扫描率
统计自动化测试涉及的测试用例总数在测试用例总数中占比
研发管理流程
节点延期
需求变更导致开发或测试工作量增大或有重复工作量需求通知不到位导致各角色获取信息有偏差，需求上线后发现前后端不一致，或必要的测试点未测试导致未发现bug
bug数据
转测（开发）测试案例评审会（测试）
自动化测试覆盖率
双周发版
对应方案
产品随意更改需求的内容/逻辑或开发修改开发方案需求变更未通知到需求的全部相关人员（特别是测试和前端）需求说明文档或开发设计文档无统一放置沟通内容无正式记录
统计每个版本的需求变更次数及原因，对占比对大的原因进行整改
产品：上线前一天在UAT环境进行测试，发送版本升级的客户影响通知开发：针对测试提出的bug进行修复测试（主导）：进行功能测试，提出bug并修复跟进，上线前一天进行回收测试并发送测试报告项目经理：确保发版时间检查完毕
05
需求清单（策划）
回归测试（QA）变更统计（开发）
统计在整个研发管理过程中各角色人员出现不遵守规范的次数与情况，进行积分排名，奖惩并罚
不规范行为次数
需求阶段
研发管理规范频繁变更，一是适应期，各角色还未养成习惯，二是存在侥幸心理和惰性心理，认为犯错没影响，导致未遵守指定研发管理规范
研发管理报告（发现问题）
统计上线前的bug数，上线后bug数，包括但不局限于占比，趋势变化情况，并分析各类bug出现的根本原因和责任人
每个阶段确定主负责人统筹推进阶段任务与交付情况，对节点交付物做检验，针对出现问题主动发起解决讨论或会议
产品经理（主导）：评估并设计需求；提供需求清单；组织需求评审会，邀请开发测试参会开发：评估本次版本需求可行性和工时，并输出开发方案设计书（如有必要，组织需求反讲会）测试：评估本次版本需求测试工时项目经理：根据开发测试工作量确定需求排版情况
随意违反研发管理规范，导致需求未能按要求完成
漏洞处理率
开发：汇总产品变更内容并提变更单测试：发版上线后进行正式环境生产验证运维（主导）：负责发版前置检查，发版上线，上线后问题处理项目经理：跟进发版进度，对出现紧急问题及时处理
各板块需求不平均，需求多的板块的相关开发人员工作量多，其余工作量少，且出现紧急插单需求增加部分人员工作负担
其他指标
客户通知（策划）
缺失开发规范文档，缺失历史的开发设计方案/需求设计方案
产品提出需求时尽量平衡安排各个板块内容；项目排版按照每个人员能在本次版本中能支持的工作量安排工作，包括紧急需求的工作量，不安排超过工作量的需求
下双周发版日
工作量多的人需求未能按时完成，工作量少的人当月无产出
版本回退率
下双周第一周
双周第一周
统计已处理漏洞占比
...
需求变更
减少研发管理犯规变更次数，只针对重要问题，定期统一宣导并执行管理规范对于规范的遵守情况奖惩并行，积分制规范管理严格化，对违反人员公示和处理
需求延期情况
严格规范需求变更规范，需由变更人提起申请，经由相关的产品，开发，测试，项目经理，领导知会及同意后才允许变更，并记录变更原因。变更内容要求正式记录，不允许口头通知或提供聊天记录
研发过程节点延期导致后续流程都出现风险，最后导致功能/产品延期，客户满意度下降
尽量统一平台管理和跟进需求的各节点交付情况，并开发研发管理工具，自动根据需求推进情况获取当前交付情况
各个阶段没有对应的统筹人，大家只负责自己部分的工作，缺少统筹
测试质量差
02
多平台操作导致工作效率降低，且容易遗漏部分环节导致需求风险
统计使用sonar扫描代码的覆盖率
0 条评论
下一页
