Iniciar Sesión Ahora 你经历过那种场面吗？项目已经启动了，前端后端都在吭哧吭哧搭架子，产品经理突然跑过来说：“那个，需求得改一下。”程序员手里的键盘一顿，空气里飘着一点说不清的情绪。
“产品经理总改需求”这个抱怨，差不多就是从程序员群体里长出来的，慢慢变成了一种刻板印象。但话说得直白点，需求就是产品经理让技术团队去做的任务，改需求就是在任务已经排好、甚至已经开干之后，再去变动这些任务的要求。
通常有两种情况最让人上头。一种是开发周期内，活儿已经排下去了，项目正在推进，产品经理跑来要改。另一种是项目刚上线没几天，产品经理又来了，说下一个版本得把这个地方动一动。而真正容易点燃情绪的，几乎都是第一种。
改需求的原因当然不止一个。领导有了新想法，合作方提了新要求，市场风向突然变了，这些都有可能，而且很多也不是产品经理自己能左右的。但今天重点聊的，是最基础、也最该被产品经理自己握在手里的那一个——计划的时候没想仔细。
比如模块之间的逻辑前后矛盾，一个对象的状态流转漏了关键环节，或者交互设计本身就不合理，流程走不通。这些错误如果在规划阶段被放过去，到了开发环节才被发现，就只能用“改需求”来兜底。对刚入行的朋友来说，这一点尤其要盯紧。一个产品经理如果交出来的 PRD 总是错漏百出，那在这个位置上很难走得长远。
怎么把方案想得更仔细？这问题太大了，几句话讲不透，更多是靠自己在项目里慢慢磨。但有两个点，我觉得特别重要，而且网上聊得不多，值得单独拿出来说。
第一点，做方案的时候，一定要把不同平台的实现形式都考虑进去，尤其是各平台那些特殊情况和限制。
现在一个产品通常不是只跑在一个地方。PC 端、触屏端、安卓 App、iOS App，可能还有微信小程序。而触屏端还得再拆一层：是在微信框架内打开的，还是在普通浏览器里打开的。不同环境下的交互能力完全是两回事。
比如你要做一个专题页，里面有个分享功能。这个专题页会同时放在 App 端和触屏端。App 端的分享好办，一般直接调用系统原生的分享模块，弹一个底部面板，上面列着微信好友、朋友圈、QQ 好友这些选项，安卓和 iOS 可以统一用一套设计。但到了触屏端的微信框架里，你就没法调起微信自身的分享面板了，只能自己做一个遮罩层，用图文提示用户去点击右上角的“…”来分享。再换到非微信框架下的触屏端，情况更复杂：你不知道用户会用哪个浏览器，挨个去适配成本太高，很多时候理性选择就是直接把这个场景下的分享入口隐藏掉。
你看，一个看似简单的分享功能，在不同平台上就得这么拆分着来想。如果公司同时还有多条产品线，或者跟外部有业务合作，那就更得提前把这些差异理清楚，不然等到开发提测了才发现，就只能临时改需求。
第二点，你得确保自己真的掌握了产品的真实状态，尤其是那些历史上留下的特殊处理。
我们经常能听到这样的故事：一个小小的问题突然引爆，整个系统被搞得狼狈不堪，然后大家才发现，平时看着光鲜的产品，内部其实已经乱成一团，不知道什么时候埋了无数坑。这种情况在普通小厂几乎是常态，只是暂时没爆雷而已。
所以规划新产品或者改老模块的时候，千万别默认系统现在就是正常、有序、干净的。在你看不到的角落里，很可能有问题。比如某个功能当初上线的时候是好的，后来不知道哪次更新被覆盖了，谁也说不清；或者开发为了赶工期，只上线了部分逻辑，剩下的打算“之后再说”，然后就再也没有然后了；再或者，某个模块的开发过程中不小心弄坏了另一个模块，当时紧急打了个补丁，怎么修的根本没有文档留下来；更常见的是，当初负责的程序员离职了，接手的人看不懂代码，只能凭感觉这里改改那里改改，系统早就面目全非。
如果你不在知名大厂，这些几乎就是日常。所以在做方案之前，你得先把跟这次改动相关的模块都跑一遍，确保自己手里拿到的信息是当前的真实状态。如果前端页面看不出来，就去找对应的程序员，请他打开代码帮你确认一下。只有前提条件是对的，后面的推导和设计才可能是对的。
很多刚入行的产品经理，在跟技术对接的时候特别紧张，生怕哪句话说不对就惹恼了程序员。毕竟人家已经开始写了，你让人家推倒重来，确实容易让人上火。
但其实待久了就会发现，改需求是一件非常频繁的事，频繁到它就是产品和开发配合中的日常组成部分。要是每一次改动都会引发一场剧烈冲突，那公司早就开不下去了，大家也早就因为互相打架而实现财务自由了。现实工作里，并没有那么多段子里的戏剧性。
我遇到过一件小事，印象很深。有一次需要加一个移动端的页面，这个页面有两种状态，假设叫 A 状态和 B 状态。不同账号访问时，A 账号看到 A 状态，B 账号看到 B 状态。然后我提了一个很自然的要求：用户点返回的时候，应该回到他进入这个页面之前的那一层，比如从主页过来的就回主页，从会员中心过来的就回会员中心。
这要求本身没什么不合理的，但开发在实现的时候，接手的那位程序员并没有做成一个带两种状态的页面，而是直接做了两个独立的页面——A 页面和 B 页面。用户进来时默认到 A 页面，如果是 B 账号，就在 A 页面加载的瞬间自动跳转到 B 页面。表面上看也能满足需求，但问题出在返回逻辑上。当 B 账号用户从 B 页面点返回，因为他的来路是 A 页面，系统就会按规则把他送回 A 页面，而 A 页面一加载，立刻又判断出他是 B 账号，于是又把他跳回 B 页面。结果就是用户点返回之后，一直在 B 页面原地打转，根本出不去。
怎么办？页面已经做完了，推倒重来不现实。最后我只能改需求，把返回路径写死，不管从哪来，B 页面返回一律跳到会员中心。
像这样的例子，其实就是日常的常态。没有段子里那种剑拔弩张，也不需要去追究谁对谁错。大家的目标是把项目做完，有问题就一起商量着解决，仅此而已。所以，当你需要改需求的时候，没必要背太重的心理包袱。而且技术团队通常任务排得很满，程序员真正在意的是你能不能把变更的内容说清楚、说准确，让他们能快速理解，而不是含含糊糊地去猜。
如果你是刚入行的产品新人，你的第一份工作很可能不是独立负责一个需求，而是去跟进其他同事手里的项目，做一些辅助性的工作。这其实是一种让你熟悉流程的练习。项目不会太复杂，但也绝不是那种简单到可以放那儿不管的。在跟进的过程中，你大概率会遇到问题，而你人生中第一次改需求，很可能就发生在这个时候。
你还没学会怎么提需求，就要先学会怎么改需求，那种措手不及的感觉，我懂。下面这四点，希望能帮你稍微稳一点。
首先，要改需求，一定得让相关干部明确点头。需求变更本身就容易引起混乱，所以必须事先确认。最好是有公司领导或者需求方的主管直接确认，退一步，至少也得找到需求经理来点头。因为变更往往意味着上线时间可能要推迟，或者程序员要加班，严格来说，产品经理自己是没有权利做这个决定的。你只有拿到授权，才能往下走。
第二，严格按照公司的需求变更规范来走。变更这件事，每个公司都不可能让它完全失控，所以一定会有一些成文或不成文的规矩。这些规矩未必每条都完美，但它们一定是团队在实际工作中磨出来的最稳妥的方案。你不按规范走，先不说责任划分，最容易出现的问题就是漏人——比如开发团队通知了，测试团队却没通知到，或者某个端的程序员被漏掉了。这种疏漏往往比需求本身更让人头疼。
第三，只要不是十万火急，尽量先把 PRD 改了，把变更落到文档里。你在更新文档的时候，会更容易进入一种系统性的思考，什么地方互相牵扯，什么地方可能被连带影响，会比口头沟通更容易发现那些容易遗漏的角落。而且，万一后续有争议，这份更新过的文档就是你的底牌，能实实在在地保护你。
第四，所有变更，都尽量亲自去跟每一个程序员当面讲清楚。改需求的时候因为怕被怼，不想直接面对程序员，这种心情完全可以理解。但即便你已经严格按照公司流程走了一遍，用文档把变更内容写得清清楚楚，在真正落地的过程中还是有可能出问题——因为需求变更本身就很容易造成混乱。这时候，产品经理是那个最了解需求全景的人，也是最清楚每个程序员当前负责哪一块的人。你必须亲自去跟每个人解释情况，回答他们的疑问，只有这样，才能把出错的概率降到最低。
最后我们回过头来看“产品经理总是改需求”这句话。虽然主语是产品经理，但这从来都不是产品经理一个人的事。它本质上是一个系统问题，是协作机制里自带的一种张力，是团队里每个人共同作用的结果。我们作为初级产品经理，很难去解决这个问题本身。
在做产品规划的时候，我们首先要做的，是明确需求的范围。同样，在工作的时候，我们也需要明确自己的职责和能力的边界。别把什么都往自己身上揽，而是找到那些自己可以控制的部分，然后把可控的部分做好。
我是 Minami，一个在普通小厂做了四年的产品人。惭愧地说，我没进过大厂，一直在各种不知名的普通公司里摸爬滚打。也正因为这样，我发现很多大厂里行得通的产品经验，在自己所在的环境里其实很难直接套用。所以我想分享一些来自普通工厂的教训和视角，给同样是新人的朋友一点参考。我不是什么产品大牛，只是一个普通的产品人，日常的一些思考和总结，如果对你有帮助，我会很荣幸。如果哪里说得不对，也欢迎你留言告诉我。