起点学院课程

PRD之道:4个撰写PRD的关键思路

25 评论 5.5万 浏览 295 收藏 10 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

作者分享了4个撰写PRD的关键思路,希望这些思路,可以让你在撰写PRD时有所受用。

我看了一下互联网上面的文章,浏览量高的文章,基本上在事无巨细地讲PRD的每个环节该怎样写,甚至直接提供了PRD模版,可能的确对于产品小白来讲是比较受用的。

那么我这篇更偏“道”一些,想讲一讲做产品两年多以来,对PRD撰写的一些思考:

一、撰写PRD应该是一个的动态获取信息的过程

心理学上,有一个效应叫做:锚定效应。

大概是讲,人会倾向于依赖容易获得的信息,快速得出结论。

比如,我们常常说的“第一印象”;或者《思考,快与慢》中作者提到的大脑中无意识的“系统1”依赖情感、记忆和经验迅速作出判断;或者《乔布斯传》中提到乔帮主常用的判断工具“直觉”。

这是原始进化动物生存的本能——站在剑齿虎面前思考的猿猴早被灭绝了。这种决策路径效率高,省心省力。

但是在未尽量获取足够信息的情况下(或经验欠缺的情况下),快速确定一个产品需求或产品方案(下决策)是很危险的,特别是面对复杂需求、复杂项目。

做完决策后,还有会有一种沉没成本效应的心理作祟。决策者即使后来认识到错误,往往也难以说服自己改变船头的方向(脑补一下跟开发哥哥说要改需求的痛苦情景)。

(摘自《神秘的程序员》by西乔)

因此在开始撰写产品PRD之前,需尽量获取更多的信息,使用用户调研、数据分析等手段。最土又最有效的办法就是多问几位前辈的意见,兼听则明。 但是,如果在执行过程中,如果真的发现方向偏了,也要有勇气踩刹车,勇于承担错误。

二、面向对象设计产品

其实我大学学的是物流管理,半毛钱编程都不懂,但是曾经读过Java的介绍留下印象:Java是一门面向对象的编程语言。什么是面向对象?结合两年多的产品经验,以我粗浅的理解,主要有几个特点:抽象、封装、可复用。

世间的万事万物都是可以被抽象的。

比方说,你要做一顿饭。锅碗瓢盆,可以算作炊具。油、糖、盐、醋,可算作调料。青菜、肉,可算作食材。那么炊具,调料,食材,就是你做饭时需要调用的对象。

封装是个啥意思呢?

简单说,就是老死不相往来。炊具、调料、食材三者互不关心各自有什么内容。你把生菜换成芥蓝,我还是可以把它做成一道菜。

那么可复用呢?

我每天都可以拿这三个对象做饭。老王来了,他也可以拿这三个对象做饭,不用自己带一套过来。

(如果理解错了,求程序员勿喷。)

我认为设计产品时,也需要面向对象设计。

举个简单的例子。以往唯品会app的忘记密码功能,iPhone、Android、iPad、WAP都需要开发一套原生界面,维护成本高,后来改成了统一的H5流程,那么原生app再也不用关心H5忘记密码的流程到底是怎样的,忘记密码的迭代也不依赖app的发版。以后如果多了一个安卓pad,也可以直接拿H5页面用。

第二个例子。以往唯品会个人中心菜单数据在中间层(服务层)配置维护,且不支持分流。但是公司内部有一个开关分流系统,可以创建开关,并灵活配置各种复杂规则。

那么,按面向对象的思维设计:

  1. 对于前端。前端去请求菜单数据时,需要获取的仅仅是:哪些菜单有数据?中间层返回了数据,前端就展示出来。不返回数据的,不展示;
  2. 对于中间层。如果某个菜单需要分流,那么可以在这个菜单上配置一个开关编码,按这个开关编码,带上前端请求时带的一些参数(用户信息),去请求开关分流系统。那么中间层也不必理会开关的配置复杂规则,仅仅需要知道一个结果:开或者关。开,就向前端返回某菜单的数据;关,则不返回。
  3. 对于开关分流系统。仍然是干自己的事情,管理开关的创建及规则配置。

三者之间的边界清清楚楚,而且对于运营来讲,极其灵活。

再扯远一些,很多交互设计定义的组件(报错组件、弹窗组件等),其实也是面向对象思想的一种应用。

面向对象设计产品的好处也是显而易见的,最直接的便是节约开发、维护成本。另外,也能帮助产品经理提高抽象思考能力,关注问题的本质。

三、面向PRD用户角色进行设计

PRD其实本身也是一件产品。它的用户是:开发、测试、设计师、项目经理。好的PRD也应当符合交互基本原则:don’t make me think。

在撰写PRD的时候,需要仔细的考虑面向用户角色的需求:

  1. 开发。涉及多开发团队时,不同的团队希望清楚的知道自己的开发范围边界是什么?当然,最重要的,需要怎样开发?和以往相比,改动了哪些东西?
  2. 测试需要知道,用户场景有哪些,便于撰写丰富的用例,模拟真实的操作场景。
  3. 设计师,需要了解哪些界面需要重新设计。
  4. 项目经理需要知道项目的基本人员组成、预期上线时间、资源、风险等状况。

