专业的短链接生成工具
链接域名
短网址有效期
如何看待“产品经理总是改需求”这件事？
更新时间：2025-6-1 11:55:07 作者：爱短链
改变需求的原因有很多。
第一个原因是产品经理在计划时没有仔细考虑，所以作者提出了两个建议，并进一步分享如何处理需求？ 01 产品经理总是改变需求是产品经理最刻板的印象之一。
这种印象，或者这种抱怨，显然是从程序员圈开始的。
因此，需求的概念可以简单地理解为产品经理需要技术团队开发的任务。
所以，改变需求就是改变任务要求。
根据我的经验，程序员抱怨改变需求： 在开发周期内，产品经理已经安排了开发任务，项目已经进入开发阶段，产品经理需要改变需求。
项目启动后不久，产品经理要求在下一个开发周期修改项目。
其中，第一种情况容易引起程序员的不满。
一般来说，产品经理改变需求大多是指第一种情况。
02 改变需求的原因有很多，首先要考虑的是产品经理在计划时没有仔细考虑。
例如，模块前后矛盾、缺乏对象状态、交互设计不合理等。
对于刚进入这个行业的朋友，我建议你关注这个。
产品经理，如果交付PRD总是错漏百出，那他肯定走不了多久。
至于其他原因，如领导改变主意、合作伙伴有新要求、市场环境变化等，大部分都无法由产品经理控制。
这里就不讨论了。
如何仔细考虑计划是一个非常复杂的问题，几句话都不懂。
这只能自己慢慢探索，没有一步一步的捷径。
在这里，根据我的经验，分享两个建议。
我觉得这些更重要，但是网上很少提到。
1. 综合考虑不同平台上项目的实现形式，特别注意各平台的特殊情况和要求 一般有公司产品PC端、触屏端、安卓端APP、iOS端APP，有时会有微信小程序。
其中，触摸屏端还需要区分微信框架和非微信框架。
比如我们要做一个专题，会放在触屏端和触屏端APP端。
那么如何规划这个话题的共享功能呢？ 首先，APP共享模块通常是本地的。
形式可能是底部弹出窗口。
选择微信好友、微信朋友圈、弹出窗口QQ好友”、“QQ空间等。
安卓端和iOS端，将采用相同的设计，不需要单独讨论。
然后，看看微信框架下的触摸屏端。
因为我们不能调动微信的共享模块，所以形式不能是底部弹出窗口，而是需要做一个屏蔽层来提示用户操作和共享。
最后，让我们来看看非微信框架下的触摸屏端。
这是非常复杂的。
因为定用户会访问什么浏览器。
所有浏览器分别适应，非常麻烦。
此时，出于成本考虑，我们应该考虑是否可以隐藏非微信框架下的共享模块。
同样，我们在策划的时候，需要考虑不同平台的情况，分别处理。
如果你的公司同时有多条产品线，或者与其他公司有业务合作，那就更复杂了。
2.确保您正确掌握了产品的真实状态，特别注意以前的特殊处理 不时有这样的消息，一个小小的紧急情况，会对公司的软件系统造成巨大的伤害。
然后我们突然发现公司外观明亮，但内部非常混乱，我不知道系统埋了多少坑。
事实上，这种情况并不少见。
特别是在各种普通的小工厂，几乎是正常的，但暂时没有雷声。
因此，说到产品规划，你不能理所当然地认为公司的产品正常有序运行。
相反，在你不知道的地方，产品很可能有问题。
比如某个功能上线的时候很好，后面不知道哪个更新就覆盖了，没人知道。
例如，个开发，为了赶工期，只上线了一些内容，剩下的计划以后再改，到目前为止还没有做。
例如，在开发一个模块时，会损坏另一个模块，然后进行紧急修复。
至于如何修复，没有文档。
比如原来负责的程序员离职了，接手的人看不懂上一个代码，改变了面目全非。
假如你不在知名大厂，那么这些情况，基本上都是日常的。
因此，在规划时，您需要首先运行与产品相关的模块，以确保您正确掌握产品的当前真实状态。
如果您不能直接在前端页面上确认，您需要找到相应的程序员并通过查看代码来确认。
只有前提条件正确，后面的演绎才有可能正确。
03 一旦程序员开始工作，让他修改，可能会惹恼他。
因此，许多新产品，在对接技术时，总是战战兢兢，怕哪句话说不出来，就惹恼别人。
其实没必要。
改变需求是一件非常频繁的事情。
换句话说，这是产品和技术工作的日常生活。
你认为每次你都有可能生气、讨厌别人和争吵吗？如果是这样，公司早就倒闭了，员工早就因为打架而实现了财务自由。
日常工作的实际工作并没有笑话那么戏剧性。
例如，有一次，我要求添加一个移动页面。
这个页面有两种状态(假设使用A”和“B说)。
用户访问时，A账号显示A状态，B账号显示B状态。
然后，我要求当用户点击返回时，返回到他进入的页面。
从主页到主页，从会员中心到会员中心。
这很容易理解，也没有什么不合理的。
但在具体实现中，却出现了问题。
接手的程序员不是一个有A、B两个状态页面。
而是做了两页，A页面对应A状态，B页面对应B状态。
用户访问时，默认进入A页面。
如果是B账号访问，则在进入A页面时自动跳转到B页面。
这看起来也能满足要求。
然而，当我接受它时，我发现当B账户用户想从B页面返回时，因为他来自A页面，他会根据我的要求跳回A页面。
但他刚刚进入了A页面，A页面将启动判断机制，并自动跳回B页面。
所以，从用户的角度来看，点击返回后，一直在B页面圈，无法返回。
怎么办？ 页面已经完成，没有办法。
我只能修改要求，写下返回路径，跳转到会员中心。
这样的例子，其实是日常工作中的常态。
没有笑话中写的剧烈冲突，也没有必要调查谁错了。
每个人都是为了完成项目，问题互相协商解决，仅此而已。
因此，当你想要改变需求时，你不需要有太多的心理负担。
而且，技术团队普遍发展任务繁重。
因此，程序员真正关心的是能否准确快速地理解需求变化的内容。
04 作为一个新，你的第一份工作很可能是改变需求。
当你刚进入这个行业时，你不能独立做一个需求。
此时，其他产品同事手中的项目通常会分配给您跟进。
这是一种练习，熟悉工作流程。
这个项目不会太复杂。
然而，它并不简单到可以放置。
在跟进的过程中，你很可能会遇到一些问题。
而你人生中的第一次改变需求很可能发生在这个时候。
还没学会如何提需求，就要改需求，你肯定会措手不及。
在这里，我总结了四点，希望能给新产品提供一些帮助。
1. 直到相关干部明确表示需要改变 需求变化是一件很容易造成混乱的事情，所以必须事先确认。
最好得到公司领导或需求部主管的确认。
不管有多糟糕，至少你必须找到需求经理来确认。
同时，需求变化意味着在线时间可能会推迟，或者程序员需要加班。
严格地说，产品经理没有权利做出这样的决定。
只有当领导确认时，你才能被授权并采取行动。
2. 严格按照公司需求变更规范执行 需求变化是一件经常发生的事情，任何公司都不可能一直失控。
因此，每个公司对需求变更都有一些规范要求，有的明确规定，有的俗成。
这些规范不一定完全合理，但必须是公司团队在实际工作中提取的最佳解决方案。
如果不遵循公司的规范流程，就不要先谈责任，很可能会有重大疏漏。
最常见的是没有通知所有需要通知的人。
例如，程序员没有通知它。
或者开发团队已经通知了它，但测试团队已经错过了它。
3. 尽量先改PRD，将变更落实到文档中 除非特别紧急，否则每次都要尽量先改变需求。
PRD。
产品文档更新后，根据变更的需要发送给相应的同事。
你知道，项目的每个模块通常都是相互关联的。
改变一个地方可能会影响其他地方。
在改变需求时，很容易遗漏。
当你去更新的时候PRD在规划的时候，更容易进入思路，更容易那些被遗漏的地方。
另一方面，如果后续有争议，修改后的正确文件也可以保证你的生命安全。
4. 所有的变化都应该亲自向每个程序员解释 在改变需求时，因为害怕被批评，不想直接面对程序员，这并非不可理解。
然而，即使您严格按照公司的标准流程，准确、全面地表达变更内容，也很可能在需求变更过程中出现问题。
因为需求变化本身就很容易造成混乱。
作为一名产品经理，在这个时候，你是最了解需求的人，也是最全面地了解每个程序员当前发展的人。
因此，你必须亲自向每个程序员解释情况，并回答他们的疑问。
只有这样，才能最大限度地避免出错。
05 最后，让我们回顾一下产品经理总是改变需求。
虽然主语是产品经理，但这不是产品经理一个人的事。
它本质上是一个系统的问题，是由合作机制的内部缺陷引起的，是团队中每个人共同作用的结果。
我们的初级产品经理无法解决这个问题。
在规划产品时，首先要做的就是明确需求的范围。
同样，当我们工作时，我们也需要明确我们的工作职责和范围。
我们不应该把一切都放在自己身上，而应该找到我们可以控制的部分，优化可控的部分。
后记 大家好，我是Minami，一家普通小厂的4年产品人。
羞愧地说，我没有进入大工厂，只能混合在各种未知的普通工厂。
因此，我发现，在离开了大工厂的理想环境后，一些优秀的产品经验实际上很难应用到我的日常工作中。
所以我想分享一些来自普通工厂的经验教训，为新朋友提供不同的视角。
我不是产品牛，只是作为一个普通的产品人，分享一些日常的思考和总结。
我很荣幸能帮助你。
如果你说错了什么，请留言。
作者:简明产品论；简明产品论；（ID：JianMingPM） 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
第一个原因是产品经理在计划时没有仔细考虑，所以作者提出了两个建议，并进一步分享如何处理需求？ 01 产品经理总是改变需求是产品经理最刻板的印象之一。
这种印象，或者这种抱怨，显然是从程序员圈开始的。
因此，需求的概念可以简单地理解为产品经理需要技术团队开发的任务。
所以，改变需求就是改变任务要求。
根据我的经验，程序员抱怨改变需求： 在开发周期内，产品经理已经安排了开发任务，项目已经进入开发阶段，产品经理需要改变需求。
项目启动后不久，产品经理要求在下一个开发周期修改项目。
其中，第一种情况容易引起程序员的不满。
一般来说，产品经理改变需求大多是指第一种情况。
02 改变需求的原因有很多，首先要考虑的是产品经理在计划时没有仔细考虑。
例如，模块前后矛盾、缺乏对象状态、交互设计不合理等。
对于刚进入这个行业的朋友，我建议你关注这个。
产品经理，如果交付PRD总是错漏百出，那他肯定走不了多久。
至于其他原因，如领导改变主意、合作伙伴有新要求、市场环境变化等，大部分都无法由产品经理控制。
这里就不讨论了。
如何仔细考虑计划是一个非常复杂的问题，几句话都不懂。
这只能自己慢慢探索，没有一步一步的捷径。
在这里，根据我的经验，分享两个建议。
我觉得这些更重要，但是网上很少提到。
1. 综合考虑不同平台上项目的实现形式，特别注意各平台的特殊情况和要求 一般有公司产品PC端、触屏端、安卓端APP、iOS端APP，有时会有微信小程序。
其中，触摸屏端还需要区分微信框架和非微信框架。
比如我们要做一个专题，会放在触屏端和触屏端APP端。
那么如何规划这个话题的共享功能呢？ 首先，APP共享模块通常是本地的。
形式可能是底部弹出窗口。
选择微信好友、微信朋友圈、弹出窗口QQ好友”、“QQ空间等。
安卓端和iOS端，将采用相同的设计，不需要单独讨论。
然后，看看微信框架下的触摸屏端。
因为我们不能调动微信的共享模块，所以形式不能是底部弹出窗口，而是需要做一个屏蔽层来提示用户操作和共享。
最后，让我们来看看非微信框架下的触摸屏端。
这是非常复杂的。
因为定用户会访问什么浏览器。
所有浏览器分别适应，非常麻烦。
此时，出于成本考虑，我们应该考虑是否可以隐藏非微信框架下的共享模块。
同样，我们在策划的时候，需要考虑不同平台的情况，分别处理。
如果你的公司同时有多条产品线，或者与其他公司有业务合作，那就更复杂了。
2.确保您正确掌握了产品的真实状态，特别注意以前的特殊处理 不时有这样的消息，一个小小的紧急情况，会对公司的软件系统造成巨大的伤害。
然后我们突然发现公司外观明亮，但内部非常混乱，我不知道系统埋了多少坑。
事实上，这种情况并不少见。
特别是在各种普通的小工厂，几乎是正常的，但暂时没有雷声。
因此，说到产品规划，你不能理所当然地认为公司的产品正常有序运行。
相反，在你不知道的地方，产品很可能有问题。
比如某个功能上线的时候很好，后面不知道哪个更新就覆盖了，没人知道。
例如，个开发，为了赶工期，只上线了一些内容，剩下的计划以后再改，到目前为止还没有做。
例如，在开发一个模块时，会损坏另一个模块，然后进行紧急修复。
至于如何修复，没有文档。
比如原来负责的程序员离职了，接手的人看不懂上一个代码，改变了面目全非。
假如你不在知名大厂，那么这些情况，基本上都是日常的。
因此，在规划时，您需要首先运行与产品相关的模块，以确保您正确掌握产品的当前真实状态。
如果您不能直接在前端页面上确认，您需要找到相应的程序员并通过查看代码来确认。
只有前提条件正确，后面的演绎才有可能正确。
03 一旦程序员开始工作，让他修改，可能会惹恼他。
因此，许多新产品，在对接技术时，总是战战兢兢，怕哪句话说不出来，就惹恼别人。
其实没必要。
改变需求是一件非常频繁的事情。
换句话说，这是产品和技术工作的日常生活。
你认为每次你都有可能生气、讨厌别人和争吵吗？如果是这样，公司早就倒闭了，员工早就因为打架而实现了财务自由。
日常工作的实际工作并没有笑话那么戏剧性。
例如，有一次，我要求添加一个移动页面。
这个页面有两种状态(假设使用A”和“B说)。
用户访问时，A账号显示A状态，B账号显示B状态。
然后，我要求当用户点击返回时，返回到他进入的页面。
从主页到主页，从会员中心到会员中心。
这很容易理解，也没有什么不合理的。
但在具体实现中，却出现了问题。
接手的程序员不是一个有A、B两个状态页面。
而是做了两页，A页面对应A状态，B页面对应B状态。
用户访问时，默认进入A页面。
如果是B账号访问，则在进入A页面时自动跳转到B页面。
这看起来也能满足要求。
然而，当我接受它时，我发现当B账户用户想从B页面返回时，因为他来自A页面，他会根据我的要求跳回A页面。
但他刚刚进入了A页面，A页面将启动判断机制，并自动跳回B页面。
所以，从用户的角度来看，点击返回后，一直在B页面圈，无法返回。
怎么办？ 页面已经完成，没有办法。
我只能修改要求，写下返回路径，跳转到会员中心。
这样的例子，其实是日常工作中的常态。
没有笑话中写的剧烈冲突，也没有必要调查谁错了。
每个人都是为了完成项目，问题互相协商解决，仅此而已。
因此，当你想要改变需求时，你不需要有太多的心理负担。
而且，技术团队普遍发展任务繁重。
因此，程序员真正关心的是能否准确快速地理解需求变化的内容。
04 作为一个新，你的第一份工作很可能是改变需求。
当你刚进入这个行业时，你不能独立做一个需求。
此时，其他产品同事手中的项目通常会分配给您跟进。
这是一种练习，熟悉工作流程。
这个项目不会太复杂。
然而，它并不简单到可以放置。
在跟进的过程中，你很可能会遇到一些问题。
而你人生中的第一次改变需求很可能发生在这个时候。
还没学会如何提需求，就要改需求，你肯定会措手不及。
在这里，我总结了四点，希望能给新产品提供一些帮助。
1. 直到相关干部明确表示需要改变 需求变化是一件很容易造成混乱的事情，所以必须事先确认。
最好得到公司领导或需求部主管的确认。
不管有多糟糕，至少你必须找到需求经理来确认。
同时，需求变化意味着在线时间可能会推迟，或者程序员需要加班。
严格地说，产品经理没有权利做出这样的决定。
只有当领导确认时，你才能被授权并采取行动。
2. 严格按照公司需求变更规范执行 需求变化是一件经常发生的事情，任何公司都不可能一直失控。
因此，每个公司对需求变更都有一些规范要求，有的明确规定，有的俗成。
这些规范不一定完全合理，但必须是公司团队在实际工作中提取的最佳解决方案。
如果不遵循公司的规范流程，就不要先谈责任，很可能会有重大疏漏。
最常见的是没有通知所有需要通知的人。
例如，程序员没有通知它。
或者开发团队已经通知了它，但测试团队已经错过了它。
3. 尽量先改PRD，将变更落实到文档中 除非特别紧急，否则每次都要尽量先改变需求。
PRD。
产品文档更新后，根据变更的需要发送给相应的同事。
你知道，项目的每个模块通常都是相互关联的。
改变一个地方可能会影响其他地方。
在改变需求时，很容易遗漏。
当你去更新的时候PRD在规划的时候，更容易进入思路，更容易那些被遗漏的地方。
另一方面，如果后续有争议，修改后的正确文件也可以保证你的生命安全。
4. 所有的变化都应该亲自向每个程序员解释 在改变需求时，因为害怕被批评，不想直接面对程序员，这并非不可理解。
然而，即使您严格按照公司的标准流程，准确、全面地表达变更内容，也很可能在需求变更过程中出现问题。
因为需求变化本身就很容易造成混乱。
作为一名产品经理，在这个时候，你是最了解需求的人，也是最全面地了解每个程序员当前发展的人。
因此，你必须亲自向每个程序员解释情况，并回答他们的疑问。
只有这样，才能最大限度地避免出错。
05 最后，让我们回顾一下产品经理总是改变需求。
虽然主语是产品经理，但这不是产品经理一个人的事。
它本质上是一个系统的问题，是由合作机制的内部缺陷引起的，是团队中每个人共同作用的结果。
我们的初级产品经理无法解决这个问题。
在规划产品时，首先要做的就是明确需求的范围。
同样，当我们工作时，我们也需要明确我们的工作职责和范围。
我们不应该把一切都放在自己身上，而应该找到我们可以控制的部分，优化可控的部分。
后记 大家好，我是Minami，一家普通小厂的4年产品人。
羞愧地说，我没有进入大工厂，只能混合在各种未知的普通工厂。
因此，我发现，在离开了大工厂的理想环境后，一些优秀的产品经验实际上很难应用到我的日常工作中。
所以我想分享一些来自普通工厂的经验教训，为新朋友提供不同的视角。
我不是产品牛，只是作为一个普通的产品人，分享一些日常的思考和总结。
我很荣幸能帮助你。
如果你说错了什么，请留言。
作者:简明产品论；简明产品论；（ID：JianMingPM） 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
