项目管理之范围

收集需求：需求分析，需求的筛选，形成范围基准。

需求调研：一般来说大部分项目是预测性(瀑布型)，这种类型项目一般是闭口合同，闭口合同就是有一个合同总价，范围也是明确的。 所以一定要事先把需求梳理一遍，然后把需求写出来，最好是制定原型，然后让客户确认。这样做的好处是能够尽量的把控住范围，否则客户天马行空，说的乱七八糟。第二个是最好有统一的接口，比如说给客户作项目，他内部有很多的部门，在沟通上，甲方派出甲方的项目经理，乙方排除乙方的项目经理，而不是甲方可以指挥乙方内部的人员。第三个一定要深挖需求，客户可能说的是需要一匹快马，但是他需要快马的目的是快速到达某个地方。

调研需求之客户：选择用户代表，用户代表一般要涵盖三类人，一，对项目有决定选的领导，二，熟悉业务的专家，三，使用系统的人。要和客户有平等合作的心态，调研需求是为了给客户解决问题，不是全盘接受，也不是指导客户工作。调研人员要熟悉用户的行业，学习用户的术语。在调研过程中不能说互联网术语，因为用户不一定理解。在调研前期一定要有一个书面的调研大纲，以方便让客户协调参与人员。

需求分析：判断伪需求和真实需求。多问为什么，通过问为什么来发现客户的真实想法。

需求的优先级排序：通过莫斯科法则MoSCoW(莫斯科)，must 必须要做的，Should 应该要做的，could 不太需要的，wouldnot 不要做的。通过莫斯科法来进行需求排序。那么在这里或许有人问为啥要给需求排序，可能有很多，资源有限，资金有限，需求的相关性，还有一种更大的可能就是“完成优先于完美”。在一个项目中，进度是一定的，资金也是一定的，那么在极端情况下，是需要优先完成最重要的内容，然后再添加那些不重要的功能，所以一定要考虑优先级的问题。

形成需求范围基准：在和各个业务部门调研需求后，可以结合一些可视化工具比如需求原型让客户了解，然后一定要请客户在需求确认书上签字确认。这样可以防止后续范围蔓延，同时要规定变更的流程。必要时候召开专家需求评审会，然后得出专家意见，让专家在专家意见书上签字，这样可以分摊责任。

控制范围：如果客户要进行变更，那么最直接的就是走变更，首先要查看合同中的是否有增项，以及增项的范围，但是在实际项目中，客户很多时候不允许走变更那么应该怎么办？其实可以推二期，一般情况作项目，项目是很忙的，客户如果临时提出变更，一般情况是没有对这一部分进行计划的，所以可以推到下一版做。另外如果客户不想走变更流程，还可以做交换，比如说客户要加一个a功能，那么就要和客户商谈，是否可以把目前范围里的b功能替换成a功能，如果客户不想替换这个功能，那么怎么办呢？其实可以谈弱化，把客户要加的功能弱化一些，这样可以减少一些工作量和成本。如果客户不想弱化功能，那么怎么办？最后只好找领导，或者找销售，运用上午的手段或者让领导来协调一下。