游戏业务常规迭代产品需求处理流程建议书
2017-04-19 10:03:05 0 举报
在处理游戏业务常规迭代产品需求时,建议遵循以下流程:首先,进行市场调研和用户反馈收集,了解用户需求和市场趋势;其次,根据收集到的信息,制定产品规划和目标,明确迭代的重点和方向;然后,进行需求分析和设计,将用户需求转化为具体的功能和特性;接下来,进行开发和测试,确保产品质量和稳定性;最后,进行上线和运营,监测产品表现并及时调整优化。在整个流程中,需要与团队成员密切合作,保持良好的沟通和协调,以确保产品的顺利迭代和用户满意度的提升。
作者其他创作
大纲/内容
P6 项目经理上线
--原则:若PRD内容若未达到指导开发和测试的要求,则技术有权要求其更改和完善
--原则:1)项目经理定需求收集截止时间点 2) 来自产品中心的需求也必须按照游戏平台的迭代计划在此时间节点收集
游戏事业部游戏相关业务常规版本迭代需求流程规范建议V1.1
--驱动主体:业务线产品经理--涉及方:技术(开发&测试)+ 产品设计团队+需求方--细节流程:1)产品组内部,完成PRD,UE+UI(如果有)的制作2)PRD评审,需要开发团队、QA团队、需求方和产品经理参与--输出:1)详细PRD+UE+UI 2)邮件告知相应开发已完成PRD制作并抄送各阶段责任人
P1 需求收集阶段
启动
P2 需求清单评审阶段
P5 测试+产品&需求方验收阶段
--原则:测试是否通过,依据QA的真实测试结果
项目经理全程跟踪、反馈项目需求完成情况
--驱动主体:项目经理--涉及方:开发工程师+测试工程师--输出:1)功能完善可用于测试的软件版本 2)定稿测试用例 3)邮件告知QA提测及抄送各阶段责任人
--驱动主体:项目经理--涉及方:开发+测试+产品+需求方--细节流程:1)QA测试:按照测试用例,完成测试,直到达到质量要求才可发版2)产品&需求方验收:产品和需求方团队对提测产品在测试环境进行验收,双方都要以邮件的方式向测试团队输出验收反馈3)bug 修复,测试过程中出现的bug,开发团队继续在此期间修复--输出:1)达到产品、开发、需求方、测试团队质量和功能预期的软件版本 2) 上线申请邮件(测试发起)
P4 开发阶段
--原则:测试用例的评审需要开发和产品团队的参与
游戏事业部游戏业务常规迭代需求处理流程建议如下:
--驱动主体:需求方--涉及方:需求方+产品+项目经理--细节流程:1)需求方在线上进行验证,如需测试资源支持线上验证,则需求方发起邮件向技术申请测试资源2)确认线上产品是否符合前期预期,如不符合,排查原因:a)查看产品PRD:是否符合原需求方所期望b)查看测试用例:测试用例标准是否符合要求c)查看产品经理产品验收反馈:验收时有无发现问题d)产品牵头,开始重新设计可满足需求的方案,并确定可上线时间点,走快速需求迭代开发的过程--输出:1)需求方回复邮件确认线上产品符合预期,需回复确认邮件的需求方责任人见以下附表
--驱动主体:项目经理--涉及方:项目经理 + 迭代线业务产品接口人(见附表)--细节流程:项目经理邮件通知迭代业务线产品接口人需求收集截止点及迭代线各里程碑时间节点,业务线产品接口人操作落实各需求方的需求收集汇总--输出:需求方的需求清单列表(包含各PMS任务链接)
--原则:项目上线与否,取决于产品经理是否邮件回复批准通过
--驱动主体:项目经理--涉及方:项目经理--细节流程:产品经理确认同意上线后,项目经理操作上线,并邮件告知相关人员,通知需求方线上回测,具体细节流程参见wiki:后端上线流程:http://wiki.qiyi.domain/pages/viewpage.action?pageId=28599686SDK发包流程:http://wiki.qiyi.domain/pages/viewpage.action?pageId=28599457--输出:1)项目经理回复上线申请邮件明确迭代版本已正式上线,并通知需求方回测
--驱动主体:业务线产品经理接口人--涉及方:技术+产品经理+需求方--周期:0.5周--细节流程:产品经理组织需求评审,综合技术、需求各方意见,粗粒度评估筛选哪些需求进入迭代版本--依据:需求优先级,紧急程度,技术可行性/完整性--输出:定稿需求清单
项目迭代周期
结束
--原则:需求方在线上产品是否符合预期这一结论上具有绝对话语权
P3 PRD+UE+UI制作和评审
P7 需求方线上回测
0 条评论
下一页