需求 Backlog¶

retaintive 的需求收集、评估、排期工作流。所有外部进来的需求（客户、市场、销售、Demo 反馈、创始人、内部）都先进这里，按统一维度评分后再决定是否、何时进入开发迭代。

为什么需要这套流程¶

需求来源散：客户群、创始人、demo 后总结，没人统一管 → 容易丢、容易重复评估
排期决策靠拍脑袋：分不清哪个真急、哪个能拖、哪个其实没人关心 → 做错优先级
已确定要做的 spec 和还在评估的 idea 混在一起 → docs 越来越乱

这套流程把"评估"和"已决策"分开：

流动层（Google Sheets）：所有进来的需求，每天都在变。打分、排序、筛选、改状态。
稳定层（docs spec.md）：评估通过、确定要做的需求才升级成 product-design/{feature}/spec.md，进入 git 长期维护。

在哪里操作¶

操作	在哪
加新需求 / 改分数 / 换状态	Google Sheets（链接：待填）
看流程怎么用	本文件
看每期排期决策记录	`decisions/`
看已确定要做的 spec	`product-design/{feature}/` 下的 spec.md

Sheets 的优势：多人同时编辑、自动算分、Filter View、手机也能加。不要把 Sheets 数据回写到 markdown — 那是双倍维护成本。

评估维度（7 个）¶

每个需求按下面 5 个核心维度打分（1-5），剩下 2 个有空再补：

维度	1	5	说明
Reach 影响范围	单个客户	全部客户	受影响的店/用户数量
Revenue 收入影响	几乎无关	直接决定续约或新签	ARR / 续约 / 新签的影响
CSAT 满意度	没人在意	客户主动反复抱怨	NPS / 投诉 / 客户主动提及频次
Urgency 紧迫性	啥时候做都行	这周不做就完蛋	时间敏感度（合规/活动/客户最后通牒）
Effort 工作量	XS (<1d)	XL (>1mo)	T-shirt size：XS=1 / S=2 / M=3 / L=4 / XL=5
Risk 风险（可选）	完全确定	高度不确定	技术风险 + 需求是否真实存在

派生分¶

Sheets 自动算（公式见模板）：

Value    = (Reach + Revenue + CSAT + Urgency) ÷ 4
Score    = Value ÷ Effort × (6 - Risk)

Score 越高越优先：高价值 / 低工作量 / 低风险 = 排前面。

第一遍只打 5 个核心分（Reach/Revenue/CSAT/Urgency/Effort），Risk 默认填 1，等评估深入再调整。

分类（Category）¶

每个需求只属于一类。Category 描述"这是什么活"，不是"重不重要"。

Category	颜色	含义	示例
`bug`	🔴 红	代码逻辑出错、计算不对、按钮无反应	Lead Funnel 总数算错
`data`	🟠 橙	源头数据问题（不是代码错）	Salesforce 同步漏 30% contact
`ui`	🟣 紫	视觉/排版/交互细节，不改流程	按钮对比度不够、tooltip 位置不对
`ux`	🔵 蓝	流程/信息架构改动，影响用户操作路径	Tasks 折叠改全展开
`feature`	🟢 绿	新功能或现有功能的实质扩展	Messages 页面、批量导出
`integration`	🟡 黄	第三方集成、API、数据管道	接 Stripe、Twilio webhook
`tech-debt`	⚫ 灰	重构/性能/可维护性，用户看不到	拆 12000 行的 HTML、build 优化

不同 category 走不同评估路径：

Category	默认流程	谁评审
`bug`	跳过 inbox，直接进 `evaluating`	工程同学
`data`	找数据源头 owner 确认	数据 + 工程
`ui`	截图改前/改后对比	产品 + 设计
`ux`	画 flow 或加注释，可能要改 spec	产品 + 创始人
`feature`	必须创始人确认是否符合战略	创始人 + 产品
`integration`	评估第三方 API 限制、成本	工程 lead
`tech-debt`	工程内部排期，不抢用户需求 capacity	工程 lead

