产品需求文档标准

一、背景
随着公司产品业务的快速发展和需求复杂度的不断提升，在产品研发协作中面临诸多挑战，主要体现在以下三个方面：

1. 理解不一致，沟通成本高： 在需求传递过程中，产品、开发、测试等不同角色对同一需求的描述和理解存在偏差。这种“认知偏差”导致在开发、测试阶段频繁出现返工与澄清，严重拖慢项目进度，并影响团队协作氛围。
2. 需求碎片化，缺乏全局视角： 各功能需求往往被孤立地设计和理解，缺乏对系统整体影响的评估。这导致项目上线后，发现不同功能模块之间相互影响、产生冲突，引发意料之外的线上问题，而非形成一个连贯、统一的用户体验。
3. 交付质量参差不齐： 由于缺乏统一的文档规范，需求描述的详略、侧重点完全依赖于产品经理的个人经验。这使得开发与测试人员难以建立稳定的预期，无法始终如一地交付高质量的产品功能。
   为解决上述问题，打破协作壁垒，降低因需求歧义导致的返工和风险，我们特制定本《产品需求文档标准》。本标准旨在为产品团队建立一个统一、清晰、无歧义的“协作语言”，确保从产品设计到开发测试的整个流程中，所有参与者对需求的理解保持一致，最终提升交付效率与产品质量。

二、目的与适用范围

1. 目的
   本文档旨在为产品团队建立统一的产品需求文档编写标准。通过规范PRD的结构、内容和格式，确保：
   • 清晰一致： 所有团队成员（研发、设计、测试等）对需求有统一、无歧义的理解。
   • 提高效率： 减少因需求不明确导致的返工和沟通成本。
   • 保证质量： 确保PRD覆盖了必要维度，是经过充分思考的完整产物。
   • 便于追溯： 为项目复盘、需求变更和知识传承提供依据。
2. 适用范围
   本标准适用于公司所有产品经理（含助理产品经理）在撰写任何正式项目或功能的产品需求文档时使用。

三、文档结构标准

1. 文档基本信息
   目的：确保文档可追溯、可管理，并清晰标识责任与版本状态。
   应包含内容：
   暂时无法在飞书文档外展示此内容

2. 背景与目标
   目的： 明确“为什么要做”，帮助团队理解需求的业务动机与价值。
   应包含内容：
   • 背景说明： 需求来源、业务问题、现状痛点。
   • 目标描述： 希望达成的业务或产品目标（可量化或定性）。
   • 成功指标： 衡量目标是否达成的指标（如转化率提升、时长降低等）。
   • 不在本次范围的事项： 明确边界，防止需求膨胀。

示例：
当前入驻流程复杂，用户完成率仅45%。本次需求精简了用户入驻流程，去除了E签宝相关内容，优化目标为将入驻完成率提升至70%。除商家入驻以外内容均不在本次需求范围。

1. 影响范围
   目的： 全面评估改动影响，避免“按下葫芦浮起瓢”的意外副作用。

   • 3.1 系统/模块影响：
   • 前端： 列出受影响的前端应用（如：经纪交易平台商家端H5, 经纪交易平台经纪公司管理后台，云商撮合平台）。
   • 后端： 列出受影响的后端服务（如：经纪交易平台商家端，经纪交易平台经纪公司管理后台，云商撮合平台）。
   • 数据： 说明是否历史数据处理、数据迁移或数据清洗需求。
   • 3.2 用户角色影响：
   • 说明本功能对不同用户角色（如：新用户、老用户、运营人员）的影响。
   • 3.3 关联业务影响：
   • 分析本功能是否会影响其他已有业务功能（如：积分体系、订单流程、客服动线）。
   • 3.4 依赖项：
   • 内部依赖： 是否依赖其他团队或模块的先行开发。
   • 外部依赖： 是否依赖第三方服务、API或数据。

2. 业务流程概述/用户故事概述
   目的： 以用户视角和可视化方式，描绘功能全景，便于各方理解。

   • 4.1 业务流程概述：
   • 使用流程图描绘核心业务的完整闭环，包括用户操作、系统判断和状态变迁和异常流程。
   • 示例：用户挂牌 -> 下单 -> 履约 -> 订单结算的完整流程。
   • 4.2 用户故事概述：
   • 采用 As a [角色], I want to [目标], so that [价值] 的格式，列出核心用户故事。
   • 可为每个用户故事标注优先级（P0/P1/P2）。

3. 功能需求说明
   目的： 无歧义地定义“做什么”，这是研发和测试的直接依据。
   建议按功能模块或用户故事进行拆分，每个模块应包含：

   • 5.1 界面原型/UI链接： 直接嵌入或链接至最终的设计稿。
   • 5.2 交互逻辑： 描述所有用户操作（点击、输入、滑动等）及系统的即时反馈（跳转、弹窗、动效、状态变化）。
   • 5.3 业务逻辑与规则：
   • 清晰描述业务判断条件、状态流图（如：优惠券的“未使用”、“已使用”、“已过期”）。
   • 定义计算公式、优先级、冲突解决策略（如：多优惠券叠加规则）。
   • 5.4 数据字段定义：
     暂时无法在飞书文档外展示此内容
   • 5.5 异常与边界情况：
   • 网络异常、数据为空、重复提交、操作失败等场景下的处理与用户提示。

