当进行敏捷开发时,你的PRD应该怎么写？.pdf

当进行敏捷开发时，你的 PRD 应该怎么写？ 敏捷开发，并不意味着产品经理在写 PRD 的时候就可以偷工减料，相反，这更考验产品经理 的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给 PRD 阅读者， 从而真正达到敏捷开发的目的。 敏捷开发这个词越来越为大家所熟知了。简单来说，敏捷开发就是以用户需求为导向，通过快速开 发将产品投入市场，获取市场反馈，从而快速迭代、优化升级、循序渐进的开发方法。 我们不去片面评价敏捷开发的好坏，毕竟事物都具有两面性，任何事物都有各自的优劣。但在创业 团队建立的前期，在产品还处于一个 idea 状态、开发人员并不多的场景下，敏捷开发还有具有一定 的优势的。 敏捷开发，其中一个重要原则就是 多沟通，尽量减少文档“ ”。因此，敏捷开发中，产品经理在撰 写 PRD 时，应该尽量做到精简。注意，此处用词是 精简“ ”，而非 简化“ ”。那么，撰写一份精简的 PRD ，产品经理具体要怎么做呢？ 1 直接将 PRD 在原型上标注 如今，越来越多的产品经理已经摒弃了 word 冗长的产品需求文档，直接在产品原型上通过备注的形 式来说明需求和描述功能点（造成这个现象的原因很大程度上是由于 PRD 的最重要用户 —— 程序员 更偏向于直接看着原型进行开发，经常直接忽略 word 格式的 PRD ）。那么，遵循敏捷开发的 尽量“ 减少文档 ”原则，在形式上，我们更提倡直接将产品需求文档内容标注在原型图上。我想，这对 于 PM 和 RD 都是一种减少工作量的好方式。当然，前提是你的 PRD 需求完整且逻辑清晰。 详细的教程请阅读干货： /rp/211554.html /rp/389092.html 2 产品全局结构图和重要流程的图示不可省略 再精简的 PRD 仍旧不可或缺结构图和流程图。 首先，全局结构图，作为整个 PRD 的骨架，可以让 PRD 阅读者对产品的总体功能构成一目了然，这 样在接下来继续阅读每个部分的原型图和对应的说明文档时，思路能够更加清晰。就像每本书都会 有目录一样，目录是让你最快了解这本书大概的内容的捷径。 其次，一些基础功能的流程图（如登录注册之类），我们是可以有选择性地不将其呈现在 PRD 里的 ；而那些实现重要业务需求的功能流程，我们还是必须将其用流程图清晰展示出来的。这样即使在 需求会议后，程序员对某个流程比较模糊了，也可以翻一翻 PRD 来确认。 所以，重要功能的流程图，可以说是一份 PRD 的灵魂，是千万不可以省略的（为了避免全是文字， 产生视觉疲劳，以用户端的优惠券功能为例，特附优惠券总体结构图和优惠券功能下的一个流 程图）。 （优惠券功能总体结构图） （获取优惠券方式： 摇一摇“ ”流程） 3 重要名词需要有清晰简洁的定义 并不是每个名词都需要写解释、下定义！ 我记得刚入行时，第一次写产品说明文档，我甚至还写了 用户“ ”二字的定义。当时的 PRD 是直接参 照公司产品前辈的，他之前写了 用户“ ”的名词解释，于是我也照抄了过来。 （反例：曾经我写的名词解释） 现在想想觉得略为搞笑。因为这个词的定义在 APP 1.0 版本的时候已经确认过了。而且，这个名词 应该属于比较容易理解、不容易产生歧义的范畴。所以我相信，像类似这样的词的解释，对于 PRD 阅读者来说就是一个无用信息。 好吧。说正事。那么什么时候你需要写名词解释呢？什么词才是重要的词呢？ 这个名词在产品设计中第一次出现且是业务需求的重点 例如，当你在设计优惠券功能时，那么 优惠券“ ”这个名词就是一个重要名词。可能大家会说：