好的，小姚。

这个问题，你问得太好了。

我先给你定个调：你问的不是“怎么控制需求”，你问的是“怎么在复杂的干系人关系中，用沟通守住项目的生命线”。

需求蔓延，是项目经理的“头号杀手”。你以为你输在文档写得不够细、流程管得不够严？我告诉你，你输在沟通。

你不是第一个被需求蔓延折磨得睡不着觉的项目经理。你身边那些看起来游刃有余的项目经理，你以为他们从来没遇到过用户朝令夕改、需求像野草一样疯长？我告诉你，他们不是没遇到过，他们是用沟通把需求蔓延变成了可控的变更。

你今天能问出这个问题，说明你已经在思考“怎么从源头上解决问题”，而不是只会抱怨“用户怎么又变了”。这说明你是一个有责任心、有追求的项目经理。

那今天老邱就专门为你，把小姚这个问题拆开揉碎了讲。不讲大道理，不讲PMBOK背课文，讲人、讲人性、讲利益、讲怎么在需求蔓延的汪洋大海里，用沟通给自己造一条船。

一、先搞清楚一个前提：需求蔓延，到底是谁的错？

小姚，在回答你怎么做之前，我想先跟你聊聊一个很多人不愿意面对的现实。

你说你苦恼于控制用户的需求蔓延，那我问你：需求蔓延，真的全都是用户的错吗？

我给你分四种情况，你对号入座。

第一种：用户自己也不知道自己要什么

这是最常见的情况。

用户跟你说：“我要一个类似淘宝的购物车。”你做了，他一看说：“不对，我要的是类似京东的购物车。”你又改了，他一看说：“不对不对，我要的是拼多多的购物车。”

你心里一万匹草泥马奔过：你早说不就完了吗？

但是小姚，我告诉你，用户不是故意耍你，他是真的说不清楚。

很多用户，尤其是业务部门的用户，他们没有受过需求分析训练。他们脑子里有一个模糊的画面，但没办法用结构化的语言表达出来。他只能说“像淘宝那样”，因为淘宝是他唯一知道的东西。

这不是他的错，这是你没有帮他理清楚。

第二种：用户的需求在变，但业务也在变

你做项目不是活在真空中。你做一个电商系统，做了三个月，市场变了，竞争对手出了新功能，老板说要跟上。用户来找你：“我们得加一个功能，不然就完蛋了。”

你说：“不行，需求已经冻结了。”

用户说：“那项目做出来也没用了。”

小姚，你告诉我，这时候是谁的错？

谁都没错，是这个世界变得太快。

但你如果说“不行，按合同来”，你就是错。因为你没有理解用户的商业压力。

第三种：你们的需求沟通是“传话游戏”

业务部门提需求给产品经理，产品经理整理完给项目经理，项目经理转述给开发，开发做出来给测试，测试完给用户。

传了五道手，每一个环节损失20%的信息，到最后用户看到的跟他要的已经不是同一个东西了。

他说：“这不是我要的。”

你说：“你当时就是这么说的。”

他说：“我什么时候这么说了？”

这是他的错吗？这是你们整个需求沟通链条的错。

第四种：用户故意在蔓延

这一种，我要跟你实话实说。

有些用户，他明知道这个需求不在合同里，他就是要提。为什么？因为他想用你的项目，给他自己多做点东西。反正又不用他花钱，用的是你们项目组的资源。

这种人，人品有问题。

小姚，你告诉我，你遇到的是哪一种？

我猜，你可能遇到的是混合型。有时候第一种，有时候第二种，有时候第三种，偶尔第四种。

那问题来了：不管他是哪一种，你的处境都是一样的——他提，你改；你改，他再提；你再改，项目延期，你背锅。

怎么办？

下面老邱给你拆开讲。

二、先别急着“控制”用户，先搞清楚你的沟通段位

小姚，你现在可能觉得自己很委屈。你每天在用户和开发之间来回传话，用户说加功能，开发说不行，你夹在中间两头受气。

我告诉你，你不是委屈，你是沟通段位不够。

我给你画一下，项目经理沟通的三个段位。你看看自己在哪一段。

段位一：传话筒

这个段位的项目经理，用户说什么，他就跟开发说什么。开发说什么，他就跟用户说什么。

