最近项目相对轻松一点，所以想把工作中和行业里的一些干货知识总结一下，绝不空空其谈，不定期更新。
干货知识问答系列第一篇——产品PRD的撰写。
Q1：什么是PRD？
A：PRD的全称是Product Requirement Document，翻译为中文就是“产品需求文档”。
Q2：PRD的作用是什么？为什么要写产品PRD？
A：先说说一般做产品的流程（不仅仅是软件产品，实物产品也是一样）：有一个idea——市场调研验证idea是否可行——详细规划idea的实现细节——把idea变成现实——测试验证——投入市场，运营宣传，盈利。
PRD其实就是“详细规划idea的实现细节”这一步骤，之所做这一步骤，是为了更好的完成下一步“把idea变成现实”。当我们从用户/客户那里收集到需求后，会将需求转化为一条条用户需求（中间可能会经过一些市场调研、需求筛选和可行性分析），而在产品经理或者UX设计师的规划和分析下会对这些需求进行去重、归类然后转化为产品需求，形成产品功能列表（Feature List）。这时候我们需要将大大小小的功能点汇总成为一个产品并最终实现它就需要将我们的意图系统的表达给设计狮、程序猿，然而此时任何的表达不清或错误都会造成后续工作的无法进行或返工，因此产品需求文档应运而生。
通俗来说，PRD就是将产品概念图纸化，用于完整描述产品需求，需要阐述详细的细节和实现模型。用于向研发相关人员说明需要开发的产品功能和这些功能的性能要求。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。PRD质量的好坏，在很大程度上直接影响着研发部门是否可以明确产品的功能和性能，好的PRD能够让产品研发更高效，流程更规范。
除此之外，产品开发过程中，大多数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD的文档修订编号和命名也是项目规范化管理的主要方法之一。
Q3：谁来编写产品PRD？
A：PRD的面向对象主要是研发部门，撰写者一般是PM，不过不同的公司工作安排不同，比如我们公司的PRD由交互设计师撰写。
Q4：PRD包含哪些内容？
A：PRD从整体上看通常包含以下内容：
1、封面部分：标题，编写人员信息等
2、修订历史：以交代每次修改的责任人和修改内容
3、项目概述：项目背景、行业现状等（从业务背景和意义出发，从整体上告诉读者为什么要做这个产品）
4、产品功能范围：从全局视角交代产品的各个功能点，重点描述系统中角色的职责，并标明每个功能的优先级，以便相关人员快速定位产品的核心功能和规划后续工作安排。
5、非功能性需求：一些非功能性的，但是必须说明的内容。如：性能和规划埋点等
6、用例详述：每个用例对应产品的一个或多个功能点，由用例名、用例描述，优先级，设计图、流程图、用例图、状态图、序列图、用例说明、交换说明、边界条件，前置条件等部分共同组成，这其中具体采用哪些类型的UML图需要根据产品的业务类型而定。
以上内容中，4、5、6三点是PRD的核心内容。
Q5：撰写产品PRD有哪些注意事项？
A：1，有规范化的格式，一般的公司都有自己的惯用格式，采用统一的规范可以在最大的程度上避免产品设计上的内容缺失，也降低了阅读人员的学习阅读成本。
2，写PRD一定要时刻想着换位思考，你得想着你的文档是给开发、设计、测试等看的，语言上尽量好理解，尽量不要用形容词，描述功能时，可以尝试用开发的逻辑去思考书写方式。要以程序猿、设计狮能理解的语言来描述，一定要让开发人员阅读无障碍。此外专业的术语不仅能减少分歧更能给相关各方留下一个专业认真的形象，有利于团队的凝聚力。
Q6：怎么撰写产品PRD？
A：这是最核心的问题，很多产品新人孜孜不倦的在网上浏览大把的文章，苦苦追寻PRD模板，就想知道该怎么写PRD文档，其实，PRD本没有什么模板可言，只要你写的PRD思路清晰，逻辑合理，表达清楚了产品需求就行了。验证PRD最好的方法就是，把你写的PRD拿给开发人员看，看工程师能不能看懂，他们是否不需要问什么问题就知道自己该怎么做？如果答案都是肯定的，那么，你的PRD在“内容”上就合格了（至于产品设计是否合理，这又是一个巨大的工程，需要测试部门乃至用户来验证了）。一份好的PRD的检验标准就是技术人员只有你的PRD，不经过语言沟通，他做出来的东西与你的设想一模一样。
不过以下几个步骤，是我们在撰写PRD时一定要做的事情。
第一步：前期准备
在做一个产品之前，我们必须做好前期的准备工作。包括市场调研，用户研究，竞品分析等，我们需要去了解所规划产品顾客、竞争对手、产品团队的实力和需要的技术。磨刀不费砍材功，准备工作做的够好，可以增强信心和说服力。
第二步：确定产品需求
每一个产品都开始于无数个需求。你必须清楚的了解这些需求，你的产品如何达到这些需求。
产品需求需要确切的指出这个产品发布的目标，并且有优先级之分。例如，你的目标可能是：
1、一款智能音箱，
2、可以控制家居设备
3、零售价不要超过4000元
4、产品要配备一个摄像头
5、用户体验要好
……
这些需求，有的来源于老板（1），有的来源于商业合作要求（4），有的来源于市场（2，3，5）你需要明确产品这些目标如何达到？怎么算达到？因为这些需求限制了你的产品规划思路
第三步：明确你可运用的资源
很少有人提到这步，很多人都是大张旗鼓的说什么用户分析啊，用户画像啊，用户行为分析啊这些，当然，这些非常重要，做用户体验，最重要这点。理论如此，有几家公司能够砸钱给你做这么多的用户研究，在退一步，你做了这些研究，针对用户需求把产品设计出来交付给工程师之后，程序员告诉你：“我写不出来。”怎么办？我个人意志秉承的观点是，厨师应该先看自己有些什么材料，在决定做什么菜。当我们做了市场调研，做了需求分析之后，我们要清点自己手中的资源，在前两步的规划中做减法，或者排优先级。如果必要资源缺失，应当立即做资源补充。
第四步：明确功能，逻辑流程和用例
有了前三步骤，基本上产品的方向已经定下来了，这个时候，我们需要把功能和逻辑流程梳理出来，利用各种图，表，文字等形式呈现出来。
第五步：写
写，把前四步积累的东西写下来，注意条理清晰，内容简洁，及时保存和备份。
第六步：修订
多找人提提意见，同时也要有自己的想法，我见过有人写PRD，别人说改哪里他就改哪里，没有主见和判断力。一般公司都会有PRD评审会，经过评审后的PRD，在非特殊情况，一般不用大改。
最后，很重要的一点需要明确：
PRD的本质是产品开发过程中详细的沟通介质，所以理论上只要满足详细和功能的需求都可以用来作为PRD的替代品。随着敏捷开发和设计至上的理念深入人心，产品的开发流程也由传统的瀑布式逐渐向产品设计配合不断修改设计，研发测试同步快速迭代功能的敏捷开发转变。所以PRD上的内容经常会需要反复修改，这样PRD的劣势也渐渐凸显出来，比如功能修改后PRD文档的修改常常会忽略相关联的模块，交互设计在PRD这种静态文档形式上不容易展现。
为了解决这些问题不同的公司也会采取不同的处理方案，有的会简化PRD的文档形式、有的则是彻底舍弃PRD以产品原型和用例文档配合来代替。于是很多人开始利用Axure等原型工具来写PRD，利用低/高保真原型来说明产品需求。刨去时间成本不说，高保真原型的确是很不错的一个选择，尤其是对于APP和网页类的产品。一是因为高保真的原型可以更加清楚明白的表述产品的交互样式和功能点，二是高保真原型在需求修改时更不容易忽略相关的功能点，最后每一个高保真原型都可以作为一个最小的MVP原型，在做用户调研时甚至不需要开发出基本的功能就可以用于用户测试，再配合用例文档和原型上的功能注释，会是一种不错的产品需求说明。
然而，一切的的形式都要与对应的目标相配合。无论是PRD文档还是高保真原型，理论上都有其适用的范围，任何一件事或一个道理脱离了他的环境都会变得没有道理，因此要通过现象看本质选择最适合团队的沟通方式才是高于任何文档形式的核心本质。
