需求管理方法论要点
IPD咨询之六大方法论
IPD咨询之六⼤⽅法论IPD集成产品开发体系，其实是⼀套⾼效的研发管理体系。
现在很多企业已经意识到，如果不搞研发，不提⾼产品质量、技术创新，⽆异于等死。
但是，现在⼤多数企业的赢利⽔平很低，研发投⼊的风险很⼤。
所以正确的做法是系统性地引进⼀套先进、成熟的研发模式。
IPD培训⽆疑是企业明智的选择。
IPD的六⼤⽅法论1、需求管理⽅法论客户需求是战略规划和新产品开发的基本依据，⽽如何获取充分的客户需求，通过分析转化为市场需求、产品需求，并最终实现需求是⼀个复杂的系统⼯程，IPD体系提供了产品包需求（OR，Offering Requirements）⽅法论来操作和管理这⼀过程。
其中的核⼼环节是按照分层（问题、特性、功能需求及⾮功能需求）、分类（如$APPEALS⼋类）的架构分析和定义⾼质量的、具有竞争⼒的产品包需求（OR）。
2、战略规划⽅法论在“产品为王”的时代，产品是战略的核⼼，不管是公司整体战略，还是业务战略均应以产品为主线。
在IPD培训中，产品及研发正是在公司战略规划、产品线战略规划、产品业务计划三个层次规划的牵引和指导下运⾏的，⽽各层次的战略规划都是通过市场管理（MM，Market Management）⽅法论来完成的。
市场管理（MM）是⼀套系统的⽅法，⽤于对⼴泛的机会进⾏选择收缩和组合决策，制定出⼀套以市场为中⼼的、能够带来最佳业务成果的战略与计划。
3、⼈才培养及激励⽅法论产品经营和研发运作需要各种类别和各个层次的⼈才，IPD体系关注系统性地规划和培养产品及研发⼈才，建⽴职业化的⼈才梯队。
⼈才培养不仅需要培训和⾃我学习，还需要任职资格体系的牵引和指导，更需要依据体系和对照模板付诸实践并提⾼。
研发绩效管理是推动绩效⽬标达成、重在辅导的⼿段⽽不是秋后算帐、倾向于负向激励的⼯具。
知识⼯作者的动⼒源泉在于⼯作的成就感和⼯作的有效性，所以导⼊IPD体系使企业产品经营及研发业务⾼效运⾏，产品及研发⼈才⼯作起来得⼼应⼿、⼼情舒畅，新产品在市场上持续成功，这才是最有效的、真正的激励机制。
需求管理方法论
17
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理
18
需求的 “沙漏‖
19
需求的 “沙漏‖
需求开发
标识涉众 收集需求
高度分散、凌乱的 非结构的信息
由集装箱卸货
飞机、汽车、火车、手机……
同义词
目标，规则，规约，约束，要求，特性，标准……
7
需求无处不在
需求
8
什么是“需求管理”？
进行需求管理的目的是在客户 和 ...项目 ...之间建立统一的 认识。 这种与客户一致的认 识是规划和管理 … 项目的基 础。”
卡内基梅隆大学软件工程学院 软件能力成熟度模型（CMM）。 /cmm
目标正确是第一位的——需求的正确捕获和表达 在项目后期才发现需求的缺陷，修复需要非常高的成 本 需求分析 分析得出带来最大价值的需求 同时得出所需的成本 我们的目标： 合理成本下的效益最佳 需求变化时如何控制成本 洞察变更影响 影响分析:迅速定位需要进行修改的模块
25
需求文档的文档反映需求的演变层次
某个银行研发中心的需求演进的层次
业务规格说明书 －> 软件规格说明书 －> 概要设计－>详细设计
某个电信制造厂商的需求演进的层次
市场需求－> 产品包需求 －> 设计需求－>…
某个芯片提供商的需求演进的层次
市场需求－>产品需求－> 系统功能－>…
11
常见问题
1. 需求只存在组织中那些“专家”的脑子里，没有被记录 下来 2. 有时客户的需求会被忽略 3. 而有时候开发的功能却不被客户使用 4. 客户签字确认了需求却一直提出修改要求 5. 需求变更对项目影响很大，难以确定变更的影响范围和 成本 6. 市场部门、开发部门、测试部门跨部门的沟通存在问题 ，例如需求变化时不能迅速通知到测试部门去调整测试 计划和案例。 7. 需求规格说明书的要求都实现了，客户却不满意 8. 需求的研发状态，需求变更的状态难以掌握
项目管理中的需求管理和范围管理
论项目管理中的范围管理摘要：从业的这些年里，经历过软件研发、研发管理、集成项目实施和实施管理。
经历的大大小小的项目，有非常成功的，也有不怎么顺利的甚至失败的。
项目的失败可能是有各种名样的原因导致的，但是否实施了有效的范围管理却是关键因素，本文论述我在多年工作中对项目范围管理的一些认识，希望与大家分享。
关键词：项目管理范围管理需求2008年我从研发部门调入实施部门负责实施项目管理工作，这之后整整一年时间，一直在努力完成一个投入不断增加、迟迟无法完成验收的项目。
推动验收的过程非常艰难，因为项目合同范围签得很虚很空，而项目过程中也没有签署相应的范围说明书及需求说明书，因此跟客户的每一次沟通在项目是否完成建设目标上都难以达成一致，双方对需求范围的理解和界定也无法达成一致。
每一次沟通，都会在原有的遗留问题或需求列表中多出新的内容来，项目组一直在不断地投入，期望最终客户能够满意，但是事实是随着系统的不断调整，客户方和项目组已经没有人能真正说清楚，这样的情况使得验收推动更加困难。
其实相信大家在项目管理的经历中，大多有过类似的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。
客户总是有新的需求要集成商做，就像客户在“漫天要价”，而系统集成公司则总是疲于应付，从而带来项目周期拖长、项目成本超出预算、客户满意度降低、公司信誉受损等一系列后果，甚至还可能导致项目失败。
实际上，造成上述问题的根本原因，就是因为项目没有执行有效的范围管理，即项目中没有就哪些该做，哪些不该做，做到什么程度等与客户达成一致。
信息系统集成项目特点之一是实施的周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把客户的全业务流程稳定下来，并通过系统实现，是需要较长的时间来巩固的，因此在项目实施过程中常常出现需求不稳定、需求变更，项目范围失控的现象，如果在此问题上没有一个“度”的控制，那么项目的范围将失去可控性，随之而来的是项目风险和成本的失败，最终导致项目的严重滞后甚至是失败。
信息系统项目管理师学习要点整理
信息系统项目管理师学习要点整理信息系统项目管理师是现代企业中非常重要的职位之一，承担着管理和协调各类信息系统项目的责任。
为了能够胜任这一职业，项目管理师需要具备一定的知识和技能。
本文将对信息系统项目管理师的学习要点进行整理，以帮助广大项目管理师提高自身能力。
一、项目管理基础知识1. 项目管理概述：介绍项目、项目管理、项目管理师的定义和作用，以及项目管理的重要性。
2. 项目管理生命周期：了解项目管理的各个阶段，包括启动、规划、执行、监控和收尾，以及每个阶段的主要任务和交付物。
3. 基本概念和术语：熟悉项目管理中常用的术语和概念，如项目范围、进度、成本、质量、风险等。
二、项目管理方法论1. 传统项目管理方法：学习传统的项目管理方法，如瀑布模型、迭代模型和螺旋模型，了解它们的特点、适用场景和优缺点。
2. 敏捷项目管理方法：掌握敏捷项目管理方法，如Scrum、XP和Kanban等，了解敏捷开发的原则和实践，以及敏捷团队的组织和协作方式。
3. 混合项目管理方法：了解将传统方法和敏捷方法相结合的混合项目管理方法，灵活应对项目中的不确定性和变化。
三、需求管理1. 需求获取和分析：学习需求获取的技巧和方法，掌握用户访谈、问卷调查、头脑风暴等技术，了解需求分析的基本原则和工具。
2. 需求确认和变更控制：了解需求确认和变更控制的过程，熟悉变更管理的方法和工具，能够有效控制和管理需求变更，避免项目风险。
四、项目计划与控制1. 工作分解结构(WBS)：学习使用WBS将项目工作划分为可管理的任务，制定项目计划和进度安排。
2. 项目成本管理：了解项目成本管理的基本原则，学习成本估算、控制和预测的方法。
3. 项目风险管理：熟悉项目风险管理的过程，包括风险识别、分析、应对和监控，能够有效应对项目风险，保证项目顺利进行。
五、团队管理与沟通1. 团队建设：学习团队建设的技巧和方法，了解团队角色和职责，培养团队凝聚力和合作精神。
2. 有效沟通：掌握有效沟通的技巧，包括听取、表达和反馈，能够与项目干系人进行良好的沟通和协调。
需求管理中的敏捷方法
需求管理中的敏捷方法1.引言1.1 概述概述需求管理是软件开发过程中至关重要的一环，它涉及到对于用户需求的收集、分析、记录和优先级排序等工作。
在传统的软件开发中，需求管理往往是一个比较复杂和繁琐的过程，常常因为需求不明确、变更频繁等问题导致项目延期、需求无法满足等困扰。
为了解决这些问题，敏捷方法在需求管理领域逐渐崭露头角。
敏捷方法是一种以快速响应变化的开发方法论，它强调的是对需求的灵活适应，而不是一成不变的计划。
相比于传统的瀑布模型，敏捷方法强调迭代交付、持续反馈和紧密合作。
这种方法的核心理念是在开发过程中充分理解并积极响应客户需求的变化，以提高软件产品的质量和用户满意度。
在需求管理中，敏捷方法的运用带来了诸多好处。
首先，敏捷方法倡导快速迭代，可以更及时地捕捉并应对需求变化。
这意味着在开发过程中，需求可以根据实际情况进行灵活调整，极大地减少了重新计划和重工的成本。
其次，敏捷方法注重团队合作和交流，通过短周期的迭代开发和持续反馈，可以让开发团队和业务代表更加紧密地合作，实现需求的共识和理解。
最后，敏捷方法强调持续交付，每个迭代都可以交付部分功能，这样可以更早地验证需求和解决问题，减少开发风险和提高项目进度。
然而，敏捷方法在需求管理中也存在一些局限性。
首先，敏捷方法对于需求的可变性有较强的承受能力，但如果需求变化过于频繁或者过于剧烈，可能会对项目的稳定性和开发效率造成影响。
其次，敏捷方法注重迭代开发和持续反馈，需要开发团队和客户之间的紧密合作和高度参与。
如果开发团队和客户之间的沟通不畅，可能会导致需求理解的偏差和迭代效率的下降。
总之，敏捷方法在需求管理中有着明显的优势，能够带来高效的需求开发和更好的用户体验。
然而，项目团队需要根据项目特点和实际情况，合理选择和灵活应用敏捷方法，以达到最佳的需求管理效果。
在本文中，我们将深入探讨敏捷方法在需求管理中的具体应用和相应的优势和局限性。
1.2文章结构文章结构部分的内容可以包括以下几个方面：1.2 文章结构本文将按照以下结构进行论述。
需求管理工作方法论简述
需求管理工作方法论简述前言需求设计也称之为原型设计，是项目管理过程中的一个具体工作环节，承担着将客户的需求通过原型的方式进行验证的一个重要过程。
在这个过程中，通过不断的对设计原型的迭代更新，则可以快速的、低成本的应对客户所提出的各种要求。
后期与客户沟通完毕后，交付开发团队的设计文件则是需求设计的最终结果呈现。
在这个需求设计的过程中我们需要通过业务的了解、工具的使用、工作方法的提炼来达成这个需求设计的工作，以下本人将个人在工作过程中所涉及到的相关工作方法进行梳理，仅共同行参考。
方法简述本文将介绍的需求处理方法实则为本人在工作过程中的总结提炼而出的一套思考思维方式，本人称之为：“知思为”思维方法。
“知思为”思维方法主要是针对我们在做事情的相关思考方式的指引，具体的工作方式因人而异，本人的“知思为”思维方法仅提供思维方向参考。
知知的意思是我们在接到客户的需求的第一时间，不要着急去回绝客户说做不了、不做、做等绝对结果，而是首先去了解、知悉客户提出该需求的背后原因。
所有的需求背后总会有一堆的原因需要我们去了解，有可能是高层的管理需求、有可能是下面的执行层员工的操作需要、或者可能是近期的业务变动。
而这些需要我们第一时间去知悉。
只有我们在获得信息全面的情况下，我们才能做出最合理的决策，没有数据、信息支撑的决策都是盲目的、不可靠的，后期肯定会带来相关风险的，如造成项目延期、客户满意度下降等。
思在我们详细的了解到已经了解到的信息后，我们则需要对我们获得的信息进行进一步的处理，这个过程我称之为思。
通过知的环节我们获得的信息，我们可以很明确的知道很多信息，如：· 这个需求提出的背景是什么，是管理需要、业务调整，还是其他；·后期的使用频率是高还是低；·该需求的功能是主要的，还是次要的；·该需求实现后的功能的使用者是谁；·后期产生的数据的使用者是谁；·……通过以上信息及结合当前的项目执行情况、业务情况等其他相关的信息的整体处理后，我们才会做成正确的决策：接受这个需求还是拒绝这个需求。
需求管理方法论
需求管理方法论目录1 需求管理的理解 (1)2 需求管理内容 (2)2.1 需求采集 (3)2.1.1 需求的特性 (3)2.1.2 需求的来源 (4)2.1.3 各个阶段的需求采集 (5)2.1.4 用户研究的方法 (5)2.1.5 避免需求雷区 (6)2.1.6 深挖用户需求 (7)2.1.7 基于产品周期研究方法 (8)2.1.8 竞品分析 (8)2.2 需求分析 (9)2.2.1 5W原则 (9)2.2.2 避免伪需求 (9)2.2.3 需求分析过程 (10)2.3 需求设计 (13)2.3.1 需求设计 (13)2.3.2 需求评审 (14)2.4 需求实现 (15)2.5 需求验证 (15)3 需求的沟通与变更 (16)3.1 沟通的重要性 (16)3.2 与领导、客户沟通 (16)3.3 与UI沟通 (17)3.4 与研发沟通 (18)3.5 关于需求变更 (19)1需求管理的理解一个方针：做对的事情远比把事情做对更重要。
三个方向：业务需求、用户需求、产品需求最终目标：挖掘需求本质，作出选择在做需求管理之前需要对产品概念要有一定的理解与铺垫：形成产品概念明确产品定位，关注核心用户，聚焦典型场景，抓住刚性需求，点出竞争优势，做到一句话的解决方案。
以人为本将设计思维贯穿在整个需求管理。
2需求管理内容需求管理要贯穿产品设计的始终，在管理过程中需要从初期考虑需求管理的完整周期，即初期确定需求，对需求进行采集与记录、中期评估需求，对需求进行分析与规划并给需求进行优先级排序、以及后期对需求的实现、追踪与验证。
需求管理的每个阶段都应该有相应的任务和产出物。
在第一阶段需求采集阶段我们需要尽可能的全面获取用户的需求，并且要有需求列表的产出；在第二阶段需求分析阶段我们要形成需求分析池，并且要对需求列表中的需求进行详细定义，在这一步就要求产出的文件要求需求列表和需求定义；第三个阶段就是需求的设计，我们在对产品原型进行设计的时候就要做好产品需求文档以及产品迭代计划的管理，这就要求我们要学会对产品进行版本的规范管理。
需求分析与需求管理方法
需求分析与需求管理方法本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。
01 概述本文是梳理需求分析与需求管理方法-产品经理工作职责工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。
知识方法无定论，任何内容先看思路，实战为主。
在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。
因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。
02 需求定义1. 什么是需求？需是是用户在某种场景下的未被满足的期望。
为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。
我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。
我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。
看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。
强调：需求不是独立存在的，是依附于用户+场景一起存在的。
用户需求案例：小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）2. 什么是需求分析？需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。
这里强调两点：找到用户需求解决用户问题案例：还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。
怎样实现统一需求管理
1）、组织支撑 通过建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需 求，并将其传递给产品研发团队 2）、端对端的流程 所谓"端到端流程'是区别于职能式的产品开发模式，建立的产品开发流程是 跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相 关的主要有三大流程体系：市场管理流程、产品开发流程、需求开发流程。 在市场管理流程的第一阶段（了解市场阶段）、在产品开发流程的第一阶段 （概念阶段）都会定义客户需求的收集活动，用需求开发流程来支撑需求收 集活动。 统一需求管理一些思考 1）、所谓"工欲善其事，必先利其器'，一个好的需求管理工具对于需求管 理有很大帮助。但工具不是万能的，关键还是使用工具的人，因此不用整天 寻找完美的工具，而是要问一下自己：对于工具的使用热情我们能够坚持多 久？ 2）、工具本身并不能解决需求管理混乱的困局。核心问题还是需求管理的 方法论、流程制度是否能够持续完善。成功需求管理的秘诀之一就是：持续 积累、持续完善。 3）、我们很多时候忙于开拓新的市场需求而忘记了总结的价值。与客户、 市场、销售、产品、技术、运营等相关人员定期对积累的各种需求（不单纯
格式为 Word 版，下载可任意编辑
怎样实现统一需求管理
在实现公司层面需求统一管理，华为及 IBM 所采用的 IPD 过程很有借鉴意义，的多样化，就要求在公司层面对需求进行统一的管理，以保证 能够：
1）、建立端对端的需求管理流程，实现技术与市场的无缝结合。 2）、深入理解行业，成为行业专家：对于互联网企业而言，必须深刻理解 所在行业的特征及行业用户的痛点才能够推出有竞争的产品，因此必须首先 成为所在行业专家。产品需求本质代表了行业用户的需求，通过产品需求的 持续积累，可以加深对于行业理解，从而成为行业专家，能够推出更符合行 业需求的产品 3）、知识的传承：通过对需求持续统一的管理可以保证知识的传承，避免 产品需求知识积累在几个人脑袋里。 4）、主动收集需求，准确把握市场机会点 5）、产品创新：通过产品及产品间原有需求的优化、借鉴、组合等手段来 达到产品创新的目的。 我们这里的所说的"统一需求管理'比 RUP 中的更为宽泛，包括： 公司层面统一的需求管理组织支撑体系 公司层面统一的需求管理流程制度 公司层面统一的需求管理工具 怎样实现统一需求管理
了解DevOps中的敏捷需求管理和产品规划(二)
DevOps（Development Operations）是一种将软件开发与运营相结合的方法论，通过将开发团队和运维团队紧密合作，实现软件开发和部署的高效性和稳定性。
在DevOps中，敏捷需求管理和产品规划是至关重要的环节，它们能够确保开发团队满足客户需求，并在短时间内交付高质量的软件产品。
一、敏捷需求管理的重要性敏捷需求管理是指在软件开发过程中，结合敏捷开发的原则，对需求进行有效管理和调整的过程。
它强调项目团队与客户间的紧密合作，通过频繁的沟通和反馈，及时修正和优化需求，确保软件产品能够符合客户的期望。
在DevOps中，敏捷需求管理起到了关键作用。
首先，敏捷需求管理能够帮助开发团队充分理解客户的需求，并将其转化为可实施的开发任务。
通过与客户持续地沟通交流，开发团队可以更好地把握项目目标和软件功能，减少需求变更的频率，提高开发效率。
其次，敏捷需求管理也能够帮助运维团队更好地规划和调配资源。
通过对需求的优先级排序和分析，运维团队可以提前做好相应的准备工作，确保项目顺利进行。
同时，敏捷需求管理还能够帮助运维团队更好地把握软件发布的时间和方式，避免因需求调整而导致的延误和不稳定性。
二、产品规划的作用与方法产品规划是指在软件开发过程中，制定产品发展的中长期计划和目标，以实现持续创新和增长。
在DevOps环境下，产品规划和需求管理密切相关，二者相互依赖。
首先，产品规划能够为需求管理提供一个明确的方向。
通过对产品的目标和发展策略进行明确的规划，可以为开发团队提供清晰的工作任务和优先级。
同时，产品规划还可以帮助团队更好地了解市场需求和竞争对手情况，为需求管理提供更合理的指导。
其次，产品规划能够帮助团队更好地评估需求的重要性和优先级。
通过对产品规划进行分析和判定，可以帮助团队更好地把握需求的紧急程度和商业价值。
同时，产品规划还能为团队制定合理的开发计划和时间表提供依据，确保项目能够按时交付。
那么，如何进行产品规划呢？首先，团队需要明确产品的愿景和核心价值，确定产品的长远发展目标。
软件开发过程管理与方法论
软件开发过程管理与方法论软件开发是一个复杂而细致的过程，需要精确的计划、组织、以及方法论的指导。
本文将讨论软件开发过程管理与方法论，旨在帮助软件开发团队高效、快速地完成项目，并提升软件质量。
一、需求管理与分析需求管理是软件开发的首要任务。
在这个阶段，团队需要与客户充分沟通，了解客户的需求和期望。
通过需求管理工具，团队可以记录、分析、并跟踪需求。
在需求管理的过程中，应尽量避免需求变更，以减少对项目时间和成本的影响。
二、项目规划与进度管理项目规划是指在软件开发前制定详细的计划，包括项目的目标、范围、时间和资源安排等。
进度管理则是在项目执行过程中对进度进行监控和控制。
工具如甘特图可以用于可视化项目进度，帮助团队及时发现并解决延期风险。
三、团队协作与沟通在软件开发过程中，团队成员之间的协作与沟通至关重要。
通过使用协作工具如团队协作软件和在线文档编辑器，团队成员可以方便地共享信息、分工合作，并实时沟通。
此外，定期的会议和报告也有助于加强团队协作。
四、软件架构与设计软件架构是指软件系统的整体结构和组成方式。
良好的软件架构能提高软件的可维护性、可扩展性和性能。
在设计阶段，团队应该使用合适的设计模式和方法，确保软件的设计符合需求，并尽量避免后期修改。
五、编码与测试编码是将设计转化为实际可执行代码的过程。
在编码过程中，团队应遵循良好的编码规范，使用版本控制工具进行代码管理，并积极进行代码审查。
测试阶段是为了验证软件是否符合需求和设计要求。
团队应该使用测试工具和方法，包括单元测试、集成测试和验收测试等。
六、质量保证与持续改进质量保证是软件开发过程中必不可少的一环。
团队应建立质量保证体系，包括制定质量标准、实施质量控制、进行质量评估等。
持续改进是指通过不断反思和调整，提升软件开发过程和产品质量。
团队可以使用敏捷开发方法和持续集成工具等来实现持续改进。
总结软件开发过程管理与方法论是确保软件开发项目成功的关键。
团队需要合理利用各种工具和方法，进行需求管理与分析、项目规划与进度管理、团队协作与沟通、软件架构与设计、编码与测试、质量保证与持续改进等环节的管理和控制。
万字干货：手把手教你做需求管理
万字干货：手把手教你做需求管理本文大纲如下：一、为什么要做需求管理？1.1 我们的工作是否像救火1.2 需求管理是什么？1.3 宗旨是什么？1.4 结尾二、需求管理中的干系人和角色2.1 什么是干系人2.2 需求管理中的角色2.3 如何识别干系人和角色三、需求管理的三个模式与公交模型3.1 破解“越快越好“的局面3.2 急诊室的场景3.3 让需求管理运转——公交模型3.4 总结四、急诊模式在需求收集中的应用4.1 再谈需求人和负责人4.2 急诊模式的应用流程4.3 关于时间的把控4.4 结语五、收集需求的模板5.1 应用场景5.2 模板样式5.3 结语六、需求池的核心：优先级和重要性6.1 什么是需求池？6.2 优先级——需求的分类和排序6.3 重要性——优先级的辅助6.4 统一的看优先级和重要性6.5 结语七、排期站会——需求收集的最后一站7.1 为什么要站着开会7.2 排期站会的一般流程7.3 排期站会的道具7.4 结语八、登机模式与需求设计8.1 何为登机模式8.2 产品文档要用共享文档8.3 结语九、Trello的使用技巧——看板模式与需求研发9.1 鸡肋的邮件9.2 看板与需求卡片9.3 Trello的使用技巧9.4 结语十、需求管理的证伪10.1 遭遇危机10.2 优化需求管理流程10.3 优化需求池10.4 普拉姆理论的缺陷一、为什么要做需求管理？1.1 我们的工作是否像救火总是做迫在眉睫的事情，会令人丧失目标。
——《普拉姆原则》我在工作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精力，时间长久就会缺乏动力。
上面讲的是个人的角度，如果一个组织或者团队面对大量的需求，在处理需求的时候，没有节奏和规划，会产生消极的影响。
从小的方面看会影响团队士气，往大的方面看，会影响组织实现既定的目标。
我的工作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为一个桥梁，保障业务运营团队从我这里输出高质量的需求，也要保障具有不同知识背景团队，能过通过需求，高效沟通，快速推进需求上线。
管理需求的技巧
管理需求的技巧
以下是管理需求的一些技巧：
1. 理解需求：在开始管理需求之前，首先要确保对需求的内容和目标有清楚的理解。
与相关方进行沟通和交流，明确各方的期望和目标，确保对需求的内容和期望有一个一致的理解。
2. 分析需求：对需求进行逐一分析，确定需求的详细内容和操作步骤，找出需求中的关键点和要点，并进行归类和整理。
3. 明确优先级：对需求进行优先级排序，确定哪些是紧急和重要的需求，以便在资源有限的情况下进行合理的分配。
4. 制定计划：制定一个详细的需求管理计划，包括需求开发、测试、上线等各个阶段的时间安排和任务分配，以确保需求的顺利实施。
5. 监控进度：及时跟踪需求实施的进度，并对进度进行监控和控制。
确保进度和里程碑的达成，并在需要的时候采取相应的措施进行调整和优化。
6. 沟通和协调：与团队成员、相关部门和利益相关者进行有效的沟通和协调。
及时传递信息和反馈，解决问题和冲突，并确保各方能够共同努力实现需求的目标。
7. 风险管理：对需求实施过程中可能出现的风险进行评估和管理，制定相应的风险应对策略。
确保风险得到及时识别和解决，以减少对项目的影响。
8. 反馈和改进：在需求实施结束后，及时收集和整理各方的反馈和评价，并进行反思和总结。
找出需求管理中存在的问题和不足，并采取相应的改进措施，提升管理的效果和质量。
需求管理方法论要点共129页
36、如果我们国家的法律中只有某种 神灵， 而不是 殚精竭 虑将神 灵揉进 宪法， 总体上 来说， 法律就 会更好 。—— 马克·吐 温 37、纲纪废弃之日，便是暴政兴起之 时。— —威·皮 物特
38、若是没有公众舆论的支持，法律 是丝毫 没有力 量的。 ——菲 力普斯 39、一个判例造出另一个判例，它们 迅速累 聚，进 于困约 ，而败 于奢靡 。——陆 游 52、 生 命 不 等 于是呼 吸，生 命是活 动。——卢 梭
53、 伟 大 的 事 业，需 要决心 ，能力 ，组织 和责任 感。 ——易 卜 生 54、 唯 书 籍 不 朽。——乔 特
55、 为 中 华 之 崛起而 读书。 ——周 恩来
40、人类法律，事物有规律，这是不 容忽视 的。— —爱献 生
谢谢！
需求管理方法论要点
需求管理方法论要点需求管理是指在项目或产品开发过程中，将用户需求转化为可执行的任务和具体实施方案，确保项目的最终结果能够满足用户的期望。
需求管理方法论是指在需求管理过程中使用的一系列方法和原则，旨在确保需求的准确性、一致性和可追踪性。
以下是需求管理方法论的几个要点：1.需求获取：需求获取是需求管理的第一步，它涉及到与用户、关键利益相关者和项目团队的沟通，以了解他们的期望和具体需求。
获取需求的常用方法包括面对面访谈、问卷调查、重要性排序等。
2.需求分析：需求分析是对获取到的需求进行详细分析和分类，以便更好地理解用户需求的本质和核心。
通过需求分析，可以将用户需求转化为具体的功能和特性，并将其组织为逻辑上相互关联的需求模块。
3.需求验证：需求验证是确保需求的准确性和一致性的过程。
通过与用户和利益相关者进行反复沟通和确认，可以确保他们对需求的理解和期望与项目团队的理解一致。
4.需求追踪：需求追踪是跟踪需求的状态和进展的过程，以确保项目团队能够及时掌握需求的变化和进展情况。
通过需求追踪，可以及时发现和解决需求变更或冲突的问题，以确保项目的成功交付。
5.需求文档化：需求文档化是将需求转化为可执行的任务和具体实施方案的过程。
通过将需求详细描述、分类和规范化，可以帮助项目团队更好地理解和实施需求，同时也为需求的评审和验收提供了依据。
6.引入变更控制：需求的变更是在项目开发过程中非常常见的现象，因此引入变更控制是必不可少的。
变更控制包括识别、评估和管理需求变更，以确保变更的合理性和可行性，并最大程度地减少对项目进度和成本的影响。
7.需求优先级管理：在项目开发过程中，由于资源和时间的限制，无法同时实现所有的需求。
因此，需求优先级管理是非常重要的。
通过根据需求的重要性和紧急程度对其进行分类和排序，可以确保项目团队在实施过程中的重点和方向。
8.需求评审和验收：需求评审和验收是验证和确认需求的过程，以确保最终交付的产品或项目能够满足用户的需求和期望。
产品经理在需求管理中如何处理“重要”需求和“紧急”需求!
产品经理在需求管理中如何处理“重要”需求和“紧急”需求！产品经理学习资料产品经理在需求管理中如何处理“重要”需求和“紧急”需求！四象限管理法则，常用于时间管理的规划方法，不管是自己在日常生活中的个人管理，还是在工作中的任务管理，很多人都会结合自己的实际情况运用。
各行各业的专业人士都根据自己需要，整理出适合自己的模型，同时也通过这个管理方法受益良多，让自己的生活和工作井井有条和高效。
一、时间管理通过使用四象限管理方法，个人可以用来规划日常生活计划或工作任务优先级。
具体的优先级策略，引用百度百科内容如下：马上做：如果你总是有紧急又重要的事情要做，说明你在时间管理上存在问题，设法减少它。
计划做：尽可能地把时间花在重要但不紧急（第二象限）的事情上，这样才能减少第一象限的工作量。
授权做：对于紧急但不重要的事情的处理原则是授权，让别人去做。
减少做：不重要也不紧急的事情尽量少做。
单看方法论说明还是比较容易理解的，整个管理方法的核心就是区分重要和紧急的事项。
道理都懂，但在具体执行时如何区分哪些任务是重要的，哪些是紧急的，哪些又是重要且紧急的…还需要结合自己的具体情况做出规划和选择。
下面以疫情期间去药店采购防护用品为例，对重要、紧急进行理解和区分，同时如果分别对应到四个象限的策略里，就可以采取相应行动来规划任务。
受疫情影响，很多人都积极采购防护用品，满足当下疫情中人们日常生活所需，然而自己所在小区附近的药店里，口罩、一次性手套等防护用品快要售完：情境1如此时自己家里的口罩也仅剩一两个，如果不出门去买之后很长一段时间可能就供不应求，从而给自己日常防护带来不便，因此需要立即采购，那么当下对于自己来讲，“出门去药店购买口罩”等防护用品就是重要且紧急的事情；因为购买口罩是自己的核心需求，需要优先解决，而且当前时间段购买口罩有时间限制，去晚了很可能就卖完了，因此会比较着急；此类事件可归类到第一象限“重要且紧急”事件，这类事情因同时具备重要性和紧急程度，因此通常都需要马上去做。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
子目标
最终目标
子目标
子目标
子目标
实现最终目标 的步骤
子目标
子目标
序
操作顺
48
应用情况举例（一件行李）
交行李 乘客入座 称重
登机
受控 登记 贴标签
测量
装机 就绪 行李拥有人 在目的地 提行李
安全检查 运至登机口
装机
装入集装箱 装机
飞行
飞行 再次装机
卸机
装机
卸机
由飞机卸货
需求管理方法论
1
目的
更深刻的理解需求以及它的价值 更深入的理解需求的层次和类型 为良好的需求管理建立坚实的方法论基础 为更有效的管理需求给出实践和建议
2
大纲
需求管理介绍 需求管理的重要概念 需求跟踪 深入管理需求 编写好的需求 需求变更管理
3
需求管理介绍
43
影响系统功能的需求信息类型
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
44
非功能性需求的信息类型
“真实的现实系统中，在决定系统的成功或者失败的因素 中，满足非功能性需求往往比满足功能性需求更为重要。 ” 性能 软件质量属性
用户的目标，用户希望完成的任务 影响系统的需求信息类型：
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
用户需求 - 涉众需求的通俗解释
30
系统需求
产品中实现的功能性需求
用户以此完成工作 进而满足业务需求
描述包含多组件的系统的顶级需求
测试方
操作方
信息化部
信息化部
39
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类
引出系统功能的需求信息 非功能性需求的信息类型
我们必须善于发现需求——捕获需求的技巧
40
用户提供给我们的足够的信息吗？
没有？不知道？ 我们知道要收集哪些信息吗？
36
每个涉众都有各自的需求集
业务
最终用户
客户
销售员
安装和维护
管理者，经理 培训和支持
技术支持
运输和装卸
考虑所有可能的用户. 遗漏了他们的任何需求都会导致系统问题的出现 或系统失败
37
标识涉众
Stakeholder: 涉众 涉众是对于系统有利益关系或关注的个人，团队或组织。 [IEEE 1471]
不同的产品/系统，不同的公司，对自己的需求体系有自 己的定义
26
典型的需求层次
业务需求
定义一个机构达到的目标和目的。
用户需求(涉众需求)
说明用户需要系统提供什么能力帮助其完成任务。
系统需求
说明系统必需完成什么功能才能提供用户所需的。
27
业务需求
我们为什么要进行这个项目？ 组织的业务目标 提高公司的运营效率——内部信息管理信息系统 提高产品的市场竞争力——对商业软件 通常来自 投资方 管理层 市场部 产品部 常见文档记录方式 工作说明书 前景和范围文档 市场需求文档 项目计划书（可行性报告）
对产品的功能作出了补充，从不同方面描述了产品的特性 如可用性，可移植性，健壮性等等。
45
影响系统功能的需求信息类型
业务目标 —— 业务需求 使用场景 —— 用例 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
46
场景和用例
用于以下目的的技术：
正确的需求：正确的功能的前提 一致性
与需求保持一致并不仅仅在项目的后期用测试来验证，更 强调的是在项目的每一个阶段都紧紧围绕需求这个主线来 开展工作。 需求跟踪正是保证需求演化的整个过程都是与需求保持一 致，以此保证项目和产品的最终质量
Phil Crosby
14
需求管理的作用 II —— 成本控制
由集装箱卸货
有哪些涉众角色？ 投资方（系统的投资方） 主管方（批准/管理系统的） 最终用户（用户/系统受益方） 操作方（操作/维护系统的） 监管方（认证系统的） 测试方（负责系统验收） 其它（受系统影响的）
38
概念：涉众角色
涉众角色举例 XXX 系统：
投资方 主管方 用户代表 最终用户 监管方 计划部 信息化部 市场部 营业员 审计部
非功能需求
必须被系统满足的潜在的条件. “约束补充了系统的质量但不会作为一个功能存在.” 对于系统而 言，约束不增加任何特殊的工作, 但它起到保证系统满足所需的功 能,保证系统更可靠,更易使用. “音乐点歌系统能够储存15,000,000个在线账号.” 非功能需求能够作为一个重要规则或条件组织和实现.
25
需求文档的文档反映需求的演变层次
某个银行研发中心的需求演进的层次
业务规格说明书 －> 软件规格说明书 －> 概要设计－>详细设计
某个电信制造厂商的需求演进的层次
市场需求－> 产品包需求 －> 设计需求－>…
某个芯片提供商的需求演进的层次
市场需求－>产品需求－> 系统功能－>…
12
电信业和银行业15个项目统计
Hofmann and Lehner 2001
最成功的项目在需求工程上投入了28%的资源： 需求获取，需求建模，需求确认和验证等 平均每个项目在需求活动上投入了15.7%的工作 量和占了 38.6%的时间
13
需求管理的作用 I —— 提高质量
关于质量，Crosby的定义很简单——与需求一致。
17
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理
18
需求的 “沙漏”
19
需求的 “沙漏”
需求开发
标识涉众 收集需求
高度分散、凌乱的 非结构的信息
目标正确是第一位的——需求的正确捕获和表达 在项目后期才发现需求的缺陷，修复需要非常高的成 本 需求分析 分析得出带来最大价值的需求 同时得出所需的成本 我们的目标： 合理成本下的效益最佳 需求变化时如何控制成本 洞察变更影响 影响分析:迅速定位需要进行修改的模块
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理
34
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类 我们必须善于发现需求——捕获需求的技巧
35
捕获需求
活动:
标识涉众 与涉众交流 收集需求 给需求的重要程度排序 选择需求 记录需求
飞机、汽车、火车、手机……
同义词
目标，规则，规约，约求无处不在
需求
8
什么是“需求管理”？
进行需求管理的目的是在客户 和 ...项目 ...之间建立统一的 认识。 这种与客户一致的认 识是规划和管理 … 项目的基 础。”
卡内基梅隆大学软件工程学院 软件能力成熟度模型（CMM）。 /cmm
成功率(%)
30 20 10
Project Size ($) $ 项目规模（ Standish Group, ‘99 () ）
6
0
什么是“需求”？
任何影响产品或系统设计制造方式的信息
功能 性能 安全性 可用性 ……
复杂的产品/项目有数以千计的需求
15
第一时间采取措施能降低成本和缩短时间
典型
缩短了 开发时间
工作量
较好
时间
16
需求管理的作用 III —— 支持项目进度的 管理
真实项目进度的反映
例如，多少需求已经被实现，它们的状态如何？ 又如哪些需求已经有对应的测试案例，哪些需求已经测试通过？
需求驱动开发
需求活动在项目正式立项之前就展开 需求分解后的功能点/模块成为项目管理中的需要实现的任务
什么是需求？什么是需求管理？ 常见问题 需求管理的重要性和益处
4
项目成功因素
28%的项目按时并 在预算内完成 49%的项目超出原 先估算
时间平均延迟了 63% 成本超出了45%
可靠的 规范的 估算 方法 标准的 组织结构 最小化范围 清晰的商业目标
6%
5% 5%
12% 14%
28
业务需求
若对项目预期的范围和目标有不同的理解，就无法对下列 获得一致意见
对哪些用户应该被访谈获取需求 哪些功能应该被纳入
现象
某些特性先被添加，又被删除，又被加入
分布式开发团队尤为重要 决策基础
目标版本 应用的广度和深度 需求变更
29
用户需求（涉众需求）
31
如果世界就这么简单……
业务需求
用户需求
系统需求
32
项目中各种信息交织在一起
用户
市场 设计 系统需求 测试 实现 部署 维护 培训 支持
33
业务
客户
法律/ 规章
质量/ 标准
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
管理层的 支持
15%
14%
17%
5% 7%
用户积极 参与程度
23%的项目在完成 之前被取消
有经验的 项目经理 熟练的员工 敏捷的需求过程