prd-writer

PRD 撰写工具

概述

PRD 撰写工具可指导产品经理创建清晰、可执行的产品需求文档，让团队围绕功能规格达成一致。它结合以用户为中心的设计、明确的技术说明和业务背景，确保功能成功实现。

何时使用此技能

• 定义要开发的新功能或产品
• 向工程团队传达需求
• 对路线图中的功能进行优先级排序
• 在开发前记录功能规格
• 向利益相关方传达产品愿景
• 为设计和 QA 团队创建规格说明

PRD 模板和结构

执行摘要

功能名称： [清晰、描述性强的名称] 负责人（PM）： [姓名] 利益相关方： [工程、设计、市场营销、法务等] 状态： [草稿、审核中、已批准、开发中] 最后更新： [日期]

愿景陈述： [用 1-2 句话描述总体愿景] 示例：“让用户能够实时协作处理项目，减少沟通成本并提升团队协同一致性。”

业务目标：

• 主要目标：[提高留存率／收入／效率]
• 可衡量目标：[指标提升 X%]
• 时间范围：[季度／年度目标]

要解决的用户问题： [描述此功能要解决的痛点] “用户目前每次都要花 30 多分钟开会，手动同步项目状态。此功能支持异步更新，可将会议时间减少 50%。”

成功标准：

• 采用率：[3 个月内采用该功能的用户比例]
• 参与度：[每周使用该功能的用户比例]
• NPS 影响：[目标为 NPS 提高 5 分]
• 收入：[MRR 增加 $X 或节省成本 $X]

---

用户故事和用例

主要用例：

用例 1：团队实时协作

• 参与者：[项目团队成员]
• 前置条件：[用户已登录，项目已打开]
• 主要流程：
  1. 用户更新任务状态
  2. 更新立即广播给团队
  3. 活动动态中显示通知
• 后置条件：[所有团队成员都能看到更新后的状态]
• 替代流程：[连接中断、离线模式]

用例 2：异步状态报告

• 参与者：[远程团队成员]
• 前置条件：[用户所在时区不同]
• 主要流程：
  1. 用户在任务中添加评论
  2. 评论显示在动态中
  3. 经理收到每日摘要
  4. 经理异步回复
• 后置条件：[无需同步会议]

用户故事框架

故事 1：查看实时更新

As a [project manager]
I want to [see live updates of task status]
So that [I can monitor progress without status meetings]

Acceptance Criteria:
- When a team member updates task status, I see the update within 2 seconds
- Status changes show in the main project view
- Activity timeline shows all updates with timestamps
- Notifications alert me to priority changes
- I can filter updates by assignee or task type

Definition of Done:
- Code reviewed and approved
- Unit tests pass (>80% coverage)
- QA tested on Chrome, Firefox, Safari
- Product Manager has signed off
- Updated help documentation

故事 2：接收活动通知

