作为一名产品经理,撰写PRD文档是基本功之一,但依旧有很多同学写不好高质量的PRD。那么该如何写出高质量的PRD,应对后续工作呢?作者结合自己的实战,与你分享了一些技巧,希望对你有所帮助。

需求文档PRD是产品经理最基本的工作。优秀的产品经理一定能写出优秀的PRD,不能写高质量PRD的产品经理大概率不是优秀的产品经理。

今天笔者同大家一起聊聊写PRD那些事儿。

本文的前提是需求已经规划好,你拿到自己的需求开始做产品规划。

一、PRD的目标用户

写好一份的PRD其实并不容易,首先PRD的读者就需求就很难统一。

对于优先级,我个人的建议是:开发>设计师>业务,老板视情况而定。业务结合UI沟通效率更高,跟设计师则可以在线下持续共同需求。但是产品经理对开发过程的参与度很低,同时开发过程也是人力、时间成本投入最高的,一旦因为PRD描述不清导致开发事故,纠错成本就会很高。

二、写PRD前的准备

产品经理尤其是经验较少的产品经理,要避免拿到需求就开始“高效”输出PRD的误区。否则很可能写出自己觉得非常完美,但是被老板和业务劈头盖脸狂喷的PRD。

俗话说“磨刀不误砍柴工”,要避免写出自嗨的PRD,需要先了解用户需求。

例子:

背景:你在一家电商公司工作,现在公司想要做一个商品推荐的功能,并且将工作分配给了你。

你拿到需求之后,开始思考,这个推荐功能是面向所有用户的吗?显然不是,对于那种有明确购买目标的用户似乎不适用。

于是你查看公司的用户画像,发现主要用户分成如下几类:

这时你发现用户画像在线制作,小美、小英、小计都能作为商品推荐的目标用户。于是你跑去找Leader,问他是要为这三类用户都做推荐吗?你的Leader摸着脑袋不好意思的笑了,说“这次是想为一些小商家做商品推荐,帮他们提高客流量,工作太忙,忘记跟你交代了”。

于是你知道小美是你最主要的目标用户,需要针对年轻女性的偏好做推荐,使用的场景集中在非工作时间。需求的方向终于确定了。你在腹诽Leader的时候,也为自己的机智点赞。

如果你再多想一步,还会注意到公司目前的战略方向是吸引小商家,那么不止是推荐商品功能可以做,店铺推荐、小商家流量折扣等功能都可以做。

三、功能拆分

了解了用户需求之后,就可以开始产品功能设计。产品设计的第一步就是做功能拆分,功能拆分好之后,才好对每个功能展开描述,撰写PRD。我习惯按照敏捷开发的思路进行。

1. 拆分原则

功能拆分应当基于INVEST和MVP的原则,以使拆分的功能更合理。

INVEST用于拆功能,将复杂、庞大的功能(Epic、Feature)拆分为简单、微小(Story)的功能。不了解Epic等含义的,可以自行了解敏捷开发的方法,在此不能面面俱到。

1. Independent(独立原则)

指的是用户故事(Story)需要彼此独立,低耦合。应当做到功能在业务流程、功能界面、数据、用户目标等层面的低耦合。这样做的好处是有利于灵活的选择Story规划、设计、开发和验收。比如“登陆账号”和“登陆密码”不是独立的,“手机登陆“和“邮箱登陆”是独立的。

2. Negotiable(可协商原则)

指的是用户故事应当是可协商、可讨论的,不能是定死的。不要把用户故事写成合同,事无巨细,不可更改。应当在不断的讨论、细化中成型。

3. Valuable(有价值原则)

指用户故事对于用户来说是重要的,有价值的。这个不用赘述,是产品功能最基本的要求。同时价值也决定了用户故事的优先级。

4. Estimable(可估算原则)

指开发团队能够根据用户故事估算所需的工作量。包含两层意思,用户故事是可实现,且方便开发团队预估开发工作量。比如“根据用户心情改变手机主题”在现有技术条件是不可实现的,“根据天气、节日改变手机主题”是可以实现的且可估算的。

5. Small&Similar Size(规模小且适中原则)

功能越小,排期预估越准,但是过小也会导致管理难度增大。并且多个用户故事之间的开发工作量差异不宜过大。所以要根据团队的情况,切分出大小合适的功能,以能够在一个迭代内完成几个用户故事。比如登陆功能可以分成手机号、邮箱、第三方等登陆方式,可以将每种登陆方式单独拆出来,根据优先级和资源情况安排迭代。

6. Testable(可验证原则)

指用户故事必须是可以被验证的。我认为可以分成三个层面理解。

