在需求评审时，很多产品都是花80%的时间在讲解需求系列怎么实现，边界条件要注意什么。

直接讲需求点，这个是初级产品最常犯的错误

要让开发理解我们的思路，一定要在讲为什么要这么做，多花点时间和心思

为什么：经过用户调研/数据分析，发现：用户有xx需求/xx功能需要优化。

一句话阐述：希望在用户遇到xx场景时，产品能够提供xx功能，以满足用户xx的需求

每个人的成长背景、经历、个人认知都会导致思维差异的形成，尊重并接受这种差异性是有效沟通的前提。

技术思维的人物画像：
背景：理工科、计算机软件工程相关专业
思维：特点=逻辑+理性，遍历和穷举（非此即彼、0和1的博弈）
行为：果断，执行力，倾向于“如何实现”的选择

—————这中间是“认知鸿沟”———————

产品思维的人物画像：
背景：文科或理科，各种专业（计算机、设计、营销等等）
思维：特点=逻辑+（理性+感性）/2，基本遍历、难以穷举
行为：反复论证，倾向“体验”选择

与工程师沟通的三原则：重事实（现状、问题、方案）、讲逻辑（分支覆盖、遍历完整、冲突性）、确定性（工作量、周期、风险预估）。

正确的提需求，及讲解需求的顺序：背景（现状、问题、方案）、方案（如何做）、执行（何时做）。

最后不要迷信需求文档。

沟通问题，要么是自己没说清楚，要么是自己认为说清楚了但别人未理解。不管是哪种，本质上我觉得是没有站在开发的角度去沟通或者说表达。首先你要明白，开发的思维和产品的思维天然是有很大的差异的，他们想的更多的是可落地具体的的，比如，页面长什么样，要哪些字段，跳转到哪里等，你如果只告诉他我要做一个xx功能，那估计是朦的，或者理解就千差万别了。

“尤其是一些只可意会不可言传的思路上”我不知道别人怎么看，在我看来，就这个问题可能要从自身找原因，如果给开发讲的时候还在讲思路或者无法讲清楚，那我会认为自己是失败的。不排除这种情况会有，但是我们要做的是尽可能具化，不管是通过给参照，画草稿，甚至做动画效果，都要朝着能让大家理解一致的角度去努力。

  产品最本质的工作就是做为沟通的桥梁去承接需求方与开发方：

  需求方与产品沟通时产品的心态基本上就是产品与开发方沟通时开发的心态，产品试着理解需求并以自己理解的方式规划成流程图与需求原型；开发则是理解产品的需求然后用技术代码去实现需求；

  每个需求从产品传达到开发的时候双方都是在不同的角度去思考问题的，假设排除产品本身就是入门级的水平，在有原型完整的基础上进行评审开发还是一头雾水，那产品可以不用单纯的在自己的角度去找问题了，更核心的在于开发有没有用脑子在思考，或者说开发人员完全在自己建立的思维模型中走不出来，并且不接受他人建立的思维模型，这种情况下建议不要多费口舌，把情况和技术领导说明，由技术领导去说服；假设技术领导是这样的人，那建议趁早走人。

除非你的功能是个玄学，那么肯定有办法通过技术语言表达出来，技术要通过0和1把功能实现出来，就意味着不能存在模棱两可，就算有些功能确实是模棱两可的，但实际上他背后还是有清晰的规则，他可能是算法，可能是概率，就不能可能是随缘。

这也是产品和开发起矛盾最常见的原因，你觉的你讲清楚了，但还是让开发感到很多未知的东西，开发就会很不耐烦。我认为解决办法就是优化你的流程图和原型，流程图层级够不够分明，有没有形成闭环，多找找有没有小逻辑被一笔带过，这些都有可能酿成bug。然后找一个语言学一下机器语言的逻辑，起码知道if..else、循环什么的，知道在代码是怎么驱动机器做事的，然后在画流程图时，带入这个思维，这样的说明才更接近开发的阅读习惯。

当然也有一些开发是另一种情况，不喜欢看文档，需求评审也不认真，凭感觉开发，也很拖进度，喜欢早早动手，你不得不在他开发的过程中反复和他沟通需求。那就只能在开发前多cue他了，反复确认，找技术部门强调重要性。

