关于项目范围管理
在范围管理中，范围的确定是重中之重，项目范围管理也不能按书上的照搬过来，都采用的话那可能真是全职的项目经理，但实际中的项目并不会有那么舒服的情况，但对于项目范围的管理我们也要养成思考以下问题的习惯，实际项目范围管理的过程我认为有以下事情：
1. 要干多少事情，项目有多少需求；
有多少需求就是有多少活，收集需求的时候就需要和相关方好好的谈了，把各个方面利用各种手段尽可能全的将需求给收集并且描述出来。业务方面的跟业务部门的人谈，环境方面的和系统组的人谈，开发方面的和开发人员谈，确认好谁提出、谁负责、谁跟踪、谁确认、谁验收。根据描述全的需求来确定项目要干多少事情，把需求给具体化，全部记录下来。
2. 哪些事情该干，确认项目范围内的需求；
哪些事情该干，多数时候客户的需求都是在天上的，也不是所有的需求对于项目成员都是能实现的，只有团队能够让需求实施落地的事情才是项目该做的事情。作为项目经理一定要清楚自己的团队可以干好什么样的事情，干什么样的事情效率高，质量好，干什么样的事情的事情会很爆炸。对记录下来的需求进行分析，分析该如何实现这些需求，在作为专家谈需求的时候，就需要对客户进行引导，既达到客户所需要的效果，又方便团队实施，比如客户提出一个难以实现的需求，我们可以根据上层需求提供容易实现的建议方案；再比如由于资源协调等原因不好实现的需求，是不是可以延后或者取消。
3. 哪些事情不该干，确认项目范围除外的需求；
哪些事情不该干，就需要我们确定好除外责任，就是这个东西我们说好就是不做的。虽然我们多数时候是确认好我们要做的就好了，但是不该干的事情，不包括在项目范围内的事情提前说明清楚的话会省很多扯皮的事情，而且对于分析该干的事情里面，也一定要同时分析这个内容里不干的事情才行，同时确认好你的理解和客户的理解一定是一致的，最好落在纸上。曾经碰上个事情：客户要求做一个网站，网站对于我们的理解就是网页端嘛，非常简单，谈需求的时候就没有想那么多，和开发说明的时候也没想那么多，在验收的时候，客户结果是用手机打开的！没错，用手机打开的，发现页面全是乱的。我们说只做了能电脑看的，客户说现在谁还不用手机看！就要重新把项目给改一遍了。这种隐含的意思一定要注意了
4. 哪些事情可以以后干，确认项目后续可以有的需求；
哪些事情可以以后干，在和客户谈需求的时候，需要深入的理解客户所需。作为领域专家的话也需要有服务意识，提供可以拿出的最好的，最优质的服务给客户，帮助他们分析和提出其他需求，确认哪些需求可以做为这次项目之后的延伸。这些事情可以是由于工期紧的原因，单后续必须要做的事情，可以是过程中发现的可优化内容，可以是其他与项目相关的事情。为项目考虑，为客户考虑，都是为了把事情做到尽善尽美，提高相关方整体的满意程度。
5. 该干的事情怎么干，分解需求、分配人力资源；
该干的事情怎么干，客户的需求都是大体上的，概括性的，而对于项目来说需求必须转化为事情，事情怎么干同样需要与客户洽谈说明并且由客户确认。因为如果需求是服务方面的，客户当然可能对于你怎么提供对应的服务会有所要求。对于和客户确认好的事情，需要详细明确的记录在纸面上（没有歧义），这些事情就是可以干的事情了，将事情分模块，分解开来，确认可干的人力资源，选择最合适的人力资源。
6. 东西好了最后拍板的人拍板了没有，确认范围
东西好了最后拍板的人拍板了没有。这就是有没有让需求落地，达到客户的预期目标的问题。包括了，阶段性的单个需求是否被满足，项目最终的整体验收是否符合要求。项目是渐进明细的，需求是分解的，分解完成的单个需求是否都符合要求将决定项目整体是否符合客户需求。在完成单个需求的时候及时与客户沟通确认，确认是否符合要求非常重要，可以避免后续一次性验收的大改。虽然客户不一定会全程跟项目，但也必须要在重要阶段参与项目，若不参与其中的风险跟客户说明清楚，相信客户也会有所考量，毕竟一般项目投入的资源都不少，达不到想要的效果会很亏。
7. 老的事情有变化怎么办，出现了新的事情怎么办，控制项目范围。
老的事情有变化怎么办，出现了新的事情怎么办。这个问题一定要在项目初期与客户沟通清楚，确认好应有的方案，达成共识。项目需求、事情有变化很正常，有些项目时间短，发生变化的可能性不大，但有些项目时间长发生变化的概率就大了，取消的也有可能。大家都认可的变化，走变更流程，该加钱加人的加钱加人，不该被接收的变化，就需要好好的拒绝一下。新的事情可以往后调整排期，可以加人、加班赶工，也可以只登记一下，不做处理。
对于项目范围和需求的事情，最重要的就是和客户达成一致的认可，思想上的统一。项目的范围控制在项目的整个生命周期都该进行全方位的把控，也就是项目经理必须要对哪些事情该干，哪些事情不该干有一个非常清晰明确的把控。
项目范围把控的好不好，将决定你下面的人将要干多少活，会活成啥样。作为一个项目经理，项目上干多少活都是谈出来的，如果你是开发可能感觉项目经理所做的事情不多，但是实际上项目经理是以另一种形式来影响项目，也将直接决定开发要干多少的活。若项目经理没有控制好项目范围，累死开发也干不完需求，求你的项目经理当个好人吧，不要乱答应需求，不然把大家都埋进去坑也填不完。
实际问题
虽然都是说的轻巧，但是在实际当中项目范围有时是实施当中最难把握控制的一个方面。
常见需求变更的问题
- 需求渐进明细下来比预想的多了很多
- 需求文档高度概括
- 新需求没有走变更流程
- 需求理解不一致
- 项目合同条款高度概括，范围不明确
比如
在项目的实施过程当中，甲方项目经理直接提出变更要求，有时甚至是甲方的分管副总直接向我们提出变更要求，而且有时这些要求并不属于项目的工作范围。这里常见的几种情况：
1.我们有项目范围说明书，或者说详细的需求文档，需求文档上确实没有这些内容
2.需求文档虽然没有明确写这些内容，但是业务需求一般写的比较概括，就可能可以把变更给概括了
3.需求文档上可能没有写，但业务理解和我方理解不一致，甲方认为应该涵盖了需要变更的内容
4.需求文档上没写，但是合同上有相关概括性的内容，甲方认为也涵盖了该部分内容
对于变更也不能简单的接受或者拒绝，这个时候就比较考验项目经理了。虽然怎么做没有标准答案，但看完了应该会有自己的一个做法了，欢迎一起来讨论。
