资源描述
...
需求管理方案
..
拟制人 审核人 批准人
日期
2018.05.07 2018.05.11
2018.05.22
版本
V1.1
V1.2
V1.3
朱良超
作者/修 改者
朱良超
朱良超
朱良超
2018.05.02
日期
日期
日期
修改记录
修改容
审核人
完善需求管理流程及相关人员分工
修改整体流程,补充需求管理措施。
增加需求评审阶段成果,需求上线阶
段增加客户确认,形成闭环。
...
...
目 录
1. 概述 1
1.1 现状分析 1
1.2目的 1
1.3 适用围 2
2. 岗位与职责 2
3. 需求流程说明 4
3.1 需求分类 4
3.2 需求管理流程及制度 5
3.2.1整体流程 5
3.2.2 需求收集 6
3.2.3 需求汇总初步分析 7
3.2.4 需求评审分析 8
3.2.5 需求开发 10
3.2.6 需求测试 11
3.2.7 需求上线 12
3.2.8 需求变更 12
4. 需求管理措施 14
5. 过程及成果资料 15
...
1.概述
1.1 现状分析
目前项目需求管理的过程中,在需求收集、流程设置、工作效率等方面存在着一
些问题,导致需求得不到及时有效的解决、项目推进缓慢、客户满意度降低等。比较 常见问题如下:
➢ 需求提出时,不够细化、完全,不能完整、准确的反映客户的实际需求。
➢ 没有考虑整体性和关联性,有些需求只适用于个别分支机构;需求上存在理
解差异,待功能交付后,用户提出所见非所求,造成需求、 bug 争论不休, 需求变更及 bug修复频繁,影响系统稳定并造成成本消耗。
➢ 需求提交方式多样,有很多口头或交流容,存在需求过于简单描述不清。
➢ 没有划定需求的优先级,需求进度难以控制,过多的争论造成了临时事务增
多,
➢ 需求提出后,经过一段时间的开发,后续无人跟踪。
1.2目的
为了更规更有效的管理需求工作,保证需求工作的可控性,明确各阶段的工作
容、处理流程、参与人员以及相关干系人的职责,特制定本管理办法,相关人员必须 严格按照本办法执行新需求相关工作。
..
...
1.3适用围
本制度适用的读者包括:
主要干系人:项目经理、需求管理员、开发负责人
相关干系人:实施人员、技术支持人员、开发人员、项目管理专员。
2. 岗位与职责
主要干系人职责:
主要职责
1. 负责需求收集,与甲方沟通、确认需求相关事宜并编写需求文档。
2. 配合开发人员提供业务知识的支持。
3. 参与需求评审分析。
4. 根据需求评审意见,及时修改需求文档,并发给需求相关干系人。
5. 维护需求信息、跟进需求变更以及需求处理进展,定期向相关领导 汇报。
6. 负责需求测试,制定需求测试计划, 分配测试任务,对系统功能进 行测试确认。
7. 测试存在问题的及时反馈开发负责人和需求管理员,并跟进解决情 况,完成之后重新进行测试。
8. 部测试完成之后负责与甲方沟通,进行测试,完成需求结果确认。
9. 负责需求上线。
1. 负责定期收集汇总、整理分类各项目提报的需求并进行审批,与提 交人及总公司人员进行沟通确认。
2. 组织项目经理、 开发人员等召开需求评审会议, 从架构、业务、技 术、风险等方面对业务需求的容和实现方式进行全面评估,并提出 评估意见,确定需求解决方案。
3. 负责收集开发负责人反馈的需求解决计划,并及时告知各项目经 理。
4. 跟踪需求解决进展情况,协调项目组与开发人员相关事宜的沟通。
5. 负责与总公司人员沟通需求,跟踪总公司需求解决进度。
6. 定期到各项目组与客户方进行沟通,了解现场问题,收集需求。
角色
项目经理
需求管理员
..
...
7. 负责需求开发结果的确认。
1. 参与需求评审,从技术角度对需现方式、风险等进行评估,确定技 术路线。
2. 负责向需求管理员反馈开发计划
3. 负责需求开发所有工作的沟通、协调管理。
4. 负责需求开发进度、成员管理。
5. 负责或参与需求所有成果的审批。
6. 参与或指定开发人员协助需求提交人员与甲方对于需求的沟通确、 认。
开发负责人
相关干系人职责:
主要职责
1. 协助项目经理进行需求收集。
2. 配合开发人员提供业务知识的支持。
3. 需要时参与需求评审分析。
4. 协助项目经理进行需求测试。
5. 协助项目经理进行需求上线。
1. 需求收集阶段协助项目经理与甲方对于需求的沟通、确认。帮助项 目经理分析、确定业务需求。
2. 必要时提供技术支持,配合项目经理完成测试环境的搭建。
1. 协助项目经理与甲方对于需求的沟通、确认。帮助项目经理分析、 确定业务需求。
2. 负责需求开发的具体实现。
3. 当项目经理对需求确认不通过时,按照反馈结果对需求进行修改。
1. 参与需求评审分析,从项目进度、质量等方面进行评审分析。
角色
实施人员
技术支持人员
开发人员
项目管理专员
..
...
3. 需求流程说明
3.1 需求分类
按照需求容大致可分为:
需求类型
新业务功能
需求类型定义
已有系统中没有此功能,需要在原有基础上新增功能
功
功能改进
能
当前系统已经有此功能,因组织架构、制度规、业务处理流 程等发生变化,需要对现有系统的某些功能进行优化调整
系统功能上线前,要在原有需求的基础上增加、修改或删除
性 需求变更
需求容,但需求容的变动会引起成本增长过大、对现有业务
影响较大、或可能存在风险、合规等问题
需
系统问题 求
界面类需求
系统现有功能可以正常使用,但是性能、安全、底层处理逻 辑和架构等即将或者未来可能成为业务进一步扩的瓶颈
前端页面设计、开发、更新修改及维护。
不直接与系统的具体功能相关的一类需求。
非功能性需求
例如:安全性、可扩展性、响应时间、交付要求等。
按照优先级可分为:
需求类型定义
1、 系统必须实现的,没有其功能就无法完
成正常的日常工作及业务处理。
立即解决
2、 严重影响系统要求或基本功能的实现,
且没有办法更正。
1、严重影响系统要求或基本功能的实现,但
存在合理的更正办法。
高级优先
2 国、家或行业法律法规标准、政府下文要求
的。
采取的措施
对 于这 类 需 求在
项目 实 施过程中
需重点投入资源,
优先实现。
对 于这 类 需 求在
项目 实 施过程中
需重点投入资源,
优先实现。
需求类型
..
...
正常排队
低级优先
3 、事先已经约定的功能。
4 、不重要但做了会产生极佳效果。
1、使用者操作不便等对正常业务影响不大
的。
2 、实现这些需求将增强系统的性能
3 、系统最终所要求的
1 、系统附加功能
2 、使系统更完美,属于锦上添花。
如果项目 实 施中
出现进度、资源等
方面的冲突时,可
与客户 沟通延迟
到下一版本。
根据项目时间进
行 安 排 , 排在最
后。
3.2 需求管理流程及制度
3.2.1整体流程
整体流程示意图:
需求管理主要分为 6 个阶段:需求收集、需求汇总初步分析、需求评审分析、需
求开发、需求测试、需求上线。
需求开发的管理流程:
..
...
3.2.2 需求收集
3.2.2.1 主要参与人员
项目经理、实施人员、技术支持人员
3.2.2.2 工作容及要求
(1) 项目经理针对用户提出的需求,采用访谈、会议、问卷等形式收集基础信
息(包括相关支持文件,例如会议纪要、下发文件等)
(2) 从业务方面判断是否合理,若不合理应第一时间告知用户,并解释清楚原
因。或是分析判断该需否可以通过系统已有的其他功能来实现。
(3) 按照模板编写 《需求文档》(需求描述要求清晰、全面,对于文字难以描述
的可采用示意图、原型设计等方法)。
(4) 按照项目组需求确认单样式填写《需求确认单》,并由甲方签字确认。
..
...
(5) 每周三 12点之前汇总本项目需求(含相关支持材料) 发送至需求管理员。
紧急需求可立即发送需求管理员并告知。
(6) 项目经理及时将新需求录入 jira 系统提交至需求管理员,并上传由客户
签字的需求确认单及其它相关支持材料。紧急需求可提交 jira 之后立
即告知需求管理员。
备注: 项目组的具体工作流程,项目经理根据实际情况进行制定。
3.2.2.3 成果资料
《需求确认单》、《需求文档》、《问题确认单》
3.2.3 需求汇总初步分析
3.2.3.1 主要参与人员
需求管理员
3.2.3.2 工作容及要求
(1) 每天对各项目提报的需求进行收集汇总、分类整理形成《需求汇总表》。
(2) 进行审批,对填写不符合要求、描述不清楚的及时退回各项目经理。
(3) 判断需否合理,若不合理及时告知项目经理,项目经理应第一时间告知用户,
并解释清楚原因。或是分析判断该需否可以通过系统已有的其他功能来实现。
(4) 联系总公司相关人员,询问公司系统版本是否已经实现该功能或类似功能。
(5) 每天将经过审批之后的需求在 jira 上及时提交给开发负责人,每周四将经过分
析确认的各项目组的需求汇总发送至开发负责人。
(6) 若开发负责人对需求有疑义,需求管理员组织项目经理、开发负责人等相关干 系人召开需求评审会议,确定需求解决方案。
..
...
3.2.3.3 成果资料
《需求汇总表》
3.2.4 需求评审分析
需求分析总体流程如下:
3.2.4.1 主要参与人员
项目经理、开发负责人、需求管理员
根据具体情况可通知技术支持人员、开发人员、项目管理专员等相关干系人参
会。
3.2.4.2 工作容及要求
(1) 需求管理员组织人员对需求设计从技术和业务方面进行可行性分析,对业
..
...
务逻辑、业务流程等进行评估。
若出现以下几种情况可退回项目经理:
技术层面:
➢ 与其他需求有重复的。
➢ 需求中有不合理事项的。
➢ 需求不明确需做补充的。
业务层面:
➢ 与目前的业务操作流程、运营有矛盾的。
➢ 业务流程未理顺 , 业务规则未明确或者没有体现,有可能导致上线后 ,
无常进行业务运作,或者存在运营风险的。
若出现以下几种情况需发送给部门领导进行审批。
技术层面:
➢ 需对系统结构进行大规模改造的。
➢ 涉及系统架构变更的。
➢ 当前技术无法实现的。
业务层面:
➢ 需大规模的更改原有的业务流程,增加大量人工后续处理成本。
(2) 项目经理根据需求评审结果完善《需求文档》,形成最终需求。
(3) 分析总公司系统是否已经实现该功能或类似功能,若已实现由需求管理员
负责与总公司相关人员进行沟通获取升级包。
(4) 如果总公司版本未实现该功能,需讨论分析并确定该需本地设计开发还是 总公司设计开发。
若为总公司开发,由需求管理员及时将需求提交到 jira 系统并与总公司人 员联系,确定完成时间。
..
...
(5) 开发负责人确认需求的实现方式,评估需求的开发工作量,确定需求开发
完成时间及开发人员,形成《解决方案》 ,并在 jira 系统中备注解决计划。
3.2.4.3 成果资料
《解决方案》、《需求文档》、《需求汇总表》
3.2.5 需求开发
3.2.5.1 主要参与人员
开发负责人、开发人员
3.2.5.2 工作容及要求
开发负责人:
(1) 每天及时登录 jira 系统,收集需求管理员发送的需求,从技术方面进行可 行性分析,并判断该功能是否会影响已有的业务功能,若存在问题应及时 告知需求管理员,由项目经理对需求进行变更并告知甲方,如无问题需在
2 个工作日向需求管理员反馈开发计划并在 jira 系统中注明。
(2) 对于有疑义的,联系需求管理员组织需求评审分析会议,从业务、技术角 度对需现方式、风险等进行评估,并制定解决计划。
(3) 制定需求开发计划,分配需求开发人员,确定技术方案。
(4) 及时向需求管理员反馈开发计划。
开发人员:
(1) 根据需求评估通过的需求文档及开发计划按时进行设计开发,并在 jira中
备注解决进展情况。
...
(2) 如果涉及到对数据库结构的变动修改,应及时更新维护数据库结构说明 书。
(3) 编码完成后,开发人员需进行编译部署、单元测试。
(4) 将开发成果提交开发负责人审核确认。
(5) 无问题之后在 jira 上转交测试人员。
3.2.5.3 成果资料
《数据库设计说明书》 (更新)、《部署文档》、《更新说明》、需求更新包(包 含数据脚本)
3.2.6 需求测试
3.2.6.1 主要参与人员
项目经理、实施人员
3.2.6.2 工作容及要求
(1) 制定需求测试计划,分配测试任务,对系统功能进行测试。
(2) 测试若存在问题及时反馈开发负责人和需求管理员,在 jira中备注测试情 况,并跟进解决情况,完成之后重新进行测试。
(3) 部测试完成之后,向甲方提出测试申请,由甲方人员进行系统测试,完成 需求结果确认。
3.2.6.3 成果资料
《测试报告》、《系统用户操作手册》 (更新)
..
...
3.2.7 需求上线
3.2.7.1 主要参与人员
项目经理、实施人员、开发人员
3.2.7.2 工作容及要求
(1) 项目经理与甲方沟通,提起上线申请。
(2) 对数据库及应用程序进行备份。
(3) 系统升级上线,并进行上线验证。
(4) 若上线验证失败,则将上线版本从生产环境中回退,需求转入开发流程。
(5) 维护更新系统操作手册,上线之后 3 个工作日针对适用人员进行操作培训。
(6) 项目经理负责与客户确认需求最终结果,由甲方人员在 《需求确认单》 上进 行签字确认并上传 jira ,关闭需求,进行需求归档。
(7) 需求管理员跟进确认结果,重要需求需要需求管理员直接与甲方人员进行确 认。
3.2.7.3 成果资料
《需求确认单》、《需求汇总表》
3.2.8 需求变更
需求变更:指开发人员受理需求后,需增加、修改、删除需求容的现象。 需求变更流程图如下:
..
...
3.2.8.1 主要参与人员
项目经理、需求管理员、开发负责人
3.2.8.2 工作容及要求
(1) 项目经理根据需求变更容填写需求变更文档。
(2) 按照项目组需求确认单样式填写需求变更,并由甲方签字确认。
(3) 需求变更后重新提交 jira 系统。
(4) 需求管理员进行审批,不通过退回至项目经理,通过之后判断是否属于重
大需求变更。
(5) 重大需求变更需求管理员组织项目经理、开发负责人及相关干系人召开需
..
...
求评审会,确定解决方案。
(6) 开发负责人 2 个工作日制定开发计划,并向需求管理员反馈开发计划。
3.2.8.3 成果资料
《需求变更文档》
4. 需求管理措施
(1) 紧急需求项目经理需及时在 jira 系统中提报需求管理员并告知,需求管理
员审核之后发送给需求开发负责人,开发负责人需在 1 个工作日反馈解决 计划。
(2) 普通需求项目经理及时在 jira 系统中提报需求管理员,需求管理员审核之
后发送给开发负责人,开发负责人在 2 个工作日反馈解决计划。
(3) 需求管理员对各项目组需求提报时间的及时性、需求容的规性进行审核,
并纳入绩效考核。
(4) 需求管理员对开发负责人反馈开发计划的及时性纳入绩效考核。
(5) 需求评审分析会议可根据实际情况采取现场会议、语音会议等方式进行,
参会人员的参加情况纳入绩效考核。
(6) 需要部门领导协助的,需在 2 个工作日的给予指导或反馈解决方法。
(7) 各部门人员按照上文职责认真履职,积极配合。
(8) 对于提交到总部的需求如果一周未进行反馈解决计划或未按照反馈时间解
决的,需求管理员将该部分需求以的方式发送部门一级领导,抄送相关分 管副总及总经理。
..
...
5. 过程及成果资料
附件 1 :《需求文档》
附件 2 :《需求变更文档》
附件 3 :《问题提报单》
附件 4 :《数据库结构说明文档》 (已有,如有变动时进行更新)
附件 5 :《部署文档》
附件 6 :《更新说明》
附件 7 :《测试报告》
附件 8 :《系统用户操作手册》 (已有,如有变动时进行更新)
附件 9 :《需求汇总表》
附件 10 :需求更新包
附件 11 :《需求提交情况统计表》
附件 12 :《解决方案》
展开阅读全文