如何看待“产品经理总是改需求”这件事？

改变需求的原因有很多。第一个原因是产品经理在计划时没有仔细考虑，所以作者提出了两个建议，并进一步分享如何处理需求？ 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） 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。如有侵权行为，请联系网站管理员删除，。