| 模块 | 关键信息 | 目的/提示 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | | **PRD 定义** | - Product Requirement Document，所有相关方的“书面沟通工具”<br>- PRD 本身也是一款“面向团队的产品” | 明确读者是谁：总监、TL、前后端、QA、UI 等 | | **阅读方诉求** | - 各角色最关心：**问题规模 → 解决方案 → 达成结果**<br>- 前端关心交互图、全状态；后端关心业务逻辑与流程；QA 关注边界 case | 写文档前先列“用户需求清单” | | **PRD 六大核心内容** | 1. **需求名称**：业务 + 变动动作 + 功能，如 “FLIGHT-59568 航班添加分亨功能”<br>2. **需求背景**：用数据度量“是什么、大小”<br>3. **需求目标**：拆成公式，可量化正负影响 <br>4. **需求方案**：最小可行产品 + 原型 + 重点/风险/外部依赖<br>5. **需求工时**：跨团队工时拆解 & 技术负责人确认<br>6. **数据/监控**：埋点规范 + 上线后实时监控 + 报警机制 | MEMC 原则：Message 清晰、Evidence 充足、Mapping 逻辑、Conclusion 明确 | | **流程节点** | - **idea FR** → **RDQA** → **需求 FR** → **排期** → **开发交付** → **后评估**- PM 作为 **owner**，对进度和方案负责 | 每个阶段都有明确目标与参与人 | | **RDQA 前-中-后** | - 会前：拉小会梳理疑点，列提纲<br>- 会中：记录问题与结论<br>- 会后：更新 PRD，确保“沟通记录”沉淀 | “记录 & 更新”是新人最易忽视的环节 | | **PRD 生命周期** | V1.0 雏形 → V2.0 初稿 → V3.0 中间稿（问题解决中）→ V4.0 终稿（工时确认）| 每版都应注明变更点，方便追溯 | | **后评估** | - T+2/T+7 拉数据，对比预估 VS 实际- 复盘：数据显著性、工期偏差、可沉淀方法论 | “生完孩子还要养”——上线后效果同样重要 | | **小 Tips** | - 让团队先认同目标再动手- 图/流程 > 大段文字- 文档形式可灵活，只要信息易获取- 建立“靠谱”人设，积极应对困难 | 增强文档可读性与个人影响力 | | **培训作业** | 1. **用户故事复盘**：听工单原声<br>2. **独立撰写 PRD**：包含指标与埋点<br>3. **导师批改 + 组内汇报** | 通过实操巩固所学 | --- # 一句话总结 这份 PPT 通过“**六大核心内容 + 明确流程节点 + 数据驱动**”的方法论，教你写出让所有协作方一目了然、能落地、可评估的专业 PRD，并强调 **沟通记录、数据监控与后评估** 是新人最容易忽视却决定项目成败的关键。