Login Now 隔壁项目组最近出了个哭笑不得的状况：开发只花了一个月，验收却拖了两个多月，到现在还没上线。
跟他们的开发聊了聊，才知道问题出在哪儿——每次带着测试版去见客户，对方总能挑出一堆问题，冷不丁又冒出几个新想法。没办法，回来接着改，改完再去，结果又带回来新的需求。就这么来回折腾，没完没了。
更头疼的是，产品和测试把客户的新需求一次次带回来之后，开发同事肉眼可见地越来越绝望，代码里的 Bug 也跟着多了起来。那种感觉，就像在一条看不到尽头的路上反复折返跑，谁都会疲掉。
也就是在这样的时刻，我越来越清晰地意识到一个词：需求边界。
说得直白一点，需求边界就是在某个明确的版本里，清楚知道该做什么、不该做什么，需求的数量和范围是可控的，而不是被外力推着走，今天加一点，明天改一处。
我们做的 B 端产品，大致可以分成两类：一类是平台化的 SaaS，也就是标准化产品；另一类是外包项目，需要为客户做定制。两相比较，外包项目的外部需求最难控制，意外也最容易冒出来，所以需求边界这件事，在外包项目里尤其重要。
如果产品经理心里没有这根弦，会发生什么？
最直接的后果，就是项目怎么也交付不了。不管在哪个阶段，习惯性地答应客户的新需求，边界被一次次撑大，上线日期只能一拖再拖。其次，开发阶段需求不断在变，团队很容易产生疲劳和抵触心理，这对士气的打击几乎是致命的。对公司来说，阶段验收就变成了无用功，项目没法交付，尾款就收不回来，最后往往成了赔本买卖。
反过来，如果能守住需求边界，阶段性工作的方向和重点就会很清晰，时间表和进度也更可控，前面说的那些灾难性问题，大概率就不会发生。
那怎么才能把边界控制住？我自己总结下来，大致可以从三个层面去用力。
需求层面
首先要承认一件事：在业务上，客户才是真正的专家。他们最清楚自己要解决什么问题，也希望我们能给出一个好的解决方案。但业务上的专长，不等于他们能直接定义产品需求。只有用户自己，才能确定需求边界的范围和深度。
当我们对需求还一知半解的时候，最好的办法不是坐在办公室里猜，而是把自己扔进业务场景里，去调研、去模拟、去推演，和客户建立起对需求理解的一致性。这样，才能慢慢想象出最终的产品形态，再从结果倒推需求边界——哪些是我们该做的，哪些是必须遵守的规则。
说到底，客户要的是解决问题，至于怎么解决、功能怎么呈现，还是得由产品经理来主导。
项目层面
先讲一个很现实的观点：需求从来不是靠过程中控制来实现的，一旦你想着在过程中去“控制”边界，反而容易把自己推到非常被动的位置。
需求之所以会无限蔓延，很多时候是因为项目一开始就没把基本规范理清楚。如果前期没建立起标准化的机制和流程，到了中期再指望靠包容和妥协来解决问题，只会越陷越深。
最好说话的时机，其实是项目刚启动的时候。那时候大家一团和气，客户也好，团队也好，都愿意坐下来好好谈。所以，一定要抓住这个窗口期，把规则和流程立起来。
做外包项目，通常都需要分阶段验收，原型和 UI 设计稿，就是我们划定开发需求边界的一个重要里程碑。客户口头说“OK”还不够，必须有一封正式的确认邮件。白纸黑字的东西，将来就是我们要拒绝无限扩需时最硬的依据。
另一个关键动作，是确定需求冻结时间。
当项目有了明确的上线或交付时间，需求确认邮件发出之后，就要尽快召开需求评审会，让开发评估需求的问题点和难度。评估结果出来以后，我们再重新调整版本计划：实在做不了的，移入下一个版本；根本实现不了的，直接拿掉；难度太大的，可以先放进待定版本池里。
这一轮排完，需求就冻结了。对外传递的信息非常明确：这个版本就做这些事，不会再临时加新需求，我们要对开发进度负责。
商务层面
合同和验收标准，是另一道很重要的墙。不管是 SaaS 还是外包，合同里写明了项目类型和交付时间，其实也就框定了需求边界。有了明确的项目解决方案，任何超出边界的需求，都可以有理有据地拒绝。
比如，我们给线下亲子店设计了一套在线预约和购买会员的解决方案，如果客户想在后面再加一个电商功能，我们就可以直接搬出合同约定来应对。
当然，如果修改要求本身就在合同范围内，有时候我们确实也做不了主——毕竟面对金主，很难硬气地一口回绝。这时候，可以重新评估一下需求变更的成本，然后给客户或者领导提供一套更简单的替代方案，或者给出一个充分的拒绝理由，把决定权交出去。
如果实在拒绝不了，还可以试试把决策压力转移出去。
一个常用的方法是提出需求池的概念。告诉客户，我们的目标是先把这一版的主要功能跑通，新的需求我们都记在需求池里，会在下一个版本统一规划。如果客户还是坚持新需求必须现在就做，那就把利害关系摊开来说——是尽快上线、慢慢迭代，还是无限期地增加需求，必然会导致成本和时间都要重新评估。为了一两个新功能，把整条交付线都拖垮，值不值得，让客户自己来判断。
如果客户依然不松口，那就得学会向领导借力了。把需求边界被打破之后的失控状况讲清楚，把最终决策权交给领导，这也是一种专业。
走了这么多弯路之后，我才慢慢明白，需求边界对产品规划的重要性，真的不是一句空话。从需求到项目，再到商务层面，每一层都需要有意识地守住那条线。很多时候，是要被需求蔓延狠狠教训过几次，才会真正长出勇气，坚持不让产品需求失控。