价值层级（Tag）¶

经典 MoSCoW，独立于 Category，描述"该不该做 / 多急"。

Tag	含义
`must`	不做就崩 — 关键 bug、合规、客户最后通牒
`should`	该做 — 高价值、客户期待
`nice`	锦上添花 — 不做也行，效果好就做
`wont`	拒绝 — 写明原因，防止重复进 inbox

Category 和 Tag 是正交的。一个 ui 类需求可以是 must（登录按钮被遮挡），也可以是 nice（圆角再大一点）。

状态流转¶

inbox → evaluating → next      → done
                  └→ next+1   → done
                  └→ next+2   → done
                  └→ backlog → 再评估或 rejected
                  └→ rejected

状态	含义
`inbox`	刚收进来，未评估
`evaluating`	正在评估，可能要找客户/创始人确认
`next`	排到本期
`next+1`	排到下期
`next+2`	排到再下期
`backlog`	进 backlog 池，没具体排期
`rejected`	拒绝（写原因到 Notes）
`done`	已发布

三个高频动作¶

① 收集（随时）¶

往 Sheets 加一行： - ID 自增（R-001, R-002...） - Date = 今天 - Title = 一句话 - Source = 谁提的 - Status = inbox - Notes = 客户原话 / 上下文

Notes 用客户原话，不要加工。原话保留信息量，加工容易丢失关键信号。

② 每周分诊（15 分钟）¶

打开 Sheets 的 "Inbox 待评估" Filter View，把 inbox 状态的全部填完 5 个核心分数 + Category + Tag。

价值低 + 工作量高 → 直接 rejected
不确定 → evaluating，找客户或创始人确认
评估清楚 → evaluating（等排期会议决定哪期做）

③ 每期排期会（迭代前 30-60 分钟）¶

打开 Sheets 的 "高分待排" Filter View（Score > 8 AND status=evaluating），从高到低塞进 next，直到本期 capacity 满。

写一份 decisions/2026-QX-iteration.md 记录决策： - 本期选了哪些（带 Score） - 哪些被刷掉了（为什么） - 总 capacity 多少 / 已排多少

迭代结束后把 next 改 done。

升级到 spec¶

某个需求一旦决定要做（status=next），需要写实现细节时：

在对应 feature 文件夹下创建 spec：product-design/{feature}/{name}.md
把 Sheets 那一行的 Spec Link 列填上 docs 链接
开发参考 spec.md，不再回头看 Sheets 那一行

Sheets 只装"待决策" + "排期中"的东西，已经写了 spec 的需求不要再回到 Sheets。这样 Sheets 永远是流动的工作台，不会累积成历史档案。

Sheets 模板¶

模板文件 requirements-backlog-template.csv（和本 README 同目录）直接导入 Google Sheets：

新建 Sheets → 文件 → 导入 → 上传 CSV → 替换当前工作表
在 Score 列（M 列）填入公式：

=IF(OR(G2="",H2="",I2="",J2="",K2=""),"",((G2+H2+I2+J2)/4)/K2*(6-IFERROR(L2,1)))

往下拉。

设置 Conditional Formatting：
Score > 10 → 绿色背景
Status = next → 浅蓝背景
Tag = must → 加粗
Category 列按 7 种颜色染整行
设置 4 个 Filter View：
Inbox 待评估 — Status = inbox
本期排期 — Status = next
高分待排 — Score > 8 AND Status = evaluating
我的 — Owner = 当前用户

注意事项¶

不要把 Sheets 数据复制到 markdown — 双倍维护，必然会不同步
Notes 字段保留客户原话 — 加工过的描述会丢信息
拒绝时写明原因 — 防止同一个需求三个月后又被重新提
Score 是参考不是审判 — 创始人有权 override（写明 override 理由）
超过 50 行的 Sheets 该清理了 — done / rejected 超过一个月的归档到另一个 sheet