识别需求何时过早滑向方案

一句话提醒

没想清问题和目标就锁定功能做法，会把一种解法误当成需求本身。

为什么今天看它

• 讨论一旦从“我们该解决什么”直接跳到“做一个什么功能”，可选路径会被提前关掉，团队也容易错过流程、规则或协作层的更优解。

留一个问题

你当前收到的一句功能诉求，能否先改写成用户、场景、目标和痛点，而不出现任何具体功能名？

参考思路

1. 1.先还原客观问题、目标用户和发生场景。
2. 2.把具体功能或实现说法暂时拿掉，确认真正要改变的结果。
3. 3.列出功能、流程、业务规则和协作方式等多条可能路径。
4. 4.比较各路径解决核心问题的力度、代价和副作用。
5. 5.确定需求后再进入方案选择，而不是反过来为既定方案找理由。

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