持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第21天，点击查看活动详情
工作分解结构，这一部分知识点比较细碎。
项目验收多做了客户满意的功能合理吗？
项目的全部工作都必须包含在工作分解结构当中，反之，不包含在工作分解结构当中的任何工作都不是项目的组成部分都不能够做，
如果在进行最终的一个验收的时候发现了比原计划多做了两项功能，成本没有超支，进度没有落后，而且，这个客户表示十分的满意。
从项目范围管理的角度来说，这个项目怎么样？成功还是失败？
注意，从项目范围管理的角度来讲，这个项目它是失败的。
为什么是失败了呢？因为我们项目的范围管理，它是强调只做它应该做的事情，只做分内的事情。不是他应该做的事情呢，那是一件，都不能做。
这就是我们工作分解结构100%规则的一个要求，其工作分解结构必须且只能包括100%的工作。
从理论的角度来说，工作分解结构必须且只能包括100%的工作。在实际工作中，如果多出的部分不追加，首先就能直观上节省成本。可能是人工、设备或者是相关的其他内容。
举个例子，在项目交付验收的时候，因为产品部门觉得某一图标可以比客户提供的初级设计稿做的更优。在这个阶段进行调整的情况下。
- 产品部门需要和设计部门沟通
- 设计部门需要进行设计完成
- 研发部门需要对新的成品进行替换
- 测试部门需要对测试完成以后的新图重新测试
- 运维部门需要监控新更新的内容是否符合公司、甚至是国家要求
当这一个个环节走下来，如果5个部门5个人，如果每个人使用2个小时来完成这个任务的情况下，那10个小时的人员工资就需要算入公司的预算中。
工作分解结构的编制的干系人
工作分解结构的编制呢，需要所有项目干系人的参与。需要项目团队成员的参与。
需要所有项目干性的参与是对的。
需要主要干系人的参与，当然也是对的，
因为我们所有干系人，他本身就会包含主要干系人。
如果改一下只需要，把需要前面加一个字加一个只需要。只需要主要干系人的参与，那那这个描述就是错误的。
工作分解结构的方向
工作分解结构的方向是自上而下的分解。这一点结合我们日常工作的实际情况来理解，是比较容易记忆的。
比如产品部门对接需求的过程中，首先客户会提供我要做一个西瓜，然后要对西瓜的部分属性进行拆解，比如颜色、大小、季节等等。从整体到部分，从上层到下层的拆解。
