由于曾经做过多年的测试工作，长期和产品经理交付的需求打交道，见过不同形式的需求交付在团队中的表现形式和作用；当后来真的成为一名产品经理以后，从接受信息方变为了输出信息方，有了一些自己的思考和感受总结，分享在这里。

在过往的经验中，经历了以下 2种场景的需求交付，分别有不同的对应方法如下：

适配场景--倾向于给产品模块做优化的需求交付

第1种ppt式的交付：

 前提：通过需求采集后，一开始计划有了要做哪些的需求清单，项目起源于计划驱动，滚动发版模式

 需要进行如下步骤：

 --》一张静态页面图+业务逻辑规则说明

 --》会议评审 通过与否

--》开发进行开发，开发测试中随时答疑

第2种禅道工具化的交付

前提：产品需求不断已经采集到禅道工具系统中，项目起源于需求接收驱动，滚动发版模式

需要进行如下步骤：

 --》禅道中，录入静态图+业务规则说明

 --》会议评审时，直接打开禅道过需求

 --》要做的直接就将任务分配给了A开发，去做

--》会议结束后，就确定出了要做哪些的需求清单list,把这部分清单发给项目经理或开发经理去跟进进度，保证按时按质交付。

总结：以上2种方式来源于一个产品的规模，不同驱动模式，禅道的管理方式可能会更加便捷快速一些，但当系统过于庞大和需求问题较多时，就需要从这些需求中列出计划再划分版本管理，做开发。

---

适配场景--整个独立系统+模块设计从无到有的需求交付

第1种PRD式的交付：

前提：PRD是一套word模板，规定了必须有的流程图、设计图、业务规则（前提、输入、输出、操作步骤文字模板化表达出）

需求进行如下步骤：

--》搭建整个系统的目录框架，总的业务流程图是怎样的？需要哪些模块来支撑？

--》按照目录框架进行模块设计，用流程图+静态图+业务规则说明（前提、输入、输出、操作步骤文字模板化表达出）

总结：综合来说性价比用于内部团队有些浪费

--》好处是：模板化的保证了该有的内容就必须要有

--》坏处是：坏处是看起来费时费力，需要开发看文档做转化，更加适配于低沟通力的团队，按照文档进行开发，保证产出，但文字理解上有偏差还是需要沟通的。

第2种axure交付：

前提：熟练使用axure工具

需求进行如下步骤：

--》搭建整个系统的目录框架，总的业务流程图是怎样的？需要哪些模块来支撑？

--》按照目录框架进行模块设计，用流程图+静态图+业务规则说明（按照页面元素所需经验来）

--》确定使用低保真简版，还是高保真动态版

总结：低保真简版，还是高保真动态版各有优劣，看团队的成熟度而言机动选择

1、最简版快速的方式：用静态图+箭头作为交互方式，+业务规则说明（综合来说适配于内部团队）

 --》好处是：原型设计的时间最短

--》坏处是：有的交付细节可能体现不到，需要补充文字说明，容易产生一些细节的信息遗漏（比如切换页签，列表内容是否有变化）

 2、相对完善的axure交付方式：动态交互按钮，页面点击情况做上去,+业务规则说明（综合来说适配于内部团队+外部团队，甲方对乙方时，为了减少信息的失真性，高保真性要求会高一些）

--》好处是：对于开发而言，所有的按钮，页面元素基本和开发出的系统一致，属于动态模型，转化理解阻力较小

--》坏处是：产品设计的时间相对较长，要通过工具把所有的动态交互做出来，对产品人员使用axure的熟练度要求会稍高一些