功能设计阶段,能够去验证用户故事的价值、合理性。开发实现阶段,能够有清晰的验收标准,确认开发结果满足设计需求。发布跟进阶段,能够收集到明确的市场反馈和效果判断标准,以判断是否达到设计预期,方便后续的迭代优化。

MVP(Minimum Viable Product)最小可行产品是极其重要的原则。无论公司大小,团队资源多少,按照MVP都能够保证项目团队一直在做最重要的事情。

比如腾讯在开发微信的时候,也需要考虑投入产出比(ROI),先把只有基本聊天功能的微信推向市场,在用户的使用过程中不断验证、迭代,逐步完成了今天庞大的微信生态。如果微信一开始就试图打造一个生态,相信对于张小龙也是不可能完成的任务。

2. 分析方法

分析方法有很多,我个人最推崇流程分析法,并且一直在使用。比如我在《产品“无”之道》中提到的例子,新手产品经理可以先只考虑业务流程,按照业务流程去做页面和功能的拆解。

分析业务流程时,强烈建议使用泳道流程图,帮助自己将业务流程分析清楚。

3. 优先级确认

将功能拆分完之后,还需要根据用户故事的优先级,确认开发顺序。重要的优先开发,相对不重要的后开发,一旦发生风险,可以去掉最不重要的用户故事。

一般按照重要紧急程度划分优先级,可以从如下几个角度考虑:

一般来说,前者重于后者。但是也有特殊情况,比如最重要客户的特殊需求,也当优先处理。

基于上述的判断标准,我个人会将功能划分为四大类:

核心功能(痛点):缺少就不能满足业务和用户的需求。比如电商的付款、社交软件的文字聊天。次要功能(痒点):没有也能用,但是有用户用的更舒服。比如电商的购物车、论坛的点赞。亮点功能(爽点):在行业内颠覆式创新的功能,别的竞争对手都没有,一旦上线能让用户非常爽。比如微信的摇一摇,360的免费。其他功能:跟业务关系不大,但是不得不做的。比如法律合规、政策要求等。

亮点功能是可遇而不可求的,并且一个亮点功能会随着竞争对手的跟进,逐渐转变为核心功能或次要功能。因此我们能做的就是优先把握核心功能,逐步补充次要功能,准备应对其他功能。

四、案例实战

以上图的在线写作业为例。建议新手产品经理一定要先做加法,尽量罗列相关的功能。我就不按照标准的用户故事格式写了,感兴趣的读者可以自行练习。

然后将题目按照需求类型和优先级分类:

选择P0、P1的用户故事开发,画出流程图如下:

到这里就做好撰写PRD的准备了。下面继续讲撰写PRD的具体技巧,如何能够写出一份自己和团队都能够读懂的PRD。

1. 通用建议

写PRD有一些通用的tips,可以让你的PRD更易于阅读。

1.1 提供流程图

除了上传自己在准备阶段梳理的整体业务流程图,如果某些Story的功能仍然比较复杂,那么也应当梳理出流程图,帮助阅读者对story有个全面的理解。

1.2 使用专业、共识词汇

专业词汇可以分为IT行业通用词汇和行业词汇,需要你在工作和团队沟通中不断积累。比如:

1.3 提供概念词典

当你文档中出现一些不常见、复杂、有歧义的词汇时,建议列出你的概念并进行严谨的解释。放到“需求描述-业务规则”中最佳,方便阅读者在了解需求时对照查看。

1.4 使用在线文档

PRD最好写到在线文档中,与使用word等离线文档相比好处非常明显,更新之后开发、测试可以直接阅读最新的文档,不需要产品先发送文档,开发、测试再下载更新。

现在在线文档的种类非常多,并且功能越来越强大、体验也越来越好,并且很多提供了历史版本的功能,方便对比查看。

2. PRD的结构

日常迭代的PRD,内容我一般写的比较简单。包括:

①版本说明

②需求背景

③业务流程

④需求列表

⑤需求描述

2.1 版本说明

版本说明用于记录PRD的更新历史,方便开发、测试了解PRD都更新了哪些内容。

对于非常重要的更新,建议使用不同颜色字体,以引起开发团队的注意。注意,开发过程中的变更一定要经过开发团队的确认,产品不能擅自更改。

2.2 需求背景

目的是向设计师和开发团队解释清楚为什么要做本次需求。团队不了解用户需求,也能做设计和开发,但是基本做不出来优秀的产品。

设计师大多是有表达欲望的用户画像在线制作,尤其在更有发挥空间的色彩和图案层面。如果设计师不了解需求背景和用户,就只能根据自己的想象去做设计,做出的交互方式以及内容展示的重点很难满足业务和用户需求。比如你想突出产品特点,设计师做成了突出产品外观。

