PRD
<h2>PRD</h2>
<h4>定义</h4>
<p>我们要做的事，具体会输出一个什么样的产品，我们如何实现它，如何将它推向市场</p>
<h4>PRD的价值</h4>
<ul>
<li>以文档的方式，向实施团队明确传达具体、完整的产品落地方案，确保团队的认知一致、有章可循、考虑全面，也能减少沟通成本</li>
<li>当产品方案有修改时，能及时记录在案，确保所有的变更有迹可循</li>
<li>作为产品历史迭代记录归档，以方便新人快速了解产品</li>
<li>检验产品经理的能力，体现产品经理的专业性</li>
</ul>
<h4>PRD撰写要求</h4>
<ul>
<li>足够完整：必要内容无遗漏，边界异常全覆盖，相关资源均到位</li>
<li>足够准确：名词概念无歧义，前后表述无偏差</li>
<li>足够清晰：更新记录足够清晰，文档结构足够清晰，方案说明足够清晰</li>
<li>足够简洁：多用图表，语言简练，结构化描述</li>
<li>足够稳定：实施前，充分确认；实施中，避免频繁变更；实施后，复盘优化</li>
</ul>
<h3>PRD文档的基本结构</h3>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=5149620cc54996afc5d52dd4a3352ffb&file=file.jpg" alt="PRD基本结构" title="PRD基本结构" /></p>
<h4>全局说明</h4>
<ul>
<li>【产品需求列表】：梳理当前版本，需要做哪些需求，以便于项目实施时有参考标准，避免遗漏 </li>
<li>【产品全局策略规则】：写清需要统一处理的文案格式、异常逻辑、默认数据展示规则等，避免重复说明和遗漏</li>
<li>【产品架构说明】：一表四图</li>
</ul>
<h4>功能需求说明</h4>
<p>定义：功能需求说明详细描述了产品锁设计的各个功能点，将整体框架拆成数个独立的功能模块，分别描述每个模块的背景、实现要求、业务流程、交互效果以及相关字段说明，为项目团队提供落地实施标准。</p>
<ul>
<li>【需求背景说明（非必填）】：说明当前需求功能模块的意义和价值，便于理解背景、统一认知</li>
<li>【实现功能说明】：可以由（使用者，前置条件，后置条件，业务规则(需求描述)）组成，业务规则必须填写，是为了说明当前需求模块具体要实现哪些功能，描述清楚策略和要求。</li>
<li>【业务逻辑和流程说明】：以流程图的方式，描述业务执行流程，说明需求逻辑，方便实施团队理解</li>
<li>【交互和界面说明】：以交互原型的方式，描述用户可见的界面交互逻辑，讲清楚不同条件下的界面显示策略</li>
<li>【字段说明（非必填）】：主要用于统计类、表单类、列表类等后台相关元素的字段说明，标语设计表结构 </li>
</ul>
<h4>非功能需求部分</h4>
<ul>
<li>【安全需求】：确保数据安全，防止隐私泄露，保障系统稳定性； 保密性，防泄漏，权限控制，防攻击防作弊；</li>
<li>【合规需求】：确保产品、业务遵循国家法律法规的相关规定，不涉及侵犯用户隐私权益、垄断条款</li>
<li>【性能要求】：确保产品使用的加载、响应时间满足用户期望的效果，避免崩溃。</li>
<li>【数据需求】：说明要在什么位置，触发什么行为时，记录什么数据，传输给服务端进行统计埋点</li>
<li>【可用和易用性需求】：让产品在特定场景下仍旧能保持一定容错和可用性，以提升用户对产品的信任度</li>
<li>【其他让产品顺利、高效运作的需求】</li>
</ul>
<h4>PRD如何收尾</h4>
<ul>
<li>上线检查</li>
<li>下线预案</li>
<li>运营准备</li>
</ul>
<h3>如何优化PRD阅读效率，让其形式更灵活？</h3>
<ul>
<li>把PRD融合到原型中</li>
<li>用Axure组织目录结构</li>
<li>把需求和原型绘制到一起</li>
</ul>