作为一名产品经理，撰写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票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦！
专栏作家
娜娜项目网每日更新创业和副业教程
网址：nanaxm.cn 点击前往娜娜项目网
站 长 微 信： nanadh666