2023年不要“宠坏”客户：谈项目范围管理

不要“宠坏”客户：谈项目范围管理在一位产品经理的工作生涯中，只服务于一款产品并不常见。反而在大多数时候，许多产品或服务是以项目的形式进行交付的。这就要求我们在工作过程中娴熟把握项目管理的方式方法，并将项目管理理论与产品经理工作实际结合起来。

下面我将从项目伊始的范围管理开头，带你领会互联网行业的项目管理，盼望籍此你也能把握肯定的方法论并运用到往后的工作中去。记住，只要你想完成你手头的项目，无论你和客户的关系多么亲热，不要“宠坏”他们。

一、什么是项目范围

在日常工作生活中，评判一个人是否靠谱，有两个很重要的评判因素“边界感”和“分寸感”。做人做事没有边界感，从小的方面看简单冒犯他人，让自己显得粗鲁莽撞；从大的方面看也简单越俎代庖，干出不合法规的事情。而缺乏分寸感，就会对事情的轻重缓急拿捏不清，重要的事情不做，反而在无关紧要的小事上钻牛角尖。

项目的范围，其实就是项目的“边界”和“分寸”。项目范围定义了哪些工作应当包含在项目内，哪些不应包含在项目内。做好项目范围管理，就是确保做且只做必要的事情，这些事是胜利完成项目所不行或缺的。简言之，能用6个包子填报肚子，就绝不吃第7个。

项目的范围可以从两个层面进行拆分理解：用户需求和项目工作。用户需求，就是用户要求产品所必备的功能及特性；项目工作，就是为使产品能满意要求，所必需完成的工作。举个例子，把你自己当作“产品”，把追女孩儿当作一个项目来操盘。

你心目中的白月光对抱负男友的要求是年少多金、风趣幽默、颀长健硕、博闻强识……而你为使自己尽可能靠近此标准，就开头健身、看书、交际、搞钱，最终你胜利抱得女神归，这就是一个胜利的项目。而假如你一不当心逼自己成为亿万富翁，远远超出女神的要求并导致对方自惭形秽而更加疏远你，那恭喜你找到了更优秀的自己，但很明显操盘了一个“失败”的项目。

掌握客户预期，把握好用户需求，将其梳理为详细的功能要点和参数特性，最终落实为项目团队详细的行动。这就是项目范围管理的本质。

二、范围管理的意义何在

现代社会的各类组织，小到部门、小组，大到集团、工会，都是由“人”组成的有机体，都在乐观的汲取外界能量，消化为自身成长的养分。因此，花最少的钱干最优的事，始终是一个组织做事的底层规律。

项目范围定义不清，往往是导致项目失败的首要缘由。在启动一个项目时，假如不能对项目要做的事情定义清楚，就是为日后项目交付时的推诿扯皮埋下伏笔。项目的范围管理是制定项目方案，做好进度把控的关键基础。一个项目没有做好范围管理，只会导致摊子越铺越大，最终无以为继，虎头蛇尾。

权责不清是大家在工作中最怕遇到的。这不仅仅是谁多做谁少做的问题，更会涉及到工作环节的连接和工作成果的交接，进而影响项目的整体进度。

打个比方，小A是终端嵌入式开发，小B是后台开发，两个人都觉得制定接口协议是对方应当主导的事情，都没对这件事上心，最终导致接近交付时才发觉终端没有与后台联调，影响交付进度。

而假如做好了项目范围管理，就能够确定项目的详细工作任务，有助于清晰的责任划分和任务分派。像小A和小B的这种事情就不会再发生了。

对于项目发起方和项目经理而言，成本始终是敏感且重要的话题。一个项目在立项之初，就需要清楚精确     的估算出所需投入的成本、所需协调引入的资源，以及所需的时间。

估算成本不是拍脑袋，需要精确     识别设备设施、人员配备、工作工时等，这些都和项目的详细工作息息相关。比方说研发一款智能手表，需要使用示波器等仪器测试硬件PCBA，假如在事先不明确这部分工作，就简单漏掉这些仪器，进而导致固定投入估算不清。

总的来说，不对项目范围进行清楚的定义，就无法明确项目的工作详细范围和详细内容，就无法提高成本、时间和资源估算的精确     性。

工作中我们经常遇到下图所示的状况，客户要求三个月做一幢豪宅，给了能做几间平房的钱，我们用一年的时间反复推倒重建，最终交付了一个公厕。假如你读到这里能够会心一笑，那证明你已经是有过几年项目阅历的PM了，有肯定阅历，但不多。

这个读来令人捧腹的例子，向我们深刻揭示了约束项目范围的三大要素：进度、成本、质量：