As a [team lead]
I want to [control which activities trigger notifications]
So that [I'm not overwhelmed with alerts]

Acceptance Criteria:
- Notification settings are accessible in preferences
- I can enable/disable alerts by activity type
- I can choose delivery method (in-app, email, Slack)
- Settings persist across devices
- Changes apply immediately

Definition of Done:
- Backend stores notification preferences
- Frontend UI implemented and tested
- Email delivery tested
- Slack integration verified
- Analytics event added for tracking

故事 3：移动设备通知推送

As a [remote employee]
I want to [receive notifications on my phone]
So that [I stay informed while away from desk]

Acceptance Criteria:
- Push notifications delivered to iOS and Android apps
- Notifications respect local time zone
- User can tap notification to jump to relevant item
- Notification includes context (project, task, change)
- Deep linking to specific feature works

Definition of Done:
- Push service integrated (Firebase Cloud Messaging)
- iOS and Android implementations complete
- Battery/battery testing on both platforms
- Deep linking tested on Android and iOS

---

详细规格

功能规格概述

功能名称： [名称] 范围： [包含的内容以及明确不包含的内容] 依赖项： [必须先存在的功能] 数据模型变更： [数据库架构更新]

功能需求

需求 1：实时状态更新

• 系统应在 2 秒内向所有项目成员广播任务状态变更
• 广播内容包括：任务 ID、新状态、先前状态、时间戳、执行变更的用户
• 系统应确保状态广播服务的正常运行时间达到 99.9%
• 系统应能处理每个项目最多 1,000 个并发状态更新

需求 2：活动动态显示

• 动态应按时间倒序显示所有活动
• 每条活动应包含：参与者、操作、对象、时间戳、上下文
• 动态应按每页 20 条进行分页
• 用户可以按以下条件筛选动态：活动类型、受派人、任务、日期范围
• 动态应在 1 秒内完成首次加载，分页加载应在 500 毫秒内完成

需求 3：通知推送

• 系统应在活动触发后 5 秒内发送通知
• 用户可以按活动类型选择通知方式：应用内、电子邮件、Slack、移动推送
• 通知应遵守勿扰时段（如已配置）
• 系统应批量处理通知，以避免通知疲劳（每小时最多 1 封电子邮件）

技术规格

技术栈：

• 前端：[React 18, TypeScript]
• 后端：[Node.js, Express]
• 数据库：[PostgreSQL]
• 实时功能：[WebSockets, Socket.io]
• 通知：[用于电子邮件的 SendGrid、用于移动设备的 FCM、Slack API]

API 端点：

POST /api/tasks/{taskId}/status
Updates task status, triggers broadcast

GET /api/projects/{projectId}/activity
Fetches activity feed with pagination

PUT /api/notifications/preferences
Updates user notification settings

POST /api/notifications/subscribe
Subscribes to WebSocket for real-time updates

数据库架构变更：

CREATE TABLE activity_feeds (
  id UUID PRIMARY KEY,
  project_id UUID REFERENCES projects(id),
  actor_id UUID REFERENCES users(id),
  action_type VARCHAR(50), -- task_updated, comment_added, etc.
  target_id UUID, -- task, comment, project
  target_type VARCHAR(50),
  changes JSONB, -- before/after values
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE notification_settings (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  activity_type VARCHAR(50),
  email BOOLEAN DEFAULT true,
  in_app BOOLEAN DEFAULT true,
  slack BOOLEAN DEFAULT false,
  mobile_push BOOLEAN DEFAULT true,
  dnd_start TIME,
  dnd_end TIME
);

---

UI/UX 规格

线框图说明

屏幕 1：动态消息流

[Header: "Activity"]
[Filter bar: Activity Type dropdown, Date range picker]
[Activity Item 1]
├─ [Avatar] [Name] [Action] [Context]
├─ [Timestamp] [2 hours ago]
└─ [Details: Task name, Previous → New status]

[Activity Item 2]
...
[Load more button]

屏幕 2：通知设置弹窗

[Header: "Notification Preferences"]
[Tabs: Delivery Methods | Do Not Disturb]

[Activity Type Toggles]
├─ Task Status Updated
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
│  ├─ Batch these notifications (dropdown: real-time, daily, weekly)
├─ New Comment
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
├─ Task Assigned to Me
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push

[Save] [Cancel]

设计考量

• 视觉层级： 动态消息项优先显示最重要的信息
• 渐进式披露： 点击条目可查看完整详情
• 无障碍性： 不仅使用颜色作为指示（状态变更时使用 ✓ + 颜色）
• 性能： 对大型动态消息流（1000+ 条）使用虚拟滚动
• 移动设备： 单列布局，便于触控的点击区域（最小 44px）

---

优先级框架：RICE

RICE 评分公式：（覆盖范围 × 影响力 × 信心度）/ 工作量

覆盖范围（3 个月内受影响的用户数）

• 示例：活跃用户的 80% = 8,000 名用户
• 范围：0-10,000+

影响力（这项变更对用户成果的影响程度）

• 极大（3x）：工作流得到巨大改善
• 高（2x）：效率显著提升
• 中（1x）：有明显改善
• 低（0.5x）：略有改善

信心度（我们对估算结果的信心程度）

• 高（100%）：基于客户数据/使用模式
• 中（75%）：部分用户反馈，部分假设
• 低（50%）：推测，需要验证

工作量（实现所需的人周数）

• 小：1-2 周
• 中：3-4 周
• 大：5-8 周
• XL：8+ 周

RICE 计算示例：

• 覆盖范围：8,000 名用户
• 影响力：2x（高）
• 信心度：75%
• 工作量：4 周

RICE 评分 = (8000 × 2 × 0.75) / 4 = 3,000

---

替代优先级方法：MoSCoW

必须具备（缺少该功能则无法完整发布）

• 实时状态更新
• 活动通知系统
• 通过电子邮件发送通知

应该具备（重要，应在首次迭代中发布）

• 移动推送通知
• 通知设置/偏好
• 动态消息流筛选
• 免打扰时间安排

可以具备（锦上添花，可在未来迭代中实现）

• Slack 集成
• 自定义通知批处理
• 高级活动分析
• 活动时间线可视化

不会实现（明确不在范围内）

• 短信通知
• 语音通知
• 通知日历集成

---

时间线与发布规划

阶段 1：MVP（4 周）

• 实时状态广播（WebSocket）
• 动态消息流（基础显示）
• 电子邮件通知
• 核心通知设置
• 发布： 目标为季度末

阶段 2：增强（3 周）

• 移动推送通知
• 高级筛选与搜索
• 免打扰时间安排
• 活动分析
• 发布： 下一季度开始后 2 周

阶段 3：集成（4 周）

• Slack 集成
• 日历同步
• 通知自定义界面改进
• 发布： 季度中期

---

成功指标

采用情况：

• 功能可发现性：60% 的用户在 30 天内发现该功能
• 初始启用率：40% 的用户在第 1 周内至少发送一条通知
• 每周活跃用户：到第 3 个月时，70% 的用户每周使用该功能

参与度：

• 每日活跃用户：50% 的活跃用户每天使用
• 动态消息流浏览量：平均每位用户每天浏览 8 次
• 通知打开率：已送达通知中有 35% 被打开

业务影响：

• 时间节省：用户反馈状态检查时间减少 30%
• 会议减少：每周平均会议时长减少 15 分钟
• 留存率：使用该功能的用户，其 12 个月留存率高出 10%

质量指标：

• 通知送达率：成功送达率为 99.9%
• 延迟：95% 的更新在 2 秒内送达
• 错误率：操作出错率低于 0.1%

---

风险与缓解措施

风险	影响	概率	缓解措施
WebSocket 扩展性问题	高	中	发布前使用 10K 并发用户进行负载测试
通知过多导致用户选择退出	高	中	默认启用智能批处理和免打扰模式
移动应用通知权限	中	高	在请求权限前清晰说明其好处
Slack 集成延期	低	中	首先在不集成 Slack 的情况下构建，第 2 阶段再添加

---

PRD 审批清单

• 用户故事清晰且可测试
• 验收标准全面
• 工程团队已确认技术可行性
• 设计模型已审核并批准
• 成功指标已定义且可衡量
• 时间安排合理且已估算
• 已识别风险并制定缓解计划
• 依赖项已记录
• 已获得利益相关方的签字确认
• 设计、工程、QA、市场团队已审核 PRD
• 待解决的问题已解决
• 已准备好启动开发

交付成果

1. 完整的 PRD 文档 - 包含以上所有部分，共 15-20 页
2. 设计模型/线框图 - 高保真或详细的线框图
3. 技术规范 - API 契约、数据模型、架构
4. 用户故事与验收标准 - 可直接用于 JIRA 的格式
5. 成功指标仪表板 - 所有 KPI 的定义
6. 时间安排/路线图 - 分阶段发布计划
7. 风险登记表 - 风险与缓解策略