他的口头禅是：“用户说要加这个”“开发说做不了”。

结果是什么？用户觉得你没用，开发觉得你没用，你就是一个人工微信群。

段位二：翻译官

这个段位的项目经理，用户说业务语言，他翻译成技术语言给开发。开发说技术语言，他翻译成业务语言给用户。

他能让两边听懂对方在说什么，但他改变不了任何人的想法。

用户该蔓延还是蔓延，开发该抵制还是抵制。

段位三：操盘手

这个段位的项目经理，他不只是传话和翻译，他是在管理双方的期望、利益和情绪。

他知道用户真正想要的是什么（不是他说出来的那个功能，是他背后的业务目标）。他知道开发能接受的底线是什么。他在中间找到那个双方都能接受的方案，让用户觉得“我赢了”，让开发觉得“我也没有吃亏”。

小姚，你现在在哪个段位？

我猜，你可能在段位一和段位二之间。你已经不做纯粹的传话筒了，但你还做不到操盘手。

没关系，老邱今天就帮你从段位二升到段位三。

三、需求蔓延中的沟通技巧：六招让你从“被动挨打”到“主动控盘”

小姚，我给你拆解六个最实用的沟通技巧。每个技巧，我给你一个具体场景和一套话术。

技巧一：用“需求分层法”把模糊变清晰

场景：用户说“我要一个报表”。

你问“什么报表”，他说“就是那种报表”。你再问，他说“你做个样给我看看”。

这是最让人抓狂的场景。

你的应对策略：不问“要什么”，问他“解决什么问题”。

具体话术：

“王经理，我想先跟您对齐一下这个报表要解决什么业务问题。您是每周要看销售额汇总？还是要监控哪个环节的异常？还是有其他用途？”

“如果我给您一个能导出原始数据的报表，您可以自己加工，还是您需要系统直接给出结论？”

你看，你不是在拒绝他，你是在帮他分层：

第一层：他要解决什么问题？（业务目标）

第二层：他要看什么数据？（数据范围）

第三层：他要什么格式？（呈现方式）

大多数用户只说得清楚第三层，甚至第三层都说不清楚。你帮他把前两层理出来，他自己就发现“原来我要的不是报表，是一个预警机制”。

需求不是问出来的，是挖出来的。

技巧二：用“优先级三板斧”让用户自己砍需求

场景：用户一口气提了八个新需求，每个都很“紧急”。

你的应对策略：不跟他争哪个重要，让他自己排顺序。

具体话术：

“张总，您提的这几个需求我都记下来了。我们现在还剩三周时间，团队资源是固定的。我想请您帮我排一下优先级，我用三个维度来问您：

第一，如果不做这个功能，业务还能不能跑？如果能跑，那它就不是P0。

第二，如果做这个功能，但是简单版本先上线，后面再迭代，您能接受吗？如果能接受，那它也不是P0。

第三，如果这个功能必须做、必须完整版、不做业务就停摆，那它就是P0。

您告诉我，这八个里面，哪几个是符合第三个条件的？”

用户自己排完，你会发现，八个变成了两个。

为什么？因为用户说“紧急”的时候，他说的不是“不做就死”，他说的是“我想要”。你让他自己定义什么叫“不做就死”，他就老实了。

这一招，叫把需求优先级的管理权还给他，让他自己承担排序的后果。

技巧三：用“变更三连问”把隐性成本显性化

场景：用户提了一个新需求，看起来不大，但牵扯到好几个模块。

你的应对策略：不问“做不做”，问他三个问题。

具体话术：

“李经理，这个需求我可以接。但在接之前，我需要跟您同步三个信息，然后您来决定做不做：

第一，这个需求会影响到A、B、C三个模块，开发评估需要额外5天。

第二，这5天会挤压我们原定下周交付的D功能的测试时间，D可能会延期3天交付给您。

第三，延期3天不影响您的大节点，但会影响您内部的一个小里程碑。

基于这三个信息，您还确定要做吗？如果您确定要做，我会正式走变更流程，把时间影响写到变更单里。”

你看，你不是在拒绝他，你是在帮他算账。

用户提需求的时候，他眼里只有“我要这个”。他不知道“这个”后面跟着什么。你帮他把账算清楚，他可能自己就说“那算了，先不做了”。

这一招，叫把隐性成本变成显性成本。