说到产品经理岗，因为各自从事的细分领域不同、企业风格不同，因此做事的偏重点也会不尽相同。但从大的颗粒度来看无非是采需求、做设计、写文档、盯进度这么几大部分，当然背黑锅、做保姆、活跃组织气氛也是大部分产品人喜闻乐见的日常工作。我们今天就来聊一聊产品经理那些年写过的那些文档。
这里按照适用群体的不同可以大体上将文档分为三个大类，分别是BRD、MRD和PRD（BRD、MRD和PRD分别是商业需求文档、市场需求文档和产品需求文档的简称），其中BRD和MRD分别是为了向老板或投资人展示产品的市场分析、未来发展方向、功能特点、商业模式等便宏观的内容，格式多以PPT为主。
而PRD则是包括了产品的整体说明、功能描述等偏具象的内容，是整体业务的细化和再拆分，是落实到功能点的可执行部分，也是产品和研发沟通的主要文档和重要说明，接下来着重讲一下PRD文档的相关内容。
在说PRD的具体内容前，我们不妨向上溯源，了解下为什么会有PRD这种文档形式，或者说PRD存在的意义是什么。
当我们从用户那里收集到需求后经过初步的市场调研、需求筛选和可行性分析后会将需求转化为一条条用户需求，而在产品经理的规划和分析下会对这些需求进行去重、归类然后转化为产品需求，形成产品功能列表也就是我们常说的Feature List。这时候我们需要将大大小小的功能点汇总成为一个产品并最终实现它就需要将我们的意图系统的表达给设计狮、程序猿，然而此时任何的表达不清或错误都会造成后续工作的无法进行或返工，因此产品需求文档应运而生。
所以对这种文档的判断要求也就变得清晰明了，第一要规范化的格式，不能一个项目一套文档标准，采用统一的规范可以在最大的程度上避免产品设计上的内容疏缺。第二则是要以程序猿、设计狮能理解的语言来描述，专业的术语不仅能减少分歧更能使产品经理给相关各方留下一个专业认真的形象，有利于团队的凝聚力。
相信通过上面的解释，我们应该已经能够明白PRD文档的适用群体和对产品的重要性，那么我们下面不妨来总结下一份优秀的PRD都应该包含哪些内容。
PRD从整体上看可以划分为总体说明部分和UC部分，总体说明部分按照功能的不同又可划分为以下几个模块，分别为修订历史——用以交代每次修改的责任人和修改内容，项目概述——从业务背景和意义入手从整体上告诉读者为什么要做这个产品，功能范围——从全局视角交代产品的功能点，重点描述系统中角色的职责，优先级划分——对功能点进行优先级的排序，以便相关人员快速定位产品的核心功能和规划后续工作安排，非功能性需求——对如性能和埋点等非功能型需求做出相关要求和说明。
UC部分则是由多个用例组成，每个用例对应产品的一个或多个功能点，由用例名、设计图、流程图、用例图、状态图、序列图、用例说明、交换说明、边界条件等部分共同组成，这其中具体采用哪些类型的UML图需要根据产品的业务类型而定。举个栗子，偏向后台流程管理的产品应将重点放在流程图、时序图、类图等能表达清楚业务流程的UML图上，而手机APP类以页面交互为主的产品则应将重点放在用例图、状态图等能够表达页面之间交换和关联关系及用户操作顺序的UML图上。以上内容就是是PRD的核心部分。
总之如果说要用一句话概括PRD是什么，应该酱婶定义，“产品经理向研发和设计详细描述产品功能点的沟通介质”。所以无论PRD的形是什么，一定要向这个核心去努力，注意关键词详细、沟通。
既然PRD的本质是详细的沟通介质，那么理论上只要满足详细和功能的需求都可以用来作为PRD的替代品。然而随着敏捷开发和设计至上的理念深入人心，产品的开发流程也由传统的瀑布式逐渐向产品设计配合不断修改设计，研发测试同步快速迭代功能的敏捷开发转变。所以PRD上的内容经常会需要反复修改，这样PRD的劣势也渐渐凸显出来，比如功能修改后PRD文档的修改常常会忽略相关联的模块，交互设计在PRD这种静态文档形式上不容易展现。
为了解决这些问题不同的公司也会采取不同的处理方案，有的会简化PRD的文档形式、有的则是彻底舍弃PRD以产品原型和用例文档配合来代替。我个人更推荐后一种形式，一则是因为高保真的原型可以更加清楚明白的表述产品的交互样式和功能点，二则是高保真原型在需求修改时更不容易忽略相关的功能点，最后每一个高保真原型都可以作为一个最小的MVP原型，在做用户调研时甚至不需要开发出基本的功能就可以用于用户测试，再配合用例文档和原型上的功能注释，相信会是一种不错的产品需求说明。
然而，一切的的形式都要与对应的目标相配合。无论是PRD文档还是高保真原型，理论上都有其适用的范围，任何一件事或一个道理脱离了他的环境都会变得没有道理，因此要通过现象看本质选择最适合团队的沟通方式才是高于任何文档形式的核心本质。
本文作者：谅直多闻，一个奋斗在北京的异乡青年儿，渴望通过自己的双脚登上产品经理之神道路，并作出一件足以改变世界的产品。
