声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中SAP相关字或图片，相应著作权归SAP所有。
上次课程已经说过，今天的内容是非常重要的，可以说是整个范围管理的核心内容。因此，也请各位打醒十二分精神，一起来学习这两个非常重要的过程吧。
项目范围是一个项目的基础和核心，而定义范围的的关键就是WBS，WBS是项目管理的核心所在！ WBS是实施项目所必须进行的全部活动的清单，也是进度安排、人员调配、预算计划的基础。
先说结论， WBS是项目范围管理中的核心内容，活动是项目时间管理的核心元素。属于两个不同的范畴内的要素！
进入倒数第二个章节，范围管理，这其实是项目管理中第一个子管理过程，之后的时间、成本等管理均依赖与它。 项目经理是项目中最重要的人，项目经理的授权在项目章程中规定，并以范围界定内容。 WBS
2、项目的范围基准是经过批准的项目范围说明书、WBS和WBS字典。判断项目是否完成要以范围基准来衡量。而新产品范围是否完成，则根据新产品是否满足了新产品描述来判断。
声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中SAP相关字或图片，相应著作权归SAP所有
WBS是项目团队为实现项目目标并创建所需的可交付成果所要进行的全部工作范围的层级分解
工作分解结构（Work Breakdown Structure，简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
WBS(工作分解结构)是项目规划的核心文件。它将工作范围分解为可管理的元素。在生成WBS之前，概念至关重要，在生成WBS时，您需要包括主要的分包商、材料和项目管理任务。本文提供了创建工作分解结构的分步指南。
（1）规划范围管理：对如何定义、确认和控制项目范围的过程进行描述。 （2）收集需求：为实现项目目标，明确并记录项目干系人的相关需求的过程。 （3）定义范围：详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。 （4）创建工作分解结构（WBS）：把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。 （5）确认范围：正式验收已完成的可交付成果。 （6）范围控制：监督项目和产品的范围状态、管理范围基准变更。
项目定义：唯一描述一个项目的编码，在项目定义里对项目相关的组织结构数据进行定义，如公司代码、利润中心、工厂等。
第五章 项目范围管理 ---- 基本介绍 项目管理的49个子过程，项目范围管理占6个 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内 项目范围管理过程包括 5.1 规划范围管理——为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程 5.2 收集需求——为实现项目目标而确定、记录并管理相关方的需要和需求的过程 5.3 定义范围——制定项目和产品详细描述的过程 5.4 创建WBS——将项
声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中所示截图来源SAP软件，相应著作权归SAP所有。
第5章 项目范围管理 49个过程占了6个过程 ---- 项目范围管理 目标 要做什么？ 只做什么？ 范围管理包括 产品范围：产品、服务或成果所具有的特性和功能，看得见摸得着的可交付成果 项目范围：为交
项目管理七大常用工具工具：SWOT、PDCA、6W2H、SMART、WBS、时间管理、二八原则 。
规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
收集需求是一个长期的、渐进明细的过程。但基本的需求，应在定义项目详细范围之前完成。
项目范围对项目的影响是决定性的，它确定了软件项目工作内容的多少。有效的范围管理可以保证项目只做必须做的事情，避免范围蔓延和做无用功，同时也避免不清晰的需求所导致的严重的系统缺陷。
项目系统->结构->实施结构-> 工作分解结构(WBS)->创建WBS元素项目类型
（2）预测型生命周期：定义阶段，计划，需求分析；开发阶段，设计，编码，测试；维护阶段，运行维护；
声明：本文仅代表原作者观点，文|Elsa。仅用于SAP软件的应用与学习，不代表SAP公司。注：文中SAP相关字或图片，相应著作权归SAP所有。
1.项目章程，2.项目管理计划，3.项目文件，4.商业文件，5.协议，6.事业环境因素，7.组织过程资产
声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中SAP相关字或图片，相应著作权归SAP所有。文| Elsa
项目范围管理一般上午考察3分，需求是龙头，是做项目管理的基础。没有需求就不能确定项目的范围，没有范围，项目就无从谈起，此部分在下午案例分析的几率也是比较大的。 上午历年考试的重点在范围定义的概念，产品范围和项目范围以及各自的衡量标准。详细范围说明书的内容，WBS的表现形式，分解的方法，原则，工作包的定义作用，范围确认，范围基准，范围蔓延，范围变更等知识点上。输入输出和工具与技术直接考察的并不算多。 本章在下午案例分析的命题思路主要表现为：给出某项目在范围管理方面的案例场景描述，要求指出该案例场景中存在哪些问题并说明相关原因，要求给出解决这些问题的补救措施。
一、测试方法 以测试过程中程序执行状态为依据可分为静态测试（ST）和动态测试（DT） 以具体实现算法细节和系统内部结构的相关情况为根据可分为黑盒测试、白盒测试和灰盒测试 从程序执行的方式来分类，人工测试和自动化测试
范围管理计划是项目管理计划的组成部分，描述如何定义、制定、监督、控制和确定范围。范围管理计划要对将用于下列工作的管理过程做出规定：
项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件，取决于具体项目的需求。
Project Breakdown Structure，项目对象分解结构，以是项目交付结果本身为对象进行的层级结构分解。
WBS对制作SOW极其重要，WBS不像SOW那样包含实施基础条件。在项目目标和工作范围都还没有界定情况下，此时去制定一份详细项目计划和进度安排显得毫无意义
进入比较重要的时间管理一章，重点是对WBS，工作单元，活动，资源，时间这一条线索的理解，熬夜加班到4点，继续俺的学习了，正好等等联调数据的状态，加油，熊二。 网络图，PDM，CPM等技术，关键路径
固定资产折旧范围：所有资产记帐到主导分类帐0L均使用正常折旧范围，对于半导体专业、印制板专业腐蚀性严重的设备，由于特殊性需要减少折旧年限的，定义不同的折旧范围；
1）MECE法则。MECE是mutually exclusive collectively exhaustive的首字母简写，中文意思是“相互独立，完全穷尽”，也就是既不重复，也无遗漏
诸如Copilot、Midjourney、notion等产品通过AI的加持，已经让用户能够充分地在应用层面感受到了便利性。
产品范围决定项目范围，项目范围有时也包括产品范围，需要根据上下文来理解。
成果名称 内含 来自 用于 变更请求 纠正、预防、缺陷补救、更新；其状态在实施整体变更控制输出中被改变 各知识领域规划、执行、监控过程组指导与管理项目执行、监控项目工作、核实范围、控制范围、控制进度、控制成本、管理质量、管理团队、管理相关方参与、控制项目工作、监控
1.工作分解结构是项目团队与相关方之间沟通的有效工具之一 2.控制账户是工作分解结构某个层次上的要素，以便与工作包一一对应 3.项目范围说明书包括产品范围、产品验收标准、项目可交付成果、项目除外责任，以及项目制约因素及假设条件的描述 4.范围变更会修改已确定的范围 5.工作分解结构的每一项都被分配了唯一的标识符：账户编码 6.规划范围管理过程是描述将如何定义、确认和控制项目范围 7.产品分析又叫产品分解，属于定义范围的工具 8.创建工作分解结构过程的结果是团队意见统一 9.WBS的基础是产品需求和项目需求 10.质量控制和确认范围往往同时进行 11.确认范围重点关注可交付成果的验收 12.控制账户>规划包>工作包 13.大多数同意是获得群里中超过50%人员的支持，就能做出决策的技术 14.审查项目章程之后，项目经理接着进行收集需求，后续再定义范围，输出项目范围说明书，范围规划后进行进度的规划 15.联合应用开发（JAD）适用于软件行业，用于改进软件开发过程 16.工作绩效信息属于控制范围过程的输出 17.原型法体现了渐进明细的理念 18.在工作分解结构自上而下的细分中，将导致估算准确度增加 19.用来衡量产品范围完成情况的文件是产品需求文件 20.工作分解结构中的工作是指作为活动结果的工作产品或可交付成果 21.质量功能展开QFD从收集客户需求（又称客户声音）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标 22.可交付成果必须具备的特性、功能和特征属于解决方案需求 23.引导与主题研讨会结合使用，可用于快速定义跨职能需求并协调相关方的需求差异 24.项目章程的可交付成果颗粒度太大 25.项目管理计划包括：范围基准、进度基准、成本基准 26.范围基准包括：范围说明书、WBS、WBS词典 27.WBS的用途：组织和定义项目的所有范围 28.管理质量-->过程QA 29.控制质量-->结果QC 30.范围蔓延是未经批准的 31.当相关方不愿或不能说明他们的需求时，用观察法收集需求
范围其实说白了就是我们要做的东西都包括哪些内容，这些内容的边界在哪里，范围其实从另一个角度来说的话，也可以看成是一个产品的约束。为什么要有一个约束呢？你见过一个即是电商，又是社交，还能兼顾全网搜索、短视频、智能推荐，甚至买火车票、在线电影、游戏棋牌都能玩。这样一个应用你觉得怎么样？相信我，谁做谁 Over 。
CJ9ECP简易成本计划 简易成本计划工具可以在WBS层次上基于数量、特性来计划项目的成本。你可以用它来创建数量结构以计算成本。系统根据你的输入和系统中定义的价格和费率来评估，然后将成本分配到相对应的
Work Package Definition The work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed.
软件项目管理提供一种结构化和系统化的方法，以确保软件项目按时、按质量、按预算完成，并最大限度地满足客户的需求和期望。它提供了一套综合的工具和技术，帮助项目团队有效地规划、组织、监控和控制项目，以实现项目的成功交付。
游戏开发中，绝大多数都是使用的瀑布型，这也是我们这个系列主要介绍的方式。 “范（围）进（度）成（本）”是一个项目的重点，而需求则直是项目管理的重中之重，它是进度、成本的大前提。项目经理需要负责确保这些需求在项目管理计划中都有所安排，并且在预算内按时完成，同时尽可能的创造利润和价值。 在游戏开发领域也是一样，你本来做着《王者荣耀》，突然吃鸡火了，项目做一半去做吃鸡模式，自走棋火了，又去做自走棋，捡树枝火了，又去做捡树枝，范围的变更会导致进度和成本遥遥无期。所以防止范围失控是项目经理首要的责任目标。 所以最后，总结一下：项目范围管理包括 做且只做 所需的全部工作。 2 收集需求 收集需求的原始定义：为实现目标而确定、记录并管理相关方的需要和需求的过程。它为定义产品范围和项目范围奠定基础。 不过在细说收集需求之前，还要先提一个过程，叫做规划范围管理计划。这个是什么意思呢？还记得我们上一个章节里有一个过程叫做规划项目管理，其中的输入就来自于各个子的管理计划的输出。 范围管理计划里面没有定义实际的范围，它是一个流程性的文件，主要描述项目是如何定义、制定、监督、控制和确认项目范围的。 举个例子，在游戏开发中，需求一般是由策划负责的。主策划出具了一份需求规范，里面有写到，需求可以由项目里的任何人提出，然后由主策划评定是否有价值，通过后纳入需求池，然后指定具体的策划出具详细的策划案，最后对已经完成策划案的功能进行版本排期开发。 这就是一份最简单的范围管理计划了。但实际项目里，需求增加会更复杂一些，它可能还需要设计需求的优先级评定，指标测量等等，但是无论如何，范围管理计划里面是一定没有实际范围的，它只是流程性或者管理性的文件。 再反过来说需求，需求的概念是根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。他包括，发起人、客户和其他相关方的 已量化 且 书面记录 的需要和期望。 你是开发，如果有策划拿着手机过来跟你说，你把这个士兵的颜色调成跟它们这个一样的红色。你可以呸他脸上。策划和程序沟通交流，最基本的礼仪就是文档。士兵ID是多少，颜色的色值是多少，有没有和主策划、PM报备过，有没有评估过实现难度，主程又知不知道。当然如果你们关系比较好，他说下午请你喝个奶茶，你调个效果给他看下，倒是可以考虑下。 需求的收集有很多种方式，这里罗列一下： 这里简单说一个我觉得有意思的地方，工作指导和工作跟随。 女朋友要换新电脑，叫你给方案。你说，CPU应该选I9，显卡应该选2080，内存应该要32GX4（确定是给女朋友配还是给自己？），这叫做指导，能够讲清楚，说明白的。但是淘宝下单，全部到了之后怎么组装？你远程视频教了两个小时，结果女朋友把硅胶涂到CPU的针脚面上了。你吓得赶紧过来，10分钟把主机组装好，为了让女朋友看的清楚，又拆掉装了两遍。然后女朋友在你手把手的方式下，自己把电脑装好了（虽然不知道为什么要插那，但是插上好像就对了）。这种方式叫做工作跟随。有些事情你要描述很困难，但是要实操一下就好。 收集需求的最终输出就是需求文件，很多流程管理里叫做用户故事Story。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。 大概有如下分类： 比如：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
