2.0 KiB
2.0 KiB
颗粒度标杆与用户故事口径
用户故事:对齐「业务条线说明」页面
页面:/prototypes/lease-business-line-overview
数据:src/prototypes/lease-business-line-overview/lines.ts
每个能力卡片的产品叙述结构:
责任部门(roles)
→ 起点(start)
→ 怎么运作(process[],有序)
→ 关键结果(outcomes,可选)
→ 闭环(closure)
AutoPRD 第 4 章必须用同一套结构写用户故事,而不是「作为…我希望…」宽表。
示例(保险采购 · 交车合规,示意)
US · 保险有效才允许交车
- 角色:采购部、运维部
- 起点:采购或运营维护车辆交强险与商业险台账,作为交车前置合规数据。
- 怎么运作:
- 在保险采购维护一车一档险种台账(录入 / 识别 / 导入)。
- 交车时系统校验交强 + 商业是否均为正常或临期。
- 不合规则拦截交车并给出可理解原因。
- 关键结果:
允许交车/禁止交车 · 保险异常 - 闭环:交车合规与台账一致、可追溯;异常车辆不能进入履约运营。
- 排期(可选):US-17 · 规模 M · 作为采购/运维,我想维护交强+商业险并在交车时校验,以便不合规车辆无法交车。
反例(不要作为主叙述)
| 编号 | 用户故事 | SP |
|---|---|---|
| B1 | 作为运营,我能看到失败原因 | 2 |
↑ 信息太扁,缺少起点、协作步骤与闭环结果。
AutoPRD 其余层次(仍要对齐)
- 一句话 + 目标/非目标
- 模块边界(独立业务线写清「不自动同步」)
- 角色表(命名对齐业务条线)
- 用户故事:起点 / 怎么运作 / 闭环 + SP/规模
- 分模块正逆向
- 关键业务逻辑
- mermaid 流程图
- 验收清单
- 交付口径
刻意不写
- 表结构、接口、代码路径
- 用实现指令代替业务闭环描述