最近有朋友向刀哥吐槽，说他们公司的开发太傻逼了，简直就是螺丝钉，拧一下动一下，一点自主意识都没有，完全就一代码机器。
比如，他提了一个需求，原型设计是这样的：
没有写具体的展示样式规则，结果开发做出来却是这样的：
问前端开发为什么不把商品名称留宽一点，对方回复：需求里没写。
朋友无语。
以上只是他日常和开发沟通的一个小例子，还有很多类似的情况。
只要一问开发为什么不那样，对方一定回复需求没写。
其实每个产品经理，或多或少，都遇到过类似的问题，你以为的常识，人人都知道该那样做，但是开发就是理解不到，非得你白纸黑字写出来，他才会做。
在不同的团队，根据配合的默契程度，发生的频率以及程度会有一些不一样。
这个问题出现的本质在于，彼此的认知存在差异，以及思维方式不一样。
产品经理是用户思维为主，技术实现思维为辅。
而开发人员是技术思维为主，用户思维为辅。
用户思维，考虑的是用户价值，使用场景，易用性等。
而实现思维是考虑如何通过代码把功能实现，两者主要的区别是思考的优先级不一样。
有些开发，在技术思维的基础上，用户思维更强一些，会考虑更多的用户场景，甚至弥补产品经理考虑不周的地方。有些开发，没有一丁点用户思维，满脑子都是代码，就会出现上文那种情况，产品写什么就做什么，产品经理一问就是需求文档没写。
要彻底避免这种情况的发生，刀哥觉得，就一个方法——写PRD的时候，默认所有的开发都是啥都不懂的傻逼。
就像装修房子的时候，你把图纸已经画得足够详细了，随便找哪个团队来做，都一样。
默认他们都是按照指令执行的机器。
但这样也要求，产品经理能够写出质量过硬的PRD，有一套属于自己成熟的写作方法论。
另外，很多“你以为的常识”不能停留在脑子里，而是要写出来。
有些人可能会说了，如果所有细节都写，产品经理得累死。
其实不是这样。
写我们以为是常识，其实也花不多了多少时间，只要你写PRD的思路没有问题，就是多敲几个字而已。
且很多时候，“想”没有问题，而写的时候，发现其实还有一些没考虑到的地方。
详细的PRD还可以作为测试写用例的依据，PRD写得细，测试覆盖的用例也就多，测试在写用例或评审用例时，还会发现一些产品没考虑到的地方，让产品经理继续完善。
当然如果你跟团队里的开发已经很有默契，开发甚至会做出超出你预期的产品时，你可以不用写那么多细节，让他们去自由发挥可能更好。
如果你跟研发团队达不到这种默契，还是把PRD写好写细吧。
总之，跟你认为没有默契的开发合作时，最好的方法是，先把他们看做啥都不懂的傻逼，把PRD尽量写细。
写细PRD没有我们想象中那么复杂，甚至能让我们发现一些没考虑到的细节。
