PRD之集装需求和散装需求

很多老铁也问过刀哥这个问题，刀哥曾经也被这个问题困扰过。经过一段时间的摸索，和程序猿大哥们也有过一些沟通，最终总结出了一套刀哥觉得还不错的写法。

这篇文章，就来跟大家分享一下两种文档的写法。

01 封装需求和散装需求

从0到1的新产品PRD，我将其定义为封装需求。封装需求需要具备完整的PRD文档结构，尤其是项目背景、全局说明和核心业务流程，需要从总设计师的角度，全面概述，同时也需要详细描述具体的用例，宏观和微观都涉及。

常规迭代的PRD，我将其定义为散装需求。散装需求是在总框架下的局部增改，着重强调具体改动的功能点及用例描述，属于微观层面。

封装需求的写法，之前刀哥有篇文章已经详细介绍过了，在刀哥的公众号回复PRD可以查看。这份封装PRD，是用Word写的。

但是用Word这种文档方式写PRD有个问题。每次迭代都会产生一个新文档，即散装PRD，每个散装PRD，都涉及对以前的功能规则调整。

几个版本以后，团队人员对某个功能的规则已经忘了，想去追溯历史的时候，找文档需要花费大量的时间，甚至都忘了在哪个版本里改过，不确定看到的规则是否是最新的规则。

这时，一份含有全量产品规则的PRD，显得尤为重要。我把这种含有全量产品规则的PRD叫做『产品白皮书』

当团队里任何一个人，想确认某个功能规则的时候，直接查阅这份『产品白皮书』即可。

团队内如果有一份产品白皮书，再也不用担心历史业务规则的追溯，也不用担心PM离职后没有熟知业务规则。

用Word来维护产品白皮书，有2种方式，一种是每次写需求都在封装PRD里写，标注变更内容，另一种方式是每次散装PRD实现后，再更新进封装PRD。

前一种方式开发看起来费劲，每次都去文档里找变更内容，如果不细心漏掉关键内容，又得扯皮，后一种维护工作量巨大，如果有一次忘了，白皮书就不全。

有没有更好的方式呢？

有。用Axure+蓝湖，完美的实现了维护白皮书（封装PRD）的同时，兼容散装需求。

02 实现方法

1、用Axure写一份封装PRD，写完之后用蓝湖生成在线版本，例如：V1.0

2、写散装PRD时，直接在原型上改，改完之后，再生成蓝湖在线文档，例如命名V1.1，散装需求就生成了。生成散装需求需要注意几点：①每次生成散装需求，需要将全局说明勾上；②担心覆盖之前的RP文档不能撤回，可以复制一份RP文件以备份。

3、生成一份全量的在线文档，作为『产品白皮书』

以上步骤后，蓝湖上可以看到多份在线文档：产品V1.0、产品V1.1……产品全量文档（白皮书）

有了这些文档，想了解最新产品功能的规则，查看白皮书，想看版本的历史迭代记录，看散装文档，因为每个版本都记录。

再也不用担心人员离职没人知道规则，也不担心过程文档查找起来费劲，文档维护也特别轻松。

03 写在最后

PRD有两种类型：封装PRD、散装PRD。

封装PRD应用于从0到1的新产品，散装PRD应用于版本迭代。

写PRD没有最好的工具，只有最合适的工具。维护一份产品白皮书可以解决很多问题。

刀哥目前用这种PRD的方式，在团队内部磨合了一段时间，整体效果还是不错。

你是用什么方式写封装PRD和散装PRD的呢？

如果有更好的方式，欢迎来讨论，如果对这种方式感兴趣，也可以加刀哥微信，刀哥给你分享一些案例。