相信很多同学都很好奇，在一个产品的设计中产品经理到底需要输出多少文档，并且这些文档又有什么作用呢？
相信产品原型、PRD这两个文档名称肯定是大家听的最多的，但是在一个产品的设计中光有这两个就够了么，先让答案是否定的，下面我就把我在产品的设计中会用到的文档类型及其作用做一个详细说明。
首先，在一个产品需求收集阶段，我们需要进行大量的用户访谈或者是调查，在这个阶段我们需要准备一封叫做“需求管理列表”的文档（也有人叫做“需求池”），这份文档也是我们后续工作的指导性文档，很多其他的文档都是从这份文档衍生出来。下面是我们自己的需求管理列表的截图：
需求管理列表示例
这份表格中的内容大多比较好理解，特别需要注意的是优先级和需求来源，这两项属性是后续决定该需求是否实现的重要依据，来源一般可以分为公司内部和外部用户，具体在往细分可以根据自己所在团队的实际情况决定。
在需求收集阶段完成之后，产品经理需要快速的把需求功能化，这一阶段需要把需求抽象、挖掘需求的本质，很多时候不同的需求可以整合到一个功能中进行实现。例如：需求1、我要能够及时的和朋友聊天；需求2、w我想要把自己拍的好看的图片传给我的朋友；需求3、要是能够和朋友进行语音或者是视频聊天就好了。类似这样的描述在需求收集阶段是经常出现的，产品经理需要挖掘其背后的本质，进行需求抽象，形成实际的功能，于是我们需求产生一份功能列表和功能结构图（信息结构图）
功能列表示例
功能结构图示例
在需求功能化的阶段，对每一个子功能都需要整理出对应那个的功能流程图，流程图是产品经理梳理自己的产品逻辑、验证产品效用的重要步骤，在制作流程图的过程中会穷尽功能的各种状态和操作，并在脑海中不断的推演功能的使用场景。在这一阶段一定要定义好具体功能的状态，通过状态去控制不同的操作，而操作又可以改变状态，在这一阶段如果能够对状态和操作进行十分明确的定义，那么在开发进行具体实现时逻辑也会清晰，因为在具体的功能实现中流程往往包含正向和逆向，而通过状态和操的相互影响是解决这两种流程的较优解决方案（至少我现在没有找到更好的解决方案）。
功能流程图示例
往往在你完成了这两份文档的时候，一般你也开始进行原型设计了，会产生线框图、低保真原型、高保真原型等等一系列的原型文档。在很多的产品经理社区一直在讨论原型和prd能不能整合为一个文档，个人认为在原型中加入必要的功能说明和交互说明是很有必要的，但是PRD也是不可缺少的文档，所有文档的存在都有其价值所在，不明白其价值而讨论起存在的合理性都是耍流氓。原型多是在项目进行中使用，其特点：直观、有交互逻辑、能给项目成员真实的体验，在完成的过程中产品经理更多的是处于交互体验的角度去考虑问题；而PRD更多的是保证产品迭代的延续性，其特点：内容全面、定性定量，在团队成员更换、产品周期较长时发挥其作用，在完成过程中产品经理更多的是规范规则和定义。两个文档的意义，决定了他存在的价值。
原型页面结构示例
在以上三分文档（功能列表、功能结构图、产品原型）准备妥当之后，我们就可以愉快的去组织第一次评审会议了，如果要求高的同学，也可以准备对应的演示PPT，主要是对整个产品的介绍，有部分公司可能需要准备MRD文档，进行立项说明，争取更多的公司内部的资源，而像我现在所在的公司属于创业型公司，产品经理提出的绝大部分功能都是为了解决实际问题的，一般不会存在争夺资源的情况。而在不断的评审确认的过程中，一般会输出更多的鱼其他人员对接的文档，与UI沟通的界面跳转流程图、与测试沟通的用例等等。
界面跳转流程图示例
而在评审和确认阶段，需要把最开始的需求管理列表和产品功能列表完善，把项目开发计划于技术人员进行确认，并逐渐完善&优化原型文档、PRD，把产品标准和规则、功能定义及说明、产品风险等事项进行充分考虑。而评审通过后，视觉进行UI设计（原型、界面跳转流程图）、开发进行技术实现（原型、PRD）、测试进行功能检测（功能列表 、PRD、原型）主要的参考依据都是以上文档，至于PRD的模板优秀的太多了，我也就不再进行累赘了。而最后作为一个产品自然少不了自己也体验并测试产品，还会输出测试反馈文档，提出功能优化意见。
测试反馈一览表示例
往往在完成了一个产品后我们都需要对其进行部署、上线，而每一次的上线我总是提心吊胆着，感觉每一次的上线都是在走钢丝，错了一步都会造成巨大的影响，功能是否全部测试到位、程序的代码是否完整的提交了、新老版本直接更新会不会出现意想不到的情况等等，这些问题一致困扰着我，而在经历了若干次的提心吊胆之后，我把上线中可能会遇到的问题整理成了一份上线前的自查清单，每次在上线前都会发送给项目中的各个成员要其对清单中的具体内容进行确认，以保证产品上线的质量，至此一个完整的项目便算完结，而后续的数据统计分析等环节，有时候更多可能是运营需要保证的工作。
产品上线自查清单示例
以上就是我在整个项目的实施过程中需要用到的文档，产品经理需要对接的角色太多，而不同角色的特定或是专业知识也是不一样的，不可能通过一份文档对接所有的干系人，所以会衍生出各种各样的的文档，而这些文档也是必须在实际的项目中遇到问题之后才能体现其价值，而我也是出于希望你能够去实际体验、领悟的目的，故不提供以上文档模板的下载链接。
其实文档不在于类型有多少，内容有多丰富，只在于需要使用你文档的人或是关键点能够发挥文档的价值即可，一切的文档都是为了保证项目的正常进行，保质保量的完美实现。
文中若有不妥的内容，欢迎大家指正！
本文由 @keeliu（微信号cainiaoPM）发布
网友评论