PM是需要常常与研发同事进行需求沟通或者需求评审。而产品的需求，往往是由于PM定义出产品的规格，再与研发同事进行讨论研发。所以，PM在对用户的需求分析上没有准确定义好，而研发仅按自己理解的规格做出的设计，就会出现以下这种场景（下图，图片来源于网络）
当然，本文不讲述PM如何做需求分析（前面的文章已经提过）。而是讲述，PM应如何好好的跟研发讲故事，让研发跳出产品规格的限制，提交一份差强人意的产品。
问题是如何产生的
先对这个问题进行需求分析。一般情况下，PM的需求沟通对象会是研发工程师、测试人员。
发生的溯源，主要是思维的不同，产品的思维与技术思维的偏差。 开发是左脑思维，逻辑理性，技术至上、性能优化、用how表示。产品是右脑思维，艺术感性，用户至上、用户价值，用why表示。
所以在需求沟通中，PM作为整个产品的发起者，研发的理解就变得非常重要了。而现在而言，很多PM都会在需求评审会议后，由于思维认知不一致，研发在开发的过程中就会衍生很多不确定的因素和疑惑，需要反复与PM协调沟通去确定最后的方案。这样一来一去，不仅仅成品不好，而且研发的时间也会加长。所以PM往往希望自己可以快速准确，高效率的完成需求沟通，而研发也能根据PM的想法，研发出好的产品。
问题产生的源头是什么？是在于产品应该学会通过讲故事的方式来传达需求
1、先自己把事情搞清楚了
PM需要优先在需求沟通前，将整个需求来源、用户场景、处理流程、预期效果等等方面的各个细节都考虑清楚
2、告诉研发产品的需求来源背景
用记述文的方式，将以下五个方面的范畴表达出来：清楚地表达出用户是在什么场景，场合下使用发现了这个需求；而是被什么角色而使用；是通过什么方式下会使用这个需求；使用这个需求会达到什么样的效果；其他的客观因素影响如何
例子：
【日常沟通】
PM：我需要做个可视化的界面去分析估值数据不同的车型在不同的规则下积累多少个异常点
研发：异常点？为什么做这个？做不了，不同的车型数据量那么大，怎么可能看出问题吧啦吧啦的。
【故事性沟通】
PM：由于现在经常会有一些车型被评估师那边反馈不准，但是现在我去查询的时候，又不知道那些车型因为什么原因不准，所以就想知道可视化不同的车型在不同的规则下积累的多少个异常点，这样我在查询车型的时候就可以知道发生了多少个异常，选取的规则是否有问题，相似的车型是怎样
研发：那这个可视化的话，只要相同特征下的车型作为横坐标，并且要做个表格查询功能就好了。
3、描述整个产品的使用流程
用uml图或者其他形式的图，把场景描述出来。【更换头像】就有三个场景下——想查看自己的头像，犹豫要不要换；直接从相册中找图片；已经更换头像后，查看头像的细节。这样研发就可以理解知道更换头像需要保存头像记录的逻辑，访问相册或者访问相机的功能，以及放大图片的功能。就比直接告诉研发说我要留有保存头像的记录，研发不了解场景，就会产生都更换头像了，为什么还要保留之前的头像的疑惑。
4、从框架上系统化拆解需求细节
通过总分分的方式，讲产品从整体拆分成区域再拆分成最小单位，层层递进的方式。使得每个阶段的衔接性更高。再结合以上2、3点进行故事性描述
5、始终目标一致性原则
时刻与研发保持目标一致性原则，切记用命令式或者施于权力的跟研发沟通，而是让研发有参与感，与PM时刻保持着同个目标
总结与思考
这样的讲述方式不仅可以让研发身在其中，具有参与感，甚至可以帮助提供更好的建议去改进产品目前的设计。毕竟有时候PM的知识有限，在没有清楚的将需求讲明白，研发就算是有非常好的解决方法也没法发挥出来。所以有时候不是因为研发真的做不出PM所想的东西，而是PM的思考模式没有顾忌到双方思维的偏差情况，而是仅仅提供一个产品的规格给研发，而没有通过讲故事的方式，没有弱化认知的差异。所以，为了跟研发可以站在同一个出发点上思考问题，还是需要好好提高自己的讲故事的能力的。
