一个产品的成功与否，和范围管理有直接的关系

　　项目范围管理是一项全局性而又基础的工作，产品经理在做项目管理时要通过需求范围来开展。
　　在做项目管理整体规划时，需要引入我们的项目范围，可以说项目范围是构成项目铁三角很重要的一个因素。还记得我曾提及的项目管理的质量，范围，时间，成本构成的铁三角吗？可以说项目范围管理的好坏直接影响我们项目的成败。
　　项目管理铁三角
　　为什么要做范围管理
　　场景1
　　老板通知产品经理小Y马上到办公室，因为昨天老板参加一个互联网的聚会看到同行产品有个全新的功能，于是需要小Y在本次迭代周期内将这个新功能列入到开发进度上去，因为是老板下达的任务小Y马上对自己的原型进行了修改，同时将工作任务交给了开发经理，开发经理看了心里一万匹草泥马在奔腾
　　场景2
　　在项目开发工程中，客户方因为人事变动新入职了一位VP，而这位VP对这个项目非常看重，并结合自己的经验需要在项目中加入一些认为非常好的功能，并告知项目经理这个功能对我们的项目非常重要，务必要增加这项新功能，项目经理将这个需求告知给开发负责人，开发负责人默默的从抽屉拿出来菜刀。
　　场景3
　　项目实施过程中，项目成员漫无天日的进行开发着，项目因为干系人的原因已经做了多次变更，这时项目经理走过来对开发负责人说，前一个版本上变更的一个功能客户反馈没有之前的好用这个版本需要改回来。。
　　以上几个场景做过项目的小伙伴是不是很熟悉啊，因为项目范围没有约定好很容易导致项目无限期的延续，最终导致管理学上的沙漠综合症，项目经理和项目团队成员像在沙漠里面行走没有方向，也不知道什么时候这个项目是个头，整个项目团队士气低落，项目开发效率严重低下，人员流动性增加，最终导致项目的失败。
　　由此可以看出来，项目范围管理是一项全局性而又基础的工作，而我们产品经理在做项目管理时要通过需求范围来开展。
　　1、项目的范围是一项全局性和基础性的工作
　　全局性是需要我们产品经理或者项目经理能够对开发的产品有全局意识，心中知道我们产品的需要达成的目的是什么，围绕我们要达成的目标建立一系列需要素材，哪些开发的项目是需要做的，哪些是不需要做的，哪些是不能够做的。
　　基础性是意味着我们团队所有的项目活动都是围绕着这一目的进行的，没有一个既定的范围所有的项目活动都是盲目的，比如我之前做的汽车类APP项目，在开发前期相关项目干系人不知道做这个APP目的是为何，产品一而再再而三的变更范围，这样投入了大量的人力物力最终没有任何结果。
　　2、KANO需求模型
　　项目范围的原则是综合考虑用户各方面的需求完成让用户满意工程，这里可以提一下KANO模型，在收集需求的时候可以将需求进行划分成为：
　　基本需求，用户使用该产品必须有的功能，当这个需求得到满足的时候用户不会感到满意，没有得到满足用户会非常反感，比如我们电商功能中的支付环节，能够支付时用户感觉理所当然，不能实现线上支付时用户觉得非常不专业。
　　期望需求，是指用户的满意情况与需求的满足程度成正比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，该需求提供的越多，顾客的满意状况越好。同时此类需求得不到满足的情况下，客户的不满也会显著增加。比如产品好的用户体验。
　　魅力需求，指不会被顾客过分期望的需求。随着满足顾客期望程度的增加，顾客满意也急剧上升但兴一旦得到满足，即使该需求表现并不尽善尽美，顾客表现出的满意状况则也是非常高的。相反，如果该需求没有被满足，用户也不会表现出来明细的不满意。比如海里捞提供擦眼镜片，等候时提供的美甲等服务。
　　无差异需求，不论是否满足该需求，对用户体验无影响。比如饿了么上面提供的天气服务。
　　反向需求，增加该需求会引起大多数的用户不满的需求。比如之前文章提到过高层领导需要获取汽车用户车辆完善的信息，而增加繁琐的录入功能，从导致现场操作人员工作量剧增的功能。
　　产品经理在编制项目范围时，需要以用户满意做为前提，通过KANO模型对需求进行有效的划分，从而根据产品生命阶段来逐步构建产品的功能需求。那作为产品经理或者项目经理怎么具体做好我们项目范围管理功能呢？
　　收集需求
　　范围管理也就是明晰需要做什么，在项目管理中收集需求需要引入范围管理计划，需求管理计划，项目章程，这三项管理计划告诉我们产品经理我们项目大体需要做什么？很多做互联网项目的是没有这个计划的，所以我们产品经理值得关注的是干系人管理计划和干系人登记册。什么是干系人呢？很多产品经理会说我们的产品面向的是C端消费者，怎么去做干系人？后面的章节会进行说明，这里需要明确的是与我们项目相关的人都可以纳入干系人行列。所以我们需要对项目相关的干系人进行管理。
　　首先需要对我们干系人进行造册，哪些人会对这个项目产生影响？这些人职位是什么？是不是有所遗漏？在前在做建站的项目时候，因为没有这块的意思，经常设计把设计稿和对接人通过后，因为又有其他领导介入导致设计搞需要重新修改，现在回想起来签订合同的商务人员可以把需求板上钉钉确定后，后期功能上面没有变更这个也就是充分的管理好了干系人。所以在收集需求的伊始不要漏下任何相关的干系人。
　　其次需要了解这些干系人对项目的诉求点是什么？怎么样权衡各个干系人之间的利益？这个说起来可能很简单但是也是最复杂的。经常在一些资料上教育产品经理发现用户的本质需求也就是这个道理（例子就不多举福特造车，打井啊大家可以百度一下）。
　　最后需要选用合适的方法和干系人进行采集，这个也需要心里有数，对外和对内由于时间和成本的差异选择的方式也就不同。常用的方法包括访谈，问卷，观察，原型法，标杆分析，文件分析，德尔菲法，引导式研讨会，群体决策等。
　　工具不是目的，工具是为了很好的为我们的目标服务的。我们通过收集需求需求为了是充分了解我们干系人对我们产品的需求是哪些。收集完需求后我们需要输出需求文件，产品经理习惯叫做需求池，里面包括需求类型，需求描述，需求的来源，解决方案，时间等。除了需求的记录另外需要建立需求的跟踪矩阵，这个文件可以包含需求收集文件内，主要记录需求跟踪情况。不要管杀不管埋，对需求要有始有终。这也是对干系人6有个交代，也是小米提及的参与感。
　　定义范围
　　我们通过上一步过程广泛的将用户需求进行了收集。这个时候还不能撸起袖子干起来，需要结合我们纲领性文件项目章程，明确我们系统到底要做什么。同时这样可以把一些伪需求给PASS掉或者做优先级较低的排期。范围的定义我们需要对产品进行分析，将我们产品怎么进行划分模块，这个也是将我们收集的需求汇总的过程，这样可以更好确定我们产品的范围同时也方便制定验收标准。系统分析和价值分析从产品未成形和成形来分析我们产品的价值，那个功能价值点会更高，更高的价值点我们需要赋予他怎么样的目标。
　　定义范围的好处在于让系统更加明确需要实现什么，不需要实现什么。需要实现的是高价值的功能，比如KANO模型里面的基本需求，期望需求和魅力需求，而需要摒弃的是一些低价值的需求，之前做酒店管理系统时与客户沟通过程中，发现产品里面80的功能是客户没有用过的，这些功能的产生可能来自个别用户，也可能是需求人员拍脑袋，从而导致系统功能很“强大”，需要专业的人员培训之后才会使用。
　　创建WBS
　　当我们把前面的工作完成后，领导就会过来问产品什么时候可以出来了，这个时候你可能还是两眼一抹黑，有经验的项目经理可能大致评估一个时间。为什么不能评估出来，因为我们没有把工作进行分解，我们的系统还是停留在构思上，没有落实到人。怎么样落实到人呢？我们需要将我们的工作做WBS分解。
　　WBS就是将我们的产品或者交付物分解到更小的单元，方便我们做时间进度和成本上的评估。WBS分解的方式可以是树状或者表格形式进行分解，并且需要确保我们分解到最小的单元，最小的单元遵循880法则，也就是说工作包最低不能低于8H也就是1天，最高不能超出80H小时，另外分解过程需要逐渐明晰，近期工作要分配详细，拆分到最小单元，而远期的工作做个规划表，这样不至于我们将手上的工作进行遗漏，这也是说的迭代的一个过程。做WBS时层级在36层比较适合，颗粒过粗不易于管理风险较大，颗粒过细效率会降低同时资源会造成浪费。
　　WBS好处：
　　让干系人放心，清晰明了的知道每一步需要做哪些工作；
　　不容易遗漏工作，做到每一项工作心里有数，什么时间节点做什么工作；
　　便于落实工作责任，哪些人员要什么时间点做什么工作；
　　成本和进度的基础，只有制定完善WBS后才能对，项目进度和成本进行估算；
　　项目沟通管理的依据，在沟通和管理管理中，对于汇报对象清晰明了知道每个的工作内容和实施情况，同时也是做计划和控制的依据；
　　WBS有效的防止范围的蔓延。
　　范围确认和监控
　　范围确认是产品或交付物正式提交后，对产品或交付物的范围进行核实，是否按量完成了该工作，范围确认和质量控制工作可以并行，质量控制是需要确认产品内容是否达到要求的质量标准，而范围核实是确认产品是否按照既定的范围进程开发。
　　范围监控主要确认范围是否按照既定范围相关文档进行，分析哪些因素会导致范围的变更，范围有变更是否按照约定的流程进行，已批准的变更是否做了组织过程资产的更新和项目文件的更新，高层是否知晓变更。做好范围监控要对外要有效控制范围蔓延，对内要控制镀金的现象。
　　以上就是关于范围管理知识的说明，一个产品成功与否和范围管理有直接的关系，所以在做产品的时候要非常重视范围和需求的问题。
　　相关阅读
　　产品经理需知的项目知识：整体管理