把PRD写细,是应对傻逼开发最好的武器

     分类 [产品经理]
2023/11/14 10:26:28 浏览量  983 喜欢  74
导读:无意对立,仅针对个别人

把PRD写细,是应对傻逼开发最好的武器

最近有朋友向刀哥吐槽,说他们公司的开发太傻逼了,简直就是螺丝钉,拧一下动一下,一点自主意识都没有,完全就一代码机器。

比如,他提了一个需求,原型设计是这样的:

把PRD写细,是应对傻逼开发最好的武器

没有写具体的展示样式规则,结果开发做出来却是这样的:

把PRD写细,是应对傻逼开发最好的武器

问前端开发为什么不把商品名称留宽一点,对方回复:需求里没写。

朋友无语。

以上只是他日常和开发沟通的一个小例子,还有很多类似的情况。

只要一问开发为什么不那样,对方一定回复需求没写。

其实每个产品经理,或多或少,都遇到过类似的问题,你以为的常识,人人都知道该那样做,但是开发就是理解不到,非得你白纸黑字写出来,他才会做。

在不同的团队,根据配合的默契程度,发生的频率以及程度会有一些不一样。

这个问题出现的本质在于,彼此的认知存在差异,以及思维方式不一样。

产品经理是用户思维为主,技术实现思维为辅。

而开发人员是技术思维为主,用户思维为辅。

用户思维,考虑的是用户价值,使用场景,易用性等。

而实现思维是考虑如何通过代码把功能实现,两者主要的区别是思考的优先级不一样。

有些开发,在技术思维的基础上,用户思维更强一些,会考虑更多的用户场景,甚至弥补产品经理考虑不周的地方。有些开发,没有一丁点用户思维,满脑子都是代码,就会出现上文那种情况,产品写什么就做什么,产品经理一问就是需求文档没写。

要彻底避免这种情况的发生,刀哥觉得,就一个方法——写PRD的时候,默认所有的开发都是啥都不懂的傻逼。

就像装修房子的时候,你把图纸已经画得足够详细了,随便找哪个团队来做,都一样。

默认他们都是按照指令执行的机器。

但这样也要求,产品经理能够写出质量过硬的PRD,有一套属于自己成熟的写作方法论。

另外,很多“你以为的常识”不能停留在脑子里,而是要写出来。

有些人可能会说了,如果所有细节都写,产品经理得累死。

其实不是这样。

写我们以为是常识,其实也花不多了多少时间,只要你写PRD的思路没有问题,就是多敲几个字而已。

且很多时候,“想”没有问题,而写的时候,发现其实还有一些没考虑到的地方。

详细的PRD还可以作为测试写用例的依据,PRD写得细,测试覆盖的用例也就多,测试在写用例或评审用例时,还会发现一些产品没考虑到的地方,让产品经理继续完善。

当然如果你跟团队里的开发已经很有默契,开发甚至会做出超出你预期的产品时,你可以不用写那么多细节,让他们去自由发挥可能更好。

如果你跟研发团队达不到这种默契,还是把PRD写好写细吧。

总之,跟你认为没有默契的开发合作时,最好的方法是,先把他们看做啥都不懂的傻逼,把PRD尽量写细。

写细PRD没有我们想象中那么复杂,甚至能让我们发现一些没考虑到的细节。

 

 

标签

微信扫一扫,分享到朋友圈

微信公众号

相关推荐