产品经理写PRD，主要有两种，一种是从0到1的新产品PRD，一种是常规迭代的迭代PRD。这两种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的呢？
如果有更好的方式，欢迎来讨论，如果对这种方式感兴趣，也可以加刀哥微信，刀哥给你分享一些案例。