一个优秀的开发是需要能从业务和用户的角度思考的。拿到同样的需求,不同能力的开发交付的产品是不一样的。这种差别,不止体现在代码的可用性、兼容性、鲁棒性等技术层面,还会直接影响用户体验。比如了解用户的算法工程师,能够完成更符合用户需求的产品推荐;前端工程师能够开发出反馈更恰当、更及时、更丝滑的效果,让用户用起来更舒服。

需求背景描述应该使用5W1H的方法,即What、Where、When、Who、Why、How。根据需求的复杂程度从用户需求(必选)、业务需求(推荐)等方面描述。

What:做什么功能。

Where:使用场景是什么。

Who:谁的需求。

Why:为什么要做。

How:怎么做。

在刚开始时,建议按照上述的格式自己列出来,再写成方便阅读的连贯文字。等到轻车熟路之后,就可以直接动笔,边写边梳理了。

2.3 业务流程

推荐以泳道流程图的形式展示,案例请看《如何写出一份优秀的PRD-准备篇》。想画好流程图其实也不难,掌握以下几个要点即可。

2.4 需求列表

按照需求的优先级,从高到低依次列出本次需要开发的功能。方便开发测试优先完成高优先级的需求,一旦发生延期风险,可以放弃开发后面的低优先级需求。

2.5 需求描述

下面就到了PRD的重头戏:需求描述(或功能描述)。一个功能设计是否合理,能否被设计和开发团队读懂,设计、开发出满足用户需求和业务需求的产品,都要依赖需求描述的合理性。

Story:

再次重申Story,避免阅读者返回需求列表查看。

流程图:

对于复杂的功能,建议详细的画出流程图。简单功能可以省略。

界面描述:

在与设计团队对接时,推荐使用手绘原型图。因为懒得画了,就想到网上找一些。很多手绘原型图画的都很好看、很精细,但是我觉得不是很合适。

如果有专业的交互设计师,这反而是对他设计的一种限制,以你的不专业影响了他的专业。如果需要你自己做交互设计,那么也没必要在手绘上画这么多时间,直接用工具做反而更好。

我个人认为画到如下程度就可以了。

在评审前,记得把手绘原型图替换为带标注的UX。虽然你更新起来会比较麻烦,但是对开发团队来说,阅读十分方便。下图是我几年前做的一个后台系统的交互及标注,供参考。

业务规则:

业务规则是PRD中最核心,也是最难描述的部分。功能的流程、页面的导航、界面设计、组件功能、提示文字、异常情况等都需要在业务规则中描述清楚。个人的一些描述习惯如下。

比如描述一个用户留言框:

对于具体的文字描述,同样有一些原则,整理如下:

描述逻辑清晰。因为受个人思维习惯的影响,所以想讲清楚什么是逻辑清晰比较困难。大概就是符合大多数人的认知规律,能够按照时间先后、因果、主次、关联、整体与部分等关系,合理的将产品功能描述清楚。因此更多的需要把功夫花在平时对自己的训练上,多读一些科学、哲学相关的书籍。

用语简洁。这个很好理解,没有人喜欢又臭又长的需求文档,要用尽量精简的语句,将产品功能描述清楚。比如:

使用专业词语。文章开篇已经交代过。使用专业词汇除了方便阅读,同时也能极大精简语句。比如”内容过多时,输入框旁边要出现滑块,拖动滑块可以改变显示文章“,改为”输入框内容过长显示滚动条“。

避免歧义。在写功能描述时,一定不要只考虑自己头脑中的概念,要考虑自己的措辞是否会造成误解。

最后是要有一个清晰的排版。每个人都有自己的排版技巧。在此就不跟大家介绍了。

关于如何书写PRD的分享就到这里,希望对你有帮助。

亲,请不要吝惜手中的票票,给笔者继续做产品经验分享的动力。

为我投票

我在参加人人都是产品经理2022年度作者评选,希望喜欢我的文章的朋友都能来支持我一下~

点击下方链接进入我的个人参选页面,点击红心即可为我投票。

每人每天最多可投35票,投票即可获得抽奖机会,抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦!

专栏作家

发表回复

后才能评论

本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。

最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。 若排除这种情况,可在对应资源底部留言,或联络我们。

对于会员专享、整站源码、程序插件、网站模板、网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。

如果您已经成功付款但是网站没有弹出成功提示,请联系站长提供付款信息为您处理

源码素材属于虚拟商品,具有可复制性,可传播性,一旦授予,不接受任何形式的退款、换货要求。请您在购买获取之前确认好 是您所需要的资源