关于写PRD的一些思路与感悟

前言

习惯了敏捷开发和小团队开发,很多事情口头上说的很快,但是忽略的事情也会有很多,如果问我觉得怎么样的人才是令人敬佩的产品经理,我想应该是那种死磕一切的大佬吧!所以我想了解下那种细到令人发指的PRD是怎么写出来的。

PRD的三大基本要素:

  • 产品背景:

告诉团队,为什么要做这个产品,这个产品的要解决什么问题?

  • 产品的目标: **

产品完成后,能达到的目的是哪些,不能达到的是哪些?后续会不会还有其他新的需求没有考虑到,要不要在某些地方留个口,不写死 。

  • 交互稿和产品逻辑:

页面的交互和流程,还有一些信息的展示与操作的逻辑条件,也就是前置条件后置条件等等,这部分是一个很关键的地方,因为逻辑的错误是一个产品的硬伤,而一个产品的战略错误则是癌症——离死不远了

1.产品背景

产品背景负责解释清楚开发的目的,也为了统一大家的想法,让大家找到认同感同时也对这个项目有投入参与感。在产品背景中需要交代清楚的有:

  • 现有的状态,最好是有数据的支撑不要给人一种假大空的感觉,例如:现在的投诉率很高,每天都有很多人吐槽不好用,这个页面打开太慢,太卡,这个视频播放没法记录上次播放的地方。
  • 需要解决的问题,例如优化页面的逻辑,重新做一个记录播放的功能,如果做完后会让用户的体验提升很多,会促进用户的好感,同时也可以减少一些不必要的吐槽。

然后交代清楚之后,大家都觉得这个功能要做,对用户的体验提升太重要, 这个是一个大问题,需要一起去面对。于是大家一起参与去克服这个问题,有参与感和认同感。

2.产品目标

产品的目标虽然感觉很简单,但是要做到一个可量化的目标还是有点难的。怎么样才算一个可量化的目标呢?

例如:没有这个功能的时候,平均用户的视频学习时间是50分钟,优化了之后提升到了80分钟或者更高;平均该页面的加载速度是2s,现在是1s;用户的吐槽率是10%,解决这个问题后降到2%等等。

目标是一个方向,虽然不能保证100%的完成,但是这些可量化的目标会给团队一个激励,一个坚定的方向,这也是产品验收环节的一个考核指标。给产品设定一个目标,用数据说话,会更有说服力。

3.交互稿和产品逻辑

交互稿很多时候就是原型,原型的话有简单的低保真,也有完整详实的高保真原型,但是不管怎样,只要能让团队的其他成员了解并不容易出偏差的情况下完成功能的设计开发就可以了,也就是说如果你在原型上没有写的很清晰的话那么你就需要在PRD上把没有说清楚的写清楚,当然敏捷开发的时候更多的是口头的交流和一些文字上的沟通。如果要做的规范还是需要写在PRD上面的。关于PRD怎么写,其实我自己也没写过多少,也不知道到底好的PRD到底是怎么样?但是我从网上看的一些资料或者是结合自己的一些思考得到的结论是这样的:

  • 了解这份文档的使用者,如果只有开发和产品,那么你就应该尽量用开发的术语去表达一些东西。
  • 知道了这份文档的使用者之后,记得写上一些版本信息和一些更新的release表,然后就开始正文吧!
  • 从大到小,从前到后,从整体到模块,从模块到细节。从大到小就是先整理产品的结构,知道一共有哪些模块,有哪些大的方向;从前到后就是先考虑前台用户看的到的那部分,然后考虑后台需要看的那部分,当然这个有可能会换顺序;从模块到细节,就是剩下的精细化操作了!

就目前来说,我是不太喜欢写PRD的,有可能是因为目前公司用不太上这个,但是也有可能是我做的还不够专业和规范;就我目前遇到的问题来说,我感觉写一个产品手册,说明书什么的比这个更重要,因为好像我们公司很多人对很多功能都不会用或者都忘了怎么用?这是一个很伤脑的问题!人员流动和业务线分割导致的问题,解决办法只能写文档或者是多培训解决了,然而文档说的清楚吗?呵呵,反正我不看!

长篇累牍的文章让人看得头晕,写作的人也会写着写着就不知所云了,所以我还是喜欢画图或者用流程图说话,当然弊端也很明显:那就是考虑不周。这是一个很严重的问题,但是敏捷开发的真谛就是先上,有问题后期再优化!看起来像一个野路子,但是挺好用的!希望以后去一个新公司,去学习规范化的操作。

任何枯燥的操作都是为了避免下一次的重复与浪费,如果下一次仍需要重复与浪费,那么只能说明这个问题还没解决,所以:文档真的是万能的吗?That’s an interesting question!

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%