在撰写文档时,最好能针对不同角色,划分不同的模块进行阐述,向不同的人展示不同的重点内容。同样也是面对对象的思维。

四、结构化、图化

PRD应尽量使用目录、表格、流程图、交互图等结构化的表现方式。程序猿哥哥都喜欢。

曾经有一些产品经理写了一堆的文字山,然后就没有然后了。

总结一下

  1. 撰写PRD应该是一个的动态获取信息的过程。最好在需求早期尽量获取大量的信息,同时要保持开放的心态,接受各方的信息。
  2. 面向对象设计产品。可以显著提高产品的可扩展性、降低维护成本。也可以锻炼自己的抽象能力,把握问题核心的能力。
  3. 面向PRD用户角色进行设计。理解你的用户,善待你的用户。
  4. 结构化、图化。子曰:程序员爱看图。

此外,撰写PRD是一件需要不断实践,不断总结的事情。但愿上面的这些思路,可以让你的PRD变得更牛逼一些。共勉。

(本文未经本人允许,不得转载。)

 

作者:Joao_Zhang,公众号:PathsVIVI

本文由 @Joao_Zhang 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 写的好啊,要不是看评论我就一眼错过了,授人以鱼不如授人以渔,没做过产品,尤其是0到1的产品,是挺难理解的

    回复
  2. 想求一个PRD的事实范例:),这是最强大的教学。

    回复
  3. 我也是学物流管理出身,想要投身于产品,不知道师兄是怎么入的行,能分享交流一下吗?微信:18829040420

    回复
  4. 面向对象设计产品 印象很深刻 感谢

    回复
  5. 标题与内容不符

    回复
  6. 没写过PRD,但也觉得XX易懂

    回复
  7. 如果你写过几个PRD,你会发现文章挺容易理解的

    回复
  8. 看懂了

    回复
    1. 多谢T.T

      回复
  9. 其实融入到自己的项目中就很好理解了,
    第一点说的是产品设计并不是一锤定音的,好的设计要经过不断的修改和吸取相关者的意见,这个过程往往是有些产品经理比较抗拒的,所以要保持一个很好的同理心,为目标用户做产品,而不是为产品做产品;
    第二点说的是一些相似的功能在逻辑结构和设计上尽可能一致化,因为为了方便复用,就要有意识的把这类功能做成一个整体的,这样就可以方便程序员理解和开发;
    第三点就是prd要考虑到不同阅读者的情况,程序员关心的是逻辑、数据层面的东西,所以prd中的流程图就要包括功能的各种事件情况,功能结构图要条理清晰,方便他们做接口和设计整体框架 。设计师关心的是交互和视觉层面的东西,所以prd的原型尽可能做到高保真,按钮的摆放,各个设计元素的层级关系也要从原型图中可以直观看出。老板的话就关心整体操作体验,和功能是不是他想要的(⊙﹏⊙)b,所以有必要的话还要制作可交互的高保真原型图方便评审和可用性测试。
    第四点就很明显了,就是prd不要通篇文字,要图形和注释一起,这样才方便理解。
    楼主可能是没有结合实际的项目说明,再加上文章用词过于专业化,没有符合大众的阅读喜好,所以才让人感觉很难理解。
    上面也是我个人的见解,如果理解有误楼主不要拍我啊~

    回复
    1. 非常感谢反馈。您有实践经验,理解成本更低一些。案例的确是少了一些。投稿前,对平台受众欠考虑了。

      回复
    2. 我觉得您回复的第三点写的比原文清楚,更容易让人理解。

      回复
    3. 我也觉得,你讲的比原作者浅显易懂,原作者的话很容易让人误解

      回复
  10. 浪费了读者的时间,泛泛而谈太明显,欠缺逻辑!

    回复
    1. 具体有什么改进意见吗?何谓泛泛而谈?四个要点是否认同?

      回复
    2. 我觉得写的还好,有可读内容

      回复
  11. 点赞和点收藏的同学看懂了吗 😮

    回复
  12. 泛泛之谈,并不是很深入。个人阅读后的感受,勿喷。

    回复
    1. 感谢阅读和反馈 :mrgreen: 。此篇主要目的是提供一些新思路吧,不是手把手教你写的类型。

      回复
  13. 根据评论中三位的反馈来看,可能此文与部分读者的预期有所偏差。此文的目的,并非手把手教一步步如何写出PRD。特别是文中的第四点,这种偏操作的,我都刻意缩略了,其他很多同类的文章都会提到。本文的意图是抽象总结一些产品设计的思路和方法,会有有一定的领会成本。如果浪费了各位时间,实在抱歉了。

    回复
  14. 我还以为我智商该充值了,原来其他人也没咋看懂 = =

    回复
    1. 😯

      回复
  15. 我没有恶意啊,我只是做了7年黑盒测试,想学习一下产品经理知识。我真的没看懂这个在讲什么。好乱的感觉。我是特意登录上来表达这个想法的。

    回复
    1. 都没看懂? 😥 加个微信交流一下?Paths_vivi

      回复
    2. 我对七年的测试比较有兴趣 😉 文章看懂了,就是实际操作还是缺啊!!

      回复