导致改需求的原因有很多，第一条就是产品经理策划时考虑不周全，所以笔者提出了两点建议，并进一步分享了如果实在要改需求的话怎么处理？

01

“产品经理总是改需求”，是“产品经理”最出圈的刻板印象之一。

这个印象，或者说这句牢骚，显然最开始是出自于程序员圈子。

因此，“需求”这个概念，就可以简单地理解为“产品经理要求技术团队开发的任务”。

那么，“改需求”，就是“变更任务要求”。

根据我的经验，程序员抱怨“改需求”，一般会是下面的这2种情况：

1. 在一个开发周期内，产品经理已经将开发任务安排下去，项目已经进入开发阶段了，这时产品经理要改需求。
2. 项目上线运行没多久，产品经理要求在下一个开发周期对这个项目进行修改。

其中，容易引起程序员不满的是第1种情况。一般说“产品经理改需求”的，大多也是指的第1种情况。

02

导致改需求的原因有很多，而首当其冲的就是，产品经理策划时考虑不周全。比如，模块前后矛盾，某个对象状态缺失，交互设计不合理，等等。

对于刚入行的朋友，我建议你要把关注的重点放在这个上面。

一个产品经理，如果交付的PRD始终错漏百出，那他肯定是走不长远的。

至于其他原因，比如领导改变主意、合作方有新要求、市场环境变化，等等，大多不是产品经理所能控制的。这里就先不讨论了。

策划时如何考虑周全，是一个非常复杂的问题，三言两语说不明白。这只能自己慢慢摸索，并不存在一步登天的捷径。

这里，根据我的经验，分享2点建议。这些是我认为比较重要，但网上却少有人提及的。

1. 通盘考虑项目在不同平台上的实现形态，尤其要关注各个平台自身的特殊情况和特殊要求

公司产品，一般会有PC端、触屏端、安卓端APP、iOS端APP，有时还会有微信小程序。其中，触屏端，还需要特别区分“微信框架下”和“非微信框架下”。

比如我们要做一个专题，这个专题将会放在触屏端和APP端。那这个专题的“分享”功能需要怎么策划呢？

首先，APP的分享模块，一般是原生的。形式大概是底部弹窗，在弹窗内选择“微信好友”、“微信朋友圈”、“QQ好友”、“QQ空间”等方式。出于成本考虑，安卓端和iOS端，会采用一样的设计，不用分开讨论。

然后，再看微信框架下的触屏端。因为我们无法调起微信的分享模块，所以形式上就不能是底部弹窗，而是需要做一个遮罩层，提示用户自行操作分享。

最后，我们来看非微信框架下的触屏端。这个就非常复杂了。因为你无法确定，用户到底会用什么浏览器去访问。所有浏览器都分别进行适配，又非常麻烦。这种时候，出于成本考虑，就要想，是不是可以把非微信框架下的分享模块给隐藏掉。

类似的，我们在策划的时候，需要通盘考虑不同平台的情况，分别进行应对。

如果你的公司同时有多条产品线，或者和其他公司有商务合作，那就更复杂了，要根据公司业务情况综合考虑。

2.确保自己已经正确掌握产品当前的真实状态，尤其要注意以前做过的特殊处理

时不时会有这样的新闻，一个小小的突发事故，就给某公司的软件系统造成巨大的伤害。然后大家突然发现，这家公司外表光鲜亮丽，然而内部极其混乱，系统里不知埋了多少坑。

其实，这种情况并不鲜见。尤其是在各种普通小厂，几乎是一种常态，只是暂时还没暴雷而已。

因此，具体到产品策划，你不能理所当然地认为，公司的产品有在正常有序地运转着。反而是，很有可能在你不知道的地方，产品已经出问题了。

• 比如，某个功能，上线的时候好好的，后面不知道哪次更新，就给覆盖掉了，没人知道。
• 比如，某次开发，为了赶工期，只上线了部分内容，剩余部分计划以后再改，但是至今一直没有搞。
• 比如，开发某个模块时，把另一个模块给搞坏了，然后进行了紧急修复。至于是怎么修复，没留下文档。
• 比如，原来负责的程序员离职了，接手的人看不懂上一任的代码，改着改着就面目全非了。

如果你不是在知名大厂，那么这些情况，基本都是日常。

所以，策划时，就需要自己先实际去跑一遍产品相关模块，确保自己已经正确掌握产品当前的真实状态。无法直接在前端页面确认的，需要找到相应的程序员，通过查代码来确认。

只有前提条件对了，后面的推演才有可能是对的。

03

一旦程序员开工了，再让他修改，都可能把他惹恼。

所以，很多产品新人，在对接技术的时候，总是战战兢兢的，生怕哪句话说得不是，就把人家给惹恼了。

其实，大可不必如此。

改需求，是一件很频繁的事情。也就是说，是产品和技术工作中的日常。就这么一项日常的工作，每次都要发火、怼人、吵架，你觉得可能吗？如果真是如此，公司早就倒闭了，员工早就因打架斗殴而实现“财务自由”了。

实际工作日常，并没有段子那么有戏剧性。

比如说，曾有一次，我要求新增一个移动端的页面。这个页面有2种状态（假定用“A”和“B”来表示）。当用户访问时，A账号显示A状态，B账号显示B状态。

