编辑导语：写PRD需求的时候，总会遇到各种坑。如何避免或少踩一些坑？作者从用户的角度分享了自己的精彩问题和解决方法，希望对大家有所帮助。
#一、背景叙述
接到公司任务后，做《避坑36计》分享珠三角写作思路。
之前的G端需求调研避免了坑分享，让我们公司几百人看到什么是自杀弄巧成拙的总结，说出自己遇到的各种奇葩问题和解决方法。这一次，我决定改变这种吃力不讨好的方式。
毕竟公司的产品都是被迫参与，改变策略，不谈个人经历，收集一波研发；d、设计投诉，然后一起分析讨论需求。这就决定了本期《用户视角的PRD撰写》的主题。
决定记录，一方面提炼总结和自我提醒；另一方面是与同行交流避坑经验，互相交流帮助，碰撞出更好的解决方案。更好地满足用户对珠三角产品的需求。
注：总结来自创业物业公司，可能与大厂遇到的问题不同。如有不同意见，欢迎交流。
#二。现有声音集合
为了收集现有的痛点和需求，我先问了设计师和研发；d工作人员一个小问题：你觉得产品的PRD怎么样？
我得到了问题的反馈，既生气又好笑，含蓄又直接。八分的玩笑透露出我很认真，但每一个反馈都值得认真对待。确实是一群有想法、有产出、能抗伤害的同事。
虽然个人认为，珠三角并不一定要实现所有的互动跳跃，但从整个流程来看，在需求不明确的场景下，B端/G端产品发生变化的风险很大。交互不难实现，但维护成本太高，有被错过的可能。
拆解研发的潜在需求；d槽其实感觉现有的表达方式不清晰，页面的跳转关系呈现不好，导致团队沟通困难。他认为交互只是他作为用户提出的解决方案。
所有上诉可以归纳为两点：
所以，我问了其他产品：你写PRD担心过什么？.
也有一些问题是我刚换产品的时候比较担心的。看到这里的读者，不知道有没有类似的顾虑？
# 3.珠三角用户视角分析
使用基本分析工具5W1H拆解PRD的用户需求。
# # 1 \.什么：什么是珠三角？
首先，在定位上，PRD是产品经理的沟通工具。两个最复杂的表达是单词Axure和Axure。两者各有利弊。事实上，它们不需要局限于一种形式。可以根据使用场景选择合适的表达形式。
## 2\.为什么：为什么写PRD？
在这里，引用其他定义并解释。
产品原型的目的是清晰表达产品设计理念、功能交互和执行逻辑，提高产品、研发；d、UI和业务部门，避免因信息不对称和信息传递的遗漏和不足而导致整个项目进度的延误。
个人经验，总结为两点：
人们说的是：减少扯皮，避免返工；能偷懒就偷懒，减少加班。
# # 3 \.什么时候：PRD是在什么阶段写的？
理论上，PRD作为产品需求文件，是继BRD和MRD之后，从产品规划到产品设计的阶段性成果。在中小公司，往往缺乏规划阶段的业务论证和市场验证。需求来源于领导者对市场决定做还是不做的敏感度，缺失的业务需求文档和市场需求分析。
结果就是在珠三角梳理的过程中，决策受到影响。结果，一些功能需求在后期摇摆不定，因为缺少这样的信息输入，直到细化PRD之后，底层逻辑需求才出现错误，导致大面积返工。
rge/pgc-image/SeWEfFzH0tYej8' />而在实践中，经常为了更快产出，会变成PRD通关全过程，缺少BRD、MRD的阶段和产出。
BRD：Business Requirement Document，产品向上沟通立项的工具。
内容：说明产品卖给谁、成本和收入情况、为什么能赢利等关键问题。阐述为什么立项，为公司提供信息，从而决策该产品是否有投入资源的价值。
MRD：Market Requirement Document
定义： 向上沟通要做什么、怎么做的工具。
内容：
说明所处行业的市场情况、目标用户、竞品情况、自身策略等信息。阐述内外环境影响，向公司说明产品在市场中的定位和策略，核心是为该产品在同公司的众多产品线中，争取更多的研发、运营和市场资源倾斜。
where：PRD在哪儿写？
此处可划分为两大阶段，四个类型。两大阶段为需求评审、交互评审；四个类型为项目的大版本需求设计、项目的小迭代需求、新产品从0-1孵化、新产品迭代需求。在不同环节，关注的内容会有所不同。
## 4\. who：分辨PRD用户是谁
在B端、G端产品中，PRD的用户在产品工作中的上下游环节，可分为公司外部相关方、内部成员。
1）内部成员：内部用户和C端基本一样。
a）需求评审阶段： 主要面向领导、研发负责人、产品负责人、项目经理。希望获取的信息如下：
* 需求价值
* 目标
* 用户故事（为谁在什么场景下解决什么问题）
* 方案可行性
* 成本（功能清单）
* 需求优先级
* 竞争力情况
* 产品架构（和其他模块的关系）
b）交互评审阶段： 主要面向前端、后端、设计、测试、项目经理、协同产品。希望获取的信息如下：
* 需求价值
* 目标
* 用户故事（为谁在什么场景下解决什么问题）
* 方案可行性
* 需求优先级
* 产品架构（和其他模块的关系）
* 页面交互
* 性能要求
作为PRD文档，交互评审阶段为核心业务场景。详细拆解该阶段各类用户的核心关注点，如下：
后端： 关注数据从哪来，数据有什么，哪些需要存，如何建表存，这些数据是否需要支持增、删、改、查等功能，需要为产品提供哪些接口，评估方案可实施性。
前端：
关注后端接口如何与前端界面结合，调取后端哪个接口，并用怎样的方式为后端收集入参，在收集入参时前端是否要做额外的限制，以及后端返回的出参如何转化为前端的提示等，评估方案可实施性。
设计师： 关注信息布局和交互的合理性、用户体验、产品的界面调性。作为产品下游，他们往往是最关注PRD中原型内容的人。
测试： 关注产品的user
story，因为QA需要模拟不同的使用场景设计测试case，大部分情况下QA会用Xmind等脑图设计工具来设计、覆盖可能出现的case，并进行遍历测试。
协同产品： 产品中有哪些通用概念，本次迭代与之前版本的功能迭代的关系，需求的紧急性和重要性。
2）外部相关方与C端不同在于，B端和G端的外部相关方，对产品有绝对性影响。可划分为高、中、基层甲方领导。
* 甲方高层：很多不看，他们喜欢看PPT和上线系统，部分喜好抠“字眼”。
* 甲方中层：注重业务逻辑（解决了什么问题）、功能价值（可达到的效果）、用户场景（为谁在什么场景下解决什么问题）、使用体验，部分喜好抠字段、交互和视觉呈现。
* 甲方基层：注重功能使用场景（功能是否满足业务需求）、使用体验、字段。
# 四、how：PRD的内容要素
PRD涉及的信息要素有版本记录、需求分析、需求设计、全局说明、原型设计四大内容。在不同阶段场景下，涉及的内容略有差别，具体内容如下图。
此处进行总结罗列，不做内容拆解，等有时间精力梳理时，再进行总结分享。
# 五、PRD撰写的避坑总结
## 1\. 避坑一：无版本记录、修订记录
版本记录、修订记录不可少。在PRD里直接记录，每次修改时顺手完成，成本远远小于事后追溯。
版本记录：用于方便对应不同版本。内容包含系统名称、文档版本号、系统版本号、创建时间、产品经理、UI设计师、前端、后台人员信息。
修订记录：易于回溯和总结变更原因，保障下次的输出。内容包含修订日期、文档版本、所在页面、变更内容、修订情况、修订人员。
在这过程中，不但要补充内容，也要思考需要修改的原因是什么。是需求挖掘没有到位？没有找到关键的业务干系人？业务流程存在疏漏？还是外部商务因素干扰引发的需求反复？
要综合衡量每次修改的成本差异、实现效果。思考修改变动是否能解决用户核心问题，此次修改是不是项目中最需要坚持的核心功能流程，要注意把撕逼的机会留给守护核心功能流程上。
## 2\. 避坑二：需求背景描述不全面
需求背景需全面，尽量还原业务场景。需求收集-
分析的过程，是产品设计的输入，让产品经理能摸清问题的本源。沟通要在信息对等的前提下进行，需求场景表达越合理，越能让团队觉得自己所做事情是有价值的。
如果被质疑时，你只能说出“老板/领导要这么做”的话，说明你在需求调研和需求分析阶段偷了懒，没有负起责任，这也容易因为对需求理解不到位造成返工。
做功能只是手段、不是目的。不要只做传话者，变成了自己讨厌的人。
常见的需求来源有：
## 3\. 避坑三：需求评审阶段，未梳理系统依赖
B/G端系统，常依赖于其他系统数据，在需求评审阶段，就需梳理清楚所有所需数据来源、系统依赖。
一方面，是进行初步的可行性评估，明确所需条件是否具备；另一方面，可提前协调相关资源，预留字段和接口。若交互设计阶段，才进行相关梳理和确认，易造成决策返工，可能会发现前置条件并不满足。
## 4\. 避坑四：数据层分析缺失
交互评审中，数据分析梳理不可缺。B/G端系统设计中，数据是核心。其中数据清单列表、实体关系图是每次需求都需梳理和更新的必要信息，数据流程图可根据需求的复杂程度决定是否分析。
## 5\. 避坑五：信息不清晰 布局不简洁
信息结构尽量清晰，布局尽量简洁。无论页面设计，还是PRD的排版布局，都要注意信息设计的合理性。并且内容越清晰，越能降低评审人员的理解门槛，提前讨论疑问点，让评审效率更高。形式的建议如下：
1) 图文结构化布局
页面元素与注释对应清晰，最好在元素边上就是注释。
2) 文字排版简洁
描述简洁精炼。避免大段文字，多分行。
信息要放得下。放不下又全要，就换个交互形式。
考虑信息主次。考虑信息的次序感，通过字体类型（粗细）和字号区分出信息层级和描述重点。
3) 色彩简洁
避免丰富的颜色。用黑白灰+主题色+强调色。
## 6\. 避坑六：忽略细节定义
注意细节定义。以下几点，都是较为重要且易被忽略的。
* 定义数据
* 定义地图交互
* 定义异常状态反馈
* 定义排序规则
* 定义状态机
最后，其实还需结果导向，不要拘泥于形式表达，最终是希望能和上下游高效协同。
# 六、总结&思考
前期设计环节考虑越充分，越能保障后续实现的质量。所以还是有必要梳理PRD规范。当生产中的每个环节都保证生产质量，从整条生产链来看，会节省了不少“补锅”成本，也就是“1-10-100”理论。
在设计阶段，花1块钱能解决的问题；留在制造阶段，要用至少10倍成本来纠错；如缺陷流出到顾客，则至少要花100倍成本来纠错。
但标准的制定和执行需要过程，需有序推进。这是关于产品质量和效率的权衡，值不值得我们花时间让它变得高质量，要聚焦目标和初心，是为了“60分”还是“100分”，优先处理最重要的事情，聚焦处理核心的需求。
在公司分享的最后环节，产品副总裁让大家挨个补充了所遇问题和感想，并针对每个槽点/问题，拆解了解决方案，让总结和分享并没有止步于会议。例如：
问题：评审没有“裁判”。
方案：定义关键要素的标准。增加打分标准。记录评审修改过程，进行评估，标准为评审次数、文档修改次数的有效归档、修改情况，利于复盘提升产品设计能力。
问题：评审没有“教练”。
方案：制定标准：原型中，写标准示例，建立知识库优秀案例
这样有自省能力和持续成长的组织，相信未来会更好。我也会继续努力，在此次总结后，梳理下出适合自身行业的PRD标准，持续优化自身和团队的输出质量及效率。望共勉之。
本文由 @wenda 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
