识别需求何时已经滑向方案

一句话提醒

还没把问题和目标分析清楚，就跳到具体功能，会把实现方式误当成需求本身。

为什么今天看它

• 面对‘加一个功能’或‘改一个按钮’的表达时，先把问题层和解法层拆开，才能看见流程、规则或协作方式等其他可能路径。

留一个问题

你正在讨论的一条需求，描述的是用户要解决的问题，还是已经预设了某个功能解法？还有哪些不同路径没有被比较？

参考思路

1. 1.先明确用户、场景、目标和当前真正受阻的环节。
2. 2.标记原始表达中已经带有的功能、流程或技术方案。
3. 3.把问题层与解法层分开，避免直接把方案当成需求。
4. 4.至少列出功能、流程、规则或协作方式等不同解决路径。
5. 5.比较各路径对目标、成本、边界和后续链路的影响后再定方案。

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