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

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

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

一、什么是项目范围

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

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

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

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

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

二、范围管理的意义何在

现代社会的各类组织，小到部门、小组，大到集团、工会，都是由“人”组成的有机体，都在积极的吸收外界能量，消化为自身成长的养分。因此，花最少的钱干最优的事，一直是一个组织做事的底层逻辑。

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

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

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

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

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

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

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

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

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

• 要求三个月完成，最终拖延一年。这是进度；
• 给了几间平房的钱，实际因为反复重修，超出预算，最终只交付了一间房。这是成本；
• 要求豪宅，最终公厕。这是质量

做项目不是做慈善，哪怕你为了梦想参与到项目里来，也不能罔顾客观实际。想要兼顾快捷、低廉、优质，那这个项目是不可能成功的。如果有客户向你提出这等非分之想，不妨把这张图发给他。

三、范围管理的方法路径

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

1. 规划范围管理：指导团队如何管理项目范围，需制定项目范围管理计划
2. 收集需求：挖掘真实需求，建立需求与可交付成果及项目目标间的对应关系
3. 定义范围：制定详细的项目范围说明书，明确验收标准
4. 创建WBS（工作分解结构）：明确范围基准，分解工作内容，关联唯一责任人
5. 确认范围：明确工作结果是否可以接受，完成验收
6. 控制范围：管理实际的范围变更。这一过程贯穿项目始终

要怎么控制好客户预期，如何把握客户的真实需求，这些需求如何落地为具体可执行的工作？带着这三个疑问，我们往下看。

1. 规划范围管理

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

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

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

1）制定详细的范围说明书

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

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

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

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

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

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

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

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

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

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

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

• 首先，你的客户有着与你不同的专业背景，你们很可能并非同一行业。假设你们在为一家医院打造业务平台，你用计算机专业的思维，去理解一些医疗行业从业者的诉求，往往鸡同鸭讲，互相get不到点；
• 其次，基于每个人逻辑思维与表达能力的不同，语言的表达有其固有的损耗。客户想的是100，传达给你的是60，你转达给开发的是40，开发能理解并做出来的不到20，这是很常见的态势；
• 最后，某个人在某一时刻的想法，往往只是灵光乍现，并非真实需求。客户本质上是一群人，且你的甲方和最终用户往往属于两个不同群体。但凡是群体，就不会有完全统一的声音。如果在收集需求时只考虑某个人的声音，就必然会造成需求图谱的失真。

收集需求的核心原则，为“具体化”、“书面化”、“可测量”。需求的模糊程度越低，执行时产生偏差的可能性就越低；需求描述的越具体，验收时发生扯皮的情况就越少。一千个人眼中有一千个哈姆雷特，为尽可能的减少分歧，在需求收集阶段就要尽可能做到明确、具体，可测量，并记录在文档内归档。

1. 收集需求和梳理需求

• 访谈：和客户直接交谈，来获取信息。信息失真小，但效率较低；
• 问卷调查：书面问卷，受众填写。信息失真大，效率较高
• 会议研讨：把行业专家和项目相关方都聚集到一起，大家坐下来对产品需求进行集中讨论与建议，了解大家对所提议产品、服务或成果的期望和态度。信息失真小，效率高，对组织能力有一定要求；
• 群体创新：头脑风暴，再用思维导图等形式将大家的想法做分类梳理。一般适用于创新类或演示类的项目；
• 群体决策：在已搜集到的需求基础上，通过一致同意原则或相对多数原则来决定具体执行哪些需求；
• 标杆对照：抄竞品；

收集需求的下一步就是梳理需求，需要建立需求与项目可交付成果以及项目目标间的对应关系。可以借用OKR的概念对这个动作进行解释。O即Objectives，核心目标；KR即Key Results，关键成果。在需求收集这个环节，项目目标就是我们的O，可交付成果即为KR，需求即为完成可交付成果所必须的步骤。需要确保所有的需求点，最终都是为达成项目目标而做的，与项目目标无关的需求要果断排除。

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

2. 输出需求跟踪矩阵

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

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

五、创建工作分解结构

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

1. 工作分解的意义

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

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

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

2. 工作分解的方法

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

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

在对大型项目进行工作分解时，除了具体的工作内容和责任人，还可能包含以下特定内容：

• 编码标识。特定的序号，用于划分层级、进行区分；
• 假设条件和制约因素。即执行此项工作的前提，及可能影响工作进度的因素；
• 进度里程碑。完成此项工作的标志；
• 所需资源。一般指软硬件外部环境，仪器设备等；
• 成本估算。一般包含人力成本和直接材料成本等；
• 质量要求
• 验收标准

在工作分解结构里，往往会人为设置一些管理控制点，叫“控制账户”。可以理解为项目节点，在这个节点上需要对范围、成本、进度进行整合分析，并与预期效果进行比对，以明确项目进度和绩效。

在实际工作中，若有专门的项目管理工程师参与统筹，是可以尽量细致的对工作进行拆分的，在设定的项目节点也可以对项目进度及时复盘。若是人员配备不足，也可酌情减少拆解的力度。

我们在这里谈到什么是项目范围，管理好项目范围的意义何在，做好范围管理的基本路径等，核心内容就是确立了范围管理的方法论——“做减法”。谈到面对客户时，我们要合理控制客户预期，无论你和他们关系多么亲密，不能“宠坏”他们。

规划范围管理是常常被人忽视，却又极为重要的步骤，这往往决定了这个项目组的做事基调。靠谱的项目团队，一定会“把丑话说在前头”，并在往后的工作中严格执行。

正如“慈母多败儿”，做好项目范围管理既是对项目团队的负责，也是对客户的负责。成为一个靠谱的项目经理或产品经理，从控制好你的项目范围开始。

本文作者 @Smile

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！