|
|
PRD是Product Requirement Document的简称，中文翻译为产品需求文档。该文档是产品(功能/需求)由“概念化”阶段进入到“图纸化”阶段最重要的东西。
对产品经理来说，PRD文档是一个很基础的工作，也可以说是产品经理用来沟通的重要文档。一份高质量的PRD文档，可以极大地降低沟通成本。
01.PRD文档有什么用
PRD文档的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员，它对每个角色有着以下的作用。
- 开发可以根据PRD了解整个功能/需求产品的整体逻辑。
- 测试可以根据它编写测试用例。
- 项目经理可以分解任务并分配工作做排期。
- 交互设计师/UI设计师输出相应的设计稿。
- 培训人员可以根据它来制作培训文档或视频。
- 市场人员可以根据它来撰写新闻稿/宣传文章。
产品经理的PRD文档，就像建筑设计师的设计图纸，是设计和思考的文档化呈现。《用户体验要素》作者有一句很经典的话：“文档不能解决问题，但定义可以”。PRD就是要定义需求。
综上，PRD文档的重要性不言而喻。
图.根据PRD制定的开发计划（有部分删减）
02.用什么工具写？
我2007年刚参加工作进入北京金山软件的时候，同事及同行们都拿Visio画原型图，然后拿着原型图给开发/测试和设计师做集中澄清。一些关键的业务流程和逻辑规则的说明，有些会放在Visio里面，有些会单独再做一份Word文档作为补充。
后来Axure这款软件开始在行业里面流行起来，于是越来越多的公司和团队开始使用这款工具。最常见的就是下面这种左边是所见即所得的原型交互页面，右边是针对每个功能的逻辑和规则说明。
因页面缩放原因，右侧需求说明文字有重叠
再后来行业里面又涌现出了诸如墨刀、Sketch和Figma等软件。这些软件各自的优劣见仁见智，大家根据自己的习惯以及团队的要求自行选择即可。
PRD用什么来写，没有最好的，只有最合适的，每个人所在的公司背景都不一样，大公司要求文档规范细节到位，小公司可能只需要记录关键信息，剩余的靠口头沟通，甚至都不需要文档。
我要强调的是：PRD拿什么工具写无所谓，但一定具备良好的可读性。
我见过有产品经理用Axure写的，整个文件横向纵向各种拖动，看的人崩溃。我也见过订单结算页面使用平台红包、卖家红包、卖家优惠券的业务规则/逻辑说明用了整整3页纸将近2500余字的，这个开始写在了Axure里面，后来可读性太差，最后改成了Word文档的。
03.写PRD的6个关键字
我看过很多教人写PRD文档的文章，这些文章很多都犯了同样的毛病，一上来就讲术的部分，鲜有人去讲道的部分，也就是具体的思路。
我的思路概括起来就6个字：框架、流程、细节。
框架：可以理解整个产品的业务蓝图，或者系统架构图及功能结构图。数字化建设不是一朝一夕之功，需要敏捷开发快速迭代，但在做之前需要有整个产品的业务规划蓝图，就跟建高楼盖房子之前要有设计图纸一样，不能边做边改。
流程：如上图所示，业务系统是由N多个业务模块或功能模块构成的，以我们熟悉的电商平台为例，就会涉及到支付，售后和物流多个功能模块，每个模块又会由前端的，后台的，正向的，逆向的流程构成。
所谓一图胜千言，这些流程如果用文字来描述，那么文档使用者就会特别特别的痛苦，这时如果有这么一张流程图，那整个文档的可读性就会好上一个数量级。
流程≠流程图，上述的核心业务流程也可以通过其它的视图方式来呈现，例如活动图，用例图，状态机图，时序图等等。而流程图只是最为常见的一种。
如下就是UML中比较常见的时序图，该图研发同学用的会多一些，这个图能清晰完整的反映出支付活动中的数据流向和流程顺序，能方便开发和测试同学更深刻全面的理解整个业务。产品经理用的比较多的则是上面的那种泳道流程图。
细节：上述框架和流程部分会占到整个PRD的20%左右，剩下80%则由大量的细节构成，细节则主要通过原型图来表达产品的界面和交互流程等。
比如用户在页面上点击了不同的区域后会分别跳转到哪些页面流程或节点，如下图所示。这里建议给页面表上序号且树状结构不超过3层，特别是需要多地远程沟通的项目。
比如开腾讯会议沟通需求的时候你告知对方打开订单列表页，别人可能需要在页面原型上找半天，如果你说打开3.1 订单列表页查看标记5的规则3，协作方就能快速定位到，这样也能提高多地协作的效率。
原型图一般会包括前台C端页面鲜活go小程序和B端管理后台页面两个大的部分，对于一些比较复杂的功能或产品，可能还会更多。
04.写好PRD的细节
PRD的细节应该包括但不限于以下部分内容：需求背景、需求描述、具体功能点的流程图、WBS、页面及功能说明、交互接口、迭代记录、其它部分等。
4.1 需求背景简单了说就是：现状是什么样，为了解决什么问题，期望达到什么目的。
- 现状：定性+定量描述当前遇到的问题，如50%的用户在注册页面跳出。
- 方案：所提供的解决方案概述，加入一键登录和手机验证码注册(登录)。
- 目标：3个月内注册跳出率降低至20%。
比较大的需求或功能可以展开了说，比如要阐述为什么要做这个需求，是新增的功能还是已有功能的优化和完善？是为了解决用户的哪些问题，满足用户的哪些需求？亦或者是公司高层的拍脑袋决策？
这个需求才做到什么程度，达到什么阶段性的目标？这样才便于PRD阅读者快速了解整个项目的梗概。
- 电商平台上线1年多以来还没有一套客观可量化的评价系统来对卖家进行约束、促进和规范。
- 电商平台：需要这样一套评价系统来了解经销商的真实经营情况和买家反馈情况，约束卖家诚信经营、督促其用心服务，提高服务水平和质量；同时也可以为后期搜索和推荐/排序等功能奠定基础。
- 买家端：可以根据评分和评价来选择卖家，进而督促卖家提高服务质量和配送效率，可以获得积分或虚拟货币奖励。
- 卖家端：可以帮助省级总经销商了解下级经销商真实的服务/配送情况，便于对下级经销商做评估和考核；同时也可以帮助经销商了解业务员、配送员真实的工作情况，便于发现工作环节中的缺陷和不足，进而对各职能部门进行约束、规范和促进。
4.2 需求描述简单了说就是：到底做什么，有哪些大的功能模块或者通过哪些方式来实现前文业务背景里面描述的问题。此处的篇幅不宜过长，但需要通俗易懂，避免使用过多专业术语。还是以XX电商网的评价系统为例。
完成评价系统的基本业务模型搭建，运营平台可以查看经销商的所有评价信息和评价数据统计。
交易平台：
- 买家可以针对已完成订单进行评价。
- 买家可以查看评价、可以追加评价。
- 评价管理：卖家可以查看评价数据统计。
运营平台：
- 评价数据统计：可以查看全部经销商的评价数据统计。
- 评价内容管理：可以查看所有买家对卖家进行的评价和评论信息，可以按照名称或订单号、评价时间和满意度等信息进行筛选/搜索，可以对有图片的评论进行审核。
- 中长期目标：评价系统在具体业务中的运用，比如评分和评价内容在商品或者商家详情页显示，在搜索结果中影响排序结果等。
4.3 流程图俗话说一图胜千言。有些功能无论你通过怎样的文字来进行阐述或者说明，都不如几张图来的简洁明了。产品经理在平时描述业务流程时常用的图有流程图、时序图，学有余力的话还可以了解一些泳道图、类图等。
下面是在XX电商网终端店用户在注册审批时用到的泳道图，仅供参考。
下面是货到付款订单增加买家取消功能用到的流程图，仅供参考。
4.4 WBSWBS是工作分解结构Work Breakdown Structure的英文首字母缩写，其是项目管理重要的专业术语之一，WBS将交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
我之前项目上的WBS是长这样的，将所有的功能点罗列并形成表格形式，使阅读者对于此需求的功能点总体上有个基本的了解，以下是订单结算页优化的WBS。
4.5 页面及功能PRD的主体部分，详细的描述此需求包含哪些页面，每个页面的布局，具备哪些功能和页面元素，每个功能的规则是怎样的。PRD的读者通过这部分的阅读，可以说基本清楚此次需求到底是做什么的，详细的规则是怎样的。
这个时候我们一般以页面为维度来进行详细的需求说明撰写，撰写的时候一般是从上往下从左往右的方式来写，如下图所示。
为了避免开发、测试过程中的扯皮，减少功能上线之后各个部门之间的甩锅，也是为了产品经理的自保，强烈建议产品经理在写的时候要把其它文档使用者当做小白来看待。
比如，这个页面上的每个字段/元素和按钮，写的时候都要想想看开发测试人员，以及功能交付后的运营人员能不能理解，会不会埋雷。
我之所以这么说就是因为踩过坑，比如上图满折优惠券的配置，如果产品经理不添加个字段折扣上限XX元且该字段必填，那么开发人员必定不会做这个功能，运营人员配置优惠券的时候就有可能出问题。
比如运营配置9折优惠券的时候心想客户最多买5000元的商品优惠500元，但如果客户购买了10万的商品就会优惠10000元，这么高的优惠力度可能是运营和财务人员不愿意看到的，可能会给公司造成损失，你觉得这个损失会由谁来担责？
所以页面上的每个元素都要尽可能的做好定义，规避来自方方面面的危险，防止被用户薅羊毛。我之前有家公司就因为优惠券的配置被用户薅了200多万元的羊毛，当时的运营和产品经理都是被追责了的。
每个字段/元素/按钮在开发时都有相应的业务规则，PRD需要将这些规则清晰完整的描述出来，让开发、测试人员能够看的清楚读的明白，且没有产生歧义。
表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等，还有对应的错误提示。
- 文本要考虑最大显示长度，超过怎么处理。
- 链接一定要指定点击后跳转到哪个页面。
- 图片要考虑显示的比例，如果未加载出来该显示什么。
- 还要考虑界面的内容是写死还是通过后台配置。
异常情况：之前听过一个观点觉得很有道理。PRD把正常业务规则写完整不难，但把所有异常情况考虑全却不简单。
比如说用户在前端电商平台领券的时候，在2台设备上登录同个账号同时点击领券操作，系统是发放双倍的优惠券还是怎么处理？
不管是C端页面还是管理后台的需求描述里面，都要尽可能的想清楚客户和公司内部员工都会有哪些骚操作，然后梳理出对应的解决方案。
4.6 交互接口《西游记》里唐僧每次介绍自己都会说：“贫僧唐三藏,从东土大唐而来,去往西天拜佛取经”。这几句话包涵了每人都要问自己的三个问题：我是谁？我从哪里来？我要到哪里去？
这句话用在产品（开发人员）身上也同样适用：我是谁（在哪个页面）、我从哪里来、我要到哪里去。
换做开发人员的视角，他们比较关注的是：
- 我是谁：用户需要输入什么，在哪里输入，输入方式是什么？输入的内容是否有限？应当被如何检查？页面显示什么？数据怎么加载、怎么缓存、怎么刷新？
- 我从哪里来：用户从哪里进入到这个页面？怎么来的？是否可以相互转移（单向还是双向）来的时候有哪些数据一起跟着来的？数据从哪儿传送的？
- 我要到哪去：用户从这个页面会去向何处，哪些数据会跟着一起去？数据怎么传送（提交/上传）？相应操作之后会有什么交互事件？页面会发生什么样的变化？会影响到哪些页面或功能？
当然大部分产品大部分情况无需过多的关注交互接口相关的东西，但如果是程序猿转产品经理的，可能会关注数据交互相关的内容。
4.7 迭代记录PRD从第一版诞生以后，经过多次需求评审、内部评审、设计评审、用例评审、开发（接口）评审等环节，对于页面布局、功能点多多少少都会有修改或变化。
当时可能通过邮件、会议纪要、微信群聊天等来说明，但如果不整理到需求文档中，时间长了，或者是项目人员变动，可能就没有人知道这部分需求最终的实现方案了。
因此，PRD迭代记录也是非常重要的一部分，记录下每一次讨论后需求的变化点，帮助各方使用者及时了解需求变化，以及对最终的实现方案做记录，方便阅读人员及时找到修改后的内容，直观的了解修改原因。
这对产品经理也能起到自保作用，比如某个功能出了线上事故，这个功能是前任产品经理做的还是你做的，都可以通过PRD文档里面的迭代记录来佐证。
4.8 其它部分以上只是PRD比较核心或主要的部分，其实PRD还有一些其它内容，例如：
相关影响点：没有任何功能是独立存在的，其或多或少都会与其它系统发生关联。这就要求PRD文档在撰写的时候需要指出这些影响点，并给予解决方案。
比如优惠券配置页面增加了1个字段优惠券类别(内部优惠券，外部优惠券)，那么就要考虑到历史的优惠券要不要刷上这个字段，用户已领取但尚未使用的券要不要刷上，以及怎么去刷。
非功能性需求：最常见的包括页面性能、页面监控和兼容性3方面。比如业务部门希望订单结算页面能够自动帮用户勾选出优惠力度最高的促销活动和优惠券，这就要求程序要把用户可用的促销和优惠券遍历一遍然后取出最优值。
假定促销活动可以叠加，优惠券可以叠加，当用户有10个促销活动和10张券的时候，这个计算量还是很大的，如果活动采用的是递进式计算而不是平行式计算，那么先满减再满折和先满折再满减的计算结果可能是不一样的。
这个计算的过程会比较耗时，从购物车点击去结算后订单确认页面，在3秒查询并计算出最优结果再显示出应付金额是符合用户预期的，如果这个过程需要5秒甚至10秒以上，那用户体验就会大打折扣。这个性能要求产品经理也需要在PRD中予以说明。
做过促销或者订单结算某款的产品经理，应该都清楚上述计算的工作量，如果产品经理在PRD没有写清楚这个性能要求，又遇到了外包性质的项目，那这个点就可能出现扯皮的情况。
我之前公司有个项目就出现了这种情况，开发提供的版本最快都得6秒+，但产品经理在PRD里面没有说明要求，最后开发团队要求加钱才能做到3秒左右。经过长时间的扯皮后问题上报到了高层，最后没办法还是加了钱。
角色权限需求：部分产品或者功能点可能会涉及到角色权限部分，比如哪些人可以使用这些功能，有什么条件限制等等。
比如订单列表页面上的导出按钮，用户审批页面的批量操作等等。这个也需要产品经理在PRD中予以说明，否则就需要在以后的迭代中增补进来。如果是自研的产品还好，如果是外包性质的，可能就需要走需求变更增加工作量增加预算，这是项目经理最不愿意看到的。
05.写在最后
如果产品经理的PRD写的不够好或者不够用心，则会有很大的项目风险，同时也会影响到产品经理本人的职业发展。
项目延期：如果PRD里面的关键需求或者主要流程描述不准确不严谨，则研发或测试过程中需要反复修改，进而导致成本增加项目延期。
这种问题我在以往的工作和项目经历中见得太多太多了，为了尽可能的避免这种情况的出现，我们一般会采用交叉审核+产品组内部评审的方式。
前者是让其他产品同事帮忙找茬找需求中的不足，后者是产品小组一起来找茬找不足。事实证明通过这两种方式内部自查后，产品经理再去做需求澄清时基本就没有大的问题了。
打击自信：如果PRD写的不够尽善尽美，则可能会出现需求评审或需求澄清的时候，项目经理+研发人员+测试人员不断挑刺甚至开怼，进而大家集体怀疑产品经理的能力和专业性，进而导致产品经理信誉度降低，自信心受打击。
这种情况发生的多了，项目经理或者部门主管在评定绩效的时候必定没法给产品经理打高分，项目组的开发测试同学也就不太愿意和这位产品经理共事来做新的项目了，然后这位产品经理在公司也就没有太大的成长和上升空间了。
所以，我建议产品经理把PRD需求文档当成一个产品去设计，要尽最大的能力用心做到尽善尽美，这样在需求澄清的时候才不会被开发和测试集体开怼，才不会在开发和测试的过程中不断亡羊补牢。
作者：詹老师，公众号：詹老师
本文由 @詹老师 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。 |
|
发表于 2025-3-29 18:42:11
