当进行敏捷开发时你的应该怎么写

　　敏捷开发，并不意味着产品经理在写PRD的时候就可以偷工减料，相反，这更考验产品经理的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给PRD阅读者，从而真正达到敏捷开发的目的。
　　敏捷开发这个词越来越为大家所熟知了。简单来说，敏捷开发就是以用户需求为导向，通过快速开发将产品投入市场，获取市场反馈，从而快速迭代、优化升级、循序渐进的开发方法。
　　我们不去片面评价敏捷开发的好坏，毕竟事物都具有两面性，任何事物都有各自的优劣。但在创业团队建立的前期，在产品还处于一个idea状态、开发人员并不多的场景下，敏捷开发还有具有一定的优势的。
　　敏捷开发，其中一个重要原则就是多沟通，尽量减少文档。因此，敏捷开发中，产品经理在撰写PRD时，应该尽量做到精简。注意，此处用词是精简，而非简化。那么，撰写一份精简的PRD，产品经理具体要怎么做呢？
　　1直接将PRD在原型上标注
　　如今，越来越多的产品经理已经摒弃了word冗长的产品需求文档，直接在产品原型上通过备注的形式来说明需求和描述功能点（造成这个现象的原因很大程度上是由于PRD的最重要用户程序员更偏向于直接看着原型进行开发，经常直接忽略word格式的PRD）。那么，遵循敏捷开发的尽量减少文档原则，在形式上，我们更提倡直接将产品需求文档内容标注在原型图上。我想，这对于PM和RD都是一种减少工作量的好方式。当然，前提是你的PRD需求完整且逻辑清晰。
　　详细的教程请阅读干货：
　　http：www。woshipm。comrp211554。html
　　http：www。woshipm。comrp389092。html
　　2产品全局结构图和重要流程的图示不可省略
　　再精简的PRD仍旧不可或缺结构图和流程图。
　　首先，全局结构图，作为整个PRD的骨架，可以让PRD阅读者对产品的总体功能构成一目了然，这样在接下来继续阅读每个部分的原型图和对应的说明文档时，思路能够更加清晰。就像每本书都会有目录一样，目录是让你最快了解这本书大概的内容的捷径。
　　其次，一些基础功能的流程图（如登录注册之类），我们是可以有选择性地不将其呈现在PRD里的；而那些实现重要业务需求的功能流程，我们还是必须将其用流程图清晰展示出来的。这样即使在需求会议后，程序员对某个流程比较模糊了，也可以翻一翻PRD来确认。
　　所以，重要功能的流程图，可以说是一份PRD的灵魂，是千万不可以省略的（为了避免全是文字，产生视觉疲劳，以用户端的优惠券功能为例，特附优惠券总体结构图和优惠券功能下的一个流程图）。
　　（优惠券功能总体结构图）
　　（获取优惠券方式：摇一摇流程）
　　3重要名词需要有清晰简洁的定义
　　并不是每个名词都需要写解释、下定义！
　　我记得刚入行时，第一次写产品说明文档，我甚至还写了用户二字的定义。当时的PRD是直接参照公司产品前辈的，他之前写了用户的名词解释，于是我也照抄了过来。
　　（反例：曾经我写的名词解释）
　　现在想想觉得略为搞笑。因为这个词的定义在APP1。0版本的时候已经确认过了。而且，这个名词应该属于比较容易理解、不容易产生歧义的范畴。所以我相信，像类似这样的词的解释，对于PRD阅读者来说就是一个无用信息。
　　好吧。说正事。那么什么时候你需要写名词解释呢？什么词才是重要的词呢？
　　这个名词在产品设计中第一次出现且是业务需求的重点
　　例如，当你在设计优惠券功能时，那么优惠券这个名词就是一个重要名词。可能大家会说：不对啊，优惠券不是很好理解吗？需要名词解释吗？我可以明确告诉你，在这个场景下，需要！这是我之前在一家O2O公司工作时，曾写过的定义：优惠券是指由xxx平台发行的，用户使用XXXAPP结账时，用于抵扣订单金额的电子券。这个定义指出了几点关键信息，一优惠券的发行方，仅仅可以使平台，不能是平台的商家；二使用场景是用户在结账时；三作用是抵扣订单金额；四优惠券非实体券，是电子券。
　　容易混淆的名词
　　让我们再来举个例子。比如，连锁店这个词已经在之前的设计中出现过，也解释过了。但是在你当前的产品设计中，有了一个商户组的概念。乍看之下，真的会让人云里雾里，有点懵。光从字面理解，好像都是指代一组商户，具体的区别并不是那么清楚。那么这个时候，你需要将两个概念最好放在同一个页面中以对比的方式解释清楚，以免造成程序员的大脑短路。
　　（对比方式的名词解释）
　　为了能真正实现敏捷开发，请提前过滤掉不重要的名词解释，把页面的位置留给那些重要的名词吧！
　　4你还需要把规则以及异常情况都写上
　　看到这里，是不是觉得，其实还是要写挺多东西的呢？没办法，规则和异常情况这二者都是非常重要、不可省略的。其实产品经理的PRD把规则和异常情况写得越清晰，程序员在开发时，就能越顺利。在你把PRD交给技术同学后，你总不希望他们三不五时的来问你这个列表具体一次加载多少个商户如果没有匹配的信息，需要给什么样的反馈呢之类的问题吧？这样首先拖慢了开发的进度，其次也会显得你作为一个PM非常的不专业！
　　规则说起来，其实是比较繁杂的一个东西，除了刚刚举例的商列表页一次加载多少商户，你可能还要写许多细致的规则如，订单编号的规则是什么、默认排序的规则是什么等等。这里就不一一举例了。相信每个做产品的同学都是明白的，如果一开始规则没写清楚，需求评审会时，就容易被问得哑口无言。
　　那么异常情况呢，这个更是关键。千万不要小看了异常情况。一个异常情况下（特别是用户端），如果没有友好的指引，你的用户很快就能流失殆尽。举个非常惨痛的例子，还是之前做O2O的公司。用户在支付完成以后，由于APP没有收到某支付平台的回调信息，所以用户看到的界面仍旧还是未完成支付的订单提交页面。但是用户的手机确实能查询到扣款信息。这个时候，那就是非常尴尬了！页面一动不动，也没有任何反馈。那究竟用户算不算付款了呢？这就是由于在产品设计中，没有考虑到支付接口回调异常这个问题，而漏掉了与此相关的产品设计。据当时地推的同事反馈，因为用户无法取消订单，而页面又没有任何反馈，用户不得不在商户那里多呆了半个小时，就为了等支付回调。
　　我已经用血和泪的教训告诉了大家，敏捷开发中，切记要把规则以及异常情况都写上！！！
　　5记录下你的PRD变更
　　最后一点，简单提一下就可以了。如果提交的原型和对应的PRD更新了，记住把变更的内容写上。嗯，就是我们常说的，版本修改信息。需要的字段有：修改时间、修改内容、备注、修改人。以及，把版本修改信息放在你原型的第一页。
　　总而言之，敏捷开发，并不意味着产品经理在写PRD的时候就可以偷工减料，相反，这更考验产品经理的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给PRD阅读者，从而真正达到敏捷开发的目的。
　　P。S：我也是正在学习中的产品，以上仅为个人经验，若有错误的地方，欢迎指正。