要求三个月完成，最终拖延一年。这是进度；给了几间平房的钱，实际由于反复重修，超出预算，最终只交付了一间房。这是成本；要求豪宅，最终公厕。这是质量做项目不是做慈善，哪怕你为了幻想参加到项目里来，也不能罔顾客观实际。想要兼顾快捷、低廉、优质，那这个项目是不行能胜利的。假如有客户向你提出这等非分之想，不妨把这张图发给他。

三、范围管理的方法路径

项目范围管理的方法论就三个字——“做减法”。我们做且只做能胜利完成项目所需的全部工作。围绕这个核心理念，我们将项目范围管理拆分成六个步骤。

规划范围管理：指导团队如何管理项目范围，需制定项目范围管理方案收集需求：挖掘真实需求，建立需求与可交付成果及项目目标间的对应关系定义范围：制定具体的项目范围说明书，明确验收标准创建WBS（工作分解结构）：明确范围基准，分解工作内容，关联唯一责任人确认范围：明确工作结果是否可以接受，完成验收掌握范围：管理实际的范围变更。这一过程贯穿项目始终要怎么掌握好客户预期，如何把握客户的真实需求，这些需求如何落地为详细可执行的工作？带着这三个疑问，我们往下看。

1.规划范围管理

在初创型企业或者传统家族式企业，做项目许多时候都是“一言堂”，老板说做那就做，老板说加那就加。惋惜如马斯克或者乔布斯那样的天才产品经理极度少见，你的老板极也许率并非这样的天才。许多时候，这种一言堂会把整个项目带进沟里。

规划范围管理这个步骤，更像是为项目，甚至是为企业制定标准。这一过程的输出，也就是“项目范围方案”，不仅是项目工作开展的指导文件的一部分，更能成为企业阅历的一部分，变成组织过程资产。

一般来说，规划范围管理这一步需要进行如下活动：

1）制定具体的范围说明书

这一步骤在许多时候和项目可行性分析、搭建需求池、建立项目章程等步骤合在了一起。只要能具体清楚的表达出项目范围，不用拘泥于形式。

2）确认从具体的范围说明书内创建WBS（工作分解结构）的流程方法

一般而言，每个公司有其通用的一套规章，项目上沿用即可。若要建立一套全新的流程，则项目经理或产品经理应对产品研发的整个流程有着特别清楚的认知，知道哪个阶段应当做什么、需要哪些前置输入，需要哪些产出。

3）确认批准和维护WBS的流程方法

WBS建立好后应如何评审，谁来参加评审，这些都要提前定义清晰。此外，应确认由哪个岗位来维护WBS，大点的团队一般会特地设立项目管理工程师这个岗位，简称“项管”，来对WBS的整体排期和进度进行追踪，小点的团队就只能产品经理或项目经理兼任这个角色。

4）确认对已完成的项目可交付物进行正式确认和接受的流程方法

项目的阶段性产出如何进行验收，谁来验收，验收的标准是什么？千人千面，适合就好。

5）明确如何对具体的项目范围说明书申请变更

一般范围说明书定义清晰后不会再改动，若的确需要变更，那一般都是特别重大的改动。需明确在发生哪些突发状况时，才允许对项目范围说明书进行变更，这一过程需要严格谨慎。

四、收集需求并挖掘真实需求

不行否认的一点是，无论对谁来说，收集需求并挖掘出真实需求都是一件很难的事情。

首先，你的客户有着与你不同的专业背景，你们很可能并非同一行业。假设你们在为一家医院打造业务平台，你用计算机专业的思维，去理解一些医疗行业从业者的诉求，往往鸡同鸭讲，相互get不到点；其次，基于每个人规律思维与表达力量的不同，语言的表达有其固有的损耗。客户想的是100，传达给你的是60，你转达给开发的是40，开发能理解并做出来的不到20，这是很常见的态势；最终，某个人在某一时刻的想法，往往只是灵光乍现，并非真实需求。客户本质上是一群人，且你的甲方和最终用户往往属于两个不同群体。但凡是群体，就不会有完全统一的声音。假如在收集需求时只考虑某个人的声音，就必定会造成需求图谱的失真。收集需求的核心原则，为“详细化”、“书面化”、“可测量”。需求的模糊程度越低，执行时产生偏差的可能性就越低；需求描述的越详细，验收时发生扯皮的状况就越少。一千个人眼中有一千个哈姆雷特，为尽可能的削减分歧，在需求收集阶段就要尽可能做到明确、详细，可测量，并记录在文档内归档。

1.收集需求和梳理需求

