如何撰写PRD（一）

如何撰写PRD（一）

菡凌若雪 写于2015年7月14日

入职3个月了，撰写过几个大大小小的PRD，也因为考虑问题不够缜密踩了一些坑，甚至有踩了又踩的坑。我觉得还是应该定期总结，把经验和教训都记录下来，时常翻看，培养自己严谨的工作作风。

一份好的PRD，应该可以做到PM不需对开发和测试进行需求宣讲，他们就能够按照PRD实现设计好的功能。需求目的、功能描述和原型设计是PRD的核心组成部分，另外可能还会有版本记录、技术支持等其他内容。

一、需求目的

       关于需求目的，应该要用简洁的语言表达出需求背景、需求期待和需求意义。直白地说，就是为什么要做这个需求，做这个有什么好处。这里可以使用5W2H原则，包括：

• Why?为什么会有这个需求？

• When？ 需求产生的条件？

• Where？ 需求的使用场景？

• Who？需求的使用对象是谁？

• What？需求是什么？

• How？需求如何实现？（可以不写，但做到心中有数）

• How much？实现需求消耗的资源，或者带来的效益（可以不写，但心中有数）。

例如：网站支持第三方店铺交易。这个需求涉及前后端各个系统，这里只讲前端。

1. Why—为什么会有这个需求？

因为公司的网站支持第三方店铺入驻，网站需要帮助用户鉴别自营商品和第三方商品，且需要将订单商品所在仓库等信息传给订单系统，以便更加便捷地处理订单。‘

2. When—需求产生的条件？

当用户浏览、购买第三方店铺的商品时。

3. Where

单品页、列表页、购物车、提交订单页、订单详情页等页面

4. Who

用户

5. What

帮助用户直观地区分自营商品和第三方店铺商品，提前告知各商家的信息和网购政策，并在用户下单后将每个商品的发货商家传给订单系统。

6. How

（1）当用户在网站上浏览时，告知用户商品是自营商品还是第三方店铺商品；

（2）当用户下单时，不同商家的商品自动分包裹，分别选择运输方式；

（3）告知用户客服、售后等相关政策。

7. How much

前端部分的功能，经开发评估，PHP需要X人力，JS需要Y人力，测试需要Z人力等等；

收益：提升用户体验，降低客服、订单处理等人力成本。

功能描述

功能描述是PRD最核心的章节，需要清晰地表达出产品设计和细节实现。我目前的写法是先对产品设计方案进行简单的概述；然后理清产品的功能逻辑；最后再说明功能的细节实现。

1、方案概述

（1）当用户在网站上浏览时，告知用户商品是自营商品还是第三方店铺商品；

（2）当用户下单时，不同商家的商品自动分包裹，分别选择运输方式；

（3）告知用户客服、售后等相关政策。

（4）用户下单后，把每个商品关联的发货地址传给后端，便于订单处理。

2、功能逻辑

功能逻辑是指用户使用产品的流程，一般用流程图表达会比较清晰，也有的人习惯用“if - else”语句来描述。以“网站支持第三方店铺交易”这个需求为例，设计用户下单的流程。这里需要表达清楚，用户从进入网站到下单成功的整个流程中涉及到的主要逻辑，包括正常情况和异常情况（库存不足等）。

3、功能细节

方案概述和功能逻辑使人对产品/项目有初步的了解，但是想要开发和测试人员顺利开展工作，必须对功能进行细节描述。功能细节一定要描述具体，包括哪些是已有功能，哪些是新增功能，已有功能中哪些需要做修改，详细到把页面所有的交互、控件设计都讲清楚，呈现在开发、设计师眼前的是一个个完整详实的网页。

同时，撰写产品的功能细节，还能帮助产品经理更好地捋顺逻辑，并且自查方案中是否有遗漏掉的地方。

功能细节根据产品的不同情况，可以按照不同功能展开描述，也可以按照不同页面展开描述。以“网站支持第三方店铺交易”为例：

（1）按照功能分类

• 区分第三方店铺商品和自营商品；

设计第三方店铺的图标，放在：单品页、列表页、购物车页、提交订单页和订单详情页。

• 第三方店铺商品与自营商品分包裹发货，并将发货信息传给订单系统；

提交订单时，自动将不同商家的商品分包裹展示：每个包裹显示该包裹包括哪些商品、属于哪个商家、优惠券、保险、运输方式以及对应的运费。

• 运费计算；

  • 于用户：第三方店铺的运费与自营的运费分别如何结算；

  • 于前端计算逻辑：运费计算涉及哪些数据，具体的计算步骤，包括仓库匹配、库存判断、承运商选择逻辑、运费相关费率，是否有相关保险等；

  • 于后端：需要维护哪些数据。

• 客服系统以及售后等相关政策。

  • 第三方店铺有自己的客服系统，还是平台提供客服；

  • 第三方店铺商品的相关政策，需要一个静态页来呈现。

（2）按照页面分类

按页面分类，依次描述每个页面新增、修改的地方：

• 列表页

  • 品类页

  • 搜索结果页

• 单品页

• 购物车页

• 提交订单页

• 我的订单页

除了上述功能相关的，还需要考虑网站的一些特点，比如文案需要翻译成多语言；功能设计师针对PC端还是移动端，等等。

原型设计

原型是前端产品方案最直接的呈现方式，许多开发/领导不喜欢看冗长的产品文档，一般只根据UI设计图来理解产品。原型设计的软件多种多样，最常用的是Axure。如果公司有专门的设计师，则产品经理不需要自己设计UI，但是必须要明确自己想要的UI的样子。这个时候，用Axure画个简单的原型图，可以降低沟通的成本，也可以避免开发、设计师对功能描述的遗漏或者误解。

我在文档里贴原型的时候，习惯按页面进行分类，介绍每个页面的修改情况，并针对需要覆盖到的case，比较它们在同一页面的不同之处。在UI有改动的地方，或者是核心功能，又或者是容易忽略的地方，我都会在图上做一些醒目的标注。

以上是入职几个月来自己总结的PRD撰写方法，没有涉及硬件、资源要求等，还不够完整。而且不同的领域、不同类型的产品，PRD的侧重点会有所不同。以后我还会吸取他人的经验，在工作中不断总结，完善自己这方面的能力。