敏捷开发，并不意味着产品经理在写PRD的时候就可以偷工减料，相反，这更考验产品经理的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给PRD阅读者，从而真正达到敏捷开发的目的。

敏捷开发这个词越来越为大家所熟知了。简单来说，敏捷开发就是以用户需求为导向，通过快速开发将产品投入市场，获取市场反馈，从而快速迭代、优化升级、循序渐进的开发方法。

我们不去片面评价敏捷开发的好坏，毕竟事物都具有两面性，任何事物都有各自的优劣。但在创业团队建立的前期，在产品还处于一个idea状态、开发人员并不多的场景下，敏捷开发还有具有一定的优势的。

敏捷开发，其中一个重要原则就是“多沟通，尽量减少文档”。因此，敏捷开发中，产品经理在撰写PRD时，应该尽量做到精简。注意，此处用词是“精简”，而非“简化”。那么，撰写一份精简的PRD，产品经理具体要怎么做呢？

1 直接将PRD在原型上标注

如今，越来越多的产品经理已经摒弃了word冗长的产品需求文档，直接在产品原型上通过备注的形式来说明需求和描述功能点（造成这个现象的原因很大程度上是由于PRD的最重要用户——程序员更偏向于直接看着原型进行开发，经常直接忽略word格式的PRD）。那么，遵循敏捷开发的“尽量减少文档”原则，在形式上，我们更提倡直接将产品需求文档内容标注在原型图上。我想，这对于PM和RD都是一种减少工作量的好方式。当然，前提是你的PRD需求完整且逻辑清晰。

详细的教程请阅读干货：

http://www.woshipm.com/rp/211554.html

http://www.woshipm.com/rp/389092.html

2 产品全局结构图和重要流程的图示不可省略

再精简的PRD仍旧不可或缺结构图和流程图。

首先，全局结构图，作为整个PRD的骨架，可以让PRD阅读者对产品的总体功能构成一目了然，这样在接下来继续阅读每个部分的原型图和对应的说明文档时，思路能够更加清晰。就像每本书都会有目录一样，目录是让你最快了解这本书大概的内容的捷径。

其次，一些基础功能的流程图（如登录注册之类），我们是可以有选择性地不将其呈现在PRD里的；而那些实现重要业务需求的功能流程，我们还是必须将其用流程图清晰展示出来的。这样即使在需求会议后，程序员对某个流程比较模糊了，也可以翻一翻PRD来确认。

所以，重要功能的流程图，可以说是一份PRD的灵魂，是千万不可以省略的（为了避免全是文字，产生视觉疲劳，以用户端的优惠券功能为例，特附优惠券总体结构图和优惠券功能下的一个流程图）。

（优惠券功能总体结构图）

（获取优惠券方式： “摇一摇”流程）

3 重要名词需要有清晰简洁的定义

并不是每个名词都需要写解释、下定义！

我记得刚入行时，第一次写产品说明文档，我甚至还写了“用户”二字的定义。当时的PRD是直接参照公司产品前辈的，他之前写了“用户”的名词解释，于是我也照抄了过来。

（反例：曾经我写的名词解释）

现在想想觉得略为搞笑。因为这个词的定义在APP 1.0版本的时候已经确认过了。而且，这个名词应该属于比较容易理解、不容易产生歧义的范畴。所以我相信，像类似这样的词的解释，对于PRD阅读者来说就是一个无用信息。

好吧。说正事。那么什么时候你需要写名词解释呢？什么词才是重要的词呢？

这个名词在产品设计中第一次出现且是业务需求的重点

例如，当你在设计优惠券功能时，那么“优惠券”这个名词就是一个重要名词。可能大家会说：“不对啊，优惠券不是很好理解吗？需要名词解释吗？”我可以明确告诉你，在这个场景下，需要！这是我之前在一家O2O公司工作时，曾写过的定义：“优惠券是指由xxx平台发行的，用户使用XXX APP 结账时，用于抵扣订单金额的电子券”。这个定义指出了几点关键信息，一优惠券的发行方，仅仅可以使平台，不能是平台的商家；二使用场景是用户在结账时；三作用是抵扣订单金额；四优惠券非实体券，是电子券。

容易混淆的名词

让我们再来举个例子。比如，“连锁店”这个词已经在之前的设计中出现过，也解释过了。但是在你当前的产品设计中，有了一个“商户组”的概念。乍看之下，真的会让人云里雾里，有点懵。光从字面理解，好像都是指代一组商户，具体的区别并不是那么清楚。那么这个时候，你需要将两个概念最好放在同一个页面中以对比的方式解释清楚，以免造成程序员的大脑短路。

（对比方式的名词解释）

为了能真正实现敏捷开发，请提前过滤掉不重要的名词解释，把页面的位置留给那些重要的名词吧！

4 你还需要把规则以及异常情况都写上

看到这里，是不是觉得，其实还是要写挺多东西的呢？没办法，规则和异常情况这二者都是非常重要、不可省略的。其实产品经理的PRD把规则和异常情况写得越清晰，程序员在开发时，就能越顺利。在你把PRD交给技术同学后，你总不希望他们三不五时的来问你“这个列表具体一次加载多少个商户”“如果没有匹配的信息，需要给什么样的反馈呢”之类的问题吧？这样首先拖慢了开发的进度，其次也会显得你作为一个PM非常的不专业！

规则说起来，其实是比较繁杂的一个东西，除了刚刚举例的“商列表页一次加载多少商户”，你可能还要写许多细致的规则如，订单编号的规则是什么、默认排序的规则是什么等等。这里就不一一举例了。相信每个做产品的同学都是明白的，如果一开始规则没写清楚，需求评审会时，就容易被问得哑口无言。

那么异常情况呢，这个更是关键。千万不要小看了异常情况。一个异常情况下（特别是用户端），如果没有友好的指引，你的用户很快就能流失殆尽。举个非常惨痛的例子，还是之前做O2O的公司。用户在支付完成以后，由于APP没有收到某支付平台的回调信息，所以用户看到的界面仍旧还是未完成支付的订单提交页面。但是用户的手机确实能查询到扣款信息。这个时候，那就是非常尴尬了！页面一动不动，也没有任何反馈。那究竟用户算不算付款了呢？这就是由于在产品设计中，没有考虑到支付接口回调异常这个问题，而漏掉了与此相关的产品设计。据当时地推的同事反馈，因为用户无法取消订单，而页面又没有任何反馈，用户不得不在商户那里多呆了半个小时，就为了等支付回调。

我已经用血和泪的教训告诉了大家，敏捷开发中，切记要把规则以及异常情况都写上！！！

5 记录下你的PRD变更

最后一点，简单提一下就可以了。如果提交的原型和对应的PRD更新了，记住把变更的内容写上。嗯，就是我们常说的，版本修改信息。需要的字段有：修改时间、修改内容、备注、修改人。以及，把版本修改信息放在你原型的第一页。

总而言之，敏捷开发，并不意味着产品经理在写PRD的时候就可以偷工减料，相反，这更考验产品经理的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给PRD阅读者，从而真正达到敏捷开发的目的