访谈：和客户直接交谈，来猎取信息。信息失真小，但效率较低；问卷调查：书面问卷，受众填写。信息失真大，效率较高会议研讨：把行业专家和项目相关方都聚集到一起，大家坐下来对产品需求进行集中争论与建议，了解大家对所提议产品、服务或成果的期望和态度。信息失真小，效率高，对组织力量有肯定要求；群体创新：头脑风暴，再用思维导图等形式将大家的想法做分类梳理。一般适用于创新类或演示类的项目；群体决策：在已搜集到的需求基础上，通过全都同意原则或相对多数原则来打算详细执行哪些需求；标杆对比：抄竞品；收集需求的下一步就是梳理需求，需要建立需求与项目可交付成果以及项目目标间的对应关系。可以借用OKR的概念对这个动作进行解释。O即Objectives，核心目标；KR即KeyResults，关键成果。在需求收集这个环节，项目目标就是我们的O，可交付成果即为KR，需求即为完成可交付成果所必需的步骤。需要确保全部的需求点，最终都是为达成项目目标而做的，与项目目标无关的需求要坚决排解。

值得留意的是，并不是全部与项目目标关联的需求都需要项目组去满意，且需求是否被批准最终是由项目发起人打算的。在一个项目里，项目经理只是一个被授权调用资源的“打工仔”，项目发起人才是“幕后Boss”。

2.输出需求跟踪矩阵

在许多互联网企业，产品经理往往会搭建一个需求池，服务的是一个长生命周期的产品。这个需求池和项目的需求跟踪矩阵有肯定相像之处，可以对比理解。在项目需求跟踪矩阵中：

首先需要明确项目的成本中心和项目背景、目标；其次以可交付成果为标杆进行需求的细化拆解；最终对需求进行具体描述，说明预期效果，阐明可交付成果、对应责任人等

五、创建工作分解结构

收集、梳理需求并关联项目目标，是回答了“做什么事情”，“为什么要做这些事”，高屋建瓴的为项目成员指明白前进方向。但是我们既要仰视星空，也要脚踏实地，需要把项目目标拆解成每个成员详细该干的事情，才能把愿望落地，让项目接地气。回答好“怎么做这些事情”，是创建工作分解结构（WBS，WorkBreakdownStructure）的核心所在。

1.工作分解的意义

首先必需要说明的是，不是全部项目都必需根据项目范围管理的条条框框来执行，也不是只有严格遵循范围管理的方法论，项目才能胜利。日常工作中，我们不能陷入教条主义。对于重难点问题攻关型项目，或者开创前人未有之道路的创新型项目，就不存在工作分解这一说了。大家都在摸着石头过河，谁也指导不了谁。这就带来工作分解这一步能正常执行的前提：必需得有一个人对项目的整个过程有着特别糊涂的认知，有过相关阅历，知道在什么时间点应当干什么事情。项目经理就起着这样的作用。

正如大家都喜爱“跟我上”而非“给我上”的领导，正确执行工作分解能带来如下好处：

可以建立完整的项目保证体系，便于执行和实现项目目标；通过工作分解结构，项目相关人员对项目一目了然，明白各自所处的位置、所要做的事情和所需担当的责任。便利后续进行费用、进度、绩效的跟踪；能够明确项目各方面的界限，便于责任划分和落实；为项目沟通供应依据，可用于与项目干系人沟通项目状态，提高项目团队整体沟通效率；2.工作分解的方法

不同组织创建工作分解结构的方法不同，有两个常见的分解工作的维度：

基于项目的生命周期的各阶段。如一个企业信息管理系统的交付类项目，往往根据需求调研——分析设计——程序设计——软件测试——产品验收交付的流程来进行，需要针对各阶段的主要工作进行拆解，如分析设计阶段，可拆解为数据库设计、系统接口设计、业务功能设计等；基于可交付成果。同样以企业信息管理系统为例，可以简化为OA系统、人事系统、营销系统、设备管理系统等多个版块，需要对各板块进行拆解。如人事系统版块可以拆解为职工管理、培训管理、党政管理等在对大型项目进行工作分解时，除了详细的工作内容和责任人，还可能包含以下特定内容：

编码标识。特定的序号，用于划分层级、进行区分；假设条件和制约因素。即执行此项工作的前提，及可能影响工作进度的因素；进度里程碑。完成此项工作的标志；所需资源。一般指软硬件外部环境，仪器设备等；成本估算。一般包含人力成本和直接材料成本等；质量要求验收标准在工作分解结构里，往往会人为设置一些管理掌握点，叫“掌握账户”。可以理解为项目节点，在这个节点上需要对范围、成本、进度进行整合分析，并与预期效果进行比对，以明确项目进度和绩效。

在实际工作中，若有特地的项目管理工程师参加统筹，是可以尽量细致的对工作进行拆分的，在设定的项目节点也可以对项目进度准时复盘。