然后，我要求，当用户点击“返回”时，要回到他进入时候的页面。从首页进的要回到首页，从会员中心进的要回会员中心。这个很好理解，也没什么不合理的。

但是，在具体实现时，却出现了问题。

接手的程序员不是做一个有“A、B”2个状态的页面。而是做了2个页面，A页面对应A状态，B页面对应B状态。用户访问时，默认进入A页面。如果是B账号访问的，那就在进入A页面的瞬间，自动跳转到B页面。

这样看起来也是能满足要求的。

但是，我在验收的时候发现，当B账号用户要从B页面返回时，因为他是从A页面来的，所以按照我定的要求，会跳回A页面。可他刚进入A页面，A页面就会启动判断机制，自动又给跳回到B页面去了。

那么，从用户的角度来看，就是，点了“返回”之后，一直在B页面转圈，回不去了。

这可怎么办呢？

页面做都做了，没办法。我只能修改要求，改成把返回路径写死，统一跳转到会员中心。

以上这样的例子，其实才是日常工作中的常态。

没有段子里面写的那种剧烈冲突，也没必要去追究是谁的错。大家都是为了完成项目，出现问题互相协商解决，仅此而已。

所以，当你要进行需求变更时，不需要有太大的心理负担。

而且，技术团队普遍开发任务重。所以，能否准确快速地了解需求变更的内容，才是程序员真正关心的事情。

04

作为产品新人，很可能你的第一件工作，就是“改需求”。

你刚入行，还没法独立地去做一个需求。这时候一般会把其他产品同事手上的项目，分给你跟进，算是练练手，熟悉一下工作流程。

这个项目，不会太复杂。但是，也不至于简单到可以放着不管。

你在跟进过程中，大概率上还是会遇到一些问题的。而你人生的第一次“改需求”，很可能就发生在这个时候。

还没学会怎么“提需求”，就要去“改需求”了，你肯定会感到措手不及。

这里，我总结了4个要点，希望能给产品新人提供一些帮助。

1. 等到相关干系人明确说出“要改需求”，才可以行动

需求变更，是一件非常容易造成混乱的事情，所以必须要事先确认清楚。最好能得到公司领导，或者需求部门主管的确认。再不济，至少得找需求经办人确认。

同时，需求变更，意味上线时间可能推后，或者程序员需要加班赶工。严格来说，产品经理并没有做出这种决定的权利。只有领导确认了，你才得到了授权，才可以行动。

2. 严格按照公司的需求变更规范去做

需求变更是一件经常发生的事情，任何公司都不可能一直让它处于失控的状态。

所以，每个公司，多少都会对需求变更有一些规范要求，有些是明文规定，有些是约定俗成。

这些规范，不一定完全合理，但肯定是公司团队在实际工作中提炼出来的最优解。

如果不按公司的规范流程来，责任的问题就先不谈了，你很可能会出现重大的疏漏。

最常见的，就是没有通知到所有需要通知的人。比如有个程序员没通知到。或者开发团队都通知到了，但把测试团队给漏了。

3. 尽量先改PRD，把变更落实到文档中

除非特别紧急，否则，每次改需求，要尽量先改PRD。产品文档更新后，再连同变更的需求发给相应同事。

要知道，项目的各个模块，往往是互相关联的。改动一个地方，很可能会影响到其他地方。在变更需求的时候，是很容易出现遗漏的。

而当你去更新PRD时，会比较容易进入策划时候的思路，比较容易发现那些被遗漏的地方。

另一方面，如果后续出现争议了，这个修改好的正确的文档，还能保障你的生命安全。

4. 所有的变更，要亲自和每个程序员说明清楚

改需求的时候，因为害怕被怼，不想直接面对程序员，这点不是不能理解。

但是，哪怕你严格按照公司的规范流程、准确全面地表达变更内容，在需求变更的过程中，还是很有可能出问题的。因为需求变更，本身就是一件非常容易造成混乱的事情。

而作为产品经理，这个时候，你是最了解需求的人，同时也是对当前每个程序员的开发情况了解最全面的人。所以，你必须亲自去跟每个程序员当面说明情况，并解答他们的疑惑。

只有这样，才能最大限度地避免出错。

05

最后，我们再回过头来，重新看看“产品经理总是改需求”这件事。

虽然主语是“产品经理”，但这并不是产品经理一个人的事情。

它本质上是一个系统性的问题，是协作机制内在缺陷导致的，是团队中所有人共同作用的结果。并不是我们这些初级产品经理有能力解决的。

我们在进行产品策划时，首先要做的就是明确需求的范围。

同理，我们在工作时，也需要去明确自己的工作职责和工作范围。不是把全部事情一股脑都揽在自己身上，而是应该去寻找自己能控制的局部，去优化可控的部分。

后记

大家好，我是Minami，一个普通小厂的4年产品人。

说来惭愧，我没进过大厂，只能混迹在各种不知名的普通小厂。也正因如此，我发现，前辈们分享的一些优秀产品经验，离开了大厂理想的环境之后，其实非常难应用到自己的日常工作中。

所以我想分享一些来自普通小厂的经验教训，给刚入行的朋友提供一个不一样的视角。

我不是产品大牛，只是作为一个普通产品人，分享一些日常的思考总结。如果能帮到你，非常荣幸。如果哪些说得不对，欢迎你留言赐教。

作者：简明产品论；简明产品论（ID：JianMingPM）

本文由 @简明产品论 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。