需求管理培训课件

1、如何做出一个好需求,需求管理经验分享,李昌明 2015年1月29日,用户：我想要一个秋千！,项目经理：我能想象到你要的是什么！,系统分析师：好了，我知道怎么设计了！,开发人员：秋千啊？很简单，我知道了！,结果，项目的文档,产品安装是这样的,用户为项目开发的投资,后期的技术,其实用户真正想要的,产品经理：放心，绝对舒适！,现象1：从前，有一个需求,现象2：”需求开发”和”技术开发”，谁的时间长？,需求开发,技术开发,vs,什么是需求？,系统,行为,规则,性能,功能,总结为两个必须：1、系统必须完成的事；2、系统必须具备的品质。,从需求范围看它的层次,从目标到具体，从整体到局部，从概念到细节,业务

2、需求,用户需求,系统需求,对系统体系化、流程化的需求，如：费用管控、成本控制等；,具有业务场景的具体需求，如：预算调整、合同变更等；,系统的功能性需求，如：可以批量处理、可以关联单据等；,从用户满意度看它的层次,最大限度地提升用户的满意度,常规需求,用户认为系统应该做到的功能或性能。如：预算执行后要进行反写；,期望需求,用户想当然认为系统应该具备的功能或性能，但并不能正确描述自己想要得到 的这些功能或性能需求。如：预算跨年；,意外需求,用户要求范围外的功能或性能，但不实现也不影响其使用。如：使用拼音或输入关键字可以快速带出相应的费用类型，进行选择；,需求工作是讲究方法的,包括创建和维护需求文档

3、所必需的一切工作,需求开发,需求管理,需求收集,需求分析,需求文档,需求确认,需求基线,需求变更,需求跟踪,风险管理,需求基线,需求收集,是一个确定和理解不同的用户需求的过程。,用户访谈,1、准备访谈；2、主持访谈；3、访谈后续工作（吸收，理解，未明确问题跟进，访谈备忘录）,问卷调查,1、确定问题及类型；2、编写问题；3、设计问卷格式；4、收集整理；,场景模拟,1、资料准备；2、制作原型；3、思维引导；,小组会议,1、选择与会人员；2、准备会议主题；3、主持会议；4、专题讨论；,根据情况选择不同的需求收集方式,用户访谈,问卷调查,原型演示,小组会议,优 势,劣 势,具有较好的灵活性，有较广的应

4、用范围； 采用开放式和封闭式问题设计； 面对面沟通，通过用户表情、肢体语言等动作来获取一些更隐性的信息；,用户较忙时，时间难以安排； 面谈时信息量大，记录较为困难； 需要较强的沟通技巧；,短时间内以较低的代价从大量的回答中收集数据； 允许匿名，用户可能会提供真实信息； 结果比较好整理和统计；,缺乏灵活性； 不如面对面沟通直接，无法获取更隐性的需求，用户也没机会立即澄清对问题有含糊或错误的回答； 不利于对问题进行展开的回答，无法了解一些细节； 回答者的数量往往比预期的要少；,给用户一个直观的演示，所见即所得； 用户体验好，交互性强； 对用户界面提供了早期的评审；,花费在原型上的时间很多，使需求获

5、取的速度大大降低；,收集需求的时间更快； 对于一些有歧义的问题、不清晰的需求，十分有用；,要考虑多方的时间，会议的组织难度大； 对于会议的主持和把控需要技巧； 气氛很重要，要开放，言之有物；,合理的提问和引导出全面的需求并记录下来,需求八要素,需 求：差旅费报销 价 值：为一线员工提供差旅报销功能，便于 触 发：差旅申请单 前 提：有部门预算，审核通过的差旅申请 频 率：平均每天100单 关键情况：关联多张差旅申请单报销,具体业务： 1、选择关联对应的差旅申请单； 2、填写此次出差费用； 3、点击提交单据； 4、打印封面，贴发票，给初审岗扫描；,异常及反向处理： 1、发起报销时，发现选错出差申

6、请单费用类型，且出差申请单已经终审； 2、没有部门预算； 3、,需求分析,提炼、分析和仔细审查已经获取到的需求，以确保所有的用户都明白其含义并找出其中的错误、遗漏或不足之处。关键在于对问题的研究和理解。,绘制系统与系统外的界限和接口关系,创建用户界面原型,分析需求的可行性,确定需求的优先级,建立需求模型,描述字段属性,寻找意外需求,需求文档,目的是使用户和开发人员对需求有一个共同的理解，使之成为整个开发工作的基础，也是需求的基线。,范围,1、文档用户和内容概述；2、需求范围；3、涉及部门及岗位；,需求,1、业务需求；2、功能需求；3、相应规则；,可追溯性,文档中需求与系统需求的双向可追踪性；,

7、引用文件,1、制度、规范；2、公司发文；3、其他参考文档；,避免长篇大论式的文档描述,文不如字，字不如表，表不如图。,需求确认,对需求文档进行评审和确认的过程。,需求评审,1、分层次评审；2、正式与非正式评审结合；3、事后跟踪工作；,需求测试,1、准备“概念”测试用户；2、基于“概念”测试用例模拟需求测试；,需求基线,经评审批准，需求文档就定义了开发工作的需求基线。它是用户和开发人员之间的约定； 开发人员可以通过基线区分“旧需求”和“新需求”； 通过基线，识别需求变更。,需求变更,需求变更是不可避免的，并不是说不应该做避免的工作，恰恰相反，在开发前尽量减少变更，以将其带来的风险降到最低。,增加

8、需求,修改需求,减少需求,质量,时间,成本,范围,需求风险管理,希望能够“掌控”风险，一旦发生能够按照预案进行应对。,日常需求开发中存在风险的做法： 需求收集阶段，没有考虑到足够的用户，导致需求是片面和不完整的。如：只考虑到了执行层面的人员，忽略了管理层的想法； 忽略了用户分类。如：一线用户、共享用户、出纳对于共享任务平台的要求都有各自的特点； 用户需求的不断增加； 模棱两可的需求； 不必要的特性。如：费控系统的填单界面，技术人员开发了限制附件数量只能在99内； 需求说明文档过于简单； 不准确的估算。如：需求交付时间未考虑测试时间就知会用户，其认为是一种承诺；,需求跟踪,正向跟踪,反向跟踪,用户需求,功能需求,始终保持原始需求与实际系统实现相符，避免遗漏和变样。,目的： 确保需求被开发出来，没有漏项； 了解当前计划执行情况； 减少核心人员变动带来的风险； 在增、删、改需求时，可以确保不忽略每个收到影响的因素。,沙僧是个细心的人！这天，他整理大师兄的内裤，发现有个洞，然后就耐心的缝了起来；第二天发现又有个洞，于是又补了起来