需求管理方法.ppt

1、需求管理,2011年6月12日,需求管理的总体原则,“试点、推广、优化” 刘总 “尊重IT建设的规律，采用迭代开发的软件工程管理方式，对系统滚动优化和升级。 建立和冻结版本，逐步演进。 不要追求完美，要追求更美； 不要技术导向，要需求导向； 不要忽略过渡期，要平滑过渡。” 赵总,综合营帐版本演进计划,绵阳试点生产上线版本,基于R1增加： 版本建立和冻结： 版本推广和上线时间：,基于R1增加： 版本建立和冻结时间： 版本推广和上线时间：,R1,R1,R2,当前需求管理主要任务和工作原则,基于绵阳试点R1版本，根据推广地市差异，建立和冻结R1版本，并逐步明确R2版本范围； 工作原则: 在推广为主的

2、前提下进行版本优化； 地市差异需求应尽量通过相应合理的业务和管理变革，基于R1版本功能实现； 对R1无法实现但是重要紧迫的合理需求，纳入R1版本； 对R1无法实现但是不太紧迫的需求或者对R1整体有根本性冲击的需求应尽量考虑放在R2或以后版本,需求管理流程,市州各部门,市州推广组/ 保障组,业务小组,技术与需求管理 办公室,项目管理 办公室,提出需求,收集定义需求和实施分析,需求一致合理?,需求分析 评估,接受需求?,是,否,1,2,8,7,4,需求业务 评估和汇总,3,在项目范围内?,5,项目范围变更?,6,是,需求研发流程,项目范围变更流程,需求业务 解释和决策,否,可配置实施?,配置实施流

3、程,是,否,需求管理流程说明,需求管理和决策机制关键点,项目需求管理与运营需求管理流程分离. 推广市州在综合营帐范围内的需求必须通过项目需求管理流程进行管理; 未推广市州运营需求或推广市州不在综合营帐范围内的需求通过运营需求管理流程; 市州推广组清楚了综合营帐范围和系统现状, 尽量基于已有功能实现需求，对必须通过开发实现的需求,协助需求提出部门明确定义和描述需求; 业务小组对省和各市州的需求从业务角度具有最终的解释和决策权, 但不决定如何以及什么时候实现需求; 业务小组形成业务上的决策力，通过省公司市场部到分公司的纵向管理线条形成业务上的执行力; 技术与需求管理小组从系统角度对需求是否属于综合

4、营帐范围以及需求分析评估具有权威和决定权; 但不能决定是否进行范围变更, 是否接受需求; 项目管理办公室根据业务小组和技术与需求管理办公室的专业评估决定是否进行范围变更, 是否接受需求; 原则上需求决策在PMO以下完成，涉及到影响面特别大的提交到项目领导组决策。,市州推广组需求管理职责,从市州相关部门收集汇总需求； 对是否属于综合营帐范围有质疑的需求直接提交给技术与需求管理办公室进行判断；对属于综合营帐范围内的需求，明确定义并进行实施分析 如果能基于综合营帐现有功能配置实施需求, 进入需求实施流程，并反馈需求提出部门； 如果不能基于综合营帐现有功能配置实施需求, 作出初步评估分析后提交技术与需

5、求管理办公室进一步分析。初步评估分析包括系统实施和业务两部分： 差距分析和实施方案初步建议(结合系统功能/业务和管理变更) 业务影响和变更可行性初步分析 如果采用实施建议,对现有业务有什么影响？ 有没有可能采用相应的业务或管理变更？,技术与需求管理办公室需求管理职责,从全省统一的业务角度对需求的一致性,合理性, 重要性, 紧迫性等进行评估, 如果需求在业务规则或业务流程方面存在矛盾或存在合理性质疑, 提交业务小组进行业务解释 判断需求是否在项目范围内, 协助项目管理办公室控制项目范围; 系统需求分析评估和实施建议 实施方案和可行性分析 对实施时间/进度/成本的影响评估 实施建议: 在那个阶段以什么方案实施,业务小组需求管理职责,从全省业务角度对有矛盾或有疑问的需求进行业务解释或澄清，形成相对统一的业务规则，规范不合理流程；并通过市场部门要求推广分公司按业务小组解释的规则和流程执行。 分析业务规则和