4. 非功能性需求
   目的： 定义产品的“品质”要求，确保用户体验和系统稳健性。

   • 6.1 性能需求： 页面首屏加载时间、关键接口响应时间（P95、P99）。
   • 6.2 兼容性需求： 明确支持的浏览器及版本、操作系统及版本、设备分辨率等。
   • 6.3 安全性需求： 权限控制、数据脱敏、防刷机制等。
5. 里程碑与变更记录
   目的： 明确项目节奏，并严格记录需求变更，保证过程可追溯。
   • 7.1 项目里程碑：
     暂时无法在飞书文档外展示此内容
   • 7.2 变更记录：
     暂时无法在飞书文档外展示此内容

四、功能需求内容颗粒度标准
核心原则：“写到可执行，不写到可猜测”—— 每个模块必须达到的最低颗粒度要求（拒绝模糊表述）
“数据不量化、流程不闭环、交互无细节 → 文档不通过”

—— 用深度标准杜绝“我以为你懂”/“这是业内通用做法”的协作陷阱
业务流程通常可以拆分为两条线，一条是用户动作，一条是数据流。

1. 用户操作流颗粒度标准
   核心目标： 任何角色阅读后，都能在脑海中精确模拟出用户从购物车到下单完成的完整操作体验。
   • 1.1 任务流程颗粒度
   • 【粗颗粒度】： “用户可以从订单详情页下单。”
   • 【标准颗粒度】： 必须描述从入口到出口的完整闭环。
   • 用户在【购物车页】勾选商品并点击【结算】 -> 系统跳转至【订单确认页】，并自动定位到【收货地址】栏 -> 用户点击【收货地址】栏 -> 系统从底部弹出【地址列表】弹窗 -> 用户选择一条已有地址后，弹窗关闭，页面地址信息更新 -> 用户点击【提交订单】按钮 -> 系统跳转至【收银台】页面，并自动调起支付键盘。
   • 1.2 交互状态颗粒度
   • 【粗颗粒度】： “有个提交订单按钮。”
   • 【标准颗粒度】： 必须定义所有可交互元素的关键状态。
   • 默认态： 【提交订单】 按钮文案为“提交订单”，颜色为品牌蓝色，可点击。
   • 加载态： 点击后，按钮文案变为“正在提交...”，颜色变为灰色，且不可再次点击，并显示loading。
   • 异常态： 若提交时某个商品库存不足，页面顶部出现红色条幅提示“商品「XX手机」库存不足，请返回购物车修改”，按钮恢复为可点击的“提交订单”状态。
   • 1.3 反馈与提示颗粒度
   • 【粗颗粒度】： “提交订单时要检查库存。”
   • 【标准颗粒度】： 必须文案化或具象化所有用户提示。
   • 成功反馈： 跳转至收银台页面。
   • 库存异常反馈： 红色条幅提示：“商品{商品名}库存仅剩{数量}件，请返回购物车修改”。
   • 价格变动反馈： Toast提示：“商品{商品名}价格已更新，请确认后重新提交”。
2. 系统数据流颗粒度标准
   核心目标： 开发人员能明确知晓前端需传何参、后端需处理何逻辑、数据如何存储与变化。
   • 2.1 数据字段颗粒度
   • 【粗颗粒度】： “入驻用户需要填写企业信息。”
   • 【标准颗粒度】： 必须使用结构化表格定义关键对象的数据构成。
     暂时无法在飞书文档外展示此内容

• 2.2 业务规则颗粒度
  • 【粗颗粒度】： “提交订单时要检查库存和计算价格。”
  • 【标准颗粒度】： 必须使用条件语句或公式明确核心逻辑。

• 提交订单前置校验规则（后端）：

  1. 库存校验： 如果 (实时库存[skuId] - 预占库存[skuId]) < 购买数量[skuId] 则中断流程，返回错误信息 STOCK_NOT_ENOUGH 及具体SKU信息。
  2. 价格校验： 如果 |(前端传入的商品总价 - 后端实时计算的商品总价)| > 0.01 则中断流程，返回错误信息 PRICE_UPDATED 及后端计算的最新价格。
• 2.3 数据持久化颗粒度
  • 【粗颗粒度】： “创建订单时要保存数据。”
  • 【标准颗粒度】： 必须明确数据何时、如何被创建或更新。
• 当用户点击下单按钮时：
  1. 保存该订单数据相关信息。
  2. 保存当前订单关联的合约数据作为该订单的合约快照。
  3. 提交订单相关数据至云商。
  4. 云商保存订单相关数据。
  5. 云商保存订单关联的合约数据作为该订单的合约快照。
  6. 云商扣减相应库存并返回数据给经纪公司交易平台。
  7. 经纪公司交易平台扣减库存。
     符合标准颗粒度的PRD，其功能需求部分应能清晰地回答以下问题：
• 用户操作流： 用户在下单过程中每一步会看到什么？能做什么？系统会有什么样的视觉和交互反馈？
• 系统数据流： 每个用户操作背后，数据（商品、价格、库存）从哪里来，经过哪些处理和判断（校验、计算），最终到哪里去（生成订单、锁定库存）？

五、常见错误

1. 规范表述：使用精确的动作与目标

   • 【规范要求】 禁止使用无明确指向的业务目标动词（如“优化”、“提升”、“改善”）。必须使用精确的功能动作动词（如“新增”、“修改”、“删除”、“查询”），并明确修改的客体与目标。
   • 【反例】
   • 优化订单列表的查询效率。
   • 用户注册流程优化。
   • 【正例】
   • 新增订单列表的“订单号”查询筛选项。
   • 将用户注册流程从3步5个必填字段修改为2步3个必填字段。

2. 明确逻辑：独立定义业务规则

   • 【规范要求】 禁止使用“参照XXX逻辑实现”等模糊引用。需求必须完整、独立地描述自身的业务规则、计算逻辑与状态变迁。如与既有逻辑完全一致，也需明确声明。
   • 【反例】
   • 会员积分计算规则参照之前的等级体系实现。
   • 【正例】
   • 会员积分计算规则为：实付金额 × 会员等级系数。其中，普通会员系数为1.0，白银会员为1.1，黄金会员为1.2。
   • A字段无需改动，采用与B页面相同的原有逻辑：从用户配置文件中直接读取。

3. 消除模糊：使用确定性语言

   • 【规范要求】 禁止使用“可能”、“大概”、“等”、“诸如”一切可能产生歧义的模糊词汇。必须使用“是/否”、“必须/禁止/建议”、“当...时，则...”等具有明确布尔逻辑的表述。
   • 【反例】
   • 用户提交后，可能需要进行手机验证。
   • 列表页需要展示订单号、商品名等信息。
   • 【正例】
   • 当用户账户在陌生设备登录时，必须进行手机短信验证。
   • 列表页必须展示以下字段：订单号、商品名称、下单时间、订单状态。

4. 保证独立：需求内容需内聚与完整

   • 【规范要求】 单一PRD的需求范围必须内聚且完整。
   • 禁止在PRD中描述与本迭代无关的功能。
   • 禁止将同一功能的完整逻辑拆分至不同PRD中进行相互引用。
   • 禁止在不同用户故事或功能模块间进行不完整的逻辑交叉引用。每个用户故事的功能逻辑必须在本故事内形成闭环。
   • 【正例】
   • 所有与“经纪公司入驻”相关的创建、计算、状态更新逻辑，均应在《经纪公司入驻功能PRD》中完整描述，不得要求开发人员同时阅读另一份PRD才能理解。

5. 定义数据：明确字段规格

   • 【规范要求】 所有涉及数据存储、传输或显示的字段，必须明确其数据类型、长度、格式、取值范围与默认值。
   • 【反例】
   • 需要记录用户的公司信息。
   • 【正例】
   • 公司名称字段：
   • 类型： 字符串（string）
   • 长度： 最大100个字符
   • 默认值： 空
   • 规则： 用户输入，支持中英文、数字及部分符号（包括：!@#$%《》？-_）。

6. 覆盖场景：核心流程必须包含异常流程

   • 【规范要求】 核心功能需求说明必须包含异常流程设计，涵盖但不限于：网络异常、数据为空、操作失败、输入错误、服务降级等场景下的系统响应与用户提示。
   • 【反例】
   • 用户点击支付按钮，调用支付接口。
   • 【正例】
   • 主流程： 用户点击支付按钮，调用支付接口，跳转至收银台。
   • 异常流程1（网络超时）： 当接口请求超时（>10s），页面显示“请求超时”提示，并提供“重试”按钮。
   • 异常流程2（支付失败）： 当接口返回支付失败，以Toast形式明确提示用户失败原因（如“余额不足”）。
7. 描述闭环：同步说明前逻辑和数据流
   • 【规范要求】 任何涉及界面修改的需求，必须同步描述其背后的数据来源、状态处理等系统逻辑。禁止仅描述前端显示效果。
     【反例】
   • 经纪公司经纪商端增加一个“优质部门”模块。
     【正例】
   • 在经纪公司经纪商端新增“优质部门”模块，展示企业部门信息及部门状态。
   • 优质部门数据来源：展示当前经纪公司下部门的最新信息，数据与经纪公司经纪商端保持一致。
   • 编辑逻辑：编辑弹窗中默认带出部门名称、部门标签、部门状态、部门图片字段信息，其中部门图片需要显示图标大小和缩略图，来源于部门资料最新数据，但不包含正在编辑未提交数据。
   • 提交逻辑：编辑后保存信息更新至部门资料中心，页面刷新后展示最新状态。
   • 状态反馈：保存成功提示“修改已保存”，若保存失败则提示“保存失败，请稍后重试”。

附件一：快速自检

• 一句话自检：“如果我消失三天，开发和测试能不能完全靠PRD上线正确版本？”
  能=达标，不能=未达标。