产品经理PM与技术开发人员RD之间常见矛盾有哪些具体表现？

产品经理PM和技术开发人员RD之间常见的矛盾有哪些，及一些解决方法简介。 一：需求频繁变更 在软件产品开发过程中，变更一些需求是无法避免的，但频繁的需求变更，不仅让开发团队疲于应对不断变化的需求，严重影响项目完成的进度，还会影响开发团队人员的士气。 在前面的文章中也讨论过一些需求频繁变更的情况和处理的简要方法。 下面进行需求频繁变更的原因详细分析。 需求管理混乱 产品经理对于需求的管理很混乱，没有一个统一的标准，集中管理需求的地方，比如用某一个软件或工具来建立需求池，并分门别类，重要程度等进行分类管理。 领导、老板想法变了 领导或老板的想法跳跃，早上看了一个 App 的功能觉得好，下午就让团队加上。或者老板直接干预细节：“这个按钮颜色我不喜欢，改一下”，加塞需求。 或者，它们突然想到了一个好的想法或功能，要求马上实现。 市场竞争环境变了 公司突然发现竞争对手的产品上线了一个杀手级功能，或者改变了补贴策略，我司必须立即跟进，否则会流失大量用户。 这种需求变更确实是紧急、优先级高的需求。 还有探索型的项目，需求频繁变更不可避免。需要不断的探索来加深对用户、对市场的认知。有一个认知循环，不断加深的过程。 这也是精益创业的一个过程。MVP -> 度量 -> 反馈，然后进行优化，然后循环。 用户反馈与数据验证 产品功能上线灰度测试后，发现数据惨淡，或者用户反馈极差。原来的假设被推翻，必须立即调整交互或逻辑。 这种基于数据或用户反馈的需求变更，是有必要的。 这种在创业公司初期 MVP 验证阶段用的很多，可能一个 APP 的方向要改很多次，才能找到合适的 PMF 。这种情况需求变更是无法避免的。 其实，这也是敏捷开发的初心。 PM 考虑需求场景不全 产品经理在编写需求文档的时候，只考虑了部分场景需求，没有考虑全所有场景的需求。或者只考虑了正常的流程，没有考虑全异常的流程。 当开发人员编写代码时候，可能会察觉需求文档描述需求不全。 等等这些都会导致需求变更。 业务或市场加需求 业务部门或市场部门时不时的加一些需求进来。 解决方法 用可视化排期看板，让相关方看到需求变更的影响 重要的需求变更，需要需求评审委员会评审，评审变更流程 建立需求变更影响评估机制（时间 / 风险 / 成本 / 需要牺牲的利益） 敏捷开发模式，比如 scrum ，kanban 等开发方法。 产品经理多思考一下反流程怎么办，出现异常怎么办。 所有需求要经过产品经理过滤和优化。 可以用 scrum，kanban，精益产品开发方法来解决。 二：需求模糊、不清晰 产品经理可能用抽象描述代替具体规则（如“用户体验要流畅”“按钮要显眼”），或未明确边界条件（如“支付失败时的提示语”）。例如： 需求文档仅写“支持批量导入数据”，但未说明文件格式、大小限制、错误校验规则； 需求描述不清晰，开发人员就需要反复追问细节，猜测产品经理的意图，最终实现效果可能与预期不符。 下面进行详细原因分析。 一句话需求或产品经理没想清楚 一句话需求，老板、业务部门等等相关部门或人员提的一句话需求，比如 “大概就是这个意思”，“先做出来看看”，“需要一个统计功能” 等话语。 老板或业务部门把这种一句话的模糊想法当成了开发人员能执行的开发需求。 从需求到开发，这中间有一些步骤和流程，再怎么省略中间步骤，也要经过产品经理把这样的一句话需求写出一个可供开发执行的开发需求。 用户需求（用户） -> 产品功能需求（产品经理） -> 可执行的开发需求（技术开发）。 对于一个需求，产品经理要考虑： 用户的本质问题是什么 - 分析本质问题 产品目标 - 要解决用户什么问题 实现方案 - 怎么解决 把用户说的方案或目标当成需求 最著名的一个例子就是福特造车的例子。在当时的时空环境下，问一个人更好的交通工具时是什么？用户会回答：更快的马车。用户为什么会这样回答？因为当时很多人没见过汽车，但是见过马车。 “更快的马车”，其实是一个方案。这不是一个需求，如果当成了需求，那么福特就会去造更快的马车而不会造福特汽车。 那用户的本质需求是什么？ 是从 A 地快速的移动到 B 地。是快速方便的到达目的地。马车只是其中一种交通工具，及是一种满足用户需求的方案。而汽车是一种创新的方案，更好的方案。 我们要仔细思考用户的本质需求是什么？而不光听用户说。 没有满足本质需求的好方案，可能会导致方案修改增多。 边界条件和异常情况未定义 产品经理只关注了主流程，对于一些异常情况或边界条件，未考虑到。 产品经理的思维要养成好习惯，要考虑正常的流程，同时也要考虑异常情况的流程。