| name | requirement-analyzer |
|---|---|
| description | 把模糊的需求变成清晰、可交付、有价值的产品方案。五步法:用户-场景-问题 → 问题vs方案 → 价值判断 → 成功指标 → 交付文档。每一步都有模板和检查点。 |
| argument-hint | [原始需求描述] |
需求分析五步法 Skill
用途
拿到一个「需求」——用户提的、老板提的、销售提的、自己想的——这些需求往往是模糊的、矛盾的、甚至是错的。这个 Skill 帮你把它拆解成研发能实现、测试能验证、老板能判断的方案。
五步法总览
- 搞清楚「谁」在「什么场景」下遇到「什么问题」
- 把「问题」和「方案」分开
- 判断价值,决定做不做
- 定义成功标准
- 写出可交付的需求
第一步:用户 - 场景 - 问题
一句话模板:
「某类用户,在某场景下,遇到了某问题」
这句话写不出来,说明还没想清楚,先别往下走。
方法:
- 问:找提需求的人问清楚,他是谁、什么情况下遇到这个问题
- 看:去现场观察用户的实际操作,看他卡在哪
- 验证:把「用户-场景-问题」写成一两句话,拿去和用户确认
常见错误:把「用户」和「场景」混为一谈。「记笔记」这个需求,上班族在会议上记笔记,和学生上课记笔记,是两件不同的事。
第二步:把「问题」和「方案」分开
用户说出来的,往往不是问题,而是他脑子里想好的方案。
- 用户说「我要一个导出按钮」→ 这是方案
- 真正的问题是「我想把数据拿去别处分析」→ 这才是问题
追问三步:
- 这到底是问题还是方案?
- 如果是方案,它要解决的真正问题是什么?
- 回到问题上,还有没有更好的解法?
第三步:判断价值
用价值三问(详见 value-judge Skill):
- 体验好了多少?
- 替换成本多大?
- 值不值得投入?
价值为正 → 继续;价值为负 → 果断说不。
第四步:定义成功标准
没有指标的需求,等于没有目标。上线后你既不知道它好不好,也不知道怎么改。
- 过程指标:使用率、完成率、转化率(用户有没有用起来)
- 结果指标:留存、效率、投诉(用了之后有没有变好)
要求:指标要可量化、可归因。「提升体验」不是指标,「客诉率下降 20%」才是。
第五步:写出可交付的需求
需求文档固定包含:
- 背景与目标(为什么要做)
- 用户与场景(给谁用、什么时候用)
- 方案说明(正常流程 + 异常流程)
- 价值与优先级(价值三问的结论)
- 衡量指标(上线后看什么)
- 不做清单(明确这次不做什么)
关键:异常流程最容易漏,也最容易被研发问倒。网络断了、数据为空、操作到一半退出、多人同时操作——这些都要写。
输出模板
## 需求文档
### 背景与目标
- 为什么做:__________
- 达成什么:__________
### 用户与场景
- 用户:__________
- 场景:__________
- 问题:__________
### 方案说明
正常流程:__________
异常流程:__________(断网/空数据/并发/误操作…)
### 价值与优先级
- 体验好多少:__________
- 替换成本:__________
- 优先级:P0 / P1 / P2
### 衡量指标
- 过程指标:__________
- 结果指标:__________
### 不做清单
- 这次不做:__________
实战案例
需求:客服反馈「要一个订单备注功能」。
- 第一步:客服在交接班时,临时信息没地方记,导致发错货。用户明确、场景清晰、问题真实。
- 第二步:「加备注框」是方案,真正问题是「临时信息无法在订单上沉淀和交接」。
- 第三步:价值为正(信息断裂导致投诉,解决了就是真价值)。
- 第四步:备注使用率、交接相关投诉量。
- 第五步:文档里补了异常流程——断网提交、超长文本、多人同时编辑、误删恢复。
检查清单
- 「用户-场景-问题」一句话写清楚了吗?
- 用户说的是问题还是方案?追问到根上了吗?
- 价值三问算过了吗,结论是正的?
- 成功指标定好了吗,可量化吗?
- 异常流程写了吗,还是只写了正常流程?
- 不做清单写了吗?
