在工作中，总是会出现一些两人之间会出现分歧的情况，产品经理与程序猿之间也不例外，那分歧点都有哪些场景呢？可以看看下面的文章了解哦！
做产品也有些年头了，在工作中也时常会遇到和程序猿沟通需求而产生分歧；那这些分歧有一些是可以调和的，而有一些是真的需要各自调整心态后重新讨论的。可以总结为以下几种场景：
和程序猿同事评审需求前，是需要先简单介绍场景的。
就像是一个故事，你是需要用简单易懂的语言，给大家去简述这个需求的背景、发展和之后的一些蓝图规划的。也可以说是对需求的一个全局观了解，否则在评审中途，你会有被无数次打断的可能！
比如医疗行业，在开场前去铺垫一些故事场景，医学知识，可能会对之后架构、库表关系的建设上有一定的帮助。
给程序猿呈现需求的业务、功能流程，他们能在细微的流程变化中帮助产品发现漏洞。比如我之前做的一个项目中，就一个挂号预约流程，资深的程序猿总是能在细微的变化中，问你一些异常情况的处理方案。
如：患者预约挂号流程
（1）第一步：校验是否已经绑就诊人。
（2）如果就诊人未绑，添加就诊人信息时需要校验是否已经被其他用户绑定，如果已绑定，需要处理解绑后再绑定的新的用户下（这一步骤的校验，可根据实际情况来添加）。
（3）校验该用户绑定就诊人是否已超过个数限制，如果已经超过，需要给予对应提示。
（4）否则提交成功后才可以真正进入挂号预约流程。
这个流程中的第二步校验，就是评审过程中他们所提出来的，足以看出他们对整个流程的严谨！
其实这一点，是需要大家真正去明确的，所有的需求功能点在规划初期可能会全部列举出来，但是在本次评审的范围内，一定需要划分出功能边界范围。否则很容易让程序猿们和测试同事产生混乱和误解。
一般会用两种方式，一种是直接在PRD中标注本次版本范围并标注出优先级，另外一种则是拆分本次版本内容，单独提供出PRD，这两种方式各有优缺点，主要还是看团队以往的协作风格和沟通方式！
（1）页面交互需求评审时的谈论
这点分歧，大多存在于C端产品的评审环节中；评审一般大多是和大家来宣讲某一版本的流程、实现范围和涵盖的大致内容，而页面交互，产品经理在评审会议中会酌情提到，但是并不会就每个元素的交互都来讲一遍，只会过大的功能流程交互点。
所以页面交互一直建议是大点弹框讲到，PRD写清楚，再过细碎的就实现过程中沟通讨论，可能对评审效率的提升有很大帮助。
（2）无关痛痒的需求文案分歧
文案的提示分歧，其实在产品评审过程中经常会有，毕竟仁者见仁智者见智，可是像这种放在评审会上讨论，很容易让人产生一种无力感。文案没有好坏之分，只有场景合适性的考量。
它体现不出程序猿的逻辑推理能力，也体现不出一个产品人的用户思维。所以只要是恰当的文案，就讨论一分钟划走即可，没必要花太大力气在评审会上专门讨论。
比如：当用户想要删除自己已经取消的历史订单时:
（3）需求实现难易程度的分歧
需求实现难易程度，我觉得这个可以放在技术方案讨论会上说，如果放在需求评审会上，不太恰当。毕竟需求评审会，大多时候是需求诉求的阐述和想要实现的方案。而实现方案，短时间内会上讨论只会显得有些仓促，通过充分调研给予合理的方案的建议才是解决事情的王道。
需求优先级的问题大多出现在多项目并行的情况下，而出现这种问题时，穿插于多项目中的程序猿，就会有一些迷茫和排斥。遇到这种分歧，大多情况可提出现状和困难点，由产品经理（兼项目经理）OR项目经理协调，明确优先级和排期冲突时间的调整，以便后续工作的正常开展。而遇到真正不能解决的，可能就需要上升到更高的管理层去协调沟通解决。
当一个公司业务量上升期，需求与产品规划都比较紧张，繁杂。所以需求池的管理，需求分析、排期都是需要相关人员知晓和合理安排的。
之前在实现阶段还遇到过实现工期的分歧问题，很多时候一个大项目的时间节点，都是建立在可预期和充足人员支撑的情况下。
一个项目预期上线时间和技术评估时间的问题，大致分两类：
比如：
不影响主流程的bug，一般都需要在版本节点范围内解决处理，而对于一些未考虑的细节优化点，非主流程的漏洞点完全可以记录下来，在下一个版本中快速迭代处理。最忌讳的是在开发中途修改主流程需求和增加新的功能点，战线太长不说，还会影响整体的项目进度和人员情绪。
以上就是自己工作中一些小小的总结，欢迎大家指正和补充！
专栏作家
木北的产品成长路，微信公众号：木北的产品成长路，人人都是产品经理专栏作家，互联网产品经理，曾担任医药产品经理和电商产品经理，经历主导过电商平台的系统整合规划。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。