要让开发理解产品的思路，首先产品要理解开发的思路；在和开发讲的时候，不要一位的谈你的设计理念，也要从技术的角度出发，讲解如何实现功能；比如业务的逻辑关系，每个元素的交互情况，每个字段的解释说明，异常情况的处理，极限条件的判断等等。。。最好穷举出所有的状态，并通过图表的形式展示出完整的链路。

当然，最核心的是，你得先让开发明白，为啥要做这个功能，什么场景下使用这个功能，这个功能的重要性和必要性，先引起开发的重视，否则都是白讲。

作为产品，我认为技术基础知识的了解在沟通中还是有一定帮助的。这就好比，如果你了解食材种类、常见菜色、厨具类型，你去要求厨师做道菜的时候沟通上也会清晰一些。

另外，开发人员的理解和表达能力也是关键。不得不说，虽然有些开发人员能力不错，但是就我的经历，一般开发的小组长或领导的表述能力就是比下级强。我觉得这也是有原因的。

综上，一方面自己要持续沟通，沟通中尝试不同的信息传达方式去试探适合于对方的沟通方式。另一方面，原型方案中使用更多形象的示意去说明吧。

看到只可意会不可言传的思路，就怪不得开发和你不在一个频道了，毕竟有1000个哈姆雷特对吧。

我认为产品和开发沟通不在一个频道，解决思路有2类，一个是调频，二是换人，下面细说
1，调频可以是你作为产品从技术开发的角度理解需求，把《产品需求说明书》写的尽量技术白话，类似判断条件、缺省值、枚举的内容等等，写直白一点，少去让开发理解你的意会，就可以减少沟通的盲点；要么是开发换个思路去用产品的思维考虑，提问，然后多做需求沟通研讨，开发一般还是有点兴趣去聊聊业务的，在需求评审之前先讲讲故事，讲讲业务逻辑，让他们有参与感，那思路也就能跟上你的想法了（ps，你的想法尽量少搞写天马行空的想象，避开和开发沟通的红线，不要说什么这个不是很简单啊、很好搞定啊、等等容易让程序猿暴怒的词汇）
2，换人是你可以找个高级的程序猿或者项目经理沟通，沟通好了以后，让他们和你处在一个频道，让他们去帮你拆分或者沟通，确保程序能理解到位。不要盯着一个和你不在一个频道的，那样很累。

项目背景（数据、业务情况、法律条文等；哪些方案因为触及什么问题而不能做）->
项目目标->
项目分解->
具体功能要怎么做（中间要说明白你为什么要这么做，这么做是为了解决那些问题）。

使用场景，流程，什么之类的我就不提了，可以帮助人快速理解开发的目的和意义。

推荐画时序图，可以帮助开发同学更好理解信息在不同角色和对象之间的传递。何时何种情况传递何种信息。

PS：sujie的《人人都是产品经理》现在基本啥也不记得了，就记着里面建议产品学一学UML画画图，个人感觉也是挺实用的建议和方法。

首先，要尽量避免一句话需求，要尽可能认真做好该做的事

其次，要有自己的理解，有简单设计和实现策略，做好功课

第三，要理解开发，同理心很重要，聆听，欣赏，接纳，真诚

最好，别拽名词，说通俗易懂的，简称，英文等尽量避免，说人话

从来就没有 只可意会不可言传 的东西。

所谓只可意会，本质是自己都没想清楚， 模模糊糊的影子在自己脑海里，自己还自信的认为这个道理真棒，不如花心思好好梳理，形成产品架构图 和 市场态势图， 给研发讲的时候，先讲这些。

然后落地的时候，研发会帮你把缺失的或者没想全的逻辑补全。

时刻记住：研发是队友， 不是对手。

团队的对手只有一个： 千变万化的市场

另外还想说，开发的日常是写代码，思考事物的方式、习惯是不同的。这一点产品如果能理解的话沟通上也会好一些

你只需把需求细节梳理清楚，细节做到极致。

开发还不明白，那就是他理解能力有问题了