PRD 撰写

标准结构包括八个部分。一是文档信息（版本、作者、变更记录）；二是背景与目标（业务问题、用户痛点、预期指标）；三是用户与场景（目标用户、使用场景故事）； 四是需求描述（功能列表、业务流程图、页面原型与交互说明）；五是规则与逻辑（状态流转、边界条件、异常处理、权限）；六是非功能需求（性能、兼容性、数据埋点）； 七是优先级与排期建议；八是风险与待确认问题。核心原则是背景讲清为什么、流程图讲清怎么走、规则讲清所有分支。 异常流和边界条件的完整度最能体现 PRD 质量。

需求背景要回答三个问题：我们遇到什么问题（用数据描述现状，如购物车放弃率 68%）、为什么现在做（业务节点或用户价值）、做成后期望什么变化（可衡量的目标指标）。 深度标准是让不了解该业务的设计、研发、测试读完能理解为什么值得做，并且能对方案合理性提出质疑。 常见错误是只写「提升用户体验」这类不可衡量的表述，或直接跳到方案不谈问题。 好的背景自带优先级判断依据，评审时能大幅减少为什么做这个功能的争论。

因为正常流只覆盖理想路径，而线上事故大多发生在异常分支。PRD 若不写清楚，研发只能按自己理解实现，测试不知道该构造什么用例，最终以用户投诉的形式暴露。 需要覆盖的典型场景包括：网络失败与超时怎么提示、重复提交怎么防、并发操作（两台设备同时编辑）如何处理、权限不足、数据为空或超长的展示、逆向流程（取消、退款、撤回）。 例如优惠券需求必须定义过期、叠加、退款回退三件事。 面试时能主动列出某个功能的五六个边界场景，是经验的重要信号。

一是预沟通，提前与核心研发、设计、运营分别过一遍方案，把分歧在正式评审前解决，评审会只做决策确认。 二是自查清单，检查目标是否可量化、流程图是否闭环、异常分支是否覆盖、埋点是否规划、依赖方是否确认。 三是材料设计，文档提前 24 小时发出，附一页议程与待决策问题清单，让大家带着意见来。 四是控制范围，把大需求拆成多次评审，避免一次会议讨论三小时。 会后 24 小时内发出纪要，明确结论、变更与待办，评审才算闭环。

首先区分变更类型：澄清性补充（原意本就如此）走文档勘误；范围性变更（新增或修改功能）必须走变更流程，说明变更原因、影响范围、工期与成本影响，由 PO 和相关方确认后再实施。 管理手段包括：所有变更记录在变更日志（时间、提出方、原因、影响评估、结论）；影响大的变更需重新评估是否放入当前迭代； 分析变更根因，若是前期需求澄清不充分，就加强评审前置；若是外部业务真变化，属于正常敏捷响应。 原则是变更可以发生，但成本必须透明。