需求分析

一句话提醒

还没把问题和目标分析清楚就跳到解法，会过早缩窄选择空间。

为什么今天看它

• 这张卡能提醒你在需求沟通里先停在问题层，不要急着接功能方案。
• 它适合今天任何需要做取舍和判断的场景。

带着这个问题去工作

我今天讨论的需求里，有哪些表述其实已经偷偷从问题滑向了方案？

参考思路

1. 1.**先把问题层和解法层拆开。** 不要把具体功能直接当需求本身。
2. 2.**补足目标与约束。** 先搞清真正要解决什么，再谈实现形式。
3. 3.**保留多条路径。** 在锁定方案前，至少比较两种以上可能解法。

原文入口

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

记录只是收集输入，分析才是在业务里做结构化判断、分层和取舍。

为什么今天看它

• 这张卡能防止你把需求清单误当成需求判断。
• 它适合在今天的沟通里提醒自己多问价值和优先级，而不是只做搬运。

带着这个问题去工作

我今天接到的需求里，哪些只是被记录下来了，但还没有真正被分析？

参考思路

1. 1.**先把原始输入和判断动作分开。** 记录不等于已经得出结论。
2. 2.**补业务价值这一层。** 先问这件事为什么重要，而不是直接接方案。
3. 3.**做结构化取舍。** 把需求放进优先级、真假需求和边界里重新看。

原文入口

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

需求一旦脱离场景，就容易退化成抽象功能名词。

为什么今天看它

• 适合开会前提醒自己先补上下文。
• 能避免把记录需求误当成分析需求。

带着这个问题去工作

这个需求发生在什么具体场景里，是谁在什么条件下、为了什么目标，遇到了什么真实阻力？

参考思路

1. 1.先补场景中的人物、时机和目标。
2. 2.再补当前做法和痛点。
3. 3.最后才谈功能表达